Tech Radar - Operable

Adopt

Kustomize

Kustomize permet de configurer de manière simple vos déploiements complexes dans Kubernetes.

Kustomize permet de gérer les configurations des ressources pour Kubernetes en utilisant des fichiers YAML, avec une syntaxe facile à utiliser. Il permet également de gérer des configurations complexes pour des applications multi-environnements en appliquant des configurations en série.

En effet, Kustomize applique des patchs et overlays sur une configuration de base. Cela permet de gérer des configurations complexes plus simplement qu’avec Helm où il faut redéfinir un fichier de values à chaque fois. Et ce, tout en gardant votre code aussi DRY que possible !

De plus, Kustomize génère automatiquement de nouveaux secrets Kubernetes chaque fois que vous modifiez un champ de données (data field) dans le fichier de configuration. Cette fonctionnalité permet de maintenir la sécurité des secrets et tout en simplifiant vos rollbacks.

Cependant, Kustomize est plus difficile à appréhender pour des personnes n'étant pas familières avec les ressources Kubernetes et leur déclaration en YAML. C’est aussi un outil moins flexible que Helm en termes de personnalisation : il n’est pas possible d’intégrer de logique via du templating par exemple.

Nous pensons que Kustomize et Helm sont deux outils complémentaires pour la gestion des configurations de déploiement pour Kubernetes. Alors que Kustomize est idéal pour gérer les configurations de manière modulaire, Helm offre un moyen pratique de gérer des packages d'application plus complexes.

En utilisant Kustomize avec Helm, les équipes peuvent bénéficier des avantages des deux outils. Par exemple, Helm peut être utilisé pour gérer des packages d'application complets, tandis que Kustomize peut être utilisé pour personnaliser des configurations spécifiques pour des environnements de déploiement.

Kustomize est un outil puissant pour la gestion des configurations de déploiement pour Kubernetes, avec une syntaxe simple et qui complète parfaitement Helm.

Renovate

Automatiser la mise à jour (Patch Management) des dépendances externes (librairies) de l’infrastructure et des applications

Le Patch Management est un enjeu majeur pour la sécurité d’une plateforme. Nos infrastructures, autant que les applications qui y sont déployées, utilisent des composants externes (dépendances, très souvent open source) qu’il faut mettre à jour régulièrement pour corriger à la fois les failles de sécurité et les bugs. Avec le rythme rapide des mises à jour et la quantité grandissante de dépendances, il peut être difficile de maintenir toutes ses dépendances à jour.

Renovate est un outil open source de gestion de dépendances qui automatise la mise à jour des packages dans vos projets. Il analyse vos fichiers de configuration de dépendances (tels que package.json, pom.xml ou build.gradle) et génère automatiquement des pull requests pour les mises à jour de packages nécessaires.

Renovate est compatible avec une grande variété de gestionnaires de packages, notamment npm, yarn, pip, Maven et NuGet, ce qui le rend facilement adaptable aux différents langages de programmation. Il permet aussi d'analyser les dépendances de votre infrastructure en supportant les chart Helm, les images Docker et les modules Terraform. Vous pouvez l'utiliser avec les Git Provider majeurs tels que Gitlab, Github, BitBucket et Azure DevOps.

Hautement configurable, il s’adapte parfaitement aux workflows de développement de nos projets. Il s’intègre via des tâches de CI ou alors, notre préférence, en tant que cronjob dans un cluster Kubernetes afin d’optimiser les traitements avec du cache dans Redis. Ce sera un mode de déploiement qui permettra de scale plus facilement en déployant plusieurs “instances” de Renovate (cronjob Kube) pour répartir la charge et adapter son fonctionnement.

Avec une exécution journalière et le merge automatique des changements (quand la CI est valide), nous automatisons une partie de la correction des failles de sécurité en appliquant automatiquement les patchs.

Renovate nous permet aussi de suivre les évolutions de nos dépendances en ayant une vue des évolutions (nouvelle version mineure ou majeure) à prendre en compte pour maintenir nos dépendances à jour (via la liste des Merge Request/Pull Request ouverte). L’objectif étant de ne pas avoir de version majeure de retard et de toujours bénéficier sur le long terme des mises à jour de sécurité.

Renovate nous permet de réduire le toil du Patch Management et de dégager du temps pour travailler sur des améliorations qui apporteront plus de valeur au business de nos clients.

Terraform

Aujourd’hui Terraform est l’outil d’Infrastructure as Code (IAC) qui domine le marché. Il permet de provisionner et de manager des ressources sur tous les Cloud Providers.

Nous avons créé des centaines d'infrastructures sur plusieurs clouds providers et nous avons utilisé à chaque fois Terraform. Un outil d’IAC est en effet essentiel pour se lancer dans le cloud, car il facilite la collaboration, mais aussi l’opérabilité d’une infrastructure.

Terraform rayonne par différentes fonctionnalités qu’il propose :

L’utilisation de modules qui permettent de définir des ensembles de ressources qui répondent à un besoin précis et de pouvoir les réutiliser facilement
Le state Terraform qui permet de suivre le cycle de vie de chaque ressource
La compatibilité avec plusieurs clouds et systèmes grâce aux providers. Par ex : AWS, OVH mais aussi Github

On sait que des outils IAC sont proposés par les clouds providers comme : CDK AWS, cloudformation ou même ARM pour Azure. Mais leur vendor lock-in et leur manque d'interopérabilité nous ont fait pencher pour Terraform.

Malgré le fait qu’il soit leader dans l’IAC pour gérer une infrastructure, il est nécessaire d’avoir un cadre pour la code base. Nous avons convergé chez Padok sur un pattern WYSIWYG (What You See Is What You Get) qui aide à l’uniformisation du code et la collaboration.

Les points à retenir sont :

Organiser les states Terraform par rapport à un besoin métier
Créer des modules qui répondent à un besoin complexe ou reproductible
Ne pas hésiter à factoriser le code quand l’infrastructure évolue

Tips pour son utilisation 💡

Il ne faut pas négliger les outils de qualité syntaxique et de maintenabilité : terraform fmt, tfllint, tfautomv ou terraform-docs.

Terraform est l’outil de référence aujourd'hui pour construire et maintenir une infrastructure dans le cloud. Des outils tels que Terragrunt améliorent encore davantage sa capacité à gérer l'infrastructure at scale en proposant des fonctionnalités permettant d'éviter la redondance de code, appelée DRY (Don't Repeat Yourself).

Grafana

Grafana est une plateforme de dashboarding open source pour tous vos environnements cloud.

Grafana est un outil de dashboarding open source créé par l’entreprise éponyme, Grafana Labs. Il permet aux utilisateurs de créer des dashboards dynamiques et personnalisables pour surveiller et analyser les metrics liées à votre infrastructure.

Il est possible de brancher de nombreuses données sources sur Grafana : bases de données temporelles comme InfluxDB, Prometheus, ElasticSearch, et même les services de monitoring natifs de votre Cloud Provider préféré. Son interface utilisateur intuitive vous permet ensuite de regrouper les différentes données sous forme de graphiques en temps réel, jauges, diagrammes en barre pour ne citer que cela.

Grafana est un incontournable du monitoring pour vos clusters Kubernetes, très facile à installer et configurer grâce à son chart Helm. De plus, vous pouvez définir vos dashboards à l'aide de ConfigMap. Si vous ne voulez pas avoir la responsabilité de gérer votre outil de visualisation, pas de soucis, il existe une offre SaaS Grafana Cloud.

Avec l’essor des architectures en microservices et de l’utilisation du cloud pour créer des environnements complets et complexes, Grafana est devenu un outil incontournable que ce soit pour les équipes opérationnelles ou les équipes de développement.

Prometheus Operator

Prometheus Operator permet de déployer et de gérer facilement toute une stack technique autour de Prometheus afin de monitorer un cluster Kubernetes.

Prometheus est l’outil de référence pour la métrologie sur les architectures Kubernetes. Le déploiement et la gestion sont particulièrement simplifiés grâce à Prometheus Operator tout en ajoutant d’autres composants annexes, mais non moins nécessaires, qui permettent d’améliorer l’opérabilité de votre plateforme :

alerting avec Alerte Manager
monitoring HTTP avec Blackbox Exporter
visualisation des métriques avec Grafana

L’installation de la suite Prometheus se fait en une seule commande et après quelques minutes d'attente, vous aurez accès à toutes les métriques de votre cluster et bien plus encore. L’opérateur permettra de manipuler les ressources Prometheus via les CRD Kube. Il ne sera donc pas nécessaire de configurer vos ressources dans Prometheus mais simplement de les déclarer dans l’API Kube.

Ainsi, on automatisera le monitoring en ajoutant ces ressources dans nos charts, et chaque application déployée sera monitorée (métrique ou surveillance HTTP, par exemple) par Prometheus.

Toutefois, le problème majeur de Prometheus n’est pas réglé par l’opérateur : une vue consolidée et centralisée dans des architectures multi-environnements et multi-cluster. Vous devrez alors déployer des composants qui permettent de faire le lien entre les différents déploiements : un Grafana central et des solutions comme Thanos pour augmenter la rétention des données.

Même si d’autres solutions existent, comme Datadog (payant), Prometheus reste le standard de facto de la communauté pour Kubernetes et sera toujours un bon choix pour opérer vos clusters.

Terragrunt

Terragrunt est un outil proposé par Gruntwork pour enrichir Terraform et booster sa capacité à gérer des déploiements multi-modules

Terraform est le standard actuel de la communauté pour le déploiement as code de ressources cloud. Il dispose notamment de librairies (nommées “providers”) pour la quasi-totalité des ressources des grands Cloud Providers.

Cependant, des limitations qui lui sont propres pénalisent les équipes pour gérer une infrastructure à plusieurs, ou pour gérer de grosses infrastructures. En effet, dans ce genre de cas, il est souvent nécessaire de découper le déploiement de Terraform déploiement de plusieurs modules (parfois également appelées layers), afin de les simplifier ou d’éviter les collisions de states Terraform.

Or, ceci est vite très compliqués à gérer car il devient nécessaire :

D’utiliser des remote states pour partager les outputs entre states
De dupliquer ou sur-templatiser les configurations de backends qui ne sont pas nativement configurable dans Terraform
De gérer les variables communes ou spécifiques des environnements, par exemples via des fichiers et des liens symboliques

Terragrunt vient se placer au-dessus, afin de créer et chapeauter des workspaces Terraform autogénérés. On peut ainsi profiter des fonctionnalités accrues de Terragrunt pour lier les apply (layers) entre eux. Terragrunt permet donc d’avoir un meilleur lien entre layers, tout en se reposant ensuite sur les capacités reconnues de Terraform pour le déploiement.

Terragrunt se configure de plus via le même langage que Terraform, l’HashiCorp Language (HCL), qui a été étendu pour lui ajouter les fonctionnalités nécessaires. Cela facilite la formation des équipes et limite la sensation d’avoir un nouvel outil à maîtriser.

D’autres outils essaient aujourd’hui de remplir ce besoin, mais Terragrunt a notre préférence car il parvient au résultat en n’ajoutant qu’une couche très fine autour de Terraform.

Trial

Excalidraw+

Excalidraw+ est une solution SaaS de tableau blanc virtuel. Sa simplicité permet de faire des schémas avec la même aisance que sur une feuille de papier, tout en conservant la capacité de les stocker et de les partager comme un Google Doc.

Excalidraw+ permet d’obtenir en 2 clics une page blanche sans limite (“Scène”) sur laquelle on peut dessiner des formes comme sur un tableau. Les scènes sont regroupées en “Collections” auxquelles on peut donner des droits par équipes, au sein d’un workspace qui nous est dédié.

Le gros point fort d’Excalidraw+ est dans sa simplicité. Seules des formes élémentaires (ex : rectangles, cercles, flèches, zones de texte) et une capacité de mise en forme restreinte (ex : couleurs, 4 tailles de police) sont possibles dans l’affichage par défaut.

Il en résulte une meilleure collaboration au quotidien, basée sur beaucoup de représentations graphiques et des schémas d’architecture plus à jour, car l’effort à produire pour les maintenir est minimisé.

Excalidraw+ permet de faire tout type de schéma, et de collaborer efficacement à distance avec un support visuel. Si vous avez besoin de faire un schéma et ne savez pas où le faire, il n’y a donc pas à hésiter 😉 Vous pouvez essayer la version gratuite sur excalidraw.com.

L’outil a cependant les limitations suivantes :

Gestion des droits trop large, par exemple :

Il faut être administrateur pour pouvoir gérer les droits
On ne peut donner des droits sur des dossiers qu’à des équipes
Un utilisateur ne peut être membre que de 6 équipes à la fois
On ne peut pas créer de sous dossiers

Absence de SLA affichés (même si l’application est globalement toujours disponible)
Impossibilité de choisir la localisation du stockage des données

Ces limitations justifient, pour nous, de le mettre en “Trial” et non en “Adopt”.

Atlantis

Atlantis est une application pour automatiser l’utilisation de Terraform via des pull request. Cela permet d’avoir un workflow pour maintenir la cohérence d’une infrastructure définie en IaC.

Atlantis est un outil open source qui permet d’automatiser les contributions à une code base Terraform, en permettant d’exécuter les commande plan, apply et import directement dans la pull request. De ce fait, on peut voir le retour directement en commentaire. C’est une application qui peut être hébergée n’importe où et qui utilise le système de webhook de Github, Gitlab ou Bitbucket.

Cela permet de résoudre les problématiques de collaboration sur des grandes infrastructures, mais aussi d’avoir un historique des modifications faites.

Des workflows plus complexes permettent d’accélérer d’autant plus la DevX (Developer Experience) :

Autoplanning à chaque nouveau commit ou pull request qui permet rapidement d’avoir un état de l’infrastructure et de valider l’impact des changements apportés
Automerging pour merge la pull request si tous les plans sont fonctionnels

Cependant il reste encore des améliorations pour que cet outil devienne une référence :

Le serveur qui gère Atlantis détient les informations d'identification permettant d'accéder à votre infrastructure. Par conséquent, pour séparer l’accès à plusieurs infrastructures, il faut instancier plusieurs serveurs, ce qui peut rapidement devenir complexe.
Il est fortement limité par son architecture et la scaler n’est pas simple. Si vous avez des besoins d'infrastructure à grande échelle, d'autres solutions plus robustes et matures existent.

Atlantis est un outil prometteur, mais sa gestion complexe de droit et de scalabilité est la raison pour laquelle nous le mettons en ‘Trial”. Des features intéressantes, comme la détection de drift, sont planifiées dans sa roadmap et méritent de le garder dans le radar.

Custom Operators

Les opérateurs custom permettent d’automatiser des tâches dans Kubernetes en ajoutant des fonctionnalités à son API.

Kubernetes est très populaire en tant qu'orchestrateur de containers. Mais c’est avant tout une API extensible. Créer vos propres opérateurs permet d’ajouter des nouvelles ressources à l’API de Kubernetes et d’en étendre les fonctionnalités.

En créant votre opérateur, vous allez définir des Custom Resource Definitions (CRDs). Le code de l'opérateur tire parti du pattern de réconciliation de Kubernetes afin de déclencher des événements dans votre cluster à chaque ajout, modification ou suppression d’une instance de CRD. Cela peut aider à automatiser des tâches répétitives (réduire votre TOIL), et à ajouter des fonctionnalités personnalisées à des applications. Si vous vous servez de Kubernetes, vous vous servez probablement déjà quotidiennement d'opérateurs custom comme cert-manager ou ArgoCD.

Dans le cadre d’un SaaS par exemple, chaque nouveau client nécessite la création d’un nouveau tenant. Avec un opérateur, il est possible d’automatiser la création de toutes les ressources nécessaires juste en déclarant un nouvel objet dans votre cluster Kubernetes !

Cependant, la création d’un opérateur peut s'avérer compliquée : il faut parfaitement maîtriser le fonctionnement de Kubernetes en plus de maîtriser parfaitement le cycle de vie et différents edge cases de ce que vous voulez automatiser. Et tester tous les cas d’application n’est pas mince à faire.

Il est important de noter que vous pouvez écrire vos opérateurs dans n'importe quel langage de programmation : Java, Rust… et même Ansible. De notre côté, nous recommandons l’utilisation de Golang : vous trouverez énormément de ressources pour vous aider et l'opérateur-sdk de Red Hat permet de bootstrapper votre code très efficacement.

La création d'un opérateur peut offrir de nombreux avantages aux équipes DevOps travaillant avec Kubernetes. Cependant, cela peut également être complexe et nécessiter une certaine expertise en programmation et en Kubernetes

Terratest

L’infrastructure étant la base de toute application robuste, elle devrait être testée ! Terratest répond justement à ce problème en étant une des rares librairies de test pour Terraform.

Terratest est la référence pour tester sur code Terraform. Codée en Go, cette librairie permet d’écrire des tests unitaires pour Terraform et Terragrunt.

En effet, Terratest permet de déployer une infrastructure et de réaliser des tests sur :

Des appels HTTPS pour voir si des load balancers sont bien fonctionnels
Des requêtes API pour vérifier la réponse de l’api gateway
Des connexions SSH vers des serveurs bastion
Le bon statut d’une ressource
L’application d’un terraform apply sans erreur

Ce sont des tests qui deviennent essentiels pour des infrastructures grandissantes car des erreurs peuvent rapidement apparaître dûes à des changements de version de Terraform ou du provider, et surtout pour garantir la non-régression des fonctionnalités existantes.

On le positionne en “Trial” car aujourd'hui ce n’est pas encore un standard de l’industrie. Il n’est notamment pas utilisé par les modules open source maintenus par les Cloud Providers. Les principaux freins sont :

la mécanique de conception du test pour valider le fonctionnement de l'infrastructure n’est pas un geste facile et documenté
la disponibilité d’un environnement pour réaliser ces tests engendre des coûts supplémentaires, même si c’est sur une courte période

En note, nous l’avons également utilisé pour tester nos packages Helm et nous en sommes satisfaits !

Assess

Tacos

Tacos, ou Terraform Automation and COllaboration Software, est une typologie qui permet de gérer du code Terraform à grande échelle avec une approche GitOps.

Terraform est massivement utilisé pour construire des infrastructures, mais à grande échelle maintenir une code base à des limites. Il est difficile de :

Proposer un flow efficace de contribution, de la code review aux tests et preview sur une pull request
Monitorer les modifications faites sur chaque layer
Détecter les modifications apportées à l’infrastructure en dehors du code. Cela provoque une désynchronisation entre le code et l'existant.

Un Tacos devient utile justement pour ce type de problématiques, donc pour des grandes infrastructures avec plusieurs environnements et plusieurs applications.

Un Tacos offre notamment :

Des workflows d’automatisation autour de code IaC comme Terraform, Terragrunt et Pulumi
De la détection de désynchronisation entre le code et l'existant grâce à des exécutions régulières et automatisées
Un tableau de bord consolidant un historique des changements et une estimation du prix de l’infrastructure

Tacos est un framework qui résout ces problèmes grâce à une interface centralisée et des intégrations avec Github ou Gitlab.

Les leaders dans ce domaine sont aujourd’hui : Spacelift, Terraform Cloud, Sclar, env0. Ils ont tous leurs avantages et inconvénients. Mais cela vient avec un ticket d’entrée non négligeable, d’environ 200 euros par mois car leur free tier ne permet pas de gérer des grosses infrastructures efficacement.

Actuellement, aucune option open source ne permet de faire du Tacos. La seule exception est Atlantis, mais ce n’est pas un Tacos complet puisqu'il ne gère que les workflow sur Github, Bitbucket et Gitlab.

Une autre limitation des outils Tacos est que toutes les solutions sont aujourd’hui hébergées dans le Cloud. Elles ne sont donc pas utilisables sur des infrastructures sensibles qui veulent garantir une privatisation élevée de leur SI.

Tacos est une typologie qui a un avenir prometteur, mais qui aujourd’hui manque d’alternatives open source.

Crossplane

Crossplane est un outil d’infrastructure-as-code basé sur Kubernetes. Il permet de créer des ressources Cloud en utilisant des Custom Resources Definitions.

Crossplane est une technologie d’infrastructure-as-code (IaC) développée par Upbound. Elle permet de déployer des ressources d'infrastructure en utilisant Kubernetes comme gestionnaire d'état. C'est un outil dont le principe de fonctionnement est similaire à Config Connector de GCP ou AWS Controllers for Kubernetes.

Crossplane se déploie comme un opérateur dans Kubernetes. Pour l’utiliser afin de gérer son infrastructure, il faudra déployer un provider dédié qui se présente comme une Custom Resource Definition (CRD). Le provider déploie alors des CRDs pour chaque ressource Cloud (exemple pour AWS : une instance EC2, un VPC, une Lambda…).

Associé à des technologies de GitOps telles qu’ArgoCD, Crossplane peut se transformer en véritable plateforme de self-service Cloud. L’utilisation de YAML et d’attributs Kubernetes pour définir et relier toute son infrastructure est très intuitive. La connaissance minimale nécessaire pour commencer à utiliser Crossplane est nettement moins élevée que Terraform.

Cependant, nous notons quelques contrepoints qui ne nous permettent pas d’accorder entièrement notre confiance à l’utilisation de Crossplane en production :

Modifier un champ immutable d’une ressource n’engendre pas son remplacement, il faut gérer manuellement ce cas de figure
Aucun support natif n’existe pour partager des informations entre des ressources gérées par des providers différents
La dépendance à un cluster Kubernetes pour gérer son infrastructure implique une gestion impeccable de ce dernier
Crossplane n'a aucune notion de "plan" ou de “dry-run” qu'on peut trouver dans d'autres outils
Importer des ressources existantes est un processus mal documenté et risqué alors que c'est un cas d'utilisation très fréquent

Aujourd’hui, nous utilisons Crossplane pour résoudre des problèmes spécifiques tels que la configuration de bases de données MySQL. Nous considérons que c’est un outil à surveiller car il peut devenir un concurrent sérieux au sein des technos d’IaC, moyennant entre autres l’adressage des problèmes que nous avons mentionnés.

Hermes

Hermes est un projet open source de HashiCorps Labs qui permet de structurer la gestion de vos documents Google Docs au sein de votre organisation Google Workspace.

À partir d’une certaine taille, chaque organisation est confrontée au défi de la gestion de sa documentation. La culture orale des premiers temps laisse place rapidement à un premier outil pour centraliser les connaissances techniques, mais aussi organisationnelles.

Choisir un outil qui saura s’adapter à toutes les étapes de la vie de votre entreprise est presque mission impossible. L’approche One Size Fits All est souvent privilégiée, car il est complexe d’avoir à gérer plusieurs outils. Mais est-ce la bonne solution ? Pourquoi ne pas revenir à un vieil adage Unix : un programme qui fait une chose, mais qui le fait bien ?

Hermes est un outil open source de gestion documentaire créé par l’équipe HashiCorp Labs. Il permet de gérer des documents au sein de votre organisation en facilitant le cycle de vie : standard de document, rédaction, relecture, validation, invalidation, collaboration et, le plus important, la recherche.

Hermes pourrait être un choix pragmatique si vous êtes au sein d’une organisation Google Workspace et que vous utilisez le Drive pour créer et stocker des documents Docs. Les atouts de Hermes :

interface simple et fonctionnelle
capacité de créer des modèles et d’avoir un cycle de vie des documents
recherche full text via le puissant moteur d’Algolia

En somme, Hermes fait peu, mais le fait bien.

Le produit est jeune, limité (seulement Google Workspace est supporté) mais

semble prometteur pour une première version. Ce n’est pas un projet officiel Hashicorp, mais l’historique de l’entreprise laisse penser qu’il y aura certainement des évolutions, sans doute aussi grâce à la communauté, et que l’outil gagnera en maturité avec le temps.

On vous recommande donc de le tester, ou à défaut de le mettre dans votre liste de projets open source à surveiller, car cela pourrait bien être un excellent outil sur le long terme pour gérer pragmatiquement des documents texte structurés.

Kubernetes Gateway API

Kubernetes Gateway API permet de gérer l’accès des services Kubernetes depuis l’extérieur du cluster avec une approche role-oriented entre les Ops et les développeurs.

Lorsque l’on souhaite exposer des services Kubernetes à l’extérieur de notre cluster, nous avons tendance à utiliser les ressources de type Ingress. Nous déployons donc des Ingress Controller comme ceux proposés par Nginx, Traefik ou encore Kong qui vont avoir leurs propres annotations pour diriger le trafic, et qui vont gérer les Ingress rattachés à eux. Généralement, les développeurs ainsi que les Ops en charge du cluster vont travailler sur ces mêmes ressources, ce qui peut créer parfois des perturbations.

Afin de mieux séparer le rôle de chacun pour gérer l’exposition des services applicatifs, un nouveau concept est apparu depuis peu : Kubernetes Gateway API. Il permet aux Ops de mettre en place une gateway globale au niveau du cluster (cross-namespace) et qui a pour point d’entrée un load balancer de type L4 ou L7.

Les développeurs sont alors autonomes pour créer leurs propres HTTPRoutes dans leurs namespaces, qui contiennent leurs propres configurations. À noter que ces ressources apportent nativement plus de fonctionnalités, comme le header-based matching ou le traffic weighting.

Kubernetes Gateway API est encore relativement nouvelle, mais est en train de gagner en popularité en raison de sa capacité à simplifier la gestion des routes dans les environnements Kubernetes complexes. Elle offre également une meilleure visibilité et un meilleur contrôle sur les gateways, ce qui facilite la détection des erreurs et des problèmes de sécurité.

Chez Padok, nous trouvons cette technologie très prometteuse pour les équipes qui cherchent à simplifier la gestion des routes dans les environnements Kubernetes. À mesure que cette technologie continue de mûrir, elle devrait gagner en popularité et devenir la référence, quitte à remplacer les Ingress.

D’ailleurs GCP l’a intégré à son service GKE sous le nom de GKE Gateway Controller, et c’est en GA !

Pulumi

Pulumi est un outil d’Infrastructure As Code qui utilise des langages comme Python, Go ou Typescript. Il offre de nombreuses possibilités, mais n’est pas encore le choix par défaut pour construire son infrastructure en IAC

Terraform est peut-être le leader sur l’IAC mais Pulumi est un concurrent sérieux avec une approche utilisant des langages comme Python ou le GO. Cela a pour principal avantage de permettre d’écrire du code conditionnel plus facilement, chose complexe en Terraform.

Pulumi propose 2 fonctionnalités qui se différencient des autres outils IAC :

Les providers natifs qui sont automatiquement mis à jour en fonction de l’API officielle des Clouds Providers. Il n’y a donc plus à attendre que le provider soit mis à jour manuellement à la suite d’une nouvelle fonctionnalité sortie sur l’API officielle avant de l’utiliser. Cela permet de profiter des dernières fonctionnalités des Clouds Providers rapidement !

La gestion de secrets par chiffrement, qui permet d’écrire des données sensibles directement dans le code. En effet, elles sont chiffrées avec des clés venant de provider comme aws kms, hashi vault ou encore gcp kms et déchiffrées au run time juste-à-temps.

Utiliser Pulumi est un bon compromis pour les équipes composées uniquement de développeurs et qui souhaitent rester sur un langage familier . Cela est avantageux, car les process de maintenance et les bonnes pratiques en place permettent de garantir une qualité de code.

Pour autant Pulumi vient avec les limitations des langages. Par exemple, la gestion de dépendances avec les `node_modules` peut devenir volumineuse avec le scaling de la code base.

En conclusion, si vous avez un besoin précis d’utiliser des langages comme le GO ou le Python dans votre stack complète, démarrer avec Pulumi sera plus simple. Cependant Pulumi ne résout pas les problèmes fondamentaux de Terraform, car il reste toujours aussi compliqué de créer, organiser et maintenir du code IAC. Si vous avez une infrastructure existante gérée avec Terraform, nous ne vous conseillons pas de migrer vers Pulumi !

Hold

Dependabot

Dependabot est un outil natif à GitHub qui permet de gérer les mises à jour de sécurité critiques des dépendances externes dans vos applications

Dependabot est un outil qui permet de gérer la mise à jour de vos dépendances applicatives externes (packages) au sein de vos applications en créant automatiquement des pull requests lorsqu’une mise à jour est disponible.

Nativement disponible sur GitHub, sa force, il est aussi possible de l’utiliser sur d’autres Git Provider tel que GitLab et Azure DevOps mais cela nécessite plus d’effort pour son intégration.

Par défaut, Dependabot tente une approche un peu différente de Renovate en se concentrant sur les mises à jour de sécurité critiques afin de créer moins de “bruit” sur les projets. Cela peut-être pratique pour des applications où il y a peu de développeurs pour la maintenance.

Mais c’est pour nous sa seule différenciation majeure. Comme Renovate, il analyse aussi la plupart de vos fichiers de dépendances pour Node.js, Spring Boot, Python, etc, mais est plus limité concernant votre code d'infrastructure en ne supportant pas Helm par exemple.

On peut aussi lui reprocher l’utilisation d’une base de données de CVE (GitHub Advisory Database) en open source, qui mène parfois à des alertes de sécurité controversées qui vont créer beaucoup de bruit.

On lui préfère donc Renovate dans la plupart des cas. Nous gardons tout de même un œil sur Dependabot, qui est régulièrement mis à jour par GitHub et qui tend à s’améliorer avec le temps.