Kubernetes : les environnements à la demande

Nous allons voir dans cet article, les raisons poussant à mettre en place un service d’environnements à la demande avec Kubernetes, pour répondre aux besoins des différents acteurs et parties prenantes d’un projet.

Pourquoi avons nous besoin d'environnements à la demande ?

L’une des raisons de mettre en place les environnements à la demande est la disponibilité de l'environnement. Lorsque l'on ne dispose que d'un seul environnement de test et qu'il y a de nombreuses équipes de développeurs, tester une fonctionnalité sur l'environnement de test devient fastidieux. En effet, les équipes ne peuvent pas tester simultanément une fonctionnalité touchant aux mêmes briques applicatives, sinon un problème de concurrence se pose.

Une des autres raisons pour mettre en place les environnements à la demande est leur stabilité. En effet, le code déployé sur l'environnement de test est souvent le code qui est le plus proche d’être déployé en production. Comme toutes les équipes testent leur code sur l'environnement de test, l’environnement est souvent instable et sujet au bug.

Avoir un environnement stable est plus un événement exceptionnel qu’habituel. Déployer du code en production devient compliqué, cela demande d'impliquer toutes les équipes de développement afin de résoudre les éventuels problèmes : ce n'est plus un acte anodin. Les environnements à la demande remédient à cette situation.

Les environnements à la demande permettent, par ailleurs, le développement et le déploiement de fonctionnalités de manière indépendante. Souvent, pour avoir un environnement stable, un calendrier est donné à toutes les équipes. Le calendrier permet aux équipes de se synchroniser pour rendre l'environnement de test ponctuellement stable afin de déployer le code en production.

Le calendrier pose un certain nombre de problèmes dont le suivant : le cycle de développement est le même pour toutes les fonctionnalités sur l'ensemble des équipes de développement.

Les fonctionnalités demandant un temps supérieur au temps imparti sont pénalisées car elles s’intègrent mal au cycle de développement et ainsi perturbent le cycle (introduction de bug ou une fonctionnalité qui n’est pas terminée sur l’environnement de test pas résoluble au moment du déploiement en production).

Des solutions existent comme le feature toggling mais la mise en place doit être pensée au début du projet, si l’architecture du code n’est pas pensée pour le feature toggling l'ajout demande beaucoup d’effort...

Kubernetes, pour construire et gérer des environnements à la demande

Kubernetes est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Si vous ne savez pas ce que c'est, je vous conseille d'aller voir notre page Technologie kubernetes sur le site de Padok et cet article pour y découvrir Kubernetes avec minikube, kind ou kubeadm.

Kubernetes est un outil adapté pour construire et gérer les environnements à la demande car déployer un environnement temporaire revient à déployer une version d'une application(ensemble de microservices). Kubernetes gère très bien le déploiement et la destruction de ressources. L'utiliser pour déployer un environnement à la demande est donc particulièrement pertinent.

Kubernetes intègre un mécanisme d'isolation des conteneurs que l'on nomme “espace de noms” (namespace). Les conteneurs qui sont dans un espace de noms, sont isolés des conteneurs qui n'appartiennent pas au même espace de noms.

Les espaces de noms peuvent ainsi être utilisés pour isoler les environnements les uns des autres et peuvent tout aussi bien communiquer entre eux si on le souhaite : on parle de soft multi tenancy.

Kubernetes permet aussi de simuler du hard multi tenancy grâce au système d'affinité entre les conteneurs et les nœuds du cluster ainsi qu'à la politique de communication (network policy) entre les conteneurs au sein du cluster.

Grâce aux ressources ingress (ressource interne à Kubernetes) , nous pouvons générer dynamiquement des URLs pour les fronts et les APIs, donnant aux personnes intéressées la possibilité d'interagir avec cette version de l'application.

Par exemple, si nous voulons déployer un environnement de test qui contient deux fronts, front 1 et front 2, et deux apis API, api 1 et api 2, sous l’url, on-demand-environment.padok.fr, les ingress nous permet d’associer facilement les urls on-demand-environment.padok.fr/env-1/front-1 et on-demand-environment.padok.fr/env-1/front-1 aux deux fronts et les urls on-demand-environment.padok.fr/env-1/api-1 et on-demand-environment.padok.fr/env-1/api-2 aux apis comme sur indiqué sur le schéma :

Les urls sont générées avec le déploiement des ressources dans Kubernetes. Nous n'avons donc pas besoin de gérer les urls des environnements à la demande Kubernetes le fait pour nous !

Cette fonctionnalité permet d'éliminer la nécessité de mettre en place des bastions (machine par laquelle nous passons pour les tunnels SSH, forwarding de ports, etc). Cela facilite le travail en interaction avec divers acteurs, ne disposant pas nécessairement d'un poste configuré à cet effet.

Kubernetes n'est pas la seule solution. Néanmoins, si vous l’utilisez déjà, mettre en place les environnements à la demande est simple. Si vous utilisez Kubernetes, vous avez très probablement mis en place un système d'alerting, de monitoring et de logging. Une fois le premier environnement mis en place, étendre l’alerting, le monitoring et le logging aux autres environnements ne nécessitent que peu de configurations supplémentaires : cela s'apparente à un effet d'économie d'échelle.

Exemple de mise en place d'environnement à la demande

Chez Padok, nous avons mis en place un système d'environnement à la demande sur un projet assez conséquent; il s'agit d'un projet qui implique de nombreuses personnes : sept équipes de développeurs y travaillent simultanément, dont plusieurs testeurs QA et une équipe d'ops de Padok gèrent l'infrastructure dans une philosophie Devops avec les développeurs.

Les développeurs travaillent sur 15 microservices qui communiquent activement entre eux et qui interagissent avec plusieurs applications tierces. Le nombre de microservices continue d'augmenter car le projet prend de plus en plus d'ampleur. Le code est organisé sous forme d'un dépôt unique (mono repository). Et une CI/CD complexe est mise en place sur le dépôt pour déployer les microservices, signe d'une certaine maturité du projet.

L'implémentation des environnements à la demande s'est faite par l'utilisation conjointe de Kubernetes et de la CI/CD en place, dans notre cas nous avons utilisé GitLab CI. Les avantages de Kubernetes ont déjà été décrites ci-dessus, l'utilisation de la CI/CD pour les environnements se justifie par les deux points suivants : amener la fonctionnalité des environnements à la demande au plus près du développeur et l'automatisation des tâches.

Pour que les environnements à la demande s'intègrent au mieux dans le flux de travail des développeurs, il ne faut pas modifier son flux de travail et il faut que l'utilisation des environnements ne passe pas par l'ajout d'un outil ou une interface supplémentaire.

La CI/CD est le bon choix car il s'agit de l'interface que les développeurs ont avec l'infrastructure. Grâce à la CI/CD, ils peuvent construire, tester et délivrer une nouvelle version de l'application et le déployer en production. Ajouter la création et la destruction des environnements à la demande dans la CI/CD semble pertinent.

Construire et détruire un environnement sont des tâches fastidieuses, répétitives et récurrentes. Laisser ces actions être exécutées par les développeurs ou par les ops fait de l’utilisation des environnements à la demande un point de souffrance et la fonctionnalité risque de n'être plus utilisée. C'est bien le contraire de ce que nous voulons surtout si l'on a investi des ressources considérables !

Automatiser la gestion s'avère nécessaire pour que la fonctionnalité subsiste et ne tombe pas dans l'oubli. La CI/CD est l'outil pour éliminer ces tâches pénibles et répétitives. Elle s'inscrit dans la philosophie DevOps dont un des buts est de faciliter la vie des développeurs. Intégrer la gestion des environnements à la demande à la CI/CD leur permet de s'émanciper de leurs tâches et de se concentrer sur ce qu'ils font de mieux : le développement de fonctionnalités.

La mise en place des environnements à la demande sur ce projet nous a demandé un travail de 3 mois pour se synchroniser avec toutes les équipes de développeurs, expliciter le besoin, conteneuriser les fronts, configurer les APIs et reconfigurer certaines applications tierces pour éviter tout conflit entre les différents environnements.

Grâce à Kubernetes, nous avons pu monter la fonctionnalité des environnements à la demande du côté de l’infrastructure et l'intégrer avec les outils et le flux de travail existant en peu de temps. La fonctionnalité n'est pas parfaite, il y a encore de nombreuses choses à améliorer voire à corriger, mais nous sommes convaincus de nos choix notamment celui de Kubernetes.

Grâce aux retours des développeurs nous espérons améliorer fortement leurs expériences de développement et l'outil en lui-même.

J'espère que tout au long de cet article, je vous ai convaincu de la pertinence de mettre en place les environnements à la demande et l'intérêt d'utiliser Kubernetes. Les environnements à la demande s'inscrivent dans la volonté d'améliorer la vitesse de livraison des fonctionnalités et l'expérience de développement.

De manière générale, ils s'inscrivent dans la philosophie Devops . Néanmoins les environnements à la demande ne viennent pas sans désavantage. Le coût que représentent les environnements à la demande est quasiment linéaire en fonction du nombre d’environnement à la demande.

Mais ils permettent une augmentation de la productivité des développeurs et potentiellement une économie. La mise en place des environnements à la demande ouvre la voie vers d'autres fonctionnalités encore plus intéressantes comme les test End to End (E2E).