Orchestration Salt : runner, orchestrate et déploiement multi-nœuds

Un highstate configure chaque minion isolément. Mais déployer une application, c'est souvent coordonner plusieurs machines : la base d'abord, les serveurs web ensuite. C'est le rôle de l'orchestration de Salt, pilotée depuis le master. Ce module déploie une architecture web + base de données dans le bon ordre. Public visé : intermédiaires et avancés maîtrisant les states.

Ce que vous allez apprendre

Distinguer highstate et orchestration.
Écrire un fichier orchestrate qui coordonne plusieurs minions.
Ordonner les étapes entre machines.
Déployer une architecture web + base de données.

Prérequis

Plusieurs minions par rôle et l'aisance sur les states.

Highstate contre orchestration

Le highstate répond à « rends ce minion conforme ». L'orchestration répond à « déploie l'ensemble dans cet ordre ». Elle s'exécute sur le master via un runner et un fichier orchestrate, qui enchaîne des appels de states sur différents minions avec des dépendances explicites entre eux.

Un fichier orchestrate

L'orchestration réutilise la logique des requisites, mais entre machines : le state web attend que le state base soit terminé. On appelle salt.state par étape, reliées par require.

deploy-database:
  salt.state:
    - tgt: 'role:db'
    - tgt_type: grain
    - sls:
      - dbdeploy

deploy-web:
  salt.state:
    - tgt: 'role:web'
    - tgt_type: grain
    - sls:
      - webdeploy
    - require:
      - salt: deploy-database

Chaque étape cible un rôle par grain (role:db, role:web) et applique un state dédié. Le state webdeploy est celui du module Gestion des fichiers ; dbdeploy est volontairement minimal, il installe et démarre PostgreSQL :

postgresql:
  pkg.installed: []
  service.running:
    - enable: true
    - require:
      - pkg: postgresql

Le require sur deploy-database garantit que la base est prête avant de toucher aux serveurs web. On lance l'orchestration avec le runner dédié, depuis le master :

sudo salt-run state.orchestrate orch.deploy

Travaux pratiques : une architecture web + base

Le fichier orchestrate ci-dessus provisionne PostgreSQL sur le minion de rôle db, attend qu'il soit prêt, puis configure les serveurs web. À l'exécution, le runner déroule les deux étapes dans l'ordre. La première installe la base :

          ID: deploy-database
    Function: salt.state
      Result: True
     Comment: States ran successfully. Updating db1.
     Started: 19:43:34.468488
     Changes:
                        ID: postgresql
                  Function: pkg.installed
                    Result: True
                   Comment: The following packages were installed/updated: postgresql
          ID: deploy-web
    Function: salt.state
      Result: True
     Comment: States ran successfully. No changes made to web1.
     Started: 19:44:28.384676

Succeeded: 2 (changed=1)
Failed:    0

L'ordre saute aux yeux dans les horodatages : deploy-database démarre à 19:43:34 et deploy-web seulement à 19:44:28, une fois la base terminée. C'est le require qui impose cette barrière, impossible à obtenir avec deux highstates lancés séparément. La base est ensuite joignable :

sudo salt db1 cmd.run 'sudo -u postgres psql -tAc "select version();"'

db1:
    PostgreSQL 17.10 (Debian 17.10-0+deb13u1) on x86_64-pc-linux-gnu

Prouver l'idempotence

Rejouée sur une infrastructure déjà conforme, l'orchestration ne change rien, étape par étape :

sudo salt-run state.orchestrate orch.deploy

          ID: deploy-database
     Comment: States ran successfully. No changes made to db1.
          ID: deploy-web
     Comment: States ran successfully. No changes made to web1.

Succeeded: 2
Failed:    0

Aucun changement sur les deux machines : l'orchestration hérite de l'idempotence des states qu'elle enchaîne. On peut la rejouer autant de fois que nécessaire, elle ne réagit qu'aux écarts réels de configuration.

À retenir

Le highstate configure un minion ; l'orchestration coordonne l'ensemble.
L'orchestration s'exécute sur le master via salt-run state.orchestrate.
Un fichier orchestrate enchaîne des salt.state reliés par require.
Elle garantit l'ordre entre machines (base avant web).

Prochaines étapes

Salt SSH Orchestrer aussi des serveurs sans agent installé.

Les pillars Servir à chaque minion sa configuration et ses secrets depuis le master.