n8n¶

Rôle¶

n8n est destiné à être l'outil d'automatisation de workflows (no-code/low-code) de l'infrastructure Indio, pour orchestrer des tâches inter-services (webhooks, intégrations API, automatisations diverses).

Architecture¶

• Le code déclare une VM unique INDSERV008, zone service (seg-service réseau), 1 vCPU / 2 Go, clone du template Rocky 9.6 durci — le dimensionnement le plus léger des services applicatifs de la flotte.
• IP prévue via lookup NetBox dynamique (data netbox_ip_addresses, filtrée sur dns_name) — même schéma que glpi/ocs/postfix/k8s.
• Détail notable dans terraform.tfvars : vsphere_folder = "seg-soc" — la VM serait rangée dans le dossier vCenter seg-soc (classement fonctionnel hérité de l'époque où n8n faisait partie du périmètre SOC au sens large) alors que son réseau NSX réel resterait seg-service. Ce découplage dossier/réseau est cohérent avec la convention de nommage de la flotte (voir Convention de nommage).
• Historique (git log du dépôt, 4 commits) : VM provisionnée le 2026-07-04, renommée vers la convention IND<SEGMENT><NNN>, branchée sur le provider NetBox, puis basculée sur le compte de service svc-terraform — le code a continué d'être maintenu après la destruction du 2026-07-06, sans qu'aucun de ces commits ne corresponde à une recréation réelle de la VM.

stateDiagram-v2
    [*] --> S1
    S1 --> S2 : terraform destroy (2026-07-06)
    S2 --> S2 : code maintenu sur disque, jamais réappliqué
    state "Provisionnée (2026-07-04)" as S1
    state "Détruite" as S2
    note right of S2
        Constaté le 2026-07-19 : state Terraform vide,
        aucune VM "n8n" ni "INDSERV008" trouvée dans vCenter
    end note

Provisioning Terraform¶

• main.tf : VM unique vsphere_virtual_machine.n8n, IP résolue via NetBox (même schéma que glpi/ocs).
• Variables clés (variables.tf) : vm_name = INDSERV008, vsphere_network = seg-service, vm_cpu = 1, vm_ram = 2048.
• Providers (versions.tf) : hashicorp/vsphere + e-breuninger/netbox.
• Vérifié le 2026-07-19 : terraform state list ne retourne rien — état 100 % vide, cohérent avec une destruction jamais suivie d'un nouvel apply.

Configuration Ansible¶

Aucun dossier ansible/ n'existe dans ce dépôt : seule la VM nue était (et serait) provisionnée par Terraform. L'installation et la configuration applicative de n8n (conteneur ou paquet, base de données, reverse proxy, TLS) n'ont jamais été automatisées ici — cohérent avec le fait que la VM n'a existé que brièvement (2026-07-04 → 2026-07-06) avant sa destruction, sans doute jamais mise en service applicativement.

Procédure de déploiement¶

Pour recréer la VM nue :

# Aucun script seed dédié n'existe pour n8n (contrairement à k8s/postfix/identité) :
# réserver l'IP manuellement côté NetBox avant l'apply, sinon la data source
# netbox_ip_addresses échoue en "no result".
terraform apply

L'installation applicative de n8n resterait ensuite entièrement manuelle (non automatisée dans ce dépôt).

Points d'attention¶

• Aucun script seed/add_n8n_vms.py n'existe dans /root/netbox/seed/ (contrairement à add_k8s_vms.py, add_postfix_vms.py, add_identity_bare_vms.py) : un futur redéploiement nécessite soit d'écrire ce script, soit de réserver l'IP manuellement via l'UI/API NetBox avant terraform apply — sinon le même échec no result que documenté sur Postfix se produira.
• Contrairement aux autres services applicatifs de la flotte documentés ici (GLPI, OCS), ce projet ne contient aucun rôle Ansible : à compléter entièrement si une automatisation de la configuration applicative est mise en place lors d'une éventuelle recréation.
• Dimensionnement minimal (1 vCPU / 2 Go) — à revoir selon la charge de travail n8n prévue (nombre de workflows actifs, volumétrie des exécutions) si le service est un jour redéployé.
• Ne pas confondre avec un service actif : malgré le code présent et entretenu sur disque, aucune VM n8n n'est déployée à ce jour (2026-07-19).