GitHub on Zwindler's Reflection

101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s'améliore

Sun, 29 Mar 2026 18:00:00 +0200

Il bouge encore

Depuis la sortie de l’interface web du projet début février, le projet a continué à évoluer. Ajout de solutions manquantes, petites améliorations de l’UI, contributions externes, optimisations de performances… Bref, un bon petit mois bien rempli pour ce gros side project que j’aimerais faire grossir.

101-ways-to-deploy-kubernetes

Note : si vous n’avez pas suivi les épisodes précédents :

93 façons de déployer Kubernetes — le Google Sheet original
101 façons de déployer Kubernetes (v2) — passage sur GitHub
Une nouvelle UI pour explorer les 118+ solutions — l’appli Astro + Tailwind

7 nouvelles solutions

Le catalogue est passé de 118 à 125 solutions. Voici les ajouts depuis le dernier article :

Xen Orchestra - ajouté pendant un stream de Cuistops => Déploiement de clusters Kubernetes (MicroK8s) via les “recettes” de Xen Orchestra, la plateforme de management de Vates. Catégorie ManagementPlatform.
Charmed Kubernetes - suite à un commentaire sur LinkedIn, j’ai remplacé l’entrée “Juju” par Charmed Kubernetes, qui est le vrai nom du produit Canonical pour déployer Kubernetes via Juju.
kubeaver - découvert en scrollant bluesky sans but => un installateur Kubernetes offline/online avec une GUI, basé sur Kubespray et Ansible. Certifié CNCF conformance (pour ce que ça vaut…).
talos-bootstrap - script interactif de Cozystack pour bootstrapper des clusters Kubernetes sur Talos OS.
boot-to-talos - Outil de Cozystack (encore) qui convertit n’importe quel OS existant en Talos Linux, complètement depuis le userspace. Partiellement utilisé par Quentin dans un contexte que je ne peux révéler ;-)
TOPF - Talos Orchestrator by PostFinance, un CLI pour gérer des clusters Kubernetes basés sur Talos. Découvert sur le discord de Cuistops
Talhelper - Outil CLI pour créer des clusters Talos en mode GitOps, à partir d’un seul fichier YAML déclaratif. Je l’avais initialement mis de côté mais à y réfléchir, pourquoi pas le mettre.

On notera qu’au même titre que kubeadm et k3s, il y a beaucoup de solutions qui s’appuient sur Talos Linux. De mon point de vue, ça valide l’OS et ça confirme l’adoption croissante de cet OS immutable pour Kubernetes.

Refonte complète des tags

Un gros chantier a été la refonte de tous les tags du catalogue. Ils étaient incohérents : des noms d’outils utilisés comme tags (openshift, rancher…), des tags redondants (on-premise + self-hosted), des tags manquants ou parfois faux (par ex. “lightweight” sur des outils qui lancent des VMs).

J’ai nettoyé les tags de toutes les catégories :

Desktop : suppression des noms d’outils comme tags, ajout de gui pour Docker Desktop, Orbstack, Podman Desktop, Rancher Desktop
Selfhosted : suppression du tag redondant on-premise (29 solutions), ajout de tags pertinents (automation, edge, lightweight, bare-metal…)
ManagementPlatform : toutes les solutions ont maintenant 3 tags (multi-cloud, managed, gui, automation…)
KubernetesInKubernetes : correction de vcluster (virtualization → lightweight)

De nouveaux filtres dans l’UI

J’ai ajouté un filtre par nombre d’étoiles GitHub qui n’apparaît que quand le filtre “Open Source only” est activé. Plutôt pratique pour identifier rapidement les projets les plus populaires (> 100, > 1k, > 10k stars).

L’occasion aussi de réorganiser la barre de filtres : le sélecteur de statut (Active/Abandoned) est passé en dropdown compact, et le layout général a été retravaillé pour rester lisible même avec plus de filtres.

Dernier point, lorsque vous faites une recherche dans la barre principale, une variable vient d’ajouter à l’URL : pratique pour partager des solutions directement avec le lien.

Les contributions d’Antoine Caron (Slashgear)

Un grand merci à Antoine Caron (@slashgear) qui, au-delà de m’avoir aidé sur les performances et la sécurité de ce blog, a aussi contribué directement au projet 101 ways avec plusieurs PRs !

Hiérarchie des headings - les cartes utilisaient des <h3> sans <h2> dans la page. Antoine a corrigé ça pour une hiérarchie correcte (h1 → h2), ce qui améliore la navigation pour les lecteurs d’écran.
Accessibilité du champ de recherche - ajout d’un vrai <label> (en sr-only) et passage du type="text" à type="search" pour une meilleure sémantique.
Skip links - ajout de liens “skip to content” pour la navigation au clavier (WCAG 2.1, critère 2.4.1). Trois liens : vers la recherche, les filtres, et le contenu principal.

Amélioration des performances

En parlant de performances, le site s’est aussi amélioré côté PageSpeed. Voici un avant/après sur Lighthouse mobile :

De 82 à 99 en performances mobiles, avec du 100/100 en bonnes pratiques et SEO.

Ces gains viennent d’un ensemble de corrections, notamment la résolution du clipping des cartes au hover, un bug CSS assez vicieux lié à content-visibility: auto qui impliquait contain: paint et coupait le haut des cartes quand elles se soulevaient au survol. Antoine avait identifié le problème avec l’overflow-hidden, et Copilot a trouvé la cause racine dans le CSS containment.

Merci !

Un grand merci à tous ceux qui contribuent, que ce soit en me mentionnant les outils manquants, en soumettant des PRs, ou simplement en partageant le projet.

Merci spécial à Antoine Caron pour ses PRs sur l’accessibilité et la CI - c’est vraiment chouette de voir quelqu’un prendre le temps d’améliorer un projet open source qui n’est pas le sien. Et c’est d’autant plus appréciable qu’Antoine m’avait déjà aidé sur ce blog avec l’optimisation des images en AVIF et les security headers HTTP. 🙏

Le projet compte maintenant 125 solutions. Si vous en connaissez d’autres, n’hésitez pas à ouvrir une issue ou une PR (ou juste à me ping, en cas de flemme) !

👉 zwindler.github.io/101-ways-to-deploy-kubernetes

101 façons de déployer Kubernetes : une nouvelle UI pour explorer les 118+ solutions

Mon, 09 Feb 2026 18:00:00 +0200

De Google Sheet à une vraie application web

Vous vous souvenez peut-être de mes précédents articles sur ce projet : d’abord un simple Google Sheet avec 93 méthodes, puis un dépôt GitHub avec plus de 100 entrées.

Aujourd’hui, je peux présenter la dernière itération de ce projet : une vraie interface web pour explorer toutes ces solutions !

👉 101-ways-to-deploy-kubernetes

Pourquoi une UI ?

Le tableau Markdown sur GitHub, c’était déjà mieux que le Google Sheet pour la collaboration, mais à peine. Difficile à parser, difficile de rajouter des colonnes sans que ça devienne trop le bazar (c’était déjà le cas, ahah), et surtout, ultra MOCHE.

J’ai donc décidé de transformer tout ça en une interface moderne et intuitive, avec l’aide d’un LLM.

Stack technique : Astro + Tailwind

Pour ce projet, j’ai choisi une stack simple mais efficace :

Astro : un framework moderne qui génère des sites statiques ultra-rapides
Tailwind CSS : pour un design responsive sans prise de tête

Le résultat ? Un site léger, plutôt rapide, et qui fonctionne aussi bien sur desktop que sur mobile (même si l’expérience desktop reste plus confortable vu la quantité de données).

Les fonctionnalités

Des cartes pour chaque solution

Fini le tableau digne d’un dev back (non, pire, un ingé kube…) ! Chaque outil dispose maintenant de sa propre “carte” animée avec :

Le logo du projet
Le type de licence (OSS ou propriétaire)
Le nombre d’étoiles GitHub
Des liens directs vers le projet et des ressources tierces (blogs indépendants, REX, tutos…)

Des filtres puissants

Vous cherchez uniquement des solutions open source ? Des outils pour le développement local ? Des plateformes de management ?

Les filtres par catégories permettent de naviguer facilement :

Desktop (développement local)
Managed (offres cloud)
Self-hosted (automatisation on-premise)
Infra As Code
Kubernetes OS (systèmes spécialisés)
Management Platform
Kubernetes in Kubernetes

Et vous pouvez aussi filtrer par statut (actif, abandonné) ou afficher uniquement les solutions open source ou production ready.

Une barre de recherche

Vous savez ce que vous cherchez ? Tapez directement le nom dans la barre de recherche pour trouver la solution en un instant.

Des tags pour affiner

Au-delà des catégories, les tags permettent d’identifier rapidement les technologies sous-jacentes (kubeadm, k3s, k0s…).

Le saviez-vous ? Au moins 18 outils utilisent kubeadm !

En compilant toutes ces données, j’ai découvert quelque chose de fascinant : au moins 18 outils utilisent kubeadm comme backend pour déployer Kubernetes ! 🤯

Et ce n’est même pas en comptant les offres managées des cloud providers !

C’est typiquement le genre d’information qu’on peut maintenant visualiser instantanément grâce à cette nouvelle interface.

Un projet collaboratif

Le projet reste 100% open source et collaboratif. Les données sont toujours stockées dans le dépôt GitHub, et l’UI est générée automatiquement à partir de ces données (j’ai même rajouté des previews pour les PRs).

Il manque un outil ou un provider ? Vous avez repéré un bug ? N’hésitez pas à ouvrir une issue ou à soumettre une Pull Request !

Le projet compte maintenant 118 solutions (et je sais qu’il en manque certainement), avec pour chacune :

Des liens à jour
Le statut du projet
Des références externes (tutoriels, retours d’expérience…)

Essayez, commentez, partagez

Rendez-vous sur zwindler.github.io/101-ways-to-deploy-kubernetes pour explorer toutes ces solutions !

OK, c’est un infâme “call to action” comme on en voit sur tous les réseaux sociaux. Soit.

Cependant, je ne peux pas savoir si c’est utile (ou non) si vous ne le faites pas. Je peux le laisser en l’état (ça n’est pas génant en soit, j’ai plein d’autres side projects qui n’attendent que mon temps libre) ou le faire vivre, si ça vous plait / sert.

Et si vous trouvez ce projet utile, n’hésitez pas à :

Star le projet sur GitHub
Partager avec vos collègues de la communauté Cloud Native
Contribuer en ajoutant des outils manquants ou en corrigeant des erreurs

Merci d’avance ! 🙏

101 façons de déployer Kubernetes (v2) : maintenant sur Github avec plus de méthodes, plus de détails, plus de tout

Sun, 04 Jan 2026 10:00:00 +0200

Une nouvelle version, une nouvelle maison

Il y a quelques mois, je vous présentais mon tableau recensant 93 façons différentes de déployer Kubernetes, sur Google Sheets.

À la suite de la remarque de Ludovic Piot qui aurait aimé contribuer un ou deux outils manquants, j’ai pris un peu (beaucoup, en vrai) de temps pendant ces vacances pour déménager tout ça sur Github : 101-ways-to-deploy-kubernetes

Pourquoi sur un dépôt git plutôt que sur un Google Sheet comme au début ? Parce que ça me permet facilement de rendre ce projet vraiment collaboratif, notamment via des PRs (et surtout leur validation ou non).

Google Sheets, c’était bien pour commencer, quand c’était un outil perso pour m’aider à écrire mon livre, mais pour la collaboration, c’était pas viable.

Quoi de neuf dans cette v2 ?

Contributions facilitées

Le projet dispose maintenant d’un CONTRIBUTING.md qui explique comment participer.

Vous connaissez une solution qui n’est pas listée ? Vous avez repéré une erreur ? Un lien cassé ? Il vous suffit de faire une Pull Request !

De nombreuses nouvelles méthodes (j’ai pas compté mais probablement une douzaine)

Le projet est passé de 93 à plus de 100 méthodes ! J’ai continué mes explorations et ajouté une douzaine de nouvelles solutions, dont certaines que vous m’aviez suggérées.

Informations sur les licences

J’ai enrichi le tableau avec des détails sur les licences de chaque projet. C’est particulièrement important pour identifier d’un coup d’oeil si un produit est réellement open source ou si c’est une solution à licence propriétaire ou commerciale.

J’ai eu le débat avec Ludovic justement, qui voulait comprendre pourquoi je n’avais pas listé “MKE (Mirantis Kubernetes Engine)”. Je lui avais répondu à l’époque que c’était parce que je ne pouvais pas avoir accès à une version d’essai en tant que “random des Internets” sans passer par un commercial, mais l’argument n’était pas hyper solide.

Pour trouver une règle “unique” à indiquer dans le CONTRIBUTING.md, j’ai donc réintégré une partie des solutions que j’avais “censurées”.

While the heart of the cloud native ecosystem is open source, both open source and closed source (proprietary) tools are accepted in this list. What matters is whether the tool helps deploy Kubernetes clusters, not its licensing model.

Nombreuses références externes

J’ai fait un important travail sur la partie “références externes”. L’idée du répo, au delà de juste fournir une liste à la prévert, est de référencer des articles de tiers indiquant comment mettre en place ces solutions et bénéficier des retours d’expérience de la communauté.

Dans l’idée de rendre le projet plus international (ça sera tout aussi utile aux anglophones qu’aux petits frenchies de ma communauté), j’ai récupéré en priorité des liens en anglais, pour le plus de solutions possibles de cette liste. Il en reste encore qui n’en ont pas, mais ça progresse.

Note importante : au-delà de la documentation officielle (qui existe très souvent pour la grande majorité des projets), j’ai en priorité voulu recenser :

Des tutoriels de qualité de la communauté
Des articles de blog détaillés
Des retours d’expérience concrets

Un projet toujours sous CC BY-SA 4.0

Le contenu reste sous licence CC BY-SA 4.0 (Attribution - Share Alike).

Cela signifie que vous êtes libre de :

Partager : copier et redistribuer le contenu
Adapter : remixer, transformer et créer à partir de ce matériel

Sous les conditions suivantes :

Attribution : vous devez créditer le projet
Partage dans les mêmes conditions : si vous adaptez le contenu, vous devez le distribuer sous la même licence

Comment contribuer ?

C’est simple :

Forkez le dépôt 101-ways-to-deploy-kubernetes
Ajoutez ou modifiez le contenu (en suivant le format du tableau)
Soumettez une Pull Request

Lisez le CONTRIBUTING.md pour plus de détails sur le processus et les bonnes pratiques.

Toutes les contributions sont les bienvenues : nouvelles entrées, corrections, enrichissements, suggestions…

Et la suite ?

Le projet va continuer à évoluer au fil des découvertes et de vos contributions.

Je continue aussi à explorer de nouvelles solutions et à enrichir les informations existantes. Et qui sait, peut-être qu’on dépassera les 150 méthodes d’ici la fin de l’année ? 😄

C’est le moment où je fais mon influenceur et que je vous demande de ne pas hésiter à :

Star le projet sur Github si vous le trouvez utile ⭐⭐⭐
Contribuer en ajoutant vos découvertes
Partager autour de vous si vous le trouvez utile

Rendez-vous sur github.com/zwindler/101-ways-to-deploy-kubernetes !

J'ai donné 1 heure à des agents Copilot pour migrer un site de Bloggrify à Hugo

Tue, 02 Dec 2025 18:00:00 +0200

TL;DR pour les pressés

J’ai fait migrer un site statique de Bloggrify vers Hugo par GitHub Copilot Agent.

Les règles ? Une heure chrono, quelques tâches mais jamais plus de 2 en parallèle pour que l’humain conserve une charge mentale acceptable.

Spoiler : l’IA est meilleure que moi en bash (je le savais déjà, c’est pas très dur), correcte pour le CSS (après 2-3 essais), et dangereusement créative sur les parties rédigées, même celles qui sont déjà bonnes (askip j’ai été speaker à la KubeCon EU 2024… j’y étais même pas !).

Point fort inattendu : Playwright qui fait des screenshots automatiques à chaque modif. Un vrai game changer dans ce genre de cas d’usage IMO.

Le contexte : pourquoi se faire mal ?

Si vous suivez le blog, vous savez que j’ai publié un livre (Kubernetes : 50 solutions pour les postes de développement et les clusters de production), et vous savez aussi qu’il y a un site séparé pour la promotion du livre : 50ndk.zwindler.fr.

A l’époque je voulais en profiter pour tester un truc nouveau, j’avais donc testé Bloggrify (un générateur de sites statiques écrit par Hugo Lassiège). Sauf qu’à l’usage, je suis perdu dans l’écosystème JS, et je me suis dit que j’allais le migrer vers Hugo avec le thème Stack (exactement le même que ce blog).

Dans les deux cas, c’est des générateurs de sites statiques avec le contenu en markdown. Théoriquement, c’est pas compliqué à faire.

Mais au lieu de le faire manuellement, j’ai décidé de me lancer un petit défi : tout déléguer à des agents GitHub Copilot, en me limitant à 1 heure et en maintenant une charge mentale acceptable (comprendre : pas plus de 2 tâches en parallèle, sinon mon cerveau explose).

J’ai donc ouvert Copilot, choisi Claude Sonnet 4.5 (car Gemini 3 Pro, qui venait de sortir, était cassé) et je lui ai donné d’un côté le dépôt de 50ndk, de l’autre le dépôt de blog.zwindler.fr et je lui ai donné un court prompt du type :

Ce site a été créé à partir d’un outil appelé bloggrify. J’aimerai migrer tout le contenu markdown / images de ce blog vers un blog statique de type Hugo, que je maitrise mieux. Bases toi sur @zwindler/blog.zwindler.fr pour la structure et le thème à utiliser

Phase 1 : La migration technique (15 minutes)

Ce qui a marché tout seul

Première bonne impression : la migration de base a pris 15 minutes. Copilot Agent a :

Converti la structure Bloggrify vers Hugo
Installé Hugo
Mis en place le thème Stack
Créé un workflow automatisé complet avec :
- Build du site
- Démarrage d’un serveur local
- Capture d’écran Playwright 📸 (on y reviendra, c’est LE truc génial)
Nettoyer tout ce qui avait un rapport avec Bloggrify / Javascript

Résultat : un site fonctionnel du premier coup. Mais pas parfait !

Les premiers soucis (détectés par l’humain… aka moi)

En regardant le screenshot généré, j’ai repéré deux trucs bofs :

Menu “Archives” affiché en double dans la partie gauche
Des catégories inutiles. En effet, dans le site 50ndk, je n’avais pas utilisé de catégories, seulement des tags. Or le thème Stack met beaucoup en avant les catégories, et c’était moche.

L’agent n’avait rien détecté car en soi, c’est OK, ça fonctionne. Normal : c’est du visuel, et il faut un humain pour dire “euh, là c’est moche”.

Les corrections (7 min + 4 min)

Une fois que je lui ai signalé les problèmes, l’agent a :

su diagnostiquer précisément la cause du menu dupliqué (défini à la fois dans hugo.yaml ET dans le frontmatter de content/page/archives/index.md)
corrigé en ~7 minutes
réglé le problème des catégories en ~4 minutes

L’agent est bon pour débugger… une fois que l’humain a détecté le bug :

Agent génère
Screenshot Playwright
Humain vérifie puis formule un feedback
Agent corrige
et on itère comme ça

Sans Playwright, j’aurais dû manuellement builder, lancer le serveur, rafraîchir le navigateur à chaque itération. L’automatisation de cette boucle, c’est un game changer absolu.

Phase 2 : La page “À propos” (20-25 min, et des “““hallucinations”””)

Ce qui a bien commencé

Deuxième tâche : améliorer la page “À propos”. L’agent a :

Analysé le contexte (mes articles, ma page whoami sur blog.zwindler.fr)
Pondu une première version correcte, bien structurée
Su ajouter des images quand je lui ai demandé
Été capable de faire des ajustements rapides sur demande (“double la longueur”) ou seul, “j’au corrigé la faute de frappe ‘20240’ → ‘2024’”)

Jusque-là, RAS. Puis…

Quand l’IA devient romancier

Après quelques itérations, le LLM a commencé à réécrire certaines parties qui étaient bonnes.

Genre, carrément :

“Participation à la KubeCon EU 2024 en tant qu’organisateur/speaker”
Changé le nom du livre et l’éditeur
…

La supervision humaine pour la vérification factuelle est indispensable, surtout sur du contenu biographique. J’ai dû corriger plusieurs fois en mode “non, cette partie est fausse”.

Phase 3 : Les tâches techniques (et là, ça roule)

Ajout de scripts de tracking

Tâche : intégrer Hakanai + Umami sur toutes les pages.

L’agent a :

Créé un partial template dans layouts/partials/
Inclus automatiquement dans le layout principal
Placé les scripts au bon endroit (avant </body>)

C’est ce que j’aurais fait aussi. Nickel, RAS.

Optimisation d’image (succès… mais… pourquoi ???)

Je lui ai donné la tâche complètement débile de réduire ma photo de profil, qui était extrêmement grosse (j’avais vraiment été bourrin sur la version Bloggrify…)

Tâche : réduire avatar.jpg de 1.3 Mo à ~250 Ko.

L’agent l’a fait. Techniquement, ✅. J’aurais été beaucoup plus rapide à le faire manuellement (quelques secondes avec un outil d’optimisation d’images). Mais j’ai voulu pousser l’expérience jusqu’au bout et tester les limites de l’agent sur des tâches “simples” (pour un humain) comme celle là.

Entre le coût cognitif de formulation de la demande, le temps d’attente et l’énergie consommée pour lancer un pauvre resize de JPEG par rapport à une action manuelle directe, c’est clairement pas le meilleur usage. Mais ça fonctionne.

Mise en page des images (page “À propos”) - CSS/Layout complexe

Tâche : faire “épouser” le texte autour des images (float layout) + définir hauteur à 200px.

L’agent a proposé plusieurs itérations avant d’arriver à une version qui fonctionnait. Les tâches CSS/layout complexes nécessitent souvent plusieurs itérations. L’agent propose des solutions techniquement valides mais qui peuvent entrer en conflit avec les styles existants du thème. La validation visuelle via screenshot est indispensable.

Widget “Commander le livre” dans la barre de droite

Tâche : ajouter un widget dans la sidebar avec liens vers vendeurs (Eyrolles, Cultura, Amazon, Fnac).

Là encore, il a fallu plusieurs tentatives pour avoir un truc qui fonctionne sur Hugo / mon thème. La première itération était KO. Il a fallu qu’il comprenne qu’il fallait faire un widget personnalisé (j’ai eu à en faire aussi, j’aurais pu le guider s’il n’avait pas trouvé seul).

L’agent a créé :

layouts/partials/widget/book-links.html
HTML + CSS inline cohérent avec le thème Stack
Modification de hugo.yaml pour référencer book-links

Résultat final : un widget affiché avec les 4 liens avec en bonus que je n’avais pas demandé un effet hover (jamais j’aurais su faire ça).

Comportement bizarre : PR ou commit direct ?

Sur ce projet, la branche main n’était pas protégée (oui c’est pas bien, nia nia nia). Donc selon les cas, l’agent s’est mis, soit à créer des PRs, soit à commiter directement sur main (avec mon accord).

Je n’ai pas réussi à bien comprendre comment il arrivait à déterminer que dans tel cas il fallait une PR, et dans tel autre, un simple commit suffisait. Je n’ai pas creusé, mais ça m’intrigue un peu (si quelqu’un a l’explication).

Dans tous les cas, cette question est probablement un peu bêbette, le mieux, c’est de protéger main.

Un PaaS, ça aide

Petit point bonus qui a bien aidé pour cette migration, le fait que le site ait été hébergé sur Clever Cloud (sur un PaaS plus généralement, car ça aurait probablement été vrai sur d’autres PaaS).

Dans ce cas précis, Clever a su détecter qu’on était passé de JS à Hugo sans que je n’aie rien à faire. Ça, plus le fait que les builds étaient très rapides (30 secondes entre le commit et la mise à dispo de la nouvelle version), ça m’a permis d’itérer extrêmement vite.

Si j’avais dû m’occuper de l’infra pour migrer le tooling sur une VM, ou en monter une autre, cette expérimentation ne serait pas allée aussi loin.

Conclusion

La découverte majeure de l’expérimentation, c’est sans aucun doute possible le fait que Copilot utilise Playwright pour tester, et quand il est content de son résultat, pouvoir afficher à l’humain une capture d’écran de ce qu’il pense être valide.

Ça s’est révélé extrêmement utile dans le cadre de ce projet. À de multiples reprises, sans Playwright, j’aurais dû manuellement builder, lancer le serveur, rafraîchir le navigateur avant de voir un truc cassé ou moche, à chaque itération. L’automatisation de cette boucle de feedback visuelle est un game changer pour la productivité.

Ça ne sera pas universel, mais j’ai trouvé que 2 tâches simultanées (3 à la rigueur) c’était une bonne limite pour garder suffisamment en tête toutes les tâches en cours et être efficace pour review quand le LLM avait “fini”. J’aurais pu faire plus de choses mais j’ai eu peur d’être moins alerte et de laisser passer plus de bêtises.

Cette expérimentation d’environ 1 heure a démontré que GitHub Copilot Agent est particulièrement efficace pour :

Les migrations techniques (gain de temps massif : ~15 min pour Bloggrify → Hugo, j’aurais mis plus, c’est sûr)
Le debugging assisté (une fois le problème identifié par l’humain)

Cependant, il nécessite toujours une supervision humaine attentive, voire très attentive pour :

Les faits (ça sortait tellement de nulle part, cette réécriture du contenu alors que je lui demandais de rajouter des images ?!?)
Les décisions UX/Design et les validations visuelles (lui, si c’est moche il s’en fout, un peu comme un dev back qui fait du front)
Les tâches CSS/layout complexes (rarement bon du premier coup, mais en même temps j’aurais pas fait mieux)
Les architecture spécifiques de frameworks/thèmes (et en plus il t’engueule en te disant que c’est la faute de ton thème)

J’insiste une dernière fois, mais l’intégration de Playwright pour les screenshots automatiques crée une boucle de feedback visuel qui transforme radicalement l’expérience de développement avec les agents. Je ne me renseigne peut-être pas assez et peut-être que ça existe depuis longtemps, mais c’est vraiment LE truc qui m’a le plus convaincu dans ce use case.

Globalement satisfait, ça fait réfléchir. Je vous laisse admirer le résultat :

Une issue ouverte sur un projet, 7 ans après ?

Fri, 24 Nov 2023 14:00:00 +0200

Introduction

Il y a 7 ans, en août 2016 (!!), je créais ma première “vraie” image docker.

Il s’agissait d’une image custom pour un outil que j’utilisais énormément XWiki, un outil de Knowledge management open source (et français) que j’apprécie particulièrement et qui remplace avantageusement un Confluence (si vous voulez mon avis).

A l’époque, mon image fournissait un XWiki prêt à l’emploi avec Tomcat 8 et le driver JDBC pour postgresql.

github.com/zwindler/docker-xwiki

J’avais fait ce projet car les images officielles du projet étaient encore balbutiantes (ça date !) et ne proposaient pas cette alternative.

J’avais d’ailleurs écrit un article pour l’occasion (Installer XWiki 8.2.1 avec Docker (compose) en 2 lignes de commandes) et fourni au fil des mois suivants des manifests pour Kubernetes.

Et aujourd’hui ?

Ca fait bien longtemps que ce projet n’a plus aucun intérêt, même si mes images ont été téléchargées environ 30000 fois (quand même !), avec un dernier téléchargement l’an dernier, malgré une version vielle de plus de 6 ans (mais pourquoiiiiii ?).

hub.docker.com - zwindler/xwiki-tomcat8

Les images officielles proposent désormais (depuis bien longtemps) toutes les options les plus courantes pour toutes les versions supportées

Pourtant ?!?

Pourtant, début novembre, j’ai reçu une issue, d’un utilisateur qui m’informait qu’il ne pouvait pas rebuild mon image car l’URL permettant de télécharger les artefacts WAR ne répondait plus (effectivement, elle a changé).

Même si au début j’étais un peu interloqué, je me suis dis que ça pouvait être fun de remettre les mains dedans et de tenter de mettre à jour mon image sur toute la stack, pour voir si ça fonctionne encore.

Voyons voir ce qui a changé depuis 2016…

Évidemment, beaucoup de choses !

D’abord, les versions de XWiki (de 10 à 14), qui ont forcément évoluées, ainsi que cette fameuse URL de téléchargement des artefacts qui avait changé.

La version de postgres est passée de 9.5 à 16, les versions du driver JDBC ont évoluées de plusieurs mineures.

Plus impactant, tomcat est passé de la version 8 à la version 10, avec un gros breaking change entre la 9 et la 10, notamment à cause de JEE, renommé en JakartaEE !

Ca parlera aux Javaistes ;-)

Plus anecdotique, le MAINTAINER a disparu depuis bien longtemps des Dockerfile (remplacé par un LABEL opencontainers), le MaxPermSize n’existe plus en Java et le format des fichiers docker-compose est passé en version 3.

Les modifs

Pour le fun, j’ai donc réparé mon image pour qu’elle marche (et pas plus), puis j’ai passé le repo en readonly, pour la postérité, en prenant soin d’informer l’auteur de l’issue qu’il valait mieux regarder du côté des images officielles ;-).

Le code de fix est disponible ici, pour les curieux/curieuses.

Mais… ça fonctionne :-p

Automatiser son site Hugo sans Github Action ou Vercel

Tue, 01 Aug 2023 06:00:00 +0200

Contexte

Fin 2021, après plus de 10 ans à écrire des articles de blog tech sur Wordpress, je prenais la décision radicale d’arrêter de maintenir cette bouse infâme (je mâche mes mots) et de partir sur des articles rédigés en markdown et un site statique avec Hugo.

Au tout début, je gérais le blog moi-même mais assez vite j’en ai eu assez de devoir aller rebuild le blog à chaque modification. J’ai rapidement mis un cron qui faisait des git pull régulièrement, mais on ne va pas se mentir, c’est assez crado…

Finalement, on m’a rapidement pointé que je devrais arrêter de m’embêter et utiliser Netlify ou Vercel.

J’étais pas super chaud, car ça allait à l’encontre de ma volonté d’auto héberger mon contenu et de limiter l’impact sur la vie privée de mes lecteurs, mais finalement, l’expérience utilisateur sur Vercel était tellement bonne que j’avais craqué. Je ferai peut-être un article là-dessus d’ailleurs, c’est la première fois que j’ai compris (ressenti) l’intérêt d’un PaaS.

Mais aujourd’hui, je reviens sur cette décision et j’essaye de voir ce qu’il est nécessaire de mettre en place pour disposer soi-même d’un site hugo qui se refresh tout seul dès qu’un commit arrive sur le dépôt git, sans utiliser de plateforme type Vercel ni d’outils types Github action+pages.

Prérequis

Je pars du principe que vous avez déjà un site statique généré avec Hugo. Si ce n’est pas le cas je vous invite à aller lire mes articles précédents sur le sujet (premiers pas, stats avec matomo, migration wordpress vers hugo).

Vous avez donc un serveur Linux sur lequel vous avez la main pour installer des choses et un dépôt git (sous Github dans mon cas, mais on peut probablement adapter l’article pour autre chose).

Hugo étant d’abord un générateur de site statique, je vais utiliser nginx en frontal pour servir les fichiers qu’on va générer. Jusqu’à il y a peu, l’usage du mode “server” de hugo n’était d’ailleurs pas conseillé en production (mais ça ne semble plus être le cas, je n’ai pas vu de warning dernièrement ?).

apt install nginx git

Déposer les sources sur le serveur

Dans mon cas, les sources de mon blog ne sont pas disponibles publiquement (parce que j’ai pas envie, c’est comme ça ¯\_(ツ)_/¯).

Il faut donc préalablement se loguer en SSH avec git avant de pouvoir pull le code. Et comme je n’ai pas envie de laisser ma clé privée sur le serveur qui va héberger mon blog, il faut que j’utilise une autre clé.

Dans mon cas, Github, qui héberge le code markdown de mon blog, a une notion de “deploy keys”, qui servent justement pour ça :

docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys

Je vais donc créer une clé sur le serveur qui héberge le blog :

ssh-keygen -t ed25519 -C "xxx@xxx.tld"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/toto/.ssh/id_ed25519):
[...]

Et je la copie dans le dossier de www-data (l’utilisateur nginx sous Ubuntu)

chmod 600 /root/.ssh/id_ed25519
sudo mkdir /var/www/.ssh/
sudo cp ~/.ssh/id_ed25519* /var/www/.ssh/
chown www-data: /var/www/.ssh/*

Une fois la clé créée, on doit l’ajouter dans Github.com. Je ne lui donne que les droits “read only” puisque le but c’est seulement de récupérer le code et générer le site statique, pas qu’on puisse éditer le code (cé pour la sécuritay).

Je retourne ensuite sur mon serveur et j’essaye de télécharger les sources et le thème:

cd /usr/share/nginx/html
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git
cd blog.example.org/themes
git submodule add -f https://github.com/CaiJimmy/hugo-theme-stack.git
chown -R www-data: /usr/share/nginx/html/blog.example.org

Webhook

Pour réagir à l’arrivée d’un nouveau commit sur notre dépôt source, on va utiliser 2 choses :

un projet qui s’appelle sobrement “Webhook”.
configurer un webhook dans github, qui va envoyer l’info que quelque chose est arrivé sur le dépôt (mais on verra ça plus tard)

Revenons à “Webhook” dans un premier temps :

webhook is a lightweight configurable tool written in Go, that allows you to easily create HTTP endpoints (hooks) on your server, which you can use to execute configured commands. You can also pass data from the HTTP request (such as headers, payload or query variables) to your commands. webhook also allows you to specify rules which have to be satisfied in order for the hook to be triggered.

On récupère la dernière release et déposer le binaire sur notre serveur :

github.com/adnanh/webhook/releases/tag/2.8.1

export VERSION="2.8.1"
wget https://github.com/adnanh/webhook/releases/download/${VERSION}/webhook-linux-amd64.tar.gz

tar -xvf webhook*.tar.gz

sudo mv webhook-linux-amd64/webhook /usr/local/bin
rm -rf webhook-linux-amd64*

webhook --version

Une fois que c’est fait, on va générer une chaîne aléatoire qui va nous servir de “secret” qui sera partagé entre le binaire webhook qui tourne sur notre serveur et un webhook sur Github.com :

WHSECRET=`uuidgen | base64`
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa==

On crée un fichier de configuration hook.json pour déclarer nos webhooks

mkdir /etc/webhook
cat > /etc/webhook/hook.json << EOF
[
 {
 "id": "redeploy",
 "execute-command": "/usr/share/nginx/html/blog.example.org/blog_refresh.sh",
 "command-working-directory": "/usr/share/nginx/html/blog.example.org",
 "trigger-rule":
 {
 "match":
 {
 "type": "payload-hmac-sha1",
 "secret": "$WHSECRET",
 "parameter":
 {
 "source": "header",
 "name": "X-Hub-Signature"
 }
 }
 }
 }
]
EOF

Ici, quand le serveur va recevoir l’url /hooks/redeploy, on va lancer le script /usr/share/nginx/html/blog.example.org/blog_refresh.sh depuis le répertoire /usr/share/nginx/html/blog.example.org.

Charge à nous de créer un script qui va soit :

récupérer les sources (git pull)
relancer un build

Voilà à quoi pourrait ressembler le script blog_refresh.sh :

#!/bin/bash
cd /usr/share/nginx/html/blog.example.org

#pull latest version
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git

#refresh theme submodule
git submodule init
git submodule update

#rebuild (fire and forget)
hugo --minify --gc &

On va ensuite créer un service systemd qui va lancer le binaire webhook en tâche de fond

cat > /etc/systemd/system/webhook.service << EOF
[Unit]
Description=Simple Golang webhook server
ConditionPathExists=/usr/local/bin/webhook
After=network.target

[Service]
User=www-data
Group=www-data
Type=simple
WorkingDirectory=/usr/share/nginx/html/blog.example.org
ExecStart=/usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
Restart=on-failure

[Install]
WantedBy=default.target
EOF

systemctl enable webhook
systemctl start webhook

Côté Github.com, on crée le webhook qui va contacter le serveur webhook de la façon suivante :

On a maintenant un serveur web qui est en attente de certains événements webhooks et qui va lancer un script si jamais l’URL de webhook est appelée par Github.com.

Configuration nginx

Il reste maintenant toute la configuration de notre nginx en frontal à faire. En partant du principe qu’on vient juste de faire l’installation du package, on commence par supprimer le fichier /etc/nginx/sites-enabled/default, et on en crée un nouveau :

rm /etc/nginx/sites-enabled/default

cat > /etc/nginx/sites-available/blog.example.org.conf << EOF
# Root configuration
server {
 listen 80;
 server_name blog.example.org;

 location /hooks/ {
 proxy_pass http://127.0.0.1:9000/hooks/;
 }

 error_page 404 /404.html;

 location / {
 root /usr/share/nginx/html/blog.example.org/public;
 index index.html;
 }
}
EOF
ln -s /etc/nginx/sites-{available,enabled}/blog.example.org.conf

On vérifie que la configuration est valide et si oui on redémarre nginx

nginx -t
systemctl reload nginx

A partir de maintenant, toutes les URLs qui arriveront jusqu’à votre serveur en /hooks seront redirigées sur le logiciel “webhook” et le reste ira sur votre site statique (/usr/share/nginx/html/blog.example.org/public).

curl https://blog.example.org/hooks/redeploy -L
Hook rules were not satisfied.%

Ici le hook renvoie une erreur, car on a pas envoyé le token secret mais c’est probable que ça fonctionne. Toutes les autres pages renvoient bien une page du blog :

curl https://blog.example.org/
<!DOCTYPE html>
<html lang="fr-fr" dir="ltr">
 <head>
 <meta name="generator" content="Hugo 0.115.1"><meta charset='utf-8'>
[...]

On peut maintenant envoyer des commits et voir si ça déclenche des rebuilds de notre blog. Ou alors, on peut récupérer un push précédent et cliquer sur “Redeliver” si on veut trigger un rebuild du blog.

root@hugo:~# systemctl status webhook
* webhook.service - Simple Golang webhook server
 Loaded: loaded (/etc/systemd/system/webhook.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2023-07-31 07:34:35 UTC; 33s ago
 Main PID: 900109 (webhook)
 Tasks: 15 (limit: 4574)
 Memory: 240.4M
 CPU: 45.504s
 CGroup: /system.slice/webhook.service
 |-900109 /usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
 `-900161 hugo --minify --gc

Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 attempting to load hooks from /etc/webhook/hook.json
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 found 1 hook(s) in file
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 loaded: redeploy
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 serving hooks on http://127.0.0.1:9000/hooks/{id}
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 os signal watcher ready
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] incoming HTTP POST request from 127.0.0.1:43258
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy got matched
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy hook triggered successfully
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] 200 | 0 B | 1.151688ms | 127.0.0.1:9000 | POST /hooks/redeploy
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] executing /usr/share/nginx/html/blog.example.org/blog_refresh.sh
[...]
Jul 31 07:37:28 hugo webhook[900109]: Pages | 3572
Jul 31 07:37:28 hugo webhook[900109]: Paginator pages | 516
Jul 31 07:37:28 hugo webhook[900109]: Non-page files | 14
Jul 31 07:37:28 hugo webhook[900109]: Static files | 2282
Jul 31 07:37:28 hugo webhook[900109]: Processed images | 2
Jul 31 07:37:28 hugo webhook[900109]: Aliases | 1563
Jul 31 07:37:28 hugo webhook[900109]: Sitemaps | 1
Jul 31 07:37:28 hugo webhook[900109]: Cleaned | 0
Jul 31 07:37:28 hugo webhook[900109]: Total in 166131 ms
Jul 31 07:37:28 hugo webhook[900109]: [webhook] 2023/07/31 07:37:28 [f089a0] finished handling redeploy

Conclusion

Si vous êtes à l’aise avec Linux et nginx, ces quelques manipulations sont assez rapides à faire, il n’y a rien de vraiment complexe.

Cependant, ça demande à l’usage un peu d’administration et de vouloir mettre les mains dans le cambouis (avoir une VM à gérer). Je ne peux reprocher à personne de préférer l’utilisation de Github/Gitlab pages, couplé à de Github actions/Gitlab runners, voire de tout déléguer à Vercel/Netlify…

Mais j’avais envie de reprendre la main sur le hosting de mon blog (avec tous les inconvénients que ça va avoir en termes de maintien en condition opérationnelle), notamment pour disposer à nouveau de l’IPv6 (perdue lors du passage à Vercel) et une navigation sur mon blog plus respectueuse de votre vie privée (pas que j’aie pas confiance en Vercel, mais bon…).

Et c’est en revanche beaucoup plus simple que d’héberger son propre serveur Gitlab + Gitlab runners + Gitlab pages ;-).

Donc, pour mon usage, ça fait le taf :)

Ressources additionnelles

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Thu, 21 Mar 2019 13:00:14 +0000

C’est quoi k3s ?

Il y a quelques jours, vous avez peut être vu passer dans vos fil d’actus k3s, ce nouveau projet open sourcé par Rancher.

Lightweight Kubernetes. 5 less than k8s.

Il s’agit d’une version réduite de Kubernetes, sans pour autant être minimaliste, qui nous vante la possibilité de monter des clusters Kubernetes avec très peu de ressources nécessaires. On parle de moins de 512 Mo de RAM pour un master, encore moins pour un worker, tout dans un binaire de 40 Mo, support de armhf, et arm64, …

Great for Edge, IoT, CI, ARM, and situations where a PhD in k8s clusterology is infeasible

Cerise sur le gâteau, comme tout est regroupé dans un seul et même binaire, l’installation est ultra simple et se résume en :

Récupérer un binaire
Lancer le binaire sur le master
Lancer le binaire sur le worker avec l’URL du master et un token

Mais c’est génial !

Nécessairement, pour arriver à ça, il a fallut faire quelques concessions mais pour l’instant je ne les trouves pas très gênantes. Parmi les modifications notables, on retrouve :

Suppression des features alpha, legacy et non standard
Suppression de tous les add-on des cloud providers
Remplacement de etcd3 par sqlite3 (même si etcd3 peut être toujours être utilisé)

J’en veux un !

Autant dire que pas mal de bidouilleurs du dimanche se sont jetés dessus.

Le premier exemple qui vient à l’esprit est de monter un cluster Kubernetes sur Raspberry pi. Nombre de personnes ont déjà installé Docker sur un raspberry qui traînait dans un tiroir (moi compris), et le nombre d’articles avec Docker Swarm sur plusieurs Raspberry pullule sur le web.

Geekerie du week end : installer Docker sur un Raspberry Pi

Tout ça c’est très bien mais jusqu’à présent, il était difficile d’installer Kubernetes sur ce genre de machines, assez limités en CPU/RAM. Du coup, vous vous en doutez, je ne suis pas le premier à parler de ça.

Vincent RABAT aka itwars (que vous connaissez sûrement si vous écumez les meetups sur Bordeaux) m’a coiffé au poteau en releasant un playbook Ansible pour installer k3s, et notamment sur un Raspberry Pi (mais pas que).

A charge de revanche, Vincent ;-).

Un peu différent

Du coup, pour me démarquer, je vous propose aujourd’hui quelque chose d’un peu différent. N’ayant pas suffisament de raspberry sous la main, j’ai voulu faire un PoC de k3s en me basant sur des machines ARM créées chez un cloud provider.

L’idée étant que si ça marche sur des machines de faible puissance en ARM, ça marchera partout (x64, raspberry, etc).

Ça fait plusieurs fois que j’utilise Scaleway comme hébergeur pour des petits projets, et en particulier pour déployer rapidement des machines car leur API est pas trop mal fichues et surtout ils disposent de modules Ansible très bien fait, notamment avec la feature « inventaire dynamique », ce que beaucoup ne font pas.

Pour ceux que ça intéresse, mon talk sur BDX.IO était basé sur le même principe :

https://www.youtube.com/watch?v=WPRE1_f0pyg

Dans ce tuto, je vais donc vous montrer comment en quelque commande, monter un cluster k3s sur des machines ARM créées à la volée chez Scaleway, le tout avec Ansible (vous l’aurez compris).

Quelques prérequis

La première chose à faire est de cloner sur votre machine les playbooks Ansible que j’ai mis à disposition sur Github à l’adresse suivante : github.com/zwindler/ansible-scaleway-k3s

Pour réaliser ce tuto, je pars du principe que vous avec déjà un compte sur Scaleway, que vous avez un clé SSH qu’on déposera à la racine du projet, appelée admin.pub (c’est original).

Il faudra également installer les package pipy suivant sur la machine locale :

pip install jinja2 PyYAML paramiko cryptography packaging

Ensuite, vous devrez installer Ansible depuis les sources (>= 2.8devel) et éventuellement le binaire jq pour requêter dans les output JSON (ça c’est juste pour se faciliter la vie)

Dans la console Scaleway, vous devrez créer un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Et enfin sourcer le fichier pour avoir la variable dans votre environnement

source scaleway_token

OK, on est prêt

La première étape de cette procédure va être de générer des instances ARM pour héberger le master et le worker Kubernetes. Pour ça, le playbook Ansible create_arm_vms.yaml va :

récupérer l’ID d’organisation du compte Scaleway
récupérer un ID d’image compatible debian Stretch
ajouter si nécessaire la clé SSH de l’admin
créer autant de machines que nécessaire

On lance la commande suivante :

ansible-playbook create_arm_vms_scaleway.yml

ET C’EST TOUT !

Normalement en 2 minutes, vous devriez avoir 2 instances ARM sur le datacenter de Paris (par1).

A noter, il se peut qu’elles ne soient pas accessibles tout de suite en SSH. J’adapterai peut être le playbook pour qu’il ne rende pas la main tant que les machines ne sont pas accessibles, et qu’on enchaîne automatiquement sur l’étape suivante (TODO).

Inventaire automatique

Je le disais plus haut, la grande force de Scaleway avec Ansible est le fait qu’ils ont fait l’effort de coder l’inventaire dynamique. Vous n’avez pas besoin de renseigner à la main les IPs des instances que vous venez de créer dans un fichier ansible/hosts. Grâce à l’API, la découverte se fait automatiquement. On va dont pouvoir enchaîner sur la suite directement.

De base, voici le contenu de mon fichier d’inventaire (inventory.yml) :

plugin: scaleway
regions:
- par1
tags:
- k3smaster
- k3sworker

Maintenant que les machines sont UP, on peut vérifier ce que nous renvoie Scaleway avec la commande ansible-inventory. Ça devrait ressembler à ça :

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "arm64",
"commercial_type": "ARM64-2GB",
"hostname": "k3smaster1",
[...]
"k3sworker": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

SSH fingerprints

Une étape qui est souvent fastidieuse, surtout quand on ajoute beaucoup de serveur, est l’étape de vérification de l’empreinte SSH des nouveaux serveurs lors de la première connexion. Cette authentification est très importante et il n’est pas du tout conseillé (comme je le vois parfois) d’ajouter l’option ANSIBLE_HOST_KEY_CHECKING=False.

Ici, je vous propose de scanner automatiquement la première fois l’empreinte, et l’ajouter dans votre known_hosts. Ainsi, si l’empreinte change en cours de route, vous serez prévenus. Cependant, ce n’est à utiliser que dans le cas de notre bidouille, pas en production.

ansible-inventory --list -i inventory.yml | jq -r '.k3smaster.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts
ansible-inventory --list -i inventory.yml | jq -r '.k3sworker.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Vous pouvez maintenant ajouter votre clé SSH dans le ssh-agent, et vérifier qu’on vous pouvez vous connecter à tous les serveurs via Ansible :

eval `ssh-agent`
ssh-add myprivate.key

Préparation du serveur

C’était facile, non ?

Et bien la suite l’est encore plus, à l’exception de cette petite subtilité/piège => Il se trouve que l’image ARM par défaut proposée par Scaleway ne dispose ni de python ni de sudo. Pour faire du Ansible, c’est très très handicapant.

J’ai donc écris un petit playbook, à n’exécuter la première fois, qui installe les prérequis non présents sur l’image de base (python et sudo)

ansible-playbook -i inventory.yml -u root install_prerequisites_scaleway.yml

Si vous n’êtes pas sur ce genre de machines, vous n’aurez pas à faire cette étapes.

Maintenant qu’on a des machines avec python et sudo, on peut installer k3s normalement avec Ansible :

ansible-playbook -i inventory.yml -u root install_k3s_scaleway.yml

Une fois de plus : ET C’EST TOUT !

Le cluster est maintenant opérationnel. Les serveurs ont Kubernetes installé et fonctionnel. Le ou les workers ont rejoint le master et font parti d’un même cluster. Un Ingress controller Treafik est créé, on peut jouer dessus directement :-)

Bonus : accéder au cluster

Bon je vous ai un peu feinté.

Certes, on peut se connecter en SSH sur le master et le piloter avec les commandes kubectl classique (mais il faut rajouter k3s devant car le binaire kubectl est intégré à k3s). Mais c’est quand même plus simple si on peut y accéder à distance, depuis votre machine locale.

Là encore, j’ai donc fais un petit playbook qui va aspirer la configuration kubectl et la coller dans le fichier ~/.kube/config.k3smaster

ansible-playbook -i inventory.yml -u root configure_kubeconfig.yml

A partir de là, vous devriez pouvoir tester votre nouveau cluster depuis votre PC :-)

cd
kubectl --kubeconfig=.kube/config.k3smaster get nodes
NAME STATUS ROLES AGE VERSION
k3smaster1 Ready <none> 2d v1.13.3-k3s.6
k3sworker1 Ready <none> 2d v1.13.3-k3s.6

Enjoy !!!

Sortie d’Ansible 2.7 et ma première contribution

Wed, 10 Oct 2018 12:15:12 +0000

Sortie d’Ansible 2.7

Hier soir, la dernière version d’Ansible (2.7) est sortie. Cette release s’est concentrée sur une amélioration de la performance et de la stabilité, même si de très nombreux modules ont fait leur apparition, comme à chaque nouvelle version.

Python

Le support de Python 2.6 est abandonné, au profit de Python 2.7. Cela signifie que l’hôte qui exécutera le playbook devra disposer de Python 2.7 au minimum (même si Python 2.6 est toujours supporté sur la machine cible).

Écritures concurrentes

Un problème auquel j’ai déjà eu affaire est la gestion des écritures concurrentes sur un même fichier (par exemple si plusieurs hôtes écrivent sur un même fichier distant ou alors un delegate_to). A priori il existe maintenant un « lock » pour éviter d’écraser les modifications. Il faudra que je teste pour voir si ça marche bien.

Performances accrues, généralisation du SSH pipelining ?

La plus grosse modification, qui va nécessiter des tests approfondis, est la modification de la manière dont sont déclenchées les actions/modules sur les serveurs distants. Précédemment, les tasks nécessitaient 2 commandes SSH au lieu d’une maintenant. Effectivement, le temps d’exécution de playbooks contenant des actions simple mais très nombreuses pouvait être très long.

Ansible-2.7 changes the Ansiballz strategy for running modules remotely so that invoking a module only needs to invoke python once per module on the remote machine instead of twice.

Un gain de performance dans ce genre de cas où on passe plus de temps à lancer des commandes que les exécuter est forcément une bonne nouvelle. Je me demande si ce n’est pas simplement une activation « par défaut » de la variable d’environnement ANSIBLE_SSH_PIPELINING=1 (que j’utilise déjà dans ce genre de cas).

A priori non si j’en crois cette issue, mais pour l’instant je n’ai pas remarqué de différence significative sur mes playbooks les plus gourmands en temps d’exécution.

Module reboot

A noter, la plupart des gens remontent l’arrivée d’un module « reboot » (et son équivalent « win_reboot ») qui redémarre une machine et ré-initie une connexion une fois que la machine a refait surface. Personnellement je n’utilise pas ce genre de fonctionnalité mais j’imagine que c’est une feature « nice to have » plutôt que d’utiliser le module « pause » ou la fonctionnalité « retry » en attendant que l’hôte refasse surface.

Les nouveaux modules

Je ne vais pas en faire la liste complète (disponible dans le changelog), mais cette version a visiblement été l’occasion pour les équipes de plusieurs cloud providers de se mettre en avant.

On peut noter les équipes de Google Cloud comme grands vainqueurs avec 39 nouveaux modules. Ils sont suivi par Azure (+21, avec l’apport des bases de données et des webapps), Vultr (13), et 8 pour Scaleway.

Tout ça m’intéresse beaucoup car, notamment pour Scaleway, de nombreux objets étaient encore indisponibles et il a fallut que j’écrive des scripts à la main pour curler l’API, ne serait ce que pour récupérer les IDs des templates de VMs que je voulais utiliser (impossible à lister autrement).

Avant :

curl -X GET -H "X-Auth-Token: $SCW_API_KEY" -H 'Content-Type: application/json' https://cp-par1.scaleway.com/images | jq -r '.images[] | select(.name|contains("CentOS")) | .id,.name,.arch,.modification_date'
37832f54-c18f-4338-a552-113e4302a236
CentOS 7.4
x86_64
2018-09-06T10:40:08.145552+00:00
[...]

Maintenant, je peux sois l’exécuter à la main directement depuis Ansible, soit requêter le serveur Scaleway pour avoir une liste des images disponible directement dans mes playbooks :

ansible localhost -m scaleway_image_facts -a region=par1
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
localhost | SUCCESS => {
"ansible_facts": {
"scaleway_image_facts": [
{
"arch": "x86_64",
"creation_date": "2018-09-14T10:01:24.268850+00:00",
"default_bootscript": {
"architecture": "x86_64",
"bootcmdargs": "LINUX_COMMON scaleway boot=local nbd.max_part=16",
"default": false,
"dtb": "",
"id": "15fbd2f7-a0f9-412b-8502-6a44da8d98b8",
[...]
- name: Gather Scaleway images facts 
scaleway_image_facts: 
region: par1
register: images_facts

Et tant qu’on est dans le genre module qui vient remplacer des trucs que je faisais à la mimine, on peut aussi citer docker_swarm + docker_swarm_service pour gérer un cluster docker Swarm (comme son nom l’indique), ou k8s_facts pour récupérer des objets dans Kubernetes.

Et ma première contribution !

Même si j’ai déjà contribué sur plusieurs projets open source (traductions du site de Shinken, petites contributions à plusieurs plugins Nagios et à XWiki, ouverture d’issues dans de nombreux projects open source), j’ai également résolu ma première issue sur un gros projet grâce à Ansible et l’équipe d’Azure.

Il y a peu, Microsoft a mis à disposition sur Azure de machine virtuelle disposant gratuitement d’interface physique dédiées (non virtualisées donc) à 30 Gbps et avec une latence moindre (plus d’info sur la documentation officielle).

Comme il s’agissait d’un simple flag à ajouter dans l’API et que l’issue avait été taguée en « easy fix » par les maintainer, j’ai sauté sur l’occasion et j’ai pris l’issue à mon compte.

Au final, sur les 70 lignes de mon commit, il n’y a que 10 lignes de codes (le reste étant des tests et de la documentation, obligatoires pour toute soumission), mais je suis quand même content car ça marche bien ;)

Champomy !!