Portrait de Patrice GADEGBEPatrice GADEGBE

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
Chemin d’une livraison par la consoleLe navigateur de l’opérateur atteint la console OliveTin à travers Apache, qui termine la connexion chiffrée. La console exécute le script de déploiement du projet choisi, lequel met à jour le dépôt et reconstruit les conteneurs par le Docker de l’hôte.Navigateuropérateur connectéApacheconnexion chiffréeOliveTinun conteneurvingt actionsScriptsun par projet,déjà dans son dépôtDockerdémon de l’hôte
Figure 1. Chemin d’une livraison, du bouton au conteneur reconstruit. La console n’exécute rien qui lui soit propre : elle appelle le script du projet.

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: Recette
Extrait 1. Une action de la console : un script existant, un argument contraint, une liste d’accès.

Refuser 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.

Retour aux autres projets