DevOps Builder 0.26.0

Ajouté

• Capacité « CDN et pare-feu applicatif » (huitième et dernière de la feuille de route 1.1) : Amazon CloudFront avec AWS WAF, Google Cloud CDN avec Cloud Armor, Azure Front Door avec son pare-feu, Scaleway Edge Services avec son WAF (OVHcloud et Outscale n'ont pas de CDN). Le CDN se place devant le répartiteur de charge du projet, sinon devant les machines de la production, sinon devant l'hôte donné dans la brique (origin) ou la variable cdn_origin. Le pare-feu bloque les attaques courantes et limite le débit par adresse (réglable) ; la mise en cache est coupée par défaut (cache = standard pour l'activer). Chez AWS le pare-feu est créé en us-east-1 par un second fournisseur aliasé ; chez Google un certificat géré s'ajoute si un domaine est donné ; chez Azure les règles gérées Microsoft demandent l'offre Premium ; chez Scaleway la brique exige un répartiteur de charge (règle R29). Quatre piles de référence cdn-*.
• Capacité « chiffrement (KMS) » (septième de la feuille de route 1.1) : AWS KMS, Google Cloud KMS, Azure Key Vault (clés) et Scaleway Key Manager (le KMS d'OVHcloud se commande hors de la pile, Outscale n'a pas de brique). La pile crée une clé à rotation automatique et la donne en sortie. Chez AWS, la clé chiffre les disques des machines, Amazon RDS, ElastiCache, les files SQS (à la place du chiffrement géré) et les secrets de Secrets Manager ; chez les autres clouds le rattachement aux ressources reste à faire (une note le dit). Cinq piles de référence kms-*.
• Capacité « fonctions serverless » (sixième de la feuille de route 1.1) : AWS Lambda, Google Cloud Run functions, Azure Functions et Scaleway Serverless Functions (OVHcloud annonce son offre, Outscale n'en a pas). Une fonction par environnement avec son déclencheur HTTP public (URL de fonction chez AWS, accès public chez Google, application de fonctions chez Azure) ; la pile la crée avec un code de remplacement (Python ou Node.js) et ne le réécrit plus, la CI déploie le vrai code (zip chez AWS et Azure, gcloud functions deploy chez Google). Chez Scaleway la fonction est créée sans code (brique « expérimentale »). Le fournisseur hashicorp/archive est ajouté pour AWS et Google. Quatre piles de référence fonctions-*.
• Capacité « file de messages » (cinquième de la feuille de route 1.1) : Amazon SQS (avec file des messages morts), Google Cloud Pub/Sub, Azure Service Bus, Scaleway Queues et OVHcloud Kafka (Outscale n'a pas de file). Une file (ou un sujet) par environnement, nommée d'après la brique, conservation de 1 à 7 jours ; l'adresse de chacune sort de la pile (queue_<environnement>_url) et une note dit de la donner à l'application (QUEUE_URL). Cinq piles de référence file-* ; OVHcloud reste « expérimental ».
• Capacité « cache managé » (quatrième de la feuille de route 1.1) : Amazon ElastiCache (Valkey), Google Cloud Memorystore (Redis), Azure Cache for Redis, Scaleway Managed Redis, OVHcloud Valkey (Outscale n'en propose pas). Le cache est une base managée de la famille clé-valeur : une instance par environnement, connexion TLS (rediss://), jeton ou clé générés, URL rangée comme celle d'une base — dans le coffre du cloud (AWS, Google Cloud, Azure) ou en variable CI. ElastiCache se place dans les sous-réseaux privés du projet, sinon dans le réseau par défaut (lu une seule fois, avec le répartiteur). Le poste de développement lance un conteneur Valkey ou Redis. Cinq piles de référence cache-* ; OVHcloud reste « expérimental ».
• Capacité « DNS » (troisième de la feuille de route 1.1) : Amazon Route 53, Google Cloud DNS, Azure DNS et Scaleway Domains and DNS (OVHcloud hors Public Cloud et Outscale n'ont pas de DNS : pas de brique). La brique reçoit le domaine, le nom de l'enregistrement et la durée de vie ; la pile écrit la zone (sauf chez Scaleway, où le domaine existe déjà) et un enregistrement A par groupe de machines, vers le répartiteur de charge du projet s'il existe (alias chez AWS), sinon vers les machines. Les serveurs de noms sortent de la pile (dns_name_servers) pour la délégation chez le registrar. Sur Kubernetes, seule la zone est écrite (les enregistrements viennent du Service ou d'external-dns).
• Cinq piles de référence dns-*.
• Capacité « répartiteur de charge » (deuxième de la feuille de route 1.1) : une brique par cloud — Amazon Elastic Load Balancing (NLB), Google Cloud Load Balancing, Azure Load Balancer, Scaleway Load Balancer, OVHcloud Load Balancer, Outscale LBU — qui place un répartiteur TCP devant chaque groupe de machines créé par la pile (ports web, sonde TCP, Traefik garde le TLS). L'adresse est une sortie lb_<groupe> : le DNS pointe vers elle. Sur AWS et Outscale, le répartiteur utilise le réseau privé du projet s'il existe, sinon le réseau par défaut. Sur Kubernetes, aucune ressource n'est écrite : le Service ou l'entrée demande le répartiteur au cloud (une note le dit).
  • OVHcloud (fiche expérimentale) : répartiteur, pool et écouteurs sur le réseau privé (la règle R29 l'exige) ; les machines ne sont pas encore sur ce réseau, leurs adresses sont à ajouter au pool à la main. Outscale : fiche expérimentale, non essayée sur un compte.
• Six piles de référence repartiteur-machines-*.
• Capacité « réseau privé » (première de la feuille de route 1.1) : une brique par cloud — Amazon VPC, Google Cloud VPC, Azure Virtual Network, Scaleway VPC, OVHcloud Private Network, Outscale Net — qui crée le réseau une fois dans la pile OpenTofu (sous-réseaux calculés dans la plage choisie) et le rattache aux clusters, aux machines et aux bases du projet. La palette ne propose que la brique du cloud du projet.
  • AWS : sous-réseaux publics (machines) et privés (EKS, RDS) sur deux zones, passerelle NAT selon le choix (auto = seulement avec EKS), groupe de sous-réseaux et groupe de sécurité de la base. Les quatre variables saisies à la main (vpc_id, subnet_ids, db_subnet_group, db_security_group_ids) disparaissent.
  • Google Cloud : réseau et sous-réseau pour GKE et les machines, Cloud NAT au choix, Cloud SQL en adresse privée.
  • Azure : un seul réseau virtuel pour les machines, AKS (Azure CNI) et le serveur flexible (sous-réseau délégué, zone DNS privée).
  • Scaleway : réseau privé rattaché à Kapsule, aux instances et à la base managée.
  • OVHcloud (cluster seulement) et Outscale (machines) : fiches expérimentales, non essayées sur un compte.
• Scénarios aws-ec2-chaine et aws-ecs-floci : le VPC est créé par la pile jouée sur Floci.
• Cinq piles de référence avec cluster et base, six avec machines (reseau-prive-*), passées à tofu validate avec les providers par la CI.
• Scénario aws-ecs-floci : la pile du modèle AWS ECS Fargate (ECR, RDS PostgreSQL, Secrets Manager) appliquée sur Floci. La suppression de la base RDS ne se termine pas dans Floci : le scénario borne le destroy à quatre minutes.
• Scénario kind-plateforme : une deuxième instance nommée de Grafana, SonarQube, Jenkins, Gitea, Zot et Jaeger ; chaque option --set est contrôlée contre les valeurs du chart (clé plate à point non échappée), et le Service rendu de chaque instance contre celui qu'attend le routage.

Corrigé

• Argo CD derrière l'entrée : l'option configs.params.server.insecure n'avait aucun effet, la clé du chart étant plate (server.insecure) ; elle est écrite configs.params.server\.insecure.
• SonarQube : le Service du chart est <release>-sonarqube (et non sonarqube), ce qui concerne la route Gateway API.
• Argo CD : le Service du chart est argo-cd-argocd-server, pour la route Gateway API.
• scripts/tf-floci.sh crée le groupe de sous-réseaux RDS que la pile suppose existant, et rend la base jetable (sans protection contre la suppression ni instantané final) : l'apply d'une pile avec RDS passe sur Floci.

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.25.1

Ajouté

• Scénario aws-ec2-chaine : le modèle AWS EC2 joué sans compte cloud. La pile OpenTofu est appliquée sur Floci, scripts/tf-inventory.sh relit l'état gardé pour écrire l'inventaire, puis site.yml et deploy.yml d'Ansible s'exécutent par SSH, l'application répond derrière Traefik et se rejoue sans échec, avant le destroy.
• TF_DIR pour scripts/tf-inventory.sh : lire la pile d'un autre dossier que infra/terraform.

Corrigé

• ansible/site.yml n'utilise plus les variables de faits injectées (ansible_os_family, ansible_distribution…), dépréciées depuis ansible-core 2.19 et retirées plus tard : ansible_facts['os_family'] à la place. Relevé par le scénario aws-ec2-chaine.

Modifié

• KEEP=1 scripts/tf-floci.sh apply garde aussi le dossier de travail (l'état local) et l'indique.

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.25.0

Ajouté

• Scénario de bout en bout compose-bases-dediees : Gitea sur PostgreSQL, Grafana sur MariaDB et une seconde instance de Grafana sur PostgreSQL, derrière Traefik en HTTPS ; santé de l'application et tables créées dans chaque base vérifiées chaque nuit.
• Exécutable macOS Intel (macos-x86_64) dans les publications, avec attestation et somme SHA-256.

Modifié

• Feuille de route : état des versions 0.21 à 0.25 et liste de ce qui reste avant la 1.0.

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.23.0

Gitea, SonarQube et Grafana peuvent avoir leur propre PostgreSQL, sur l'hôte Docker comme sur Kubernetes.

Ajouté

• Base PostgreSQL dédiée par outil : paramètre « Base de données » (integree par défaut, postgresql) sur Gitea, SonarQube et Grafana, par instance. Hôte Docker : un service <outil>-db avec son volume, son mot de passe dans deploy/secrets.sh (variable <OUTIL>_DB_PASSWORD) et une dépendance « healthy ». Kubernetes : platform/db-<outil>.yaml (Cluster CloudNativePG avec l'opérateur, sinon StatefulSet et Secret tiré à l'installation) et les options Helm qui branchent le chart sur cette base. Sans ce choix, rien ne change. Les clés Helm suivent la documentation des charts et sont à vérifier à la première installation.

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.22.0

Les adresses IP sont signalées là où elles ne marchent pas, et un registre auto-hébergé sans HTTPS est déclaré sur les clients qui le refusent par défaut.

Ajouté

• Adresses IP : la règle R56 avertit quand l'adresse publique d'un outil, celle de l'application ou le
  domaine des outils est une adresse IP (refusée par un Ingress, sans certificat Let's Encrypt, une IP ne pouvant
  pas porter plusieurs noms). Les registres, eux, peuvent être une IP.
• Registre auto-hébergé en HTTP simple (Harbor, Zot, Distribution sur une IP ou localhost) : les hôtes Docker
  déployés par Ansible reçoivent insecure-registries (/etc/docker/daemon.json fusionné sans perte, Docker
  redémarré si le fichier change), k3s reçoit deploy/registries.yaml, et une note explique le réglage à faire
  côté CI (Docker, BuildKit, Kaniko, podman).

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.21.0

Douze pipelines complets, prêts à ouvrir et à ajuster : un Kubernetes managé pour chacun des six fournisseurs du
catalogue, et des variantes sans Kubernetes ; un écran d'accueil qui dit par où commencer. Avec Traefik sur hôte Docker, les interfaces web passent derrière lui : les fichiers générés de ces projets changent (voir « Modifié »).

Modifié

• Outils derrière Traefik (hôte Docker avec Traefik) : Grafana, SonarQube, Jenkins, Gitea, console MinIO,
  interface Jaeger et registres Zot / Distribution ne publient plus leur port sur l'hôte ; ils sont servis en HTTPS
  par Traefik, à l'adresse <outil>.<domaine des outils> ou au paramètre « Adresse publique » (hostname) de la
  brique. Prometheus et Loki, sans authentification, ne sont plus publiés du tout (Grafana les interroge sur le
  réseau Compose). Restent publiés les ports « machine » : OTLP (Jaeger, collecteur), SSH de Gitea, API S3 de
  MinIO. Sans Traefik, rien ne change. Le plan de ports, R39 et la vue Réseau suivent.

• Entrée Kubernetes (Traefik, ingress-nginx, Envoy Gateway) : jusqu'ici, le contrôleur d'entrée était installé
  mais rien n'était routé. Le chart Helm (templates/ingress.yaml) et les overlays Kustomize (ingress.yaml)
  créent désormais l'Ingress de l'application, un nom d'hôte par environnement (paramètre « Adresse publique de
  l'application », maintenant aussi sur Kubernetes et sur ingress-nginx et Envoy Gateway), et platform/install.sh
  place Grafana, SonarQube, Jenkins, Gitea, Zot, Harbor, Argo CD, Argo Workflows et Chaos Mesh derrière le contrôleur (classe traefik ou nginx). Avec Envoy
  Gateway, qui n'a pas d'Ingress : une HTTPRoute par application (chart ou overlay) et platform/gateway.yaml
  (GatewayClass, Gateway HTTP, routes des briques). Jaeger, dont le chart n'a pas de réglage d'Ingress fiable, a le
  sien dans platform/ingress.yaml. Argo CD derrière l'entrée parle en clair (configs.params.server.insecure).
  HTTPS quand cert-manager est dans le pipeline : platform/cluster-issuer.yaml (ClusterIssuer Let's Encrypt,
  challenge HTTP-01 ; contact facultatif : paramètre « Contact Let's Encrypt »), Ingress de l'application et des
  briques avec tls et l'annotation cert-manager, et, avec Envoy Gateway, un listener HTTPS par nom d'hôte sur la
  Gateway (cert-manager installé avec la Gateway API activée). R54 (information) propose d'ajouter cert-manager
  à une entrée Kubernetes restée en HTTP. Chaque nom d'hôte doit pointer vers l'entrée avant l'émission (cert-manager) ; noms des Services à vérifier.
  Le contrôleur embarqué de k3s est reconnu. Les projets Kubernetes avec un contrôleur voient donc leurs fichiers
  changer et un avertissement R34 de plus (adresse d'exemple).

Ajouté

• Plusieurs instances d'un même outil : deux Grafana, deux Gitea, deux SonarQube… Chaque brique d'un outil
  « multi » porte un nom d'instance (champ instance, propriétés de la brique, demande à l'ajout). L'instance
  nommée a son service Compose (grafana-equipe-b) ou sa release Helm, ses volumes, son adresse, ses ports
  décalés sans entrée, son Ingress ou sa HTTPRoute et son certificat. Plan de ports et vue Réseau suivent. Règle
  R55 (nom invalide, doublon, outil à instance unique). Les projets existants ne changent pas.

• Modèles de pipeline par fournisseur (devops_builder/modeles.py) : AWS (EKS, ECS Fargate, EC2), Google
  Cloud (GKE, Cloud Run), Azure (AKS, machines virtuelles), OVHcloud (Managed Kubernetes, instances), Scaleway
  (Kapsule, instance Docker) et Outscale (SecNumCloud, machines). Chacun réunit les services du fournisseur
  (registre, base managée, coffre de secrets, supervision, état OpenTofu), la connexion de la CI au cloud et les
  contrôles de sécurité ; aucune erreur bloquante, seules les valeurs propres au projet restent signalées (R34).
  Menu Fichier › Nouveau depuis un modèle de fournisseur, et devops-builder template [modèle] -o projet.devops.yaml.

• Écran « Par où commencer ? » : un projet vide ne montre plus trois panneaux vides, mais cinq départs (assistant
  conseillé, modèle de fournisseur, exemple, projet enregistré, construction à la main) ; les panneaux viennent avec
  la première brique. Bandeau Prochaine étape (erreurs bloquantes, valeurs d'exemple à renseigner, dossier de
  l'application, génération). Audité dans les deux thèmes et à 200 %.

• Guide : page « Pipelines types par fournisseur cloud ». Douze projets de référence ajoutés aux tests, et le
  corpus de compatibilité des fichiers projet de la 0.20.

• Vue Réseau (Vues › Réseau, Ctrl+Maj+R) : le schéma d'un environnement en plan 2D ou en isométrique 3D, avec
  les flux et leurs ports, et les erreurs posées sur les composants (pastille de forme distincte par gravité, texte
  dans la liste « Composants et constats », correction applicable, accès à la brique) ; constats propres au réseau :
  service publié sans passer par l'entrée, application en HTTP simple, cluster sans point d'entrée ; export PNG.

Corrigé

• L'anneau de focus suit le contrôle quand le pipeline (ou tout parent) défile, et est rogné par la zone visible, au lieu de rester en l'air.

Modifié

• Barre d'outils réduite à Nouveau, Ouvrir, Enregistrer, Annuler, Rétablir et Valider (Paramètres et Générer sont
  dans l'en-tête du projet, le thème dans Affichage) ; les filtres du catalogue sont repliés sous « Filtres ».

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.20.0

Accessibilité de l'application vérifiée et corrigée, messages d'erreur en français, deux à trois fois plus
rapide sur un gros projet, et un guide de l'utilisateur avec quatre tutoriels. Les fichiers générés changent
pour l'hôte Docker avec Traefik (adresse publique de l'application par environnement).

Ajouté

• Audit d'accessibilité automatisé (devops_builder/ui/audit.py, tools/audit_accessibilite.py) sur la
  fenêtre principale, les onze dialogues et l'assistant, dans les deux thèmes : nom accessible, clavier, focus
  mesuré à l'écran, contrastes, titres, langue, raccourcis, texte coupé à 200 % ; critères de l'EN 301 549
  (WCAG 2.1 AA) et du RGAA en regard. Deux jobs de CI lisent l'arbre de l'application comme Orca (AT-SPI) et
  comme NVDA (UI Automation, Windows). État et limites : docs/accessibilite.md.
• Taille du texte réglable de 100 à 200 % (Affichage, Ctrl++ et Ctrl+-), retenue d'une session à l'autre ;
  à 150 % et plus, le nom du projet passe sur sa propre ligne, les messages des diagnostics se replient.
• Anneau de focus de deux pixels, au contraste vérifié, autour du contrôle actif.
• Annonces aux lecteurs d'écran : chaque message de la barre d'état ; l'ajout et le déplacement d'une
  brique disent l'étape et la position.
• Alt+↑ et Alt+↓ déplacent une brique dans son étape (le glisser avait seul cette possibilité).
• Guide de l'utilisateur (docs/guide/, site publié par GitHub Pages) : prise en main, clavier, et quatre
  tutoriels de bout en bout — hôte Docker, k3s en GitOps, Amazon EKS, souverain SecNumCloud sur Outscale. Un test
  vérifie que chaque fichier cité par un tutoriel est généré et que chaque paramètre à renseigner y est nommé.
• Adresse publique de l'application (brique Traefik, hôte Docker et machines virtuelles) : la production
  prend le nom saisi, les autres environnements un préfixe (staging.boutique.fr) sauf surcharge ; R34 tant
  qu'il garde sa valeur d'exemple, et le mode d'emploi liste les noms à faire pointer vers chaque hôte.
• R53 : cible d'hébergement inconnue (fichier modifié à la main), bloquante, avec les corrections.
• devops-builder projet.devops.yaml ouvre le projet dans l'interface.

Corrigé

• Accessibilité : textes de Qt en anglais (« Close », « Cancel », boutons des boîtes de message, menus
  contextuels) ; focus presque invisible sur la plupart des contrôles ; avertissements en orange à 3,5:1,
  boutons d'action à 2,8:1 et boutons principaux à 4:1 (4,5:1 et plus désormais) ; icônes d'étape exposées
  comme images sans nom ; zones de défilement et onglets sans nom.
• Hôte Docker avec Traefik : la règle visait <app>.example.com, identique dans chaque environnement ; la
  préproduction réclamait le certificat de la production.
• Messages d'erreur : un fichier projet qui n'est pas en UTF-8 arrêtait la ligne de commande sur une trace
  Python ; les erreurs du système (« [Errno 21] Is a directory »), de YAML (« mapping values are not allowed
  here ») et des commandes sont traduites, avec la cause et la piste ; une fiche personnelle illisible est
  signalée au lieu d'interrompre le chargement du catalogue.
• Validation : quand les playbooks échouent faute de collection Ansible, elle donne la commande
  ansible-galaxy collection install -r ansible/requirements.yml.

Performances

• libyaml pour écrire les fichiers générés et lire ou écrire le projet (texte identique sur les 183 projets de
  référence et 301 fichiers projet) : sur 167 briques et cinq environnements, évaluation des règles en 0,07 s
  au lieu de 0,23 s, génération en 0,17 s au lieu de 0,45 s, ajout d'une brique dans l'interface en 0,2 s au
  lieu de 0,3 s ; la suite de tests passe de 5 à 3,5 minutes. Un test garde ces temps.

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

DevOps Builder 0.19.0

S'installe sans cloner le dépôt : paquet PyPI ou exécutable autonome, chacun avec sa preuve de provenance.
Les fichiers générés ne changent pas.

Ajouté

• Paquet PyPI izinum-devops-builder (« devops-builder » y était déjà pris ; la commande reste
  devops-builder) : pipx install izinum-devops-builder. Sous pipx, les conseils d'installation des linters
  deviennent pipx inject izinum-devops-builder ….
• Exécutables sans Python pour Linux x86-64, Windows x86-64 et macOS Apple Silicon (DevOps Builder.app),
  construits par PyInstaller et éprouvés sur chaque système avant publication (version, check, generate,
  démarrage de l'interface). Non signés pour l'instant : le README dit comment passer SmartScreen et Gatekeeper.
  Leur dossier LICENCES joint la LGPL de Qt et PySide6 (bibliothèques remplaçables, adresses des sources), la
  licence de Python et celles des polices d'icônes (docs/licences-tierces.md).
• Attestations de provenance (SLSA, gh attestation verify) pour chaque exécutable et le paquet, et
  SHA256SUMS dans chaque publication ; le paquet PyPI porte aussi les attestations PEP 740.
• Workflow « Publication » : une version se publie depuis Actions, sans étiquette créée à la main ; il vérifie
  version, journal et étiquette libre, relance les tests, publie sur PyPI par publication de confiance (aucun
  secret stocké), puis crée l'étiquette et la publication GitHub avec les notes tirées du journal. Sur une branche,
  il construit et éprouve sans publier.
• CI complète : un job installe OpenTofu et un miroir des providers (tools/miroir_tofu.py), kubeconform,
  sops, age et Ansible ; chaque pile Terraform des projets de référence passe tofu validate, et un test sauté y
  fait échouer la CI. La CI tourne aussi sur les branches lot-*.

Corrigé

• Ligne de commande : une sortie redirigée sous Windows (page de code cp1252) ne s'arrête plus sur un caractère
  qu'elle ne sait pas écrire.
• Validation : quand les playbooks échouent faute de collection Ansible sur le poste, elle donne la commande
  ansible-galaxy collection install -r ansible/requirements.yml.

Installation : pipx install izinum-devops-builder ou l'exécutable de votre système ci-dessous (non signé, voir le README). Provenance vérifiable : gh attestation verify <fichier> --repo denvi44/devops-builder.

0.18.0 — Fermer les limites qui piègent

0.18.0 — 2026-10-15 — Fermer les limites qui piègent

Droits de la CI séparés, verrou d'état sur les clouds européens, connexion unique de Harbor et SonarQube, Renovate hors GitHub ; trois charts qui ne s'installaient pas (SonarQube, Loki) ou dépréciés (Grafana, Tempo), trouvés par le nouveau scénario kind-plateforme.

Ajouté
Deux identités de CI par cloud (AWS, Google Cloud, Azure, connexion OIDC) : les jobs d'infrastructure (plan, apply) prennent la leur, aux droits étendus (AWS_INFRA_ROLE_ARN, GCP_INFRA_SERVICE_ACCOUNT, AZURE_INFRA_CLIENT_ID) ; build et déploiement gardent une identité limitée à ce qu'ils font, déduit des étapes générées (pousser l'image, accéder au cluster, mettre à jour ECS, Cloud Run ou Container Apps, lire l'état). Avec GitHub, seul le plan ou l'apply obtient l'identité d'infrastructure ; avec GitLab, dont le jeton ne distingue pas les jobs, la séparation tient aux variables. Le mode d'emploi crée les deux. Ces droits réduits n'ont pas encore été éprouvés sur un vrai compte cloud.
EKS : accès Kubernetes du rôle de déploiement par entrée d'accès, administrateurs déclarés dans cluster_admin_arns (l'identité qui applique la pile change après le premier apply).
Renovate hors GitHub : job planifié dans GitLab CI (pipeline portant RENOVATE=1, les autres jobs exclus), workflow planifié pour Gitea Actions ; planification créée par l'API dans le mode d'emploi. Scénario gitea-renovate : Renovate lancé comme le workflow généré ouvre son tableau de bord et ses demandes de fusion sur une vraie forge Gitea.
Connexion unique de Harbor et SonarQube : Harbor reçoit ses réglages OIDC par le chart et son adresse publique ; SonarQube Community, qui ne parle pas OIDC, est relié à Keycloak en SAML (client et attributs dans le realm, réglages par l'API dans le mode d'emploi), vérifié jusqu'à la page de connexion de Keycloak ; avec Dex, son authentification GitHub ou GitLab intégrée. Sur hôte Docker, Grafana et SonarQube sont servis par Traefik à l'adresse que connaît le fournisseur d'identité.
Scénario kind-plateforme : platform/install.sh d'un projet à vingt-huit charts, chacun rendu avec les options générées et passé à kubeconform.
Verrou d'état Terraform sur Scaleway et OVHcloud (use_lockfile, écriture conditionnelle documentée par les deux) ; Outscale OOS reste sans verrou.
Corrigé
SonarQube ne s'installait pas sur Kubernetes : le chart exige l'édition (Community) et un code de sonde.
Loki ne s'installait pas sur Kubernetes : le chart exige un stockage ; disque du pod et schéma de test, stockage objet à poser en production.
platform/install.sh avec Dex s'arrêtait (set -u) quand le secret d'un client n'était pas encore renseigné.
Politique de confiance AWS de la CI avec GitLab : deux clés StringEquals, l'une écrasait l'autre (la condition sur l'audience du jeton disparaissait).
Elasticsearch de SonarQube sur hôte Docker sans vm.max_map_count à régler ; dimensionnement de SonarQube porté à 2,5 Gio (mesuré à 2,4 Gio au repos).
Mode d'emploi : les outils branchés sur la connexion unique ne citent plus Vault ou Argo CD absents du projet.
Mode d'emploi Argo CD : attente de la première synchronisation portée à dix minutes (un passage de bout en bout a dépassé cinq minutes).

0.17.0 — Vérification sur une vraie infrastructure

0.17.0 — 2026-10-15 — Vérification sur une vraie infrastructure

Les fichiers générés sont exécutés pour de vrai sur les machines de GitHub Actions (onze scénarios, chaque nuit) ; ces passages ont trouvé une dizaine de défauts, corrigés ci-dessous. Le déploiement réel sur un cloud (apply puis destroy) attend un compte de test et viendra dans une 0.17.x.

Ajouté
Tests de bout en bout (tools/e2e/run.py, workflow « Bout en bout ») : les fichiers générés exécutés pour de vrai sur les machines de GitHub Actions. Trois scénarios pour commencer : chart Helm avec CloudNativePG dans kind, overlays Kustomize avec PostgreSQL et Valkey dans kind, hôte Docker avec Compose, sauvegarde puis restauration. Une application de démonstration (tools/e2e/app) ne répond 200 sur /db que si chaque base accepte une connexion authentifiée avec les secrets transmis par le pipeline.
Second palier : OpenBao initialisé et configuré par les scripts générés puis lu par External Secrets (kind-coffre-openbao) ; Keycloak par son opérateur derrière Traefik, realm appliqué par OpenTofu puis relu sans écart, revendication groups vérifiée (kind-identite-keycloak). Preuves publiées en annotations.
Ajouté (suite)
Zabbix pris en charge sur hôte Docker et VM : images officielles 7.4 (serveur, interface web, agent 2) et base PostgreSQL dédiée, mot de passe par le circuit habituel (variables CI, SOPS ou coffre), interface derrière Traefik, section du mode d'emploi (mot de passe Admin à changer par l'API, agent vérifié). Keycloak, Dex et Zabbix apparaissent dans la vue Ports, et R39 signale leur conflit sur 8080 sans Traefik.
Fiches Puppet, Chef Infra, Elasticsearch, Kibana, Logstash, ZAP, Burp Suite DAST, CircleCI et Drone CI, au niveau « à configurer à la main » : dans la palette et contrôlées par les règles (rôle déjà tenu, licence, cycle de vie). Leurs entrées du CNCF Landscape mènent à la fiche. Règle R51 : Drone CI, repris par Harness, avec remplacement par Woodpecker.
Bases de Zabbix et de Keycloak sur l'hôte Docker sauvegardées et restaurées par db-backup.sh et db-restore.sh, comme celles de l'application.
Scénarios de bout en bout compose-sops (clé age, brique, secrets-seed.sh, puis les lignes mêmes de la CI générée) et sauvegarde-restauration de Zabbix.
ZAP pris en charge (DAST) : un job après le déploiement de l'environnement analysé (par défaut le dernier avant la production), avant le déploiement suivant, dans chaque CI générée. Scan de base (passif), complet ou d'API (OpenAPI) ; image officielle à version fixe (2.17.0) ; adresse analysée réglable par environnement ; .zap/rules.tsv généré (règles d'en-têtes et de cookies à FAIL) ; rapport HTML et JSON publié même en échec ; non bloquant par défaut, paramètre « Bloquant ». Section « Analyse dynamique » du mode d'emploi. Scénario de bout en bout compose-zap : le job extrait du workflow généré analyse l'application derrière Traefik, en root comme sur GitHub Actions et sous l'utilisateur de l'image comme sur GitLab CI.
Dimensionnement des machines : besoin de chaque hôte Docker calculé à partir des services du fichier Compose généré (application, bases, Traefik, Keycloak, Zabbix, SonarQube, Prometheus, Grafana…), multiplié par les environnements qu'il porte ; section « Dimensionnement » de PIPELINE.md ; pour les machines créées par Terraform, type retenu comparé au besoin et plus petit type suffisant proposé sur chacun des six clouds. Règle R52 (machine sous-dimensionnée) avec correction en un clic, par environnement quand les machines diffèrent. Valeurs par service dans data/sizing.yaml, sourcées quand une documentation les donne (Keycloak, Grafana, SonarQube), estimées sinon.
Scénarios de bout en bout kind-argocd (dépôt GitOps privé sur Gitea, Argo CD installé par platform/install.sh et branché par le mode d'emploi, job de déploiement de la CI joué dans alpine comme sur GitLab : l'étiquette poussée arrive dans le cluster, une relance sans changement ne casse rien) et compose-dex (découverte OpenID, connexion de l'application suivie jusqu'à la page d'autorisation de la forge, adresse de retour inconnue refusée). Un scénario seul se lance à la demande (entrée scenario du workflow).
Paramètre « Dépôt GitOps » des briques Argo CD et Flux, repris dans les applications, la source Flux et la variable GITOPS_REPO ; mode d'emploi Argo CD sans la CLI argocd (secret de dépôt étiqueté, attente de la synchronisation), jeton de lecture saisi sans écho.
Corrigé
GitOps (Argo CD, Flux) ne pouvait pas fonctionner tel que généré : le dépôt surveillé était une adresse d'exemple codée en dur ; la CI ne changeait que l'étiquette de l'image, si bien que le dépôt restait ghcr.io/OWNER/… (Helm) ou $CI_REGISTRY_IMAGE que Kustomize ne développe pas ; apk add yq est ambigu sur Alpine 3.20 (yq-go maintenant) ; un pipeline relancé échouait sur un commit vide ; avec le dépôt de l'application comme dépôt GitOps, chaque mise à jour relançait le pipeline (commits marqués [skip ci]). La source Flux reçoit le secret d'accès créé par le mode d'emploi.
Dex sur hôte Docker démarrait sans application OAuth : Compose remplaçait $DEX_CONNECTOR_ID et $DEX_CONNECTOR_SECRET de sa configuration par l'environnement du shell au déploiement, vide sur l'hôte, et DEX_CONNECTOR_ID n'était écrit nulle part. Les deux sont désormais lus par Dex dans secrets/dex.env. Le premier passage du scénario compose-dex réussissait parce que le harnais transmettait les secrets à docker compose up : il ne transmet plus que IMAGE, comme le déploiement par SSH.
Étapes non bloquantes (Checkov, KICS, Snyk, Infracost, Floci) : Tekton, AWS CodeBuild et Google Cloud Build arrêtaient le pipeline à leur échec ; elles sont maintenant tolérées (onError: continue, allowFailure, échec signalé dans le journal de CodeBuild).
Binaire sops non vérifié : la CI générée téléchargeait sops et l'exécutait, clé age en mémoire, sans contrôle ; son empreinte publiée est maintenant vérifiée (sha256sum -c) avant exécution.
Traefik sur hôte Docker ne faisait pas de HTTPS : aucune configuration TLS, le port 443 répondait en HTTP clair. TLS sur l'entrée websecure, certificat Let's Encrypt (challenge TLS), redirection du port 80, volume des certificats ; adresse ACME facultative (paramètre « Contact Let's Encrypt »). Trouvé en préparant les tests de bout en bout de l'hôte Docker.
Validation installée par pipx : les outils ajoutés à l'environnement de l'application (pipx inject devops-builder shellcheck-py) sont trouvés, alors qu'ils restaient « absents » ; le conseil d'installation propose pipx inject sous pipx ; un contrôle sans outil liste les fichiers générés qui le demandent (signalé lors du premier essai sur macOS).
Python 3.15 refusé à l'installation avec un message clair (requires-python), au lieu d'un échec de PySide6, dont les versions 6.11 ne vont pas au-delà de Python 3.14 (vu lors de l'installation sur macOS).
PySide6 limité aux 6.11 pour toutes les versions de Python : la 6.12.0 provoque aussi des erreurs de segmentation intermittentes sous Python 3.12 (vu sur la CI), pas seulement le plantage de sortie sous 3.11.
Keycloak sur Kubernetes ne démarrait pas, deux défauts trouvés par les tests de bout en bout : platform/install.sh n'installait pas les CRD keycloakoidcclients et keycloaksamlclients de l'opérateur 26.8, qui ne devenait jamais disponible ; et l'image officielle, désignée dans la ressource Keycloak, était lancée avec --optimized et s'arrêtait en boucle (startOptimized: false ajouté).