Bienvenue dans cette revue hebdomadaire du Cloud et de l’Infrastructure as Code (IaC) !
haque semaine, nous décryptons les actualités, tendances et innovations majeures qui façonnent l’univers du cloud computing. À travers une sélection de sources fiables et spécialisées : blogs techniques, forums d’experts, réseaux sociaux et publications officielles nous vous proposons un résumé clair et structuré pour rester informé.

Avertissement : Contenu généré par IA avec MistralIA
Cet article a été généré automatiquement à l'aide d'une intelligence artificielle. Bien que nous nous efforcions d'assurer l'exactitude des informations, des erreurs ou imprécisions peuvent subsister.

Si vous constatez une erreur ou souhaitez signaler un problème, n'hésitez pas à me contacter :
Email : pro@sarquentin.fr
LinkedIn : Quentin Sar

Le résumé de la semaine

Cette semaine, nous avons exploré une variété de sujets passionnants dans le domaine du cloud et des infrastructures DevOps. Nous avons commencé par découvrir comment contrôler le routage des sessions pour les hôtes multi-IP dans Boundary, une solution qui permet de gérer dynamiquement les infrastructures cloud en synchronisant directement avec les fournisseurs de cloud comme AWS, Azure ou Google Cloud. Nous avons ensuite examiné comment HashiCorp Vault et Vault Radar travaillent ensemble pour répondre aux exigences de conformité PCI DSS 4.0.1, en sécurisant les secrets et en surveillant continuellement les expositions potentielles.

Nous avons également été introduits à HashiCorp Agent Skills, une nouvelle série de compétences spécialisées pour les produits HashiCorp, conçues pour améliorer les flux de travail d'infrastructure en fournissant des connaissances spécialisées et à jour. De plus, nous avons examiné la dernière version de Dragonfly, qui apporte des améliorations significatives en termes de performances et de fonctionnalités, notamment un nouvel algorithme de planification sensible à la charge et le support du protocole Vortex pour le transfert de fichiers P2P.

La Cloud Native Computing Foundation (CNCF) a célébré les stagiaires réussis du programme de mentorat LFX 2025 Term 3, mettant en lumière les contributions significatives de jeunes talents dans divers projets cloud natifs. Nous avons également exploré les différences entre l'OpenTelemetry Collector et l'agent, en fournissant des recommandations sur la manière de choisir la bonne approche de télémétrie pour votre environnement.

Enfin, nous avons découvert le Node Readiness Controller, une nouvelle solution pour gérer la disponibilité des nœuds dans Kubernetes, et nous avons examiné comment automatiser le FinOps sur AWS en utilisant Terraform et incident.io pour créer un module de surveillance des coûts. Ces articles offrent un aperçu complet des dernières innovations et meilleures pratiques dans le domaine du cloud et des infrastructures DevOps.

Contrôle du routage des sessions pour les hôtes multi-IP dans Boundary

Dans Boundary, un catalogue d'hôtes dynamique agit comme un système d'inventaire automatisé qui découvre et gère les cibles d'infrastructure en se synchronisant directement avec les fournisseurs de cloud, éliminant ainsi la nécessité d'entrées manuelles. Ce catalogue utilise des plugins pour interroger votre infrastructure en fonction de balises, ce qui permet de gérer efficacement les environnements dynamiques.

La gestion de ces infrastructures dynamiques implique souvent de traiter des hôtes disposant de multiples interfaces réseau et adresses IP. Par exemple, une instance EC2 sur AWS peut avoir une adresse IP publique, une adresse IP privée, et potentiellement d'autres attribuées à différents sous-réseaux. Pour les administrateurs de Boundary, il est crucial de s'assurer que les sessions se connectent à la bonne adresse IP, spécifiquement celle accessible par le worker de Boundary, afin de garantir la connectivité et la sécurité.

Conformité PCI DSS 4.0.1 avec HashiCorp Vault et Vault Radar

La norme PCI DSS (Payment Card Industry Data Security Standard) définit les exigences techniques et opérationnelles pour la protection des données de paiement. Avec la sortie de la version 4.0, les crédentiels statiques, les secrets codés en dur et le manque de visibilité dans les pipelines de développement ne sont plus seulement de mauvaises pratiques, mais représentent des risques d'audit qui pourraient entraîner des amendes importantes.

HashiCorp Vault et HCP Vault Radar travaillent ensemble pour aider les organisations à répondre aux exigences de la PCI DSS 4.0.1 en sécurisant les secrets au sein de l'environnement de données des titulaires de cartes et en surveillant continuellement les expositions potentielles tout au long du cycle de vie de la livraison de logiciels. Vault sécurise les secrets et le matériel cryptographique au sein des systèmes approuvés, tandis que Vault Radar détecte lorsque ces secrets fuient dans des endroits où ils ne devraient pas se trouver, comme les dépôts de code source, les pipelines CI/CD ou les outils de collaboration.

Introduction à HashiCorp Agent Skills

HashiCorp a récemment annoncé HashiCorp Agent Skills, un dépôt de compétences pour les agents et plugins Claude Code pour les produits HashiCorp. À son lancement, cette initiative inclut des compétences pour Terraform et Packer. Ces compétences fournissent aux assistants IA des connaissances spécialisées sur les produits HashiCorp, y compris les architectures des frameworks de plugins, les définitions de schémas et les meilleures pratiques à jour.

Le pack initial de compétences HashiCorp Agent Skills comprend des compétences qui peuvent suivre les conventions de style HashiCorp lors de la génération de code Terraform, écrire et exécuter des tests Terraform, créer des orchestrations avec Terraform Stacks, aider à construire des fournisseurs Terraform selon les meilleures pratiques, refactoriser des modules Terraform, et construire des images AWS, Azure et Windows avec Packer, entre autres.

Dragonfly v2.4.0 est sorti

Dragonfly v2.4.0 est sorti ! Cette nouvelle version apporte plusieurs améliorations et nouvelles fonctionnalités significatives. Parmi les nouveautés, on trouve un algorithme de planification sensible à la charge, un support pour le protocole Vortex pour le transfert de fichiers P2P, un SDK pour le routage des requêtes des utilisateurs vers les Seed Peers, une simplification du déploiement multi-cluster Kubernetes, des optimisations de performance et de ressources pour les composants Manager et Scheduler, et une prise en charge de la préchauffage basée sur les adresses IP.

De plus, la version 2.4.0 introduit le calcul de l'ID des tâches basé sur le hachage SHA256 des blobs d'images pour éviter les téléchargements redondants, la mise en cache des réponses HTTP 307 pour les téléchargements fractionnés, le remplacement du client Go par un client Rust, et plusieurs autres améliorations et corrections de bugs.

CNCF célèbre les stagiaires réussis du programme de mentorat LFX 2025 Term 3

La Cloud Native Computing Foundation (CNCF) a célébré les stagiaires réussis du programme de mentorat LFX 2025 Term 3, qui s'est déroulé de septembre à novembre 2025. Cette cohorte a vu des mentees travailler sur 27 projets différents, allant des projets Gradués aux projets Incubating et Sandbox, tels que Cilium, KubeArmor, KubeEdge, Kubernetes, OpenCost, et bien d'autres.

Les mentors et mentees ont travaillé sans relâche pendant trois mois pour améliorer le code, la documentation et l'engagement communautaire. Le programme LFX Mentorship continue d'être un pipeline vital pour les nouveaux contributeurs à l'écosystème cloud native, formant la prochaine génération de leaders open source.

Le meilleur de KubeCon + CloudNativeCon : Regardez la vidéo !

La Cloud Native Computing Foundation (CNCF) a lancé une nouvelle vidéo célébrant l'énergie, les personnes et la communauté qui font de KubeCon + CloudNativeCon un événement unique. La vidéo met en lumière la diversité des projets représentés, les moments personnels marquants pour les participants, et l'ouverture et l'accueil de la communauté.

Filmé lors de KubeCon + CloudNativeCon North America à Atlanta en novembre 2025, la vidéo invite les spectateurs à expérimenter la magie de l'événement. Alors que nous regardons vers le prochain chapitre du voyage cloud native, la CNCF ne peut pas attendre de voir la communauté se réunir à nouveau. À bientôt à Amsterdam !

OpenTelemetry Collector vs agent : Comment choisir la bonne approche de télémétrie

Alors que les architectures cloud native continuent de mûrir, l'observabilité est devenue une exigence fondamentale plutôt qu'un ajout optionnel. Selon la Cloud Native Computing Foundation, OpenTelemetry continue de faire croître sa base de contributeurs et reste le deuxième projet à la plus haute vitesse dans le CNCF, devenant le "kubernetes" du monde de l'observabilité.

Alors que les organisations standardisent sur OpenTelemetry, une question architecturale revient constamment : faut-il collecter la télémétrie en utilisant un OpenTelemetry Collector, un agent, ou une combinaison des deux ? Dans ce guide, nous démystifions le débat OpenTelemetry Collector vs agent, expliquons comment chacun s'intègre dans l'architecture OpenTelemetry, et vous aidons à choisir la bonne approche pour construire des pipelines d'observabilité efficaces et évolutifs.

Introduction au Node Readiness Controller

Dans le modèle Kubernetes standard, l'aptitude d'un nœud à accueillir des charges de travail repose sur une seule condition binaire "Ready". Cependant, dans les environnements Kubernetes modernes, les nœuds nécessitent des dépendances d'infrastructure complexes—telles que des agents réseau, des pilotes de stockage, des micrologiciels GPU ou des vérifications de santé personnalisées—pour être pleinement opérationnels avant de pouvoir héberger de manière fiable des pods.

Aujourd'hui, au nom du projet Kubernetes, nous annonçons le Node Readiness Controller. Ce projet introduit un système déclaratif pour gérer les taches des nœuds, étendant les garde-fous de disponibilité pendant l'amorçage des nœuds au-delà des conditions standard.

En gérant dynamiquement les taches en fonction de signaux de santé personnalisés, le contrôleur garantit que les charges de travail ne sont placées que sur les nœuds qui répondent à toutes les exigences spécifiques à l'infrastructure.

Automatisation du FinOps sur AWS : Comment nous avons construit un module de surveillance des coûts avec Terraform et incident.io

Gérer les coûts dans le cloud est un défi constant pour les équipes d'ingénierie. La discipline du FinOps vise à apporter une visibilité et une responsabilité à ces dépenses, mais sans les bons outils, il est facile d'être surpris par la facture en fin de mois.

Dans cet article, je partage l'expérience et les détails techniques de la création d'un module Terraform réutilisable pour automatiser les alertes budgétaires sur AWS, en s'intégrant directement avec les outils de gestion des incidents (dans ce cas, incident.io), éliminant ainsi les intermédiaires inutiles comme les fonctions Lambda à cette fin spécifique.

Déploiement de Stategraph sur AWS avec Terraform - Partie 1

Si vous suivez l'espace Infrastructure as Code, le nom de Josh Pollara vous est probablement familier. Bien que je n'aie pas personnellement essayé terrateam, j'ai suivi ce que lui et ses cofondateurs construisent. L'une des questions les plus courantes que je reçois de la part des clients utilisant Terraform concerne la gestion de l'état. La plupart des déploiements AWS par défaut utilisent S3 comme backend (avec DynamoDB pour le verrouillage dans les versions de Terraform antérieures à 1.10). L'idée d'explorer un autre mécanisme dans l'espace de gestion de l'état m'a intrigué, surtout avec les promesses de plans plus rapides grâce à leur fonctionnalité Velocity à venir. La page First Principles vaut la peine d'être lue, et ceci m'a particulièrement marqué : "L'infrastructure est un graphe. Stockez-la sous forme de graphe."

J'ai commencé par leur implémentation backend en utilisant le quickstart Docker Compose. J'ai gardé les nuances de la nature transactionnelle des changements d'état et du suivi des métadonnées pour un futur article.

Économie, ce n'est pas de la chance, c'est de l'automatisation. Voyez comment j'ai surveillé les coûts sur AWS avec Terraform.

Cet article est une republication d'un article précédent sur l'automatisation du FinOps sur AWS, en se concentrant sur la création d'un module Terraform pour automatiser les alertes budgétaires sur AWS et les intégrer avec les outils de gestion des incidents.

Sources

• How to control session routing for multi-IP hosts in Boundary
• PCI DSS 4.0.1 compliance with HashiCorp Vault and Vault Radar
• Introducing HashiCorp Agent Skills
• Dragonfly v2.4.0 is released
• CNCF celebrates successful mentees from LFX Mentorship 2025 Term 3
• The Best of KubeCon + CloudNativeCon: Watch the video!
• OpenTelemetry Collector vs agent: How to choose the right telemetry approach
• Introducing Node Readiness Controller
• Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io
• Stategraph: Deploy on AWS with Terraform Part 1
• Economia não é sorte, é automação. Veja como monitorei custos na AWS com Terraform.