Déploiement déclaratif d’applications Cloud Native sans compromis avec Kubernetes

La conception et le développement de produits numériques Web nous amènent depuis plusieurs années à déployer ces produits chez différents fournisseurs cloud : Amazon Web Services, Google Cloud et Azure.

Chacun de ces fournisseurs offre une solution clé en main de déploiement d’applications Cloud Native prenant en charge le provisionnement de containers Docker, la configuration de leurs variables d’environnement respectives ainsi que l’orchestration des processus de déploiements et autres opérations de gestion. Nous avons mis en production et maintenons plusieurs projets utilisant l’une ou l’autre de ces solutions mais depuis quelques années, nous nous tournons vers Kubernetes.

Kubernetes est une alternative qui se distingue en offrant un grand nombre d’avantages sans pour autant faire de compromis par rapport aux autres solutions.

À l’origine développé chez Google pour les aider à gérer leur immense flotte de containers déployés à travers leurs centres de données, Kubernetes évolue maintenant grâce à une communauté open-source vibrante et est utilisé par des milliers d’entreprises partout dans le monde pour accomplir la même chose, à une échelle évidemment beaucoup plus petite que celle de Google.

Avantage n° 1 : Philosophie déclarative (Infrastructure as code)

La philosophie derrière Kubernetes est intéressante. Il ne s’agit pas d’un outil d’orchestration traditionnel à qui on fournit une liste de tâches définies qu’il exécute ensuite (eg. A → B → C). Il s’agit plutôt d’un ensemble de processus indépendants et composables qui, continuellement, amène l’état d’un système vers un état désiré et exprimé de façon déclarative.

Supposons que nous ayons présentement deux instances de containers qui exécutent l’image foo:1.0.0. Nous souhaitons remplacer cette image par foo:2.0.0 tout en passant à quatre instances.

Plutôt que de demander impérativement à Kubernetes d’effectuer ces étapes séquentiellement :

1. Trouver les instances présentement déployées avec l’image foo:1.0.0 ;
2. Déployer quatre nouvelles instances qui roulent l’image foo:2.0.0;
3. Lorsque toutes les nouvelles instances sont prêtes, arrêter les anciennes trouvées à la première étape;
4. Rendre disponibles les nouvelles instances.

On exprime déclarativement l’état du système que nous souhaitons atteindre :

Il devrait y avoir quatre instances déployées avec l’image foo:2.0.0.

En utilisant cette méthode déclarative, Kubernetes prendra la décision lui-même pour amener l’état actuel (les deux containers déployés avec l’image foo:1.0.0) vers l’état déclaré.

Ultimement, les étapes seront très similaires à celles listées plus haut, mais Kubernetes les effectuera automatiquement en arrière-plan et il fera tout pour qu’elles soient le plus optimales possible. Il n’y a rien de magique par contre; si on veut que Kubernetes ne provoque pas de downtime lors du déploiement, il faut bien le configurer pour qu’il soit en mesure de connaître l’état des instances et savoir quand elles sont réellement prêtes.

Bref avec Kubernetes, on n’effectue pas d’opérations d’orchestration. On déclare un état du système désiré et Kubernetes effectue les opérations nécessaires de la façon la plus optimale pour atteindre cet état.

Avantage n° 2 : Portabilité et partage de connaissances

Kubernetes est complètement agnostique du fournisseur cloud chez qui il est utilisé. Ce n’est pas une solution propriétaire propre à un fournisseur spécifique. Cette portabilité d’expertise nous confère un avantage indéniable.

Pour une entreprise comme Mirego qui déploie et maintient des dizaines d’applications Cloud Native dans des environnements toujours différents, plus nous pouvons nous appuyer sur une technologie possédant cette indépendance, plus nous nous assurons d’être efficaces dans notre partage de connaissances et dans notre amélioration continue.

Le choix du fournisseur cloud chez qui un produit Web sera déployé n’apporte pas de complexité supplémentaire et permet donc à nos équipes de développement de rester polyvalentes en n’ayant pas à se spécialiser dans chacune des solutions propres à chaque fournisseur. Évidemment, cela ne veut pas dire que Kubernetes n’est pas complexe, au contraire. Cela veut dire que le temps que nous avons passé et que nous passons à maîtriser cette complexité profite à plus de nos clients, peu importe leur situation.

Nous avons même mis en place un projet gabarit pour regrouper nos bonnes pratiques en un seul endroit et nous prévoyons publier ce projet bientôt pour en faire profiter la communauté.

Kubernetes nous permet de concentrer nos efforts de développement et de maintenance à bâtir les meilleurs produits numériques possibles, peu importe le fournisseur cloud chez qui ils seront déployés ou la stack technologique qu’ils utilisent (Node.js, Elixir, Ruby, PHP, etc.).

Avantage n° 3 : Solution managed chez les fournisseurs

Le fait de ne pas être lié à un fournisseur cloud spécifique ne signifie pas pour autant que nous nous retrouvons laissés à nous-mêmes chez les principaux fournisseurs — au contraire!

Kubernetes est devenu une référence assez importante dans la communauté DevOps pour que les trois fournisseurs cloud majeurs (Amazon Web Services, Google Cloud et Azure) comptent maintenant une solution Kubernetes managed au sein de leur offre de services.

Ces solutions sont un peu plus dispendieuses de par leurs frais de gestion, mais cela signifie que nous n’avons pas de machine à provisionner ni de mises à jour de sécurité manuelles à effectuer sur celles-ci, ce qui nous sauve une importante quantité de temps et nous procure une plus grande confiance envers la stabilité et la sécurité de notre infrastructure.

Avantage n° 4 : Communauté et outillage unifié

Kubernetes possède un ensemble d’outils pensé par des développeurs, pour des développeurs, qui nous permet d’être productifs et efficaces dans nos tâches d’introspection et de manipulation de cluster.

Les outils CLI (command-line interface), souvent très appréciés par les développeurs, ne sont pas considérés comme des citoyens de deuxième classe; ils sont les fondations mêmes de l’écosystème Kubernetes et servent de base à la communauté pour le développement d’outils additionnels.