[Retours Tech&Wine] REX: transformer de l'Ansible+docker-compose en Helm+k8s - 3/5

Kévin Delbegue était à la "Tech & Wine" qui se tenait au château de Montchat le 18 juin dernier. Découvrez ici son retour sur la conférence de Boris Maras.

Pour son premier talk, Boris Maras, nous présente son retour d’expérience issu d’une mission freelance qu’il a réalisé pour un de ses clients.

Pour commencer, nous tenons à remercier Boris pour le temps consacré à nous partager son expérience et sa connaissance. Cet article est une preuve de remerciement.

Il a transformé une stack “Ansible + Docker-Compose”, comprenant une trentaine de conteneurs environ, avec des outils et technos comme : Java Spring Boot, Angular, PostgreSQL, Kafka, Apache Spark, Keycloak, etc…

Les déploiements et mises à jour de cette stack étaient réalisés avec Ansible, principalement “on-prem” chez leurs clients.

Cette architecture et ce fonctionnement présentaient sûrement des point forts et points faibles, on peut par exemple imaginer la simplicité de gestion de la stack, et à l’inverse le manque de scalabilité ou de résilience.

Afin de répondre aux besoins de résilience, de disponibilité et de scalabilité, Boris a décidé de tester Docker Swarm dans un premier temps, avant de se tourner vers Kubernetes.

Le choix “Docker-Compose + Ansible” vs “Kubernetes + Helm” se présente également chez WanadevDigital dans le cadre de certains projets.

Comme nous, au cours de son projet, il a été amené à tester et utiliser des outils comme Kompose, afin de “traduire” une configuration Docker Compose en manifests Kubernetes. En complément, il souligne une fonctionnalité “Early Access” dans Docker Compose : bridge, qui semble offrir un comportement similaire à Kompose.

À travers les différents exemples concrets, on distingue les bien les avantages et inconvénients que propose chaque manière de déployer.

Pour Docker-Compose + Ansible :

• Contrôle total des configurations par les développeurs, possibilité de modifier n’importe quelle option dans le fichier
• “Simplicité” offerte par la configuration en un seul fichier
• Cependant, les limites de résilience se font rapidement ressentir
• La configuration en un seul fichier avec une trentaine de conteneurs rend la maintenance complexe

De l’autre côté avec Kubernetes + Helm :

• Il est maintenant possible de créer des “packages” avec un versionning SemVer
• Un mécanisme de “paramètres” / “options” est apporté grâce aux Chart Helm
• Le nombre de fichiers augment drastiquement avec les manifests Kubernetes
• Les manière de configurer l’application sont plus “standardisées”

Un gros enjeux était : comment remplacer les opérations réalisées par Ansible ?

De nombreuses manière de faire existent, comme par exemple :

• Exécuter les scripts Ansible au sein des containers
• Utiliser les fonctionnalités “pre-install” et “post-install” hooks fourni par Helm
• Se connecter aux pods avec le plugin kubectl d’Ansible
• …

La solution retenu s’articule essentiellement autour de la fonctionnalité d’initContainers offerte par Kubernetes. En effet, grâce à ces containers qui s’exécutent avant le(s) pod(s) de l’application, il est possible de réaliser certaines actions avant même le démarrage du container.

Malheureusement cette méthode n’est pas magique et ne peu répondre aux cas ou la configuration doit se faire une fois l’application démarré, avec une API par exemple.

Il a cependant réussi à utiliser des outils comme https://github.com/tianon/docker-postgres-upgrade, pour mettre à jour une version majeure de base de donnée PostgreSQL, avant son démarage, via un initContainer par exemple.

Une autre grande problématique qu’il a rencontré, et qui est surement rencontré par de nombreuses autres personnes, Wanadev y compris, c’est la gestion des “secrets” dans le code source.

Il est évidemment pas recommandé de stocker des “secrets” en clair dans une répertoire Git par exemple, encore moins avec un accès partagé à plusieurs collaborateurs…

Pour cela, Ansible fournit un outil très pratique : Ansible-Vault. Cette solution permet le chiffrement de fichiers complets, mais aussi de certaines clés uniquement dans un fichier YAML par exemple. La seule condition étant de ne pas versionné la clé secrète servant au chiffrement des “secrets”.

Cette utilisation dans Kubernetes ou même Docker est assez complexe à mettre en place, surtout pour éviter de divulguer la clé secrète.

Grâce à un outil nommée https://github.com/getsops/sops, il est possible de chiffrer des fichiers complets ou des clés spécifiques d’un fichier YAML. Permettant ainsi une intégration plus fiable dans l’écosystème “Cloud Native”. La solution https://github.com/bitnami-labs/sealed-secrets pousse la problématique encore plus loin, surtout sur l’aspect sécurité, ou seulement le controller dans le cluster est capable de lire les “secrets”.

En conclusion de cette riche présentation, Boris souligne les points positifs et négatifs qu’il a retour de son expérience, parmis lesquels on retourve par exemple :

• Le besoin de résilience du client qui est totalement satisfait
• D’autres clients réclament cette nouvelle stack
• La gestion offerte par Kubernetes en tant que Plateforme
• L’abstraction de l’OS possible grâce à Kubernetes
• La courbe d’apprentissage de Kubernetes est assez importante
• Peut être overkill pour certains petits clients
• Les couches supplémentaires d’abstraction représentes des potentiels problèmes en plus

Chez Wanadev nous allons pouvoir nous inspirer de ce retour d’expérience afin de faire évoluer nos stacks de déploiements, notamment celles impliquant des conteneurs. Mais aussi éviter certains pièges grâce aux anectodes et tips mentionné dans ce talk.

Merci encore à Boris pour sa conférence riche en connaissances et en retours d'experience.

Suite à la journée "Tech & Wine", plusieurs articles sont disponibles. N'hésitez pas à aller les consulter :

• DevOps is Dead, les -Plateformes- sont le futur - 1/5
• La checklist ultime pour rendre vos applications cloud native !” - 2/5
• Défier l'entropie : réécrire ses applications ou reprendre le contrôle ? - 4/5
• Vers un Nouveau Paradigme : Platform Engineering, Docker, DevOps et la Gestion de l'Entropie - 5/5