La photo de couverture de l’article vient du compte Twitter Kubernetes Community Days France.


Ladies of Code Paris était partenaire communauté du Kubernetes Community Days qui a eu lieu le 7 mars dernier au centre Georges Pompidou à Paris.

J’ai eu l’opportunité d’animer deux tables rondes dans l’après-midi et j’ai pu profiter de quelques conférences sur le reste de la journée.

Le replay des conférences devrait être disponible mais voici ce que j’ai retenu !

Conférences

Il a fallu faire des choix: l’inconvénient des confs par tracks, tu n’es pas encore doté du don d’ubiquité pour en voir plusieurs à la fois…

Voici celles auxquelles j’ai assisté !

Building Container Images in k8s : it’s been a journey !

J’ai démarré la journée avec une conférence donnée par Laurent Bernaille et Mayeul Blanzat de chez Datadog qui ont fait un retour d’expérience sur leur manière de builder leurs containers sur kubernetes.

Les containers ne devraient jamais se lancer en tant que root.

buildkit exploite la notion de rootless build où on crée un user namespace avec des “faux root” (user root dans le container est différent du root de la machine hôte).C’est une fonctionnalité interne au kernel Linux. Plus d’informations sur le mode rootless.

Le mode rootless affecte le montage du système de fichiers qui occasionne des problèmes parfois difficiles à débugger (ils ont montré notamment un souci de “fichiers fantôme” qui pouvaient perdurer dans leurs builds et causer des problèmes de compilation: derrière un simple git checkout se cache d’autres manipulations sur le système de fichiers!)

Ce qui m’a marqué dans cette conférence, c’est les détails donnés sur la manière dont ils ont débuggé leurs problèmes de build avec deux commandes que je ne connaissais pas 👇

  • strace pour surveiller les appels reçus par un processus ainsi que les signaux reçus.
  • netstat -tulnp pour voir les ports utilisés du début à la fin du process de build.

De ces cas concrets se dégage une bonne pratique liée aux images Docker: on évite de démarrer un démon au démarrage d’une image docker (ou on les kill en sortant).

A case for a developer portal

Contexte: Une architecture avec un monolith qu’on souhaite exploser. On a du mal à visualiser les dépendances, qui est responsable d’une brique, monter l’infrastructure liée à chaque microservice prend du temps… Sounds familiar ? 😄

Backmarket avait une architecture monolithique qu’ils ont explosé en une trentaine de microservices. Avec cette nouvelle architecture, l’équipe “Infrastructure” devenait le bottleneck de leur organisation.

Est venue alors la nécessité d’avoir un “Developer Portal”: c’est un outil pour permettre de mieux visualiser les différences briques et faciliter la création de nouveaux microservices. Sami Farhat de Back Market a présenté leur utilisation de backstage.io en interne, un outil pour fournir un developer portal.

Le Central Hub permet de visualiser la stack technique. On peut déclarer une nouvelle “entité” (API, SDK…) aux moyens de YAML. Il existe des extensions permettant de se brancher à Github, CircleCI…

Le Service Bootstrap était la première fonctionnalité la plus demandée pour faciliter la création de microservices. La team Dev n’a qu’à décrire la stack souhaitée, indiquer le dépôt Git, les outils dont ils ont besoin (dashboard qualité, etc.) et tada 🧙🏻 Grâce à Terraform et Chassis (un outil maison qui fournit un skeleton d’application), le microservice est crée au bout d’une heure. Ils travaillaient encore sur l’accélération du process mais déjà, l’automatisation fait gagner du temps à l’équipe infrastructure qui est moins sollicitée par les équipes de développement.

Des Coupling Scores sont donnés pour chaque service grâce à un outil qui crawle le code source des différents microservices. Les sources à optimiser sont ainsi détectées plus facilement par les équipes dev.

La mise en place du dev portal est longue, il faut y aller par itérations. Vendre cette solution n’est pas facile mais met en lumière toutes les inconsistances du projet et apporte beaucoup sur le long terme. Ca encourage aussi à être rigoureux sur les RBAC du projet.

En ayant un Developer Portal fiable, cela inspire la confiance des utilisateurs et encourage l’adoption de l’outil.

Comment créer un plugin kubectl?

k8s est fait pour être étendu: on le voit avec les opérateurs mais aussi avec les plugins.

Les plugins peuvent être un moyen d’enrichir son utilisation de kubernetes en encapsulant des commandes qu’on a tendance à répéter.

Il est possible de créer simplement un plugin, il faut juste lui passer un binaire à exécuter (codé en Rust, Quarkus, Python, Go…).

La recette est simple :

  • On crée un fichier touch kubectl-monsuperplugin
  • On lui donne les droits d’exécution chmod +x kubectl-monsuperplugin
  • Mets le DTP (Dans Ton Path) mv ./kubectl-monsuperplugin /usr/local/bin/
  • Run kubectl monsuperplugin et ça devrait marcher.

Il est possible de déployer le plugin sur un index privé pour le rendre utilisable par ses collègues (pour des plugins relatifs à de la tambouille interne à une entreprise, par exemple!).

Des plugins sont trouvables d’autres gens sur Internet sont trouvables via krew (c’est comme brew mais pour des plugins kubectl)

Quelques plugins cools partagés par les speakers:

  • kubectl view-secret monsecret -a
  • kubectl pod-inspect pour une inspection moins verbeuse
  • kubectl neat qui nettoie le YAML

Quelques bonnes pratiques pour le développement de plugins k8s :

  • Le Go est à privilégier
  • Attention au naming et aux mots clés réservés à kubectl
  • krew-release-bot et GoReleaser pour générer des versions du plugin.

Mention spéciale au binôme Aurélie Vache et Sébastien Blanc pour leur énergie et qui transmettent leur savoir avec beaucoup de pédagogie et des exemples simples mais concrets 💕

J’ai découvert lors de cette conf l’existence des outils suivants:

  • stern pour tail les logs de plusieurs pods à la fois
  • ktail pour observer plus joliment les logs d’un pod

Comment rendre les secrets Kubernetes vraiment… secrets?

La conférence a été donnée par Julie Hourcade, Ingénieure Devops chez Formance. Les secrets sur Kubernetes ne sont que des données encodées en base64. Ce n’est pas du chiffrement et ça n’assure pas vraiment la sécurité des secrets.

On peut utiliser un Secret Vault Manager (je découvre leur existence !) et déporter ainsi ça côté tiers (AWS, Google Cloud Platform, HashiCorp Vault). Vault s’utilise en CLI avec curl.

Le manager s’installe via un Secret Store DSI Driver, une interface qui s’installe au niveau du cluster kubernetes.

On peut définir des politiques d’accès plus restreintes d’un pod à une liste de secrets.

Il est possible aussi d’utiliser un SDK pour la gestion des secrets et complétement externaliser cette problématique.

Quelque soit la solution choisie, il faut avoir conscience de la complexité introduite et s’assurer que cette complexité est raisonnable pour nos besoins.

Chaos Engineering Journey - Injecting harms

La conférence a été donnée par Si Li, développeuse et SRE chez Carrefour.

Le concept a été propulsé par Netflix. L’objectif était de générer des problèmes sur leur infrastructure pour l’éprouver dans un contexte sécurisé et ne pas attendre de faire face à ces problèmes en production.

chaoskube est un outil permettant de tuer des pods de manière aléatoire (selon des annotations, labels ou âge) dans un cluster donné. Il s’installe facilement via helm.

Un process de chaos engineering va de pair avec un bon monitoring pour pouvoir voir les points d’amélioration sur une infrastructure: litmuschaos permet de metttre en lumière les défaillances sur une infrastructure. On peut générer un chaos sur un node, des pods ou sur un network entier avec des scénarios installables.

Tables rondes

J’ai eu l’opportunité d’être la modératrice de deux tables rondes. Il n’y avait malheureusement pas d’audience en raison du lieu qui ne s’y prêtait pas mais elles étaient enregistrées. C’était des vastes sujets mais nous n’avions que 30 minutes pour en parler !

Ops / Dev / DevOps

Avec Juliette Audema, Angélique Jard et Hugo Lassiège, nous avons pu discuter autour des pratiques ops.

Ce que je retiens surtout de cet échange, c’est à quel point la notion de “DevOps” a des définitions variantes: pour certains, c’est un ensemble de pratiques, une philosophie pour d’autres, c’est devenu un métier “Un dev qui fait aussi de l’ops”.

Je retiens aussi l’importance quand on est dev d’être responsable de son code du début à la mise en production et donc de s’intéresser à l’infrastructure.

En tant que dev, on peut souvent galérer sur des problématiques d’infra car ce n’est pas notre spécialité: Les pratiques DevOps augmente notre charge cognitive déjà élevée juste sur le métier de dev.

Accorder du temps et de l’énergie à la “Developer Experience” fluidifie le rapport à l’infrastructure pour un dev, et fournit aux équipes de développement les connaissances nécessaires en infra.

Open-source: Comment contribuer ?

Avec Zineb Benhiba, Christophe Chaudier et Rémi Verchère, nous avons discuté open source et les freins aux contributions.

Ce que je retiens de cette table ronde, c’est qu’il y a plein de manières de contribuer à un projet open source qui ne sont pas nécessairement liées au code: une bonne manière de débuter sont bien sûr les “good first issue” identifiées par le maintainer, il y a aussi communiquer sur les projets open-source (via Youtube, Linkedin, Twitter ou autre réseau social). Contribuer à un projet qu’on utilise est aussi une manière simple de se lancer: on est plus à l’aise de “tester” notre contribution.

En tant que maintainer d’un projet open source, il est important de veiller à l’inclusivité dans son projet: accueillir en ayant un processus bien clair dans le README, avoir un code of conduct, faire preuve de bienveillance envers les membres. Zineb s’est lancée dans sa première contribution lors d’un meetup, organiser une rencontre “dans la vraie vie” peut être un moyen efficace d’attirer de nouvelles personnes contributrices.

Si on est perdu devant la license à choisir pour créer son projet, choosealicense (pour un projet code) et creative commons (pour du contenu vidéo ou écrit) peut nous guider vers la license la plus adéquate selon nos besoins.

Cette discussion a germé des graines en moi 🌱 En rentrant, j’ai réalisé qu’une PR traînait sur le welcome kit de la communauté Ladies of Code sans que j’y prête attention … Je visualise le chemin à parcourir, que ce soit en tant que maintainer et contributrice ! :)

Bilan

La journée est passée très vite, le lieu était vraiment canon aussi, mêlant art et tech. J’ai passé un super moment et ressors de là énergisée et inspirée pour la suite !

Un grand grand merci aux speakers pour leur partage de connaissances, à la communauté Duchess France et Ladies of Code Paris: c’est sincèrement toujours un plaisir de vous voir à ces événements ! Et last but not least, merci à Aurélien Violet, Denis Germain pour l’invitation et l’organisation de l’événement :)

/img/stickers-kcd.jpg

Point bonus pour le sticker bar, la récolte a été fructueuse !