Article technique · Console de déploiement

Une console de déploiement qui appelle les scripts existants

Publié le , mis à jour le

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

Mots-clés

Tous les articles