Installer via un pipeline Aetheus

Dès que vous exploitez un Aetheus, il peut installer le suivant. Cette page décrit le plus petit pipeline qui y parvient : construire, déployer, enregistrer une release. Pas de QA, pas de porte qualité, pas d'analyse de sécurité.

Ce qu'il faut avant d'écrire le moindre YAML

1. Un projet

   Tout le reste s'y rattache : le dépôt, le pipeline, les releases et les artefacts.

2. Un dépôt Git lié à ce projet

   La définition du pipeline est lue depuis le dépôt à chaque lancement, et l'exécution y récupère une révision épinglée. Un pipeline nécessitant un espace de travail est refusé avant même la création de l'exécution si son dépôt source est absent ou ambigu : liez-le donc explicitement quand le projet en contient plusieurs.

3. Un agent en ligne sur l'hôte cible

   Le pipeline s'exécute sur la machine que vous déployez. Enregistrez cette machine en tant que serveur et attendez que son agent soit en ligne : une étape sans runner éligible attend au lieu de déployer ailleurs.

   L'hôte a aussi besoin de ce qu'utilise le build. Pour la configuration ci-dessous, c'est Docker avec le greffon Compose.

4. Une bibliothèque de variables pour les valeurs non secrètes

   Noms d'hôte, ports, racines web, chemins de déploiement. Un pipeline ne voit qu'une bibliothèque qu'il liste explicitement : la déclarer dans le YAML fait partie de la mise en place, pas des finitions.

5. Un coffre pour les secrets

   Mot de passe de la base, clé JWT, clé et sel de chiffrement, mot de passe administrateur initial. Un coffre que le pipeline ne peut pas résoudre échoue l'exécution, ce qui est le comportement souhaitable : l'alternative serait de déployer avec des secrets vides.

Le pipeline minimal

Commitez ceci en tant que .pipeline/aetheus-install.yaml dans le dépôt lié. Trois étapes : construire les images, transmettre la charge utile à l'étape de déploiement, puis enregistrer ce qui a été publié.

name: aetheus-install
trigger: manual

variable_libraries:
  - aetheus-target-host

vaults:
  - aetheus-target-secrets

variables:
  APP_VERSION: "1.0.$(BUILD_PIPELINE_RUNNUMBER)"
  COMPOSE_PROJECT: "aetheus"
  DEPLOY_DIR: "/srv/aetheus"

stages:
  - name: Build
    os: linux
    group: Deploy
    steps:
      - name: Construire les images de production
        checkout: true
        working_directory: "$(WORKSPACE)"
        timeout_seconds: 3600
        shell: |
          set -eu
          SOURCE_COMMIT="$(git rev-parse HEAD)"
          docker build \
            --load \
            --build-arg "APP_VERSION=$(APP_VERSION)" \
            --file deploy/docker/Dockerfile.back \
            --tag "aetheus-back:${SOURCE_COMMIT}" .
          docker build \
            --load \
            --file deploy/docker/Dockerfile.front \
            --tag "aetheus-front:${SOURCE_COMMIT}" .
          docker image inspect \
            "aetheus-back:${SOURCE_COMMIT}" \
            "aetheus-front:${SOURCE_COMMIT}" >/dev/null
          mkdir -p .pipeline-artifacts
          printf '%s' "${SOURCE_COMMIT}" > .pipeline-artifacts/source-commit

  - name: Deploy
    os: linux
    group: Deploy
    depends_on:
      - Build
    steps:
      - name: Démarrer la pile
        checkout: true
        working_directory: "$(WORKSPACE)"
        timeout_seconds: 1800
        shell: |
          set -eu
          SOURCE_COMMIT="$(git rev-parse HEAD)"
          export AETHEUS_BACK_IMAGE="aetheus-back:${SOURCE_COMMIT}"
          export AETHEUS_FRONT_IMAGE="aetheus-front:${SOURCE_COMMIT}"
          export APP_VERSION="$(APP_VERSION)"
          cd "$(DEPLOY_DIR)"
          docker compose up -d
          # Ne pas appeler cela un succès tant que la base n'est pas réellement joignable.
          for attempt in $(seq 1 30); do
            if curl -sf http://127.0.0.1:10026/health/ready; then exit 0; fi
            sleep 5
          done
          echo "Le backend n'est jamais devenu disponible." >&2
          exit 1

  - name: Release
    os: linux
    group: Deploy
    depends_on:
      - Deploy
    steps:
      - name: Enregistrer la release déployée
        type: release
        version: "$(APP_VERSION)"
        changelog: true
        deployed: true
        timeout_seconds: 300

Lire ce pipeline

• checkout: true clone la révision épinglée dans $(WORKSPACE). Sans lui, l'étape s'exécute dans un répertoire vide.
• depends_on est ce qui sérialise les trois étapes. Sans lui, elles seraient distribuées en parallèle.
• La tâche de déploiement interroge /health/ready et non /health/live, car le processus répond « vivant » avant que sa connexion à la base soit utilisable. Interroger le mauvais point de santé est la façon classique de déclarer réussi un déploiement cassé.
• La tâche release est un type natif, pas un script : le backend connaît alors la version, le commit et les artefacts, ce qui donne à un futur retour arrière une cible précise.

Première exécution

1. Poussez le YAML sur la branche par défaut du dépôt lié. La définition est lue depuis Git au lancement : rien à synchroniser dans l'interface.

2. Créez le pipeline dans le projet en le pointant sur ce slug, et rattachez-lui la bibliothèque de variables et le coffre.

3. Lancez-le, et suivez la chronologie d'exécution. Une étape bloquée en attente signifie presque toujours qu'aucun agent éligible n'est en ligne pour son os.

4. Une fois au vert, la vue d'ensemble de l'exécution porte la release produite et le commit dont elle est issue.

Ce que ce pipeline laisse volontairement de côté

Les pipelines que le projet applique à lui-même ajoutent beaucoup à ce squelette : artefacts candidats immuables, bascule de couleur blue-green pour que le plan de contrôle ne tombe jamais en se déployant lui-même, étape de retour arrière déclenchée uniquement si la release échoue, et rétention. Ajoutez-les quand vous en aurez besoin ; rien de tout cela n'est nécessaire pour installer une instance.

• Pipelines : étapes, tâches, artefacts et modèles en détail.
• Apache : publier les deux noms d'hôte une fois la pile démarrée.