Orchestration multi-machine
AutomationSequence V8

Architecture d'orchestration

AutomationSequence V8 peut distribuer des actions sur plusieurs machines depuis un nœud maître. Deux architectures sont possibles : SSH direct (exécution de commandes sur les nœuds distants via Paramiko) et Agent distribué (un processus AutomationSequence-Agent tourne sur chaque nœud et reçoit des instructions via API REST chiffrée).

# Architecture SSH (simple, sans agent)
Nœud maître
  ├── SSH → srv01 : commandes bash/python
  ├── SSH → srv02 : commandes bash/python
  └── SSH → srv03 : commandes bash/python

# Architecture Agent (recommandée pour séquences complexes)
Nœud maître
  ├── HTTPS → agent:8421 (srv01) : actions AutomationSequence
  ├── HTTPS → agent:8421 (srv02) : actions AutomationSequence
  └── HTTPS → agent:8421 (srv03) : actions AutomationSequence

Modes de connexion

Mode SSH

{
  "type": "ssh_exec",
  "host": "srv01.intranet",
  "user": "deployer",
  "key_vault": "SSH_KEY_PROD",
  "cmd": "systemctl restart nginx && systemctl status nginx",
  "timeout": 30,
  "output_var": "srv01_status"
}

Mode Agent

# Démarrer l'agent sur chaque nœud cible
automation-sequence-agent --port 8421 --token vault:AGENT_TOKEN

# Dans la séquence maître
{
  "type": "agent_exec",
  "agent_url": "https://srv01:8421",
  "token_vault": "AGENT_TOKEN",
  "sequence": "deploy_app.asenc",
  "vars": {"version": "{{app_version}}"},
  "output_var": "srv01_result"
}

Exécution parallèle

{
  "type": "parallel_exec",
  "nodes": [
    {"host": "srv01", "label": "Web-1"},
    {"host": "srv02", "label": "Web-2"},
    {"host": "srv03", "label": "Web-3"}
  ],
  "actions": [
    {"type": "ssh_exec", "cmd": "systemctl stop app"},
    {"type": "ssh_exec", "cmd": "rsync -az /opt/release/ /opt/app/"},
    {"type": "ssh_exec", "cmd": "systemctl start app"}
  ],
  "timeout_per_node": 120,
  "fail_threshold": 1,
  "output_var": "deploy_results"
}

fail_threshold: 1 arrête l'ensemble si plus d'un nœud échoue. Mettre 0 pour continuer quoi qu'il arrive (mode best-effort).

Gestion des pannes

• Retry automatique — chaque action distante peut être configurée avec "retry": 3, "retry_delay": 10.
• Rollback — définir une séquence de rollback déclenchée si fail_threshold est atteint.
• Checkpoint — V8 sauvegarde l'état d'avancement en cas d'interruption. La séquence reprend depuis le dernier checkpoint au prochain lancement.

{
  "type": "parallel_exec",
  "nodes": ["srv01", "srv02", "srv03"],
  "actions": [/* ... */],
  "on_failure": {
    "sequence": "rollback_deploy.asenc",
    "notify": "smtp:ops@entreprise.fr"
  }
}

Monitoring distribué

Le dashboard web local (port 8420) agrège les statuts de tous les nœuds en temps réel via Server-Sent Events (SSE). Chaque agent pousse ses métriques au maître toutes les 5 secondes :

• Statut de chaque nœud : actif, en cours, erreur, terminé.
• Progression action par action pour chaque nœud.
• Log consolidé avec code couleur par nœud.
• Alertes SMTP ou toast Windows si un nœud passe en erreur.

Patterns d'usage courants

• Rolling deploy — déployer nœud par nœud (pas de parallel_exec) avec vérification de santé entre chaque.
• Blue/Green — déployer sur un sous-ensemble de nœuds, valider, basculer le load balancer.
• Collecte distribuée — exécuter des requêtes Oracle sur plusieurs serveurs, consolider les résultats sur le maître.
• Audit de parc — lancer une séquence d'inventaire en parallèle sur 50 postes, consolider en un rapport.

Conclusion

L'orchestration multi-machine d'AutomationSequence V8 couvre les cas d'usage de déploiement coordonné, de collecte distribuée et d'audit de parc. Les deux modes (SSH direct et agent) permettent de s'adapter aux contraintes réseau : pas d'agent installable → mode SSH ; séquences complexes avec état → mode agent. Le mécanisme de checkpoint garantit la reprise après interruption sans recommencer depuis zéro.