Une plateforme, cinq outils
Le cluster en lui-même n'a rien d'original : K3S, Traefik, un certificat. Ce qui fait la différence à l'usage, c'est la couche d'outillage écrite autour, dont l'objectif unique est de réduire chaque opération à son intention. En voici l'inventaire.
1. Le moteur de déploiement
Un programme Python, exécuté par systemd, qui transforme une déclaration en application publiée. Il assure quatre fonctions :
- Traduction : la déclaration YAML devient un jeu complet de ressources Kubernetes (espace de noms, secret TLS, volume, déploiement, service, règle d'entrée).
- Application : les manifestes sont écrits sur disque puis appliqués au cluster ; ils restent consultables pour l'audit.
- Nettoyage : les applications dont le fichier a disparu sont supprimées, en ne touchant qu'aux espaces de noms portant son étiquette de gestion.
- Robustesse : une déclaration invalide est signalée dans le journal sans jamais empêcher le déploiement des autres.
Le déclenchement repose entièrement sur systemd — une unité path pour la réactivité immédiate, un timer de cinq minutes pour la réconciliation. Aucun démon maison, aucune dépendance externe : ce sont les mécanismes du système, avec leurs journaux et leur supervision habituels.
2. La CLI d'exploitation
Tout fonctionne à la copie et à la suppression de fichiers, mais une petite interface en ligne de commande évite d'avoir à s'en souvenir :
k3s-app templates # modèles disponibles k3s-app new wikijs mon-wiki # crée la déclaration et déploie k3s-app list # applications, état, URL k3s-app status mon-wiki # pods, service, ingress, volume, évènements k3s-app logs mon-wiki -f # journaux applicatifs k3s-app rm mon-wiki # suppression complète k3s-app ca # autorité locale à importer sur un poste
Un détail qui n'en est pas un : k3s-app list affiche l'URL publique de chaque application à côté de son état. La question « quels services tournent ici, et à quelle adresse ? » se règle en une commande.
La CLI répond à la question « qu'est-ce qui tourne ici, et à quelle adresse ? » en une commande : état, URL publique et fichier de déclaration de chaque application.
3. Les modèles d'applications
Trois modèles sont fournis dans /srv/k3s-apps/templates/ :
- wikijs — Wiki.js avec base SQLite et volume persistant, l'exemple de référence ;
- whoami — service de test minuscule, idéal pour valider la chaîne DNS, proxy, TLS et conteneur en quelques secondes ;
- generique — modèle documenté champ par champ, point de départ pour n'importe quelle image web.
Chaque modèle contient un marqueur remplacé par le nom choisi : la copie du fichier et le nommage de l'application sont une seule et même action.
4. Les scripts de construction
Côté hôte, trois scripts rejouables couvrent tout le cycle de vie de la plateforme :
- 01-create-vm.sh — génère l'ISO cloud-init, crée le disque, pose les droits d'accès, réserve l'adresse IP et lance l'installation totalement automatisée d'Ubuntu.
- 02-provision-vm.sh — attend que la machine réponde, copie les fichiers de provisionnement et installe K3S, la chaîne de certificats et le moteur de déploiement. Idempotent : on peut le relancer à volonté, il ne réinstalle que ce qui manque.
- 03-test-deploiement.sh — recette de bout en bout : dépôt d'une application, attente de disponibilité, contrôle du code HTTP, du certificat présenté et de la redirection, puis suppression et vérification du nettoyage.
Ce troisième script est le plus utile des trois : il transforme « je crois que ça marche » en preuve reproductible, et il a effectivement servi à détecter une redirection HTTP vers HTTPS silencieusement inopérante.
5. La documentation et la fiche opératoire
Le livrable comprend dix chapitres Markdown — prérequis, installation, réseau et DNS, K3S, certificats, moteur de déploiement, exemple complet, exploitation, recette — assemblés en un PDF de 33 pages par un petit script de génération.
S'y ajoute une fiche opératoire : un fichier texte unique qui rassemble les accès, la procédure de déploiement, le format des déclarations, les commandes de diagnostic et les pièges connus. Sa raison d'être est simple : permettre à quelqu'un d'autre — ou à un assistant — d'intervenir sur la plateforme sans relire toute la documentation.
Enfin, le message d'accueil SSH rappelle en cinq lignes comment déployer une application. La documentation la plus lue est celle qui s'affiche toute seule au bon moment.
Trois principes de conception
- Déclaratif plutôt qu'impératif : l'état voulu est décrit par des fichiers ; l'outillage se charge de faire converger le cluster vers cet état, en boucle.
- Idempotence systématique : chaque script peut être relancé sans effet de bord. C'est ce qui rend une infrastructure réparable plutôt que fragile.
- S'appuyer sur le système, pas à côté : systemd pour le déclenchement et les journaux, les manifestes auto-appliqués de K3S pour la configuration durable de Traefik. Moins de code maison, c'est moins de code à maintenir.