Platform engineering : l'expérience de Believe pour le développement Kubernetes
Publié par Clément Bohic le - mis à jour à
Passé sur Kubernetes dans le cadre d'une migration GCP, Believe a maximisé les abstractions pour autonomiser ses populations de développeurs.
Avec GCP, faisons table rase ? Ce fut l'une des motivations* de Believe.
L'entreprise française, qui connecte artistes et labels sur les plates-formes de streaming, avait précédemment une grosse partie de sa plate-forme sur AWS - et le reste on-prem. Des briques sujettes, au fil du temps, à un empilement de couches.
Le passage chez Google Cloud a induit une uniformisation des ressources (Cloud SQL pour la partie base de données, entre autres) et des process. Il a aussi accompagné le passage à un mode de développement en conteneurs, avec le trio Docker-Kubernetes-Helm.
Face à la courbe d'apprentissage pour les développeurs, Believe a activé une démarche de platform engineering, maximisant les abstractions pour autonomiser cette population. Christophe Biguereau et Mélanie Rao, tous deux SRE, sont revenus sur cette approche dans le cadre de la conférence DevOps Rex.
Generic-Kube, un chart Helm maison au coeur de la démarche
Étant les plus proches de leurs apps, les développeurs ont été désignés comme les mainteneurs des images Docker. Believe leur a fourni des images de base. PHP et Java essentiellement, avec diverses extensions, Docker Bake permettant ensuite de construire des déclinaisons (CLI, FPM, avec ou sans Composer, etc.) de manière déclarative.
L'ensemble est poussé sur le registre de GCP. En plus de poser des bases communes, ce système offre une capacité de gestion en interne, par exemple pour la résilience (déploiement sur plusieurs régions cloud) et pour le contrôle des versions (indépendance vis-à-vis des dépôts extérieurs).
Believe est parti du principe que les développeurs sont censés connaître les concepts Kubernetes (qu'est-ce qu'un déploiement ? un secret ?...), mais pas forcément comment les définir. Aussi leur a-t-il fourni une interface plus simple, en l'occurrence du YAML. L'entreprise a créé son propre chart Helm, nommé Generic-Kube. Les devs fournissent la configuration et une configmap est générée, à partir de labels prédéfinis dans le Generic-Kube.
Pour le déploiement, Believe a créé des profils en fonction des patterns qu'il a pu observer. Les labels intégrés permettent des usages dans le domaine du FinOps et de la supervision (en l'espèce, intégration dans Datadog). "On a aussi du scoping par namespace", précise Mélanie Rao. Un schéma JSON est par ailleurs fourni pour recenser tous les paramètres à disposition des développeurs.
Initialement, le déploiement des dépendances hors Kubernetes (buckets GCP, topics Confluence...) reposait sur du code Terraform. Generic-Kube a accompagné la transition vers Crossplane, unifiant ainsi l'interface. Et apportant là aussi un scoping par namespace, "même si c'est plus dur à mettre en place", concède Mélanie Rao.
La gestion de l'évolution rapide de Generic-Kube (de nouvelles versions quasiment tous les jours) est un autre défi : pas évident de'assurer des non-régressions. Et de la mise à jour du côté des équipes de dev, même si Believe a automatisé ses tests.
Vers un developer lab
Sur GitLab, même concept que sur Docker : les devs ont l'ownership de leurs pipelines. Du code réutilisable leur est tout de même fourni, sous la forme d'une trentaine de configurations stockées dans un dépôt central. Ces "building blocks", comme les nomme Believe, gèrent par exemple le tagging des images, leur push sur GCP et la récupération de tokens Vault pour l'authentification sur GitLab. Argo CD surveille l'ensemble et met à jour les clusters GKE sur lesquels tournent les applications.
Pour gérer la montée de version des services, Believe s'appuie sur Renovate Bot. Un outil "assez simple à intégrer", selon Christophe Biguereau, et qui permet aussi, avec différents types de configurations, de gérer toutes les dépendances.
Au niveau de l'entreprise, un programme Be Odyssey a aidé à aligner les équipes et les objectifs. Pour accompagner le mouvement d'autonomisation des développeurs, Believe a travaillé ses documentations. Y compris en mettant en place une FAQ. "C'est un peu simple, mais on s'est rendu compte que beaucoup des équipes de dev posaient les mêmes questions aux différents SRE", fait remarquer Mélanie Rao. S'y est ajoutée une web app fondée sur Backstage (portail développeur de Spotify) pour recenser les services offerts au niveau de la plate-forme. L'heure est désormais à la construction d'un developer lab censé centraliser l'activation des différentes couches d'abstractions mises en place. Et ainsi favoriser l'onboarding des nouveaux devs.
"On a proposé, durant la transformation, d'intégrer la partie qualité, précise Christophe Biguereau. Grâce à de l'automatisation au niveau du CI/CD et à des produits externes, on a mis des gates. On a aussi travaillé sur un cadre commun pour que tout le monde ait les mêmes objectifs sur tous les langages."
Believe a des scans réguliers des apps sur la partie GitLab CI. Il travaille sur l'analyse au niveau des images. Le test et la validation des charts Helm se font avec Ginkgo et Gomega.
* "Il y a aussi eu des choix budgétaires [effectués] avant notre arrivée", reconnaissent les deux SRE à propos de la décision d'aller sur GCP.
Illustration principale générée par IA