Retour sur Cloud Nord 2022 (deuxième partie)

Retrouvez la première partie de notre compte-rendu ici.

DailyClean est une app permettant d’éteindre ponctuellement ou de manière planifiée des environnements Kubernetes. Une API tourne dans chaque namespace et il peut également y avoir un front. Ce front met en page l’ensemble des déploiements présents dans chaque namespace, avec le statut, le nombre de réplica et une estimation des coûts. On peut également y planifier des jours et des heures d’extinctions et d’allumage. Cette planification va créer un cronjob qui va communiquer avec l’API Kube afin d’éteindre les déploiements. 

Une future fonctionnalité sera de pouvoir ajouter des labels sur les déploiements qui ne doivent pas être affectés par DailyClean. C’est également un outil qui est intéressant de coupler avec flux afin de garder la persistance des configurations des déploiements. 

Talk intéressant de Loïc Knuchel qui nous a présenté Azimutt.app. Azimutt est un outil qui permet d’explorer et d’organiser visuellement les tables des base de données SQL sous la forme de diagrammes entité-association (ERD).

Il s’avère particulièrement utile pour découvrir les grosses bases de données et les bases de données “legacy”. Azimut a d’abord été développé pour les besoins de Doctolib et est maintenant disponible pour tous sous licence libre (MIT).

Loïc nous a présenté les (nombreuses !) fonctionnalités de l’outil et ses avantages par rapport aux solutions pré-existantes. Cerise sur le gâteau, Azimut est développé avec Elixir et Elm.

Maxime et Quentin sont revenus sur la migration menée par La Redoute d’un hébergement classique on premise vers Google Cloud Platform.

Cette conférence très intéressante expliquait les succès (plus grande stabilité, passage à l’échelle amélioré, pas d'incidences lors de pics de traffic), mais aussi les limites et petits désagréments liés à une telle externalisation.

Stéphane nous a présenté ce qu’est un opérateur, qui se compose à la fois d’une CustomResourceDefinition (CRD), de l’API associée, de CustomResources (CR), et d’un controller. Il y a généralement un contrôleur par CRD, bien qu’il soit possible de contrôler plusieurs CRD depuis le même contrôleur, mais cela complique la logique et la maintenabilité. Les opérateurs peuvent intervenir sur plusieurs périmètres. Les plus courants sont l’installation, la désinstallation et la mise à jour d’une application. Pour des usages plus avancés, les opérateurs interviennent également dans la sauvegarde et la restauration, l'auto-configuration, l'observabilité et la scalabilité.

Il existe de nombreux frameworks pour créer son opérateur. Ceux-ci nous permettent de nous concentrer sur notre métier en implémentant nativement, entre autres, la boucle de réconciliation. Le plus connu d’entre eux est Operator SDK, qui permet de développer un opérateur avec 3 langages différents : HELM, Ansible ou Go. L’opérateur HELM n’apporte pas grand chose par rapport à l’utilisation directe de HELM, mais permet de facilement migrer ses charts sous forme d’opérateurs pour homogénéiser le déploiement de ces applications par rapport aux autres opérateurs qu’on pourrait avoir. Cela simplifie aussi l’expérience utilisateur : on ne modifie plus que les values du chart via le CustomResource, en masquant tout le reste des manifests YAML. Stéphane nous a ensuite montré quelques exemples, en Go ou en Java.

Une attention particulière a été portée sur la gestion des finalizers : ils permettent de réveiller l’opérateur en cas de suppression d’un objet. L’opérateur va pouvoir effectuer des actions pour correctement terminer l’application, puis enlever le finalizer, ce qui va permettre à Kubernetes d’effectivement supprimer l’objet. Il est donc important de créer ou supprimer les finalizers au bon moment, pour éviter de se retrouver bloqué.

Clément et Ismaël nous ont proposé une initiation à FluxV2, un outil intéressant pour mettre en place une démarche GitOps dans son organisation. Ils sont revenus sur les principes mêmes qui sous-tendent que cette démarche généralement mal comprise, y compris parfois dans le métier. Le GitOps est en effet trop souvent assimilé à une simple CI/CD alors que le paradigme est assez différent. Il s’agit en fait de découpler complètement la CI et la CD.

Le GitOps fonctionne sur un mode déclaratif qu’on retrouve aussi chez Kubernetes, ce qui leur fait d’ailleurs dire que cet orchestrateur est le seul du genre à pouvoir entrer dans la catégorie des outils GitOps. En effet, il ne s’agit pas de décrire de façon impérative les ressources nécessaires pour un cluster, mais à énoncer une volonté que FluxV2 aura alors à sa charge de mettre en œuvre sur un cluster à l’aide d’une boucle de réconciliation. Le dépôt git devient alors la source unique de vérité quand il s’agit de décrire un cluster et ses ressources.

Ils voient dans ce type d’outil GitOps de nombreux intérêts :

L’effort pédagogique des deux intervenants était très appréciable, il y avait une vraie volonté de transmission du savoir. Le workshop était assez dense mais on peut retrouver toutes les instructions sur le dépôt Github qui est de fait une excellente ressource pour quiconque veut s’initier à la démarche GitOps. FluxV2 est un outil utilisé au quotidien chez Les-Tilleuls.coop et ce workshop nous a confortés techniquement et stratégiquement dans ce choix.

Nous avons passé une excellente journée à Euratechnologies, que nous retrouvions deux semaines après avoir organisé la API Platform Con 2022. Cet événement était l'occasion pour nous de présenter notre équipe SRE (qui s'est agrandie récemment avec l'arrivée de Hugo Moubèche), et de présenter à la communauté notre toute nouvelle offre Cloud. En effet, en addition à nos expertises et contributions reconnues, nous proposons désormais un accompagnement dans la gestion, le maintien et la sécurisation des infrastructures. N'hésitez pas à nous contacter pour en savoir plus ! Bravo à l'équipe d'organisation de Cloud Nord pour cette journée qui s'est terminée par un atelier houblonné au sein de l'Atrium. Comptez sur notre présence l'année prochaine !