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.