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, l'actualité du cloud et des infrastructures cloud native a été marquée par plusieurs annonces majeures. HashiCorp a dévoilé de nouvelles fonctionnalités pour Terraform, notamment le support natif des monorepos, les configurations de composants de Stack, et bien plus. La communauté Kubernetes a également partagé des mises à jour significatives, incluant la graduation de la fonctionnalité In-Place Pod Resize à stable dans la version 1.35, ainsi que des améliorations de sécurité et des nouvelles fonctionnalités en version bêta. Le Cloud Native Computing Foundation (CNCF) a accueilli 12 nouveaux membres argent, soulignant l'importance croissante de l'observabilité et de l'automatisation. De plus, un audit de sécurité de KubeVirt a été publié, et des conseils pratiques pour construire une plateforme d'observabilité rentable avec OpenTelemetry ont été partagés. Enfin, un article a exploré les défis et les avantages de l'utilisation de Terraform pour la gestion des infrastructures, offrant des conseils pratiques pour améliorer la sécurité et la maintenabilité des configurations.

Terraform ajoute un support natif pour les monorepos, les configurations de composants de Stack et plus encore

HashiCorp a annoncé plusieurs améliorations pour Terraform, notamment le support natif des monorepos, les configurations de composants de Stack, et la publication flexible de modules. Ces nouvelles fonctionnalités visent à aider les équipes de plateforme à gérer les opérations d'infrastructure de manière efficace et sécurisée. Les configurations de composants de Stack permettent de standardiser les motifs d'infrastructure complexes et de les rendre accessibles dans le registre privé. La publication flexible de modules offre un support natif des monorepos, permettant de spécifier à la fois le dépôt VCS et le chemin du module spécifique pendant le processus de publication. De plus, Terraform permet désormais de tester les modules directement sur les agents auto-hébergés pour HCP Terraform Premium et Terraform Enterprise, améliorant ainsi la confiance dans les déploiements et réduisant les risques.

Terraform Stacks, expliqué

Terraform Stacks est une fonctionnalité conçue pour simplifier la provision et la gestion des infrastructures à grande échelle. Cet article explique les défis que Terraform Stacks résout, ses avantages, ses cas d'utilisation, son fonctionnement, ses fonctionnalités et sa feuille de route future. Les Stacks aident les utilisateurs à automatiser et à optimiser la coordination, le déploiement et la gestion du cycle de vie des configurations Terraform interdépendantes, réduisant ainsi le temps et les efforts nécessaires pour gérer l'infrastructure. Les cas d'utilisation courants incluent le déploiement d'une application complète avec des composants comme le réseau, le stockage et le calcul, ainsi que le déploiement sur plusieurs régions, zones de disponibilité et comptes de fournisseurs de cloud.

Suite de l'expérience gratuite améliorée de HCP Terraform

En 2023, HashiCorp a introduit des mises à jour pour les offres HCP Terraform, incluant une expérience gratuite améliorée pour renforcer la posture de sécurité dès le départ. Cette semaine, HashiCorp a annoncé la finalisation de la transition vers l'expérience gratuite améliorée pour toutes les organisations utilisant encore les anciens plans gratuits basés sur les utilisateurs. Le nouveau plan gratuit offre un accès à des capacités premium pour jusqu'à 500 ressources gérées, avec des utilisateurs illimités, permettant aux équipes de collaborer sans friction liée au nombre d'utilisateurs. Ces mises à jour visent à rendre les défauts sécurisés accessibles dès le départ, à maintenir faible la friction de prise en main pour les petites équipes, et à fournir une manière cohérente de comprendre l'utilisation à travers les niveaux.

Livrer des secrets aux pods Kubernetes sans les stocker dans etcd, en utilisant VSO

Le Vault Secrets Operator (VSO) a simplifié la gestion des secrets entre HashiCorp Vault et Kubernetes en synchronisant automatiquement les secrets de Vault dans les objets Secret de Kubernetes. Cependant, avec le flux de travail par défaut de VSO, ces secrets finissent par être stockés non chiffrés dans etcd, le magasin de données persistant du cluster. Cet article évalue les différences entre le modèle VSO par défaut et le modèle de secrets protégés éphémères, et explore les avantages de chaque approche. Le modèle de secrets protégés utilise un pilote CSI pour livrer les secrets directement aux pods Kubernetes, sans les stocker dans etcd, offrant ainsi une intégration plus sécurisée et éphémère.

Le flywheel de mentorat : Comment le CNCF fait grandir la prochaine génération de leaders cloud native

En 2025, les programmes de mentorat du CNCF ont atteint un jalon : 187 projets de mentorat réussis, un record. Mais l'histoire ne se résume pas aux chiffres. Il s'agit de ce qui se passe après la fin du mentorat. Cette année, le CNCF a suivi ce qu'il appelle le « flywheel de mentorat » — le cycle vertueux où les mentorés deviennent des contributeurs, les contributeurs deviennent des mainteneurs, et les mainteneurs deviennent des mentors qui amènent la prochaine génération. Les données racontent une histoire convaincante, tout comme les individus derrière elles. L'un d'entre eux est Mariam Fahmy. Son parcours, de complète novice à mainteneuse de Kyverno en moins d'un an, illustre exactement ce que le mentorat structuré peut accomplir — et pourquoi cela compte pour la santé à long terme de l'open source.

Cilium publie son rapport annuel 2025 : Une décennie de réseau cloud native

Une décennie après son premier commit en 2015, 2025 marque un jalon important pour le projet Cilium. La communauté a publié le rapport annuel 2025 de Cilium : Une décennie de réseau cloud native, qui fait le bilan de l'évolution du projet, des jalons clés et des développements notables au cours de l'année écoulée. Ce qui a commencé comme un effort expérimental de mise en réseau de conteneurs est devenu une plateforme mature et largement adoptée, combinant la mise en réseau, l'observabilité et la sécurité cloud native grâce à une architecture basée sur eBPF. Alors que Cilium entame sa deuxième décennie, la communauté continue de croître en taille et en dynamisme, avec un développement à haut volume soutenu, une adoption en production généralisée et des cas d'utilisation en expansion, y compris les machines virtuelles et les infrastructures d'IA à grande échelle.

Le CNCF accueille 12 nouveaux membres argent, soulignant un besoin croissant d'observabilité et d'automatisation

Nouveaux membres mondiaux rejoignent le CNCF pour renforcer les contributions de la communauté dans l'observabilité, l'infrastructure cloud et l'IA cloud native. Le Cloud Native Computing Foundation (CNCF) a annoncé l'ajout de 12 nouveaux membres argent, renforçant ainsi le dynamisme continu de l'adoption cloud native à travers les industries et renforçant davantage la communauté mondiale de la fondation. Selon le dernier rapport de l'état du développement cloud native du CNCF, plus de 15 millions de développeurs utilisent désormais les technologies cloud native, les professionnels du backend et des DevOps menant l'adoption à 58 %. À mesure que les entreprises se tournent vers des stratégies d'infrastructure hybrides, multi-cloud et distribuées, les outils cloud native sont devenus fondamentaux pour scaler les systèmes, réduire les coûts opérationnels et soutenir les charges de travail d'IA.

KubeVirt subit un audit de sécurité OSTIF

Le Open Source Technology Improvement Fund (OSTIF) est fier de partager les résultats d'un audit de sécurité récent de KubeVirt, une API et un runtime de virtualisation Kubernetes pour la gestion des machines virtuelles. Avec le soutien continu de Quarkslab et du Cloud Native Computing Foundation (CNCF), KubeVirt maintient le support des utilisateurs finaux exécutant des charges de travail de machines virtuelles qui nécessitent de containeriser des applications. L'audit a eu lieu sur 37 jours début 2025. Deux auditeurs ont examiné la fonction et la structure de KubeVirt pour créer un modèle de menace qui informerait le travail suivant. Le modèle de menace, qui a été discuté avec les mainteneurs du projet, définit les acteurs de la menace, les scénarios d'attaque et les surfaces d'attaque du projet. Il a également dirigé la partie suivante de l'audit, qui consistait en des tests automatisés et une revue manuelle du code dans les zones définies par les zones faibles recommandées par le modèle de menace.

Comment construire une plateforme d'observabilité rentable avec OpenTelemetry

La gestion de millions de connexions simultanées lors d'événements mondiaux tels que les soldes flash et les votes en ligne nécessite une observabilité résiliente et évolutive. Chez STCLab, nous exploitons des plateformes comprenant une plateforme de mitigation des bots et une plateforme de gestion du trafic qui prennent en charge jusqu'à 3,5 millions d'utilisateurs simultanés dans 200 pays. En 2023, nous avons pris une décision pivot en mettant fin à notre architecture legacy de 20 ans, sur site. Nous avons complètement restructuré notre plateforme de gestion du trafic, la construisant à partir de zéro en tant que SaaS natif Kubernetes et mondial. Le coût n'était pas le seul problème. Il s'agissait des conséquences. Nous avons été contraints de désactiver complètement l'APM dans les environnements de développement/staging et d'échantillonner seulement 5 % du trafic de production. Les régressions de performance n'étaient détectées qu'après leur mise en production. Ce combat réactif était insoutenable. Nous avions besoin d'une solution capable de surveiller tous les environnements de manière rentable, sans compromis.

Sécurité Kubernetes : Fonctionnalités stables en 2025 et aperçu de 2026

Il est temps de faire le bilan des principales avancées en matière de sécurité de Kubernetes en 2025 et de présenter les fonctionnalités susceptibles de passer en stable début 2026. Du point de vue DevSecOps, 2025 a apporté plusieurs améliorations significatives en matière de sécurité qui ont directement influencé les opérations jour-2 et les efforts de durcissement en production. Avec la version 1.35 de Kubernetes prévue pour le 17 décembre, le moment est idéal pour réviser les progrès de l'année écoulée et se préparer à ce qui nous attend.

Construire des plateformes en utilisant kro pour la composition

Les développements récents de l'industrie, tels que l'annonce par Amazon des nouvelles capacités d'EKS, soulignent une tendance à soutenir les plateformes avec des outils GitOps gérés, des opérateurs de ressources cloud et des outils de composition. En particulier, l'implication de Kube Resource Orchestrator (kro) — une initiative jeune et multi-cloud — reflète l'intérêt croissant de l'écosystème pour simplifier le regroupement des ressources natives de Kubernetes. Son inclusion dans le package de capacités signale que les principaux fournisseurs de cloud reconnaissent la valeur du projet maintenu par SIG Cloud Provider et son rôle potentiel dans les flux de travail futurs de l'ingénierie de plateforme. C'est une victoire pour les ingénieurs de plateforme. La composition des ressources Kubernetes devient de plus en plus importante à mesure que les outils d'Infrastructure as Code (IaC) déclaratifs augmentent le nombre d'objets que nous gérons. Par exemple, le projet Crossplane, récemment diplômé de la CNCF, et les alternatives spécifiques aux clouds, comme le AWS Controller for Kubernetes (ACK), qui est fourni avec les capacités EKS, peuvent ajouter des centaines, voire des milliers de nouveaux CRD à un cluster.

Kubernetes v1.35 : La mise à jour in situ des ressources des Pods devient GA

Cette version marque une étape majeure : plus de 6 ans après sa première conception, la fonctionnalité In-Place Pod Resize (également connue sous le nom de mise à l'échelle verticale des Pods) est désormais stable (GA) dans Kubernetes v1.35 ! Cette graduation est une étape majeure pour améliorer l'efficacité et la flexibilité des ressources des charges de travail en cours d'exécution sur Kubernetes. La mise à jour in situ des ressources des Pods permet de modifier les ressources CPU et mémoire sans redémarrer les Pods ou les conteneurs. Auparavant, ces modifications nécessitaient la recréation des Pods, ce qui pouvait perturber les charges de travail, en particulier pour les applications stateful ou par lots.

Kubernetes v1.35 : Job Managed By devient GA

Dans Kubernetes v1.35, la capacité à spécifier un contrôleur Job externe (via .spec.managedBy) passe en Généralité. Cette fonctionnalité permet aux contrôleurs externes de prendre en charge la réconciliation des Jobs, débloquant des modèles de planification puissants comme la diffusion multi-cluster avec MultiKueue. Pourquoi déléguer la réconciliation des Jobs ? La motivation principale de cette fonctionnalité est de prendre en charge les architectures de planification de lots multi-cluster, telles que MultiKueue. L'architecture MultiKueue distingue entre un Cluster de Gestion et un ensemble de Clusters de Travail : Le Cluster de Gestion est responsable de la diffusion des Jobs mais ne les exécute pas. Il a besoin d'accepter les objets Job pour suivre l'état, mais il saute la création et l'exécution des Pods. Les Clusters de Travail reçoivent les Jobs diffusés et exécutent les Pods réels.

Kubernetes v1.35 : Timbernetes (The World Tree Release)

Similaire aux versions précédentes, la sortie de Kubernetes v1.35 introduit de nouvelles fonctionnalités stables, bêta et alpha. La livraison constante de versions de haute qualité souligne la force de notre cycle de développement et le soutien vibrant de notre communauté. Cette version comprend 60 améliorations, dont 17 fonctionnalités stables, 19 bêta et 22 alpha. Il y a aussi quelques dépréciations et suppressions dans cette version ; assurez-vous de lire à ce sujet. Thème de la version et logo. 2025 a commencé dans l'éclat de Octarine : The Color of Magic (v1.33) et a chevauché les rafales Of Wind & Will (v1.34). Nous clôturons l'année en tenant l'Arbre du Monde, inspiré par Yggdrasil, l'arbre de vie qui unit de nombreux royaumes. Comme tout grand arbre, Kubernetes pousse anneau par anneau et version par version, façonné par les soins d'une communauté mondiale. Au centre se trouve la roue de Kubernetes enveloppant la Terre, ancrée par les mainteneurs, contributeurs et utilisateurs résilients qui continuent de se présenter. Entre les emplois du temps, les changements de vie et la gestion ouverte et constante, ils élaguent les anciennes API, greffent de nouvelles fonctionnalités et gardent l'un des plus grands projets open source au monde en bonne santé. Trois écureuils gardent l'arbre : un magicien tenant le parchemin LGTM pour les réviseurs, un guerrier avec une hache et un bouclier Kubernetes pour les équipes de publication qui coupent de nouvelles branches, et un rôdeur avec une lanterne pour les triageurs qui apportent de la lumière aux files d'attente d'incidents sombres.

Conseils Terraform depuis les tranchées de l'IaC

Après quelques années d'écriture de modules Terraform open source, j'ai appris quelques astuces de syntaxe qui rendent le code plus sûr, plus propre et plus facile à maintenir. Ce ne sont pas des révolutions, mais des motifs simples qui empêchent les erreurs courantes et rendent l'infrastructure plus résiliente. D'après les configurations que j'ai vues dans la nature, ces techniques semblent sous-utilisées. Utilisez one() pour des références de ressources conditionnelles plus sûres. Lorsque vous créez des ressources de manière conditionnelle avec count, ne vous tournez pas vers [0] — utilisez one(). Le problème. Il est courant d'utiliser count avec un booléen pour créer des ressources de manière conditionnelle (surtout dans les modules open source qui s'adaptent à de nombreuses configurations différentes) : data "awsroute53zone" "this" { count = var.createdns ? 1 : 0 name = "rosesecurity.dev" } resource "awsroute53record" "this" { zoneid = data.awsroute53zone.this[0].zoneid # ❌ Dangereux name = "blog.rosesecurity.dev" type = "A" # … } Cela semble correct et pourrait même fonctionner dans les environnements dev où var.create_dns = true. Mais dès que cette variable est false dans un autre environnement, vous obtenez : Error: Invalid index. La clé donnée n'identifie pas un élément dans cette valeur de collection : la valeur de la collection est un tuple vide. Le problème ? Cela échoue au moment de l'exécution, pas au moment de la planification. Le code fonctionne lorsque la ressource existe et se casse lorsqu'elle n'existe pas. Utilisez one() avec l'opérateur splat [] : data "awsroute53zone" "this" { count = var.createdns ? 1 : 0 name = "rosesecurity.dev" } resource "awsroute53record" "this" { zoneid = one(data.awsroute53zone.this[].zoneid) # ✅ Plus sûr(name = "blog.rosesecurity.dev" type = "A" # … } La fonction one() (disponible dans Terraform v0.15+) est conçue pour ce motif exact : Si count = 0 : retourne null de manière élégante au lieu de planter Si count = 1 : retourne la valeur de l'élément Si count ≥ 2 : retourne une erreur (attrape votre erreur tôt) Lorsque vous utilisez [0], vous supposez que la ressource existe. Lorsque vous utilisez one(), vous validez son existence. Bonus : one() fonctionne également avec les ensembles, qui ne supportent pas la notation par index. L'utilisation de one() rend le code plus polyvalent et futuriste.

CDKTF est déprécié : que faire ensuite pour votre équipe ?

En juillet 2020, CDK for Terraform (CDKTF) a été introduit, et la semaine dernière, le 10 décembre, il a été officiellement déprécié. Le support de CDKTF a pris fin, l'organisation et le dépôt ont été archivés, et HashiCorp/IBM ne le mettront plus à jour ni ne le maintiendront, laissant de nombreuses équipes sans une voie claire à suivre. Pour la plupart des équipes, cela signifie qu'il est temps de commencer à chercher un remplacement. C'est une situation malheureuse dans laquelle se retrouver soudainement en tant qu'utilisateur de CDKTF, mais vous avez des options, et Pulumi en est une. Dans cet article, nous allons vous aider à comprendre quelles sont ces options, comment Pulumi s'intègre dans celles-ci, et à quoi ressemblerait la migration de vos projets CDKTF vers Pulumi. Quelles sont les options ? Les équipes migrant de CDKTF ont généralement trois options : Option 1 : Revenir à HCL. La recommandation officielle de HashiCorp est d'exporter vos projets en HashiCorp Configuration Language (HCL) et de les gérer avec Terraform. CDKTF dispose même d'une commande qui rend cela relativement simple : cdktf synth --hcl. Bien sûr, si vous utilisez CDKTF, vous l'avez probablement choisi spécifiquement pour éviter HCL. Donc, bien que possible, ce n'est probablement pas le choix que la plupart des équipes feraient à moins qu'elles n'y soient contraintes. Option 2 : Migrer vers AWS CDK. Si votre équipe est entièrement investie dans AWS, une autre option serait de migrer vers AWS CDK. Il est largement utilisé, officiellement supporté, le modèle de programmation est similaire à celui de CDKTF, et à la fois CDK et CDKTF transpilent vers un format intermédiaire (YAML CloudFormation et JSON Terraform, respectivement) qui est ensuite transmis à leurs outils sous-jacents pour le déploiement. Mais bien que leurs modèles de programmation et de déploiement soient conceptuellement similaires, leurs modèles de ressources et leurs API sont entièrement différents. Voici le code pour un bucket S3 écrit en AWS CDK, par exemple : import * as s3 from 'aws-cdk-lib/aws-s3'; const bucket = new s3.Bucket(this, 'my-bucket', { bucketName: 'my-example-bucket', versioned: true, publicReadAccess: false, }); Et voici le code pour un bucket configuré de manière similaire dans CDKTF : import { S3Bucket } from '@cdktf/provider-aws/lib/s3-bucket'; const bucket = new S3Bucket(this, 'my-bucket', { bucket: 'my-example-bucket', versioning: { enabled: true, }, acl: 'private', }); Remarquez à quel point ces API sont différentes — et il s'agit d'une seule ressource simple avec seulement quelques propriétés ; imaginez avoir à réécrire des dizaines ou des centaines d'entre elles. Au-delà de cela, il y a aussi le problème de l'état : comment traduire le contenu d'un fichier d'état Terraform contenant des centaines de ressources en YAML ou JSON CloudFormation équivalent ? Malgré leurs similitudes superficielles, CDKTF et AWS CDK ont peu en commun. La migration signifierait essentiellement une réécriture de zéro qui vous laisserait également sans le support multi-cloud que vous avez déjà avec CDKTF. Pour la plupart des équipes, cela rend cette option un non-démarrage pratique. Option 3 : Migrer vers Pulumi. C'est là que nous devrions reconnaître notre biais évident — mais nous croyons sincèrement que pour la plupart des utilisateurs de CDKTF, Pulumi est vraiment la voie la plus simple et la plus largement compatible. Comme CDKTF, Pulumi vous permet de construire et de gérer votre infrastructure avec des langages généralistes tels que TypeScript, Python, Go, C# et Java, et il prend en charge l'organisation de votre code en abstractions de niveau supérieur appelées composants, que vous pouvez considérer comme des constructions CDKTF. Les deux organisent les ressources cloud en piles (pensez à dev, prod), et les deux suivent des états de déploiement de manière similaire, avec des options locales, distantes et hébergées dans le cloud disponibles. De nombreux fournisseurs les plus populaires de Pulumi (par exemple, le fournisseur AWS) sont également construits à partir de schémas Terraform open source, ce qui signifie que leurs modèles de ressources seront presque identiques à ceux auxquels vous êtes habitué avec CDKTF. Voici à quoi ressemble un bucket S3 dans Pulumi, par exemple : import * as aws from '@pulumi/aws'; const bucket = new aws.s3.Bucket('my-bucket', { bucket: 'my-example-bucket', versioning: { enabled: true, }, acl: 'private', }); Vous pouvez également utiliser n'importe quel fournisseur Terraform avec Pulumi, et vous pouvez même référencer directement les modules Terraform dans votre code Pulumi. Pulumi est également différent de CDKTF à plusieurs égards. L'un d'eux est que plutôt que de transpiler votre code source en un format comme JSON comme le fait CDKTF (et ensuite le déployer séparément plus tard), Pulumi utilise son propre moteur de déploiement déclaratif qui résout le graphe de ressources au moment de l'exécution et provisionne directement les ressources cloud, ce qui est beaucoup plus rapide et plus flexible. Vous pouvez en savoir plus sur le modèle de déploiement dans Comment fonctionne Pulumi. Compte tenu des similitudes d'API, du support de tous les fournisseurs et modules Terraform, de la capacité à coexister avec les projets gérés par Terraform, et du support intégré pour la conversion (que nous aborderons ensuite), nous pensons que Pulumi est la meilleure option pour la plupart des équipes cherchant à migrer. À quoi ressemble la migration vers Pulumi ? La migration d'un projet CDKTF vers Pulumi se déroule généralement en trois étapes : Conversion, qui traduit votre code CDKTF en un nouveau programme Pulumi Importation, qui lit le contenu de votre état CDKTF dans une nouvelle pile Pulumi Réfactoring, qui aligne le code dans le nouveau programme avec les ressources actuellement déployées dans la pile Conversion et importation La migration commence par l'exportation de votre projet CDKTF en HCL avec cdktf synth. De là, les commandes intégrées convert et import de Pulumi s'occupent de la création du nouveau programme et de l'importation de votre état : # Exportez votre projet en HCL. cdktf synth --hcl # Convertissez le HCL en un nouveau projet Pulumi. pulumi convert --from terraform --language typescript # Créez une nouvelle pile Pulumi. pulumi stack init dev # Importez les ressources de votre pile CDKTF dans votre nouvelle pile Pulumi. pulumi import --from terraform ./terraform.dev.tfstate Le convertisseur traduit automatiquement les variables d'entrée Terraform, les sources de données, les ressources et les sorties en leurs équivalents Pulumi. Vous pouvez en savoir plus sur le fonctionnement de ce processus dans la conversion de HCL Terraform en Pulumi. Réfactoring Une fois que vous avez importé votre état, vous devrez souvent apporter quelques ajustements au code pour l'aligner avec la nouvelle pile Pulumi. Par exemple, pulumi import marque les nouvelles ressources protégées par défaut, pour éviter qu'elles ne soient supprimées accidentellement — mais comme le code produit par pulumi convert n'inclut pas l'option de ressource protect, vous devrez l'ajouter vous-même. Heureusement, l'étape d'importation émet également du code que vous pouvez copier dans votre programme pour faciliter un peu ce processus. La réfacturation peut devenir un peu plus compliquée lorsque des logiques personnalisées et des abstractions de niveau supérieur sont impliquées, car la fidélité au code CDKTF original est souvent perdue dans la traduction en HCL. Dans ces situations, l'aide d'un LLM pour recapturer cette logique originale ou traduire vos constructions CDKTF en composants Pulumi peut être un gain de temps important. Un exemple de bout en bout Le meilleur moyen de se faire une idée de la manière dont cela fonctionne, cependant, est de l'essayer vous-même. Le dépôt pulumi/cdktf-to-pulumi-example sur GitHub contient un projet CDKTF avec plusieurs piles écrites en TypeScript, ainsi qu'un guide qui vous guide à travers le processus de migration de ce projet vers Pulumi. Le guide couvre tout ce dont nous avons discuté jusqu'à présent, y compris : La conversion du projet CDKTF en un nouveau projet Pulumi L'importation de ses ressources en cours d'exécution dans les piles Pulumi La modification du code généré pour l'aligner avec l'état importé L'exécution d'un déploiement initial avec Pulumi pour compléter le processus de migration Le tutoriel prend seulement quelques minutes à compléter, et c'est un excellent moyen de mettre en place un exemple personnel pour mieux se familiariser avec Pulumi. Que faire ensuite ? Si vous quittez CDKTF, il y a quelques chemins possibles à suivre. Pour les équipes qui veulent continuer à utiliser des langages réels et éviter une réécriture de zéro, Pulumi offre la voie la plus claire à suivre. Pour en savoir plus sur le fonctionnement de Pulumi, comment il diffère de CDKTF et de Terraform, comment gérer des scénarios de conversion supplémentaires, et plus encore, nous recommandons : Plonger dans les docs Pulumi pour se familiariser avec les concepts et les fonctionnalités clés de la plateforme Lire Migrating from Terraform or CDKTF to Pulumi pour plus de conseils de migration détaillés, spécifiques à Terraform Rejoindre notre Slack Pulumi Community pour poser des questions et apprendre des autres qui ont réussi à passer de Terraform et CDKTF à Pulumi Et bien sûr, n'hésitez pas à nous contacter ! Nous serions ravis de vous aider de quelque manière que ce soit.

Sources

• Terraform adds native monorepo support, Stack component configurations, and more
• Terraform Stacks, explained
• Continuing HCP Terraform’s enhanced free tier experience
• Deliver secrets to Kubernetes pods without storing in etcd, using VSO
• The mentorship flywheel: How CNCF is growing the next generation of cloud native leaders
• Cilium releases 2025 annual report: A decade of cloud native networking
• CNCF Welcomes 12 New Silver Members Emphasizing a Growing Need for Observability and Automation
• KubeVirt undergoes OSTIF security audit
• How to build a cost-effective observability platform with OpenTelemetry
• Kubernetes Security: 2025 Stable Features and 2026 preview
• Building platforms using kro for composition
• Kubernetes 1.35: In-Place Pod Resize Graduates to Stable
• Kubernetes v1.35: Job Managed By Goes GA
• Kubernetes v1.35: Timbernetes (The World Tree Release)
• Terraform Tips from the IaC Trenches
• CDKTF is deprecated: What's next for your team?