Florian Forestier

Dans les années 1970/1980, de nombreux enfants ont eu la chance de grandir avec des petits trains électriques, au format HO (1:87). Le principe était simple : on pose des rails, qu’on alimente en 18V, et les trains circulent sur les rails.

Un demi-siècle plus tard, mon grand-père de 85 ans et moi-même nous sommes lancés dans le projet un peu fou de faire passer au numérique ses trains électriques de cette époque. Bienvenue dans ce retour d’expérience, avec du matériel, et des humains, qui ont traversé les générations.

Au menu, de l’électronique (pas trop, promis !), des Raspberry, du TinyGo… et des petits trains, bien entendu.

S’il y a bien un projet utilisé à l’échelle mondiale, c’est le Kernel Linux. Un énorme morceau de code, que celles et ceux qui en ont entendu parler considèrent comme un code mystique, inaccessible au commun des mortels. Il n’en est pourtant rien : derrière ce nom qui rebute, se cache en réalité du code, des gens, des communautés. Et comme tout code, on y retrouve des features à coder, des bugs à corriger, des smells à nettoyer.

Aujourd’hui, je vous propose de vous faire découvrir comment nous avons découvert, investigué, troubleshooté, corrigé, et proposé à la communauté un correctif pour un bug vieux de six ans dans le Kernel ; et ce sans expérience précédente sur cet énorme morceau de code.

Et rassurez-vous ; le code le plus compliqué que vous allez voir aujourd’hui, c’est un if de deux lignes. Aucune connaissance n’est requise, nous reprenons tout de zéro pour devenir des héros !

Les mises à jour, c’est toujours compliqué à suivre ; ne dites pas le contraire ! Même dans nos métiers, où la sécurité est de plus en plus mise en avant, il est rare de tomber sur un parc applicatif totalement à jour. Qui n’est jamais tombé sur un Keycloak resté 3 versions en arrière, ou un GitLab dont l’uptime ferait pâlir Michel Drucker ?

Et, lorsque vous avez comme moi une infrastructure à la maison pour vos besoins personnels, c’est encore pire : aucun SOC ni responsable de la sécurité pour vous ouvrir un ticket JIRA ; aucun QA-Analyst pour vous sermonner avant chaque passage en prod. Résultat ? Votre Nextcloud déployé en 2021 est resté là, peinard, toujours vivant, toujours debout.

Mais rassurez-vous, aujourd’hui, j’ai la solution à tous vos maux. Aujourd’hui, nous reprenons le contrôle sur nos mises à jour ; nous nous libérons du joug de la flemme qui vous envahit lorsque, à 21h, vous devez démarrer une session SSH pour mettre à jour un serveur obsolète. Ensemble, nous allons voir comment mettre à jour nos services avec un bouton dans un channel Discord (et un paquet de trucs derrière ce bouton, mais il fallait que l’abstract soit percutant).

Le stockage et le partage de secrets a toujours été une tâche complexe. Le stockage dans un fichier a plat s’est souvent limité à un stockage symétrique, avec un secret partagé par toute l’équipe. Des solutions plus évoluées (comme OpenBAO, Bitwarden, etc) requièrent un accès réseau et une instance d’un serveur de secret fonctionnel.

Mais lorsque vous ne pouvez pas vous permettre de partager un secret commun ET que disposer d’une instance de secret n’est pas une option (par exemple, pour… stocker les secrets du serveur de secrets ?), quelles sont les options à votre disposition ?

Aujourd’hui, nous allons découvrir SOPS, un outil conçu par la fondation Mozilla et donné à la CNCF. Et il y aura même une Yubikey dans la partie !

Docker Swarm est un outil de clustering de nodes Docker, plus simple et léger que Kubernetes. Au bout de trois ans de bons et loyaux services, notre cluster avait bien vécu et n’était plus à jour.

Nous nous sommes donc lancé dans la mise à jour du cluster, sans interruption de service pour nos clients. Voici un bref RETEX de notre tentative.

Et si on parlait un peu d’ingénierie et de conception hardware! Comment avons nous créé une appliance physique 2U offrant la capacité de Function as a Service et reposant sur un cluster de Raspberry Pi 4B 4Go? 3 mois de fun entre les impressions 3D, l’électronique, le réseau, alpine, du C et même du Go ; un projet complet.

En entreprise, l’infrastructure est le nerf de la guerre. Réussir à calibrer les ressources pour chaque projet et offrir des environnements identiques entre l’intégration et la prod” est un véritable casse-tête. Alors, avec l’arrivée du concept DevOps, les gens se sont demandé s’il ne serait pas plus simple de laisser directement faire les développeurs. C’est ainsi que naquit le concept d’Infrastructure as Code ; qui, comme nous le verrons, apporte son lot d’avantages au quotidien.