[DevFest] Le GitOps dont vous êtes le héros

19 novembre 2021

_année_2021 _mois_nov. conférence github kubernetes lille

source

Par Louis Tournayre

Commençons notre aventure avec un site qui ne marche pas bien. La direction demande aux ops de faire une version Halloween, qui a été livrée après Halloween. Comment livrer la version de Noël ? La direction a entamée des séances de brainstorming. Les développeurs aimeraient faire des livraisons plus petites, et disposer de plus de temps pour effacer la dette technique. Pour ça, il faut faire plus de livraisons, et que ce soit des non-événements. Dans l’équpe d’ops, c’est la cata, parce qu’il faut passer des documents de livraison à quelque chose de plus rapide. En en discutant avec les collègues, Louis propose de packager les applications dans des conteneurs Docker livrés dans Kubernetes en livrant grâce aux principes GitOps.

NOTE: Toute la présentation est animée façon livre dont vous êtes le héros, ce qui dynamise bien un sujet qui arrive au moment de la digestion.

GitOps n’est pas une révolution, c’est simplement l’application des concepts de livraison continue au monde Kubernetes grâce à la boucle de réconciliation. On a deux principes fondamentaux . Git est la source de vérité . Chaque environnement est décrit dans une branche différente.

Et dans chaque branche, on ne met que l’état désiré de l’infrastructure. Et évidement, on ne touche pas à l’infrastructure à la main.

GitOps, c’est un peu l’anneau unique du déploiement dans K8s. Pour ça, on va déployer un opérateur Kubernetes ArgoCD, qui va lire les informations depuis les dépôts Git configurés pour appliquer les changements.

Et Louis se lance dans une démo d’installation d’argocd dans un cluster Kubernetes. A laquelle suit logiquement le déploiement d’une application dans K8s avec ArgoCD. Et l’interface d’argoCD est vraiment bien faite : on y voit toutes les ressources nécessaires au fonctionnement de l’application (ce qui nous montre que l’application est correctement déployée). Hélas, pour l’instant, on ne déploie que l’environnement de prod. Comment faire pour déployer ces autres environnements pour lesquels les URLs, le nombre d’instance, les connexions aux bases de données. On a le choix entre Helm et Kustomize.

Helm fournit le templating, le packaging, et un système de gestion de dépendances. Testons ce déploiement avec YAML. Ca marche bien. A noter qu’ArgoCD rafraîchit les différentes branches toutes les 3 minutes.

Passons maintenant aux secrets (les mots de passe JDBC, par exemple) potentiellement contenus dans l’application. On pourrait utiliser Vault, qui est très sophistiquée et marche très bien, mais notre équipe n’a pas encore la compétence. On ne doit pas utiliser les secrets natifs de K8s, puisqu’il s’agirait simplement d’encoder les mots de passe en base 64 pour les stocker dans notre repository Git. C’est une mauvaise idée. On va donc utiliser des "sealed secrets", c’est-à-dire des secrets chiffrés via des clés asymétriques. Il y a quelques subtilités dans la gestion de ces sealed secrets (en termes de namespaces) que Louis détaille.