Console de déploiement
La console de déploiement est une page web qui présente un bouton par projet et qui exécute, sur le serveur, le script de livraison que ce projet possède déjà, de sorte qu’une mise en ligne ne suppose ni compte sur le serveur ni outillage sur le poste de celui qui la déclenche.
- Rôle
- Auteur unique
- Période
- Août 2026
- État
- En service. En service ; vingt actions, un seul compte déclaré à ce jour
- Technologies
- OliveTin, Docker Compose, Apache, scripts shell
- Dépôts
- Un
Contexte
Chacun de mes projets se livre par un script placé dans son dépôt, qui met à jour le code sur le serveur puis reconstruit ses conteneurs. Ce fonctionnement convient tant que je suis seul à livrer, puisqu’il suppose un compte sur le serveur, les clés qui permettent d’y lire les dépôts et, pour certains projets, le jeton qui annonce la livraison.
Problème
Confier une livraison à un collaborateur revenait à lui ouvrir le serveur entier, alors qu’il n’a besoin que de déclencher une opération connue. Écrire un outil de déploiement distinct aurait par ailleurs créé une seconde façon de livrer, dont rien ne garantissait qu’elle resterait identique à la première.
Réponse apportée
Appeler le script existant
La console repose sur OliveTin, dont l’image embarque déjà docker, git et ssh. Chaque bouton se réduit à une ligne, qui se place dans le répertoire du projet et y lance son script. Rien n’est réécrit : le script du dépôt demeure la seule source de vérité, et une livraison lancée depuis la console ne peut pas différer d’une livraison lancée depuis un terminal. L’environnement, production ou recette, est un argument du bouton, limité à une liste fermée.
- title: Sanu - API Django
shell: cd "$PROJECTS_ROOT/sanu-api-django" && bash ci/{{ environnement }}.sh
timeout: 1800
maxConcurrent: 1
acls: [devs]
arguments:
- name: environnement
title: Environnement
type: ascii_identifier
default: production
choices:
- value: production
title: Production
- value: staging
title: RecetteRefuser par défaut
Toutes les permissions sont refusées par défaut. Le groupe des administrateurs voit chaque action, tandis que le groupe des développeurs ne voit que celles qui le nomment dans leur liste d’accès. Ajouter une action ne la rend donc visible à personne tant qu’une liste ne l’autorise pas, et un oubli se traduit par un bouton absent plutôt que par un accès de trop. Chaque action de livraison est par ailleurs limitée à une exécution à la fois et bornée par un délai.
Le même chemin des deux côtés
Les scripts appellent Docker depuis le conteneur de la console, mais c’est le démon de l’hôte qui résout les contextes de construction. Le répertoire des projets est donc monté dans le conteneur au chemin exact qu’il occupe sur l’hôte, faute de quoi une construction chercherait des fichiers là où ils ne sont pas. La version de l’image est enfin figée, afin qu’un redémarrage du serveur ne change pas la console sans que personne l’ait décidé, et le redéploiement de la console attend que son contrôle de santé réponde avant de se déclarer réussi.
Limites et perspectives
Une console capable de piloter Docker et de lire les dépôts équivaut à un accès complet à la machine, et il m’a semblé préférable de l’écrire dans sa documentation plutôt que de le laisser deviner. Trois précautions en découlent, qui ne sont pas facultatives : la console n’écoute qu’en local, derrière une connexion chiffrée, le mode invité est fermé, et l’image est tenue à jour. Une seconde barrière devant la console, par filtrage ou par un service d’authentification, reste à mettre en place.
La délégation, qui justifiait le projet, n’a pas encore été exercée : un seul compte est déclaré, et le groupe des développeurs n’a aucun membre. La console ne garde par ailleurs d’autre trace d’une livraison que ses journaux. Les dépôts les plus récents de Sanu se livrent enfin par leurs pipelines, si bien qu’une partie du périmètre de la console s’est déplacée depuis son écriture et que certaines de ses actions demandent à être revues.
