Par Romain Boulanger.
Tout comme l’année dernière, j’ai eu l’occasion de participer en tant que Speaker au Voxxed Days Luxembourg sur un sujet GitOps intitulé « Argo et Flux sont dans un Kargo, lequel tombe à l’eau ? ».
Une belle occasion pour moi de vous raconter la première journée de cette conférence, à laquelle j’ai eu l’opportunité d’assister. Cette conférence s’est déroulée sur deux jours, respectivement du 20 au 21 juin 2024.
Pour rappel, cet événement regroupe une multitude de passionnés sur plusieurs thématiques : développement logiciel, méthodes Agile, Cloud, Big Data, sécurité, DevOps, automatisation, etc. Que vous soyez débutant ou senior, il y a toujours de belles choses à découvrir !
Au menu, plusieurs types de format : Keynote pour le début et fin de la journée, University (2 heures), conférences (50 minutes), Tools in Action (25 minutes) et Launch Talk (15 minutes).
Dans la suite de cet article, revivez avec moi les différentes keynotes et conférences que j’ai pu suivre.
Par Pierre Henriquet
On commence par une keynote d’ouverture totalement passionnante sur les prouesses informatiques dans la découverte de l’espace.
L’objectif était aussi de parler de bugs qui ont causé quelques dommages dans la perte des communications avec les robots envoyés dans l’espace.
Cette course effrenée de la découverte de l’espace commence en 1957 avec le satellite Spoutnik qui reste la première machine à dépasser l’atmosphère.
Plus tard, c’est au tour de Viking 1 qui est envoyé pour découvrir la surface de Mars, notamment la présence du mont Olympe et du plus grand canyon se nommant Valles Marineris en 1979.
Malheuresement, le programme s’arrête en 1982 à la suite d’une mise à jour censée réduire l’utilisation de la batterie. En effet, lors de la mise à jour, les données permettant de pointer l’antenne vers la surface de la terre sont écrasées définitvement, ce qui rend le système totalement inopérable.
Une autre erreur informatique a été réalisée avec le programme Mars Climate Orbiter entre 1998 et 1999 dont l’objectif était d’étudier la planète Mars. Seul problème, cette sonde devait réduire sa distance de l’orbite en passant par l’atmosphère de Mars de manière à freiner progressivement et économiser du carburant.
L’erreur commise est dans le sous traitement d’un composant de la NASA à Lockheed Martin qui travaillait en livre-force alors que la NASA travaille avec le système internationnal c’est à dire en Newton.
Pierre a ensuite parlé de plusieurs découvertes comme la lune Titan, un satellite de Saturne, qui ressemble étrangement à la Terre dont l’objectif sera d’y aller dans quelques années avec des robots capables d’étudier le fonctionnement de cette dernière.
En parlant de robot, il en existe de plusieurs types comme le bras Canadarm 2 de 2001 au sein de la station spatiale internationale ou encore le Robonaut 2 de 2011 permettant d’aider les astronautes dans des tâches où il est nécessaire de porter du matériel lourd.
Pour terminer, Pierre conclut avec les sondes Voyager qui est un programme lancé en 1977 permettant d’explorer le système solaire. Deux sondes sont concernées par ce programme, toutes deux équipées de puces de microcontrôleur, de 70Ko de mémoire et d’un code informatique écrit à la base en FORTRAN 5 !
Il faut dire que ces deux sondes sont toujours en fonctionnement malgrès quelques déboires récents liés à plusieurs corruptions de données, il a fallu par exemple les patcher à 24 millards de km de distance avec un débit de 20 octets par seconde et un ping de 45 heures ! Totalement incroyable quand on y pense…
Par Henri Gomez
Henri Gomez a présenté une vision du Site Reliability Engineering (SRE) qui va au-delà des idées reçues.
Pour Google, le SRE est un ingénieur logiciel qui crée de la valeur par l’automatisation systématique. Henri a souligné l’importance des 4 golden signals : erreur, trafic, saturation et latence, dont le dernier est essentiel pour valider la qualité du service.
Les missions du SRE incluent l’outillage, l’observabilité (en mettant l’accent sur une bonne journalisation), ainsi que l’architecture. Néanmoins, de nouvelles missions émergent, telles que la gestion de la performance, la planification de capacité, et le FinOps.
Henri a ensuite abordé plusieurs mythes entourant le SRE :
Le mythe que le SRE façon Google est applicable partout en soulignant que Google reste une boîte de tech qui fait des produits techs pour des techs. Il y a donc des choses à adapter selon les contextes ;
Le mythe du super héros qui connaît tout, alors que les SRE ont une expertise sur une stack technique complexe mais ne peuvent pas maîtriser l’ensemble des langages, frameworks et outils ;
Le mythe du détecteur de bug, en soulignant l’importance des SLI (Service Level Indicators) et de la collaboration avec les équipes de développement ;
Le mythe du bouclier ultime, en rappelant que la sécurité est l’affaire de tous, même si certains domaines comme le pentesting restent spécialisés ;
Le mythe de l’ops qui fait du dev, en précisant que les SRE ne sont pas des experts dans tous les domaines mais peuvent aider les développeurs à trouver les problèmes jusqu’au code.
Henri a également clarifié la confusion courante entre SRE et DevOps, ce dernier étant plus axé sur la création d’infrastructure et l’automatisation.
Pour réussir en tant que SRE, il faut un environnement reproductible et prédictible, une bonne compréhension des SLA, SLI et SLO, et être à l’écoute pour renforcer la résilience.
L’organisation doit équilibrer juniors et seniors, avec un périmètre bien défini. De plus, les soft skills sont cruciales : écoute, communication, capacité à convaincre et à apprendre.
Enfin, Henri recommande d’ajouter progressivement des outils en cohérence avec les problématiques rencontrées, plutôt que de tout implémenter d’un coup.
Cette présentation offre une vision équilibrée et réaliste du rôle de SRE, démystifiant certaines idées reçues tout en soulignant l’importance de cette fonction dans les organisations modernes.
Par Dotan Horovits
La présentation utilise Jenkins comme exemple pour illustrer l’importance de l’observabilité dans les pipelines CI/CD. Dotan souligne plusieurs questions cruciales à se poser concernant les échecs de pipeline, telles que :
L’accent est mis sur les métriques DORA pour DevOps, notamment la fréquence de déploiement en production et le Lead Time for Change (temps entre un commit et sa mise en production).
Le manque d’observabilité rend difficile l’évaluation de ces métriques. Dotan propose une approche en quatre étapes pour améliorer l’observabilité :
Il souligne que le CI/CD ne se limite pas à l’outil utilisé et recommande l’utilisation du tracing pour mesurer la performance des agents.
Pour cela, il est possible d’utiliser OpenTelemetry, en configurant le plugin Jenkins associé, pour stocker les données dans le backend Jaeger.
Pour aller plus loin, Dotan suggère de tracer des outils comme Maven pour la récupération et la gestion des dépendances de manière à étuder tout défaut qui pourrait survenir lors de cette phase sur les performaces des agents de CI/CD.
Il recommande également de surveiller l’environnement CI/CD, à savoir l’infrastructure, en collectant des métriques avec Telegraf et le plugin Prometheus, puis en les visualisant ces dernières avec Grafana.
Enfin, Dotan souligne qu’il est fondamentale de traiter la CI/CD comme un élément à part entière de la production, en lui appliquant les mêmes pratiques d’observabilité.
Par Mehdi Boissat-Bron
La présentation commence par un rappel sur l’Agilité, en mentionnant l’historique avec la sortie du manifeste pour le développement agile en 2001.
Par la suite, Mehdi passe ensuite en revue les grandes séances propres à la méthodologie SCRUM comme le Sprint Planning Meeting,Daily Standup Meeting, le Backlog Refinement, etc.
Un point important soulevé dans l’estimation des tâches des équipiers est de ne pas utiliser le temps comme mesure, mais plutôt des points de complexité pour éviter de se mettre une pression inutile par rapport à une notion temporelle.
De plus au sein de SCRUM, Le rôle du Scrum Master est comparé à celui d’un aiguilleur du ciel, soulignant son importance dans la coordination et la facilitation du processus de livraison de nouvelles fonctionnalités.
Une bonne pratique recommandée par Mehdi est d’avoir une session de backlog refinement technique avec l’équipe SCRUM pour être beaucoup plus efficace lors du véritable backlog refinement. Cette session vise à :
La présentation se conclut sur l’importance de savoir s’adapter au contexte, rappelant ainsi l’un des principes fondamentaux de l’agilité.
Par Valentin Dumas
Cette présentation se concentre sur l’utilisation de l’IA pour la génération de tests, en mettant l’accent sur les tests unitaires dans un premier temps. Valentin aborde les questions de qualité du code et de régression, soulignant l’importance de ces aspects dans le processus de développement.
L’IA peut être particulièrement efficace pour générer des tests unitaires en se basant sur du code déjà écrit notamment grâce à l’outil Codiumate qui permet de récupérer le contexte du projet en transmettant les demandes à ChatGPT 3.5 ou 4.
Quelques limites avec les tests d’intégration sont à prevoir cependant : L’IA est moins efficace pour ce type de besoin, nécessitant plus d’intervention humaine pour enrichir les tests générés. Certainement à cause des différentes interactions entre composants.
Cette approche vise à améliorer la qualité du code et à réduire les risques de régression, tout en optimisant le temps des développeurs dans le processus de test sans négliger les interactions humaines pour définir la couverture de code.
Par Denis Germain
La présentation commence par un rappel de ce qu’est Kubernetes de telle sorte à avoir une déinition conmnune de l’outil.
Dans la suite, Denis va créer son propre cluster Kubernetes de zéro pour explorer en détail l’ensemble des composants. Pour ajouter une petite couche de complexité, il utilise des composants en version alpha et release candidate.
Quelques pièces d’infrastructures sont déjà déployées en amont comme les machines virtuelles, les certificats et les binaires nécessaires à l’installation du cluster.
Chaque composant est installé à tour de rôle :
Cette présentation offre ainsi une compréhension approfondie de l’architecture de Kubernetes, en mettant en lumière le rôle et l’importance de chaque composant dans le fonctionnement d’un cluster.
Par moi 🙂
Voici un résumé du sujet que j’ai eu l’occasion de présenter cette année. Celui-ci parle de GitOps et plus spécifiquement de GitOps au sein de Kubernetes.
Grâce à l’approche Pull, il est possible de tirer parti de la boucle de réconcialiation de Kubernetes permettant de syncrhroniser via un opérateur, comme Argo CD, le contenu du cluster avec la source de vérité associée à Git regroupant nos objets à déployer.
Sur le marché, on retrouve deux outils très en vogue actuellement avec cette approche : Argo CD et Flux CD. Chacun possédant ses forces :
Argo CD bénéficie d’une interface graphique livrée par défaut où il est possible de visualiser ce qui a été déployé au sein du cluster. Il est possible d’utiliser des ressources personnalisées (CRD) permettant de simplifier le déploiement de nos ressources comme les AppProject, Application ou encore les ApplicationSet.
Flux CD dispose de contrôleurs permettant de gérer le cycle de vie d’applications déployées avec du Helm, Kustomize ou encore Terraform par exemple. De plus, il est possible d’en ajouter pour étendre l’opérateur. Enfin, l’approche de Flux est très native par rapport aux concepts de Kubernetes notamment dans la gestion des permissions.
Au-delà de ces différentes informations qui permettent de faire choix entre ces deux outils, comment associer les deux ? C’est là que je vous ai présenté Flamingo, un outil open-source associant Argo CD et Flux CD avec la possibilité de choisir l’une ou l’autre des boucles de réconciliation en fonction de vos besoins.
La deuxième partie de cette présentation se concentre sur la gestion des environnements en utilisant l’approche GitOps, avec une utilisation de fichiers ou dossiers pour représenter les environnements au sein d’une branche spécifique.
Néanmois, le monde GitOps manque d’outils permettant d’avoir une vue centralisée orchestrant les changements entre environnements. C’est pourquoi, Kargo, outil open-source encore en développement à un grand potentiel pour répondre à cette problèmatique notamment grâce à sa vue unifiée et la promotion de changements entre environnements.
Comme à chaque fois dans nos domaines, il convient de choisir le bon outil en fonction de votre besoin sans vouloir tout utiliser au risque de faire fausse route. Enfin, il est toujours important de rester à l’écoute de nouveaux outils permettant de répondre à des problématiques existantes.
Par Grace Jansen
Pour commmencer, Grace Jansen propose une analogie entre le diagnostic médical et l’analyse des applications cloud-natives pour détecter les problèmes. Elle met l’accent sur l’importance de l’observabilité, en la comparant à l’examen médical d’un patient.
Cette observabilité repose sur trois piliers principaux :
Elle repose sur trois étapes clés pour être utilisée efficacemment :
Pour répondre à ce besoin d’observabilité, Grace met en avant l’utilisation de MicroProfile pour Java, qui offre des API cloud-natives prêtes à l’emploi.
Une partie importante de la présentation est consacrée à OpenTelemetry, de dernier est décrit comme :
Pour finir, Grace souligne qu’OpenTelemetry n’est pas un backend d’observabilité en soi, mais plutôt un outil de collecte et de standardisation des données. Elle mentionne également Openliberty.io, qui est un projet open-source IBM, permettant de créer des applications cloud-natives en Java rapidement.
Par Johannes Dienst
La conférence met en avant l’importance cruciale de la documentation pour le succès d’un produit.
Johannes insiste sur le fait que la documentation est la ressource la plus essentielle pour les développeurs.
Lors de la création de documentation, il énumère plusieurs erreurs à éviter, telles que l’absence de barre de recherche, d’exemples de méthodes d’API, d’un guide de démarrage et d’explications sur la configuration de l’environnement pour utiliser un outil ou un produit.
Il recommande de privilégier une documentation intuitive plutôt que simplement esthétique et de limiter le nombre de sous-éléments à 5 par catégorie pour encourager la lecture.
La segmentation de la documentation en fonction de l’audience et des besoins spécifiques des utilisateurs finaux est également cruciale.
Dans la suite de sa présentation, Johannes encourage l’approche Docs as Code, utilisant des outils comme le Markdown associé à Git permettant de bénéficier des révisions et du versioning.
Pour finir, il recommande également des outils comme Docusaurus pour créer des sites de documentation, ou Vale pour la vérification orthographique et grammaticale.
Par Pierre Henriquet
On termine avec la keynote de clôture qui parle d’un sujet qui s’éloigne de l’informatique mais qui permet de garder nos esprits scientifiques éveillés sur les différences entre la fusion et la fission pour produire de l’énergie avec les différentes avancées scientifiques dans ce domaine.
Une keynote de fermeture aussi passionnante que la première !
Le fait d’avoir été sélectionné de nouveau sur cette édition 2024 m’a permis de découvrir un ensemble de sujets très diversifiés, de l’Agile à la génération de tests par l’intelligence artificielle.
J’étais vraiment très content de présenter mon sujet sur l’état de l’art du GitOps dans Kubernetes, et pouvoir vous faire découvrir Flamingo et Kargo !
Encore merci aux organisateurs pour la qualité de l’événement !