Sommaire
Épisode 2 du feuilleton où je baragouine sur ma prod.
Dans le journal précédent, on parlait de Docker Swarm et de CI/CD.
J'aime bien Arch, y compris sur des serveurs. On a des paquets très récents; et grâce au rolling release, on s'évite de trop gros changement d'un coup (pensez juste à vous abonnez à la mailing list pour être prévenu des trucs qui cassent). Arch Linux is one of the best distro for home servers, change my mind.
Malheureusement, lors d'un changement de serveur, j'ai pu constater que OVH ne proposait plus d'images Arch Linux. Et mon serveur n'avait pas de IPMI/KVM/autres pour faire une installation manuelle. J'aurais pu tenter des trucs, mais flemme. Tant pis, on va partir sur Ubuntu LTS.
Oh joie, la LTS est sortie il y a 20 mois. Ça veut dire que tous les paquets sont ultra-périmés et que dans quelques mois faudra se taper une upgrade vers la nouvelle LTS. Génial.
C'est la que j'ai décidé de prendre une décision importante dans ma vie. Avant, je n'utilisais Docker Swarm que pour les projets liés à une CI/CD. Pour les autres services, je les installais directement sur le système, avec des paquets. C'était chiant à maintenir, mais au moins ça marchait. Mais maintenant, je serais "cloud-natif" et je containeriserai tout. Plus de dépendance à une distribution, plus de problèmes de paquets périmés, plus de problèmes de compatibilité. Juste des conteneurs Docker qui tournent sur n'importe quelle machine. Et des docker-compose pour tout gérer de manière déclarative et versionnée.
Ce fut un peu relou, mais avec le temps j'ai réussi à docker swarmisé tous mes services (freshrss, mattermost, nextcloud, vaultwarden, miroir archlinux…).
Avantages :
- contrôle fin des versions: je ne suis plus soumis à la politique de mise à jour de la distribution
- isolation des services: chacun tourne dans son petit sous réseau, à sa propre base de données, …
- déclarativité et reproductibilité: tout est dans git, je peux redéployer toutes les stacks en quelques minutes sur n'importe quelle machine (faut quand même se taper quelques heures de migration manuelle des données :D me suis pas encore posé la question de comment partager les volumes docker entre les machines du cluster swarm)
Inconvénients :
- parfois le truc que tu veux n'a pas encore d'image officielle
- parfois l'image est cloud-hostile. Je pense à vous machins qui me demande d'éditer un fichier de config. Tu crois que c'est facile de modifier un fichier de config dans un environnement CaaS sans SSH ? Tu crois que j'ai que ça a faire que de build une image custom juste un fichier de config ? Les gens, soyez cloud-friendly et permettez de configurer votre app par des variables d'environnement et des arguments de ligne de commande.
- maintenant que vous avez une db par service, faut se taper vachement plus de migrations de postgres :D
- c'est plus relou à backuper proprement. je suis un sauvage et j'ai directement ajouté /var/lib/docker/volumes à borgmatic. J'ai pas eu à restaurer, je ne sais pas à quel point c'est une mauvaise idée
Et surtout, c'était relou de redeploy tout ce petit monde pour prendre les mises à jours.
À l'époque, quand j'avais regardé, le seul projet qui gérait ça était Watchtower, mais qui était déjà non maintenu. (Le camarade flagos< vient de me faire découvrir gantry, pas encore testé).
Du coup je gérais ça via la GUI de Portainer.
Pis j'ai découvert les contextes Docker. Et là, c'est la révélation. C'est exactement ce qu'il me fallait pour gérer mes stacks Docker Swarm à distance depuis ma CI/CD. Et c'était l'occasion de martyriser encore un peu plus Make, mon outil préféré pour l'automatisation.
Automatiser le déploiement de stacks Docker Swarm avec Make et les contextes Docker
Voici un petit exemple avec deux stacks :
.
├── Makefile
├── stack1/
│ ├── compose.yml
│ └── Makefile
└── stack2/
├── compose.yml
└── Makefile
Exemple d'utilisation :
# Déployer la stack1 :
$ cd stack1
$ make deploy
# Déployer la stack2 :
$ cd ../stack2
$ make undeploy
# tout déployer d'un coup :
$ cd ..
$ make -j2 deploy-allMakefile d'une stack :
deploy:
DOCKER_CONTEXT=mon_cluster docker stack deploy --compose-file compose.yml --prune stack1
undeploy:
DOCKER_CONTEXT=mon_cluster docker stack rm stack1Makefile racine :
deploy-all: deploy-stack1 deploy-stack2
deploy-stack1:
$(MAKE) -C stack1 deploy
deploy-stack2:
$(MAKE) -C stack2 deployC'est facile d'ajouter de nouvelles stacks, c'est facile de redéploy une stack spécifique après avoir touché le compose.yml, c'est facile de tout redéployer d'un coup afin de s'assurer d'avoir les dernières images de tous les services (docker swarm ne redéployant que ce qui a effectivement changé). Et tout ça sans jamais quitter la ligne de commande, sans jamais se connecter en ssh à un serveur, sans jamais ouvrir une interface web. Juste du Make et des contextes Docker. C'est beau, c'est propre, c'est efficace. J'ai même hésité à ajouter une CI pour encore plus d'automatisation.
Pour les curieux, le dépot de mon ancienne infra où j'implémente cette approche : https://github.com/jtremesay/infra
À l'épisode 3 du feuilleton où je baragouine sur ma prod, on verra nixos et les containers systemd-nspawn pour une prod toujours plus containerisé, déclarative, reproductible tout en restant facile à maintenir
# Nix
Posté par François Chaix (Mastodon) . Évalué à 2 (+1/-0).
Rha, tu m'as devancé. Je prenais mon élan pour écrire un commentaire sur Nix ou Guix, étant de parfaites solutions aux problèmes que tu décrits !
Hâte de lire l'épisode 3, donc !
[^] # Re: Nix
Posté par par . Évalué à 3 (+2/-0).
Nix ? Ça y est ? Ils ont enfin une vraie doc ? Parce qu'il y a encore quelques mois, j'ai essayé, on en était encore au WTFM (Write The Fucking Manual). On avait surtout droit à un ensemble de how-to qui ne vont pas très loin, sans grandes explications, et sans trop savoir à quelles versions ils s'appliquent…
[^] # Re: Nix
Posté par François Chaix (Mastodon) . Évalué à 1 (+0/-0).
Je suis utilisateur de Nix, et j'approuve ce message. C'est clair que la doc est très éparpillée voire inexistante, et quand on a des besoins un peu complexes, comme j'imagine c'est le cas pour du professionnel, ça peut être pénible.
Moi je n'utilise ça que pour mon informatique personnelle, c'est moins complexe, je peux me permettre des petites sessions de geekerie (Une journée passée à bidouiller, en gros), surtout en regard du fait qu'ensuite quand on a une config qui marche, c'est incroyablement stable, et incassable, du moins selon mon expérience. Si je compare avec le temps que je passais à l'époque à réparer ma Arch, puis ma Gentoo, le gain est substantiel.
J'ai même essayé pour quelques cas de m'aider d'un LLM pour écrire du Nix. Il ne s'en est pas trop mal sorti. Mais bon, il vaut mieux connaitre un minimum le truc pour comprendre ce que ça fait. Comme pour tout ce qui sort de ces outils, d'ailleurs.
[^] # Re: Nix
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+1/-0).
Hop https://www.nicdumz.fr/nix-config/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pas de rolling release en prod
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Chez soi, pourquoi pas, mais en prod, sur les dizaines de baremetal qu'on a, il est hors de question d'avoir des systèmes qui changent tous les jours. On a besoin de stabilité, pour ne pas avoir de risques de régression tous les 4 matins. On a autre chose à faire que de surveiller tous les jours qu'un update majeure de paquets ne va pas casser notre prod.
Bref, Debian est très bien pour de la prod. On a juste les mises à jours mineures et de sécu à faire. On préfère passer 2-3 jours à tester un upgrade majeure de debian sur notre infra de test, et être tranquille pour 2-3 ans, que de s'adapter en permanence aux évolutions des softs systèmes ou autre. Cela nous laisse plus de temps pour se concentrer sur les installations/maintenances de nos stacks de conteneurs de nos applis métiers (qui, elles, évoluent régulièrement).
Pour certains softs dont les versions sont un peu trop vieilles pour nous dans Debian, on utilise les dépôts tiers, comme c'est le cas pour Docker, en gelant la version majeure (pin) pour éviter les surprises comme expliqué plus haut.
# Make
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
J’ai arrêté d’utiliser make. Pour les question hors de build de projets C ou C++, je trouve qu’il y a pleins d’alternatives qui sont très intéressantes. Elles n’ont comme seule défaut d’être une pléthore de choix, mais je ne crois pas que ça puisse inquiéter quelqu’un qui a déjà choisi son gestionnaire de paquet, son shell, son environnement de bureau et sa distribution…
Pourquoi remplacer make ?
Mon préféré c’est mise. Je commit un mise.toml et j’ai un mise.local.toml qui est exclu de mes commits. Il peut installer des outils dans des versions spécifiques pour moi. Je le lance en mode watch pour certains usages. Il fait aussi l’équivalent de direnv.
Je m’en sert aussi pour mon serveur perso. Outre le fais de me simplifier des commandes ansibles un peu longues, j’ai aussi une commande « check » qui utilise hurle pour vérifier un certain nombre de services.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# CI/CD
Posté par flagos . Évalué à 3 (+1/-0). Dernière modification le 06 mars 2026 à 13:40.
Dans le CI/CD, autant le CI est bien présent de nos jours, autant parfois le CD manque a l'appel. C'est vraiment bien d'avoir une plateforme toujours a jour, et d'enlever les frictions au déploiement. Ca permet de se rendre compte rapidement si il y a un problème dans un environnement partage. On évite l’écueil du collègue qui nous répond: "Ca marche chez moi" alors qu'en fait ca marche chez personne d'autre: si ca marche pas sur la plateforme de CD, ca ne marche juste pas.
Bref, faites du CD.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.