Come funziona

Le parti di un’installazione, cosa succede a un avvio, e dove vengono conservati i dati

  1. Architettura
    1. Costruito con
  2. Cosa succede quando avvii un modulo
  3. Dove vengono conservate le cose

Architettura

AnsibleForms è un server Node.js che serve l’applicazione web e un’API REST, appoggiandosi a un database MySQL. Legge i moduli da file YAML e non esegue nulla da sé: passa ogni job a un runner. Un playbook va a uno dei tuoi container RTE (ambiente di runtime), che esegue ansible-playbook, e un template o un job va ad AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins:

Architettura di AnsibleForms Il browser e un client MCP facoltativo comunicano con il server di AnsibleForms. Il server salva i suoi dati in MySQL e nella cartella persistente, e si collega a origini dati, archivi di segreti, repository git, provider di accesso, canali di notifica, server syslog e un fornitore di modelli facoltativo. I suoi runner passano ogni playbook a uno di uno o più container RTE, ciascuno tramite un WebSocket, che eseguono ansible-playbook e rimandano l'output al server, e ogni template o job ad AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins. Browser moduli, designer, job, chat Client MCP facoltativo Server di AnsibleForms Node.js / Express App web e API REST Moduli, espressioni Workflow, pianificazioni Server MCP (facoltativo) Runner passano ogni job al suo runner Origini dati database, API REST, file Archivi di segreti HashiCorp Vault, CyberArk Repository git moduli, playbook, config Provider di accesso LDAP, Entra ID, OIDC Canali di notifica mail, Slack, Teams, webhook Server syslog il log, la traccia di audit Fornitore di modelli facoltativo, assistente chat Cartella persistente config, moduli, playbook MySQL / MariaDB job, utenti, credenziali Container RTE eseguono ansible-playbook AWX / AAP / Ascender Semaphore, Rundeck, Jenkins playbook, WebSocket template, job

I componenti del diagramma hanno ognuno un ruolo proprio:

Componente Ruolo
Browser L’applicazione web Vue: i moduli, il Designer, la cronologia dei job e le impostazioni
Server di AnsibleForms Valuta i moduli, registra i job, esegue i workflow e le pianificazioni, passa ogni job al suo runner e lo segue, e serve l’API REST
Runner Dove girano i job, aggiunti in Connessioni > Runner: un modulo ne nomina uno con runner: <name>, o usa il runner predefinito del suo tipo (vedi Runner)
Container RTE Uno o più container dell’ambiente di runtime, lo stesso server avviato con AF_ROLE=rte: ognuno esegue ansible-playbook per i moduli ansible, con le librerie python e le collection della sua immagine, e rimanda l’output e lo stato finale al server tramite un WebSocket, senza credenziali del database (vedi Come gira l’RTE)
AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins Runner per template e job: i moduli AWX avviano un job template o un workflow template, i moduli Semaphore, Rundeck e Jenkins avviano uno dei loro job, e il server ne segue l’output
MySQL / MariaDB Contiene i job e il loro output, gli utenti, le credenziali e le connessioni; solo il server lo legge e lo scrive
Cartella persistente Contiene config.yaml, i file dei moduli, i playbook, i log e i backup
Origini dati Riempiono i campi: query su database, API REST, file e altre funzioni
Archivi di segreti Forniscono l’utente e la password di una credenziale al momento dell’uso, vedi Archivi di segreti
Repository git Tengono i moduli, i playbook e config.yaml sotto controllo di versione
Provider di accesso Fanno accedere gli utenti: LDAP, Entra ID e OIDC, accanto agli utenti locali
Canali di notifica Portano le notifiche e le richieste di approvazione: mail, Slack, Microsoft Teams, Telegram o un webhook
Server syslog Ricevono il log e la traccia di audit man mano che vengono scritti, vedi Syslog
Client MCP, chat Facoltativi, entrambi disattivati per impostazione predefinita: il server MCP e l’assistente chat, che ha bisogno di un fornitore di modelli

Per impostazione predefinita un solo container esegue insieme il server, l’app web e il lavoro in background, accanto a un RTE. Per più nodi dell’app dietro un load balancer, un worker che esegue il lavoro in background, e più RTE, vedi Scalabilità.

Costruito con

Il server e l’interfaccia web sono costruiti su questi componenti:

Parte Tecnologia
Server Node.js ed Express
Database MySQL o MariaDB
Interfaccia web Vue 3, con Bootstrap 5 e Font Awesome

Cosa succede quando avvii un modulo

Un avvio passa per gli stessi passi sia che arrivi dal browser sia dall’API REST:

  1. Caricamento : il server invia solo i moduli consentiti dai ruoli dell’utente, e valuta le espressioni lato server
  2. Invio : il browser trasforma i valori dei campi in extravars e le invia a POST /api/v2/job
  3. Controllo : il server ricarica il modulo per i ruoli dell’utente e, con la validazione all’avvio attiva, controlla i valori
  4. Registrazione : il job viene salvato con stato running, e il suo id viene aggiunto alle extravars come __jobid__
  5. Approvazione : un modulo con un punto di approval aspetta finché un approvatore non accetta il job
  6. Credenziali : per un playbook, l’app (mai l’RTE) legge le credenziali del modulo dal database o da un archivio di segreti
  7. Esecuzione : il job va al suo runner, quello che il modulo nomina con runner: o il predefinito del suo tipo. Per un playbook, l’app invia il job al suo RTE tramite il WebSocket dell’RTE, con le credenziali sigillate per esso, e l’RTE esegue ansible-playbook (vedi Come gira l’RTE), e AWX, AAP, Ascender, Semaphore, Rundeck o Jenkins esegue un template o un job. Un workflow esegue i suoi nodi, ognuno come job a sé sul proprio runner
  8. Monitoraggio : il server salva l’output nel database man mano che arriva, inviato dall’RTE tramite il suo socket per un playbook, o letto dagli altri runner. La pagina del modulo rilegge il job ogni due secondi, e la pagina Job lo segue in tempo reale man mano che il server annuncia ogni cambiamento
  9. Fine : il job riceve il suo stato finale, e le sue notifications partono via mail e verso i suoi canali di notifica quando il modulo le richiede

Dove vengono conservate le cose

AnsibleForms conserva il suo stato in due posti: il database MySQL e la cartella persistente. Fai il backup di entrambi.

Nel database

Il database, AnsibleForms, viene creato al primo avvio (a meno che ALLOW_SCHEMA_CREATION non sia 0) e contiene:

  • i job, le loro extravars e il loro output, le pianificazioni e i job salvati
  • gli utenti locali, i gruppi e i token API
  • le credenziali, cifrate con ENCRYPTION_SECRET, e le connessioni agli archivi di segreti
  • i runner, i canali di notifica (mail compresa), i server syslog, e le impostazioni di LDAP, SSO, repository e assistente chat
  • il registro di audit

Nella cartella persistente

È /app/dist/persistent nell’immagine e server/persistent dai sorgenti; ogni percorso ha la sua variabile:

Percorso predefinito Variabile Contenuto
config.yaml CONFIG_PATH Le categorie, i ruoli e le costanti
forms/ FORMS_FOLDER_PATH I file dei moduli, .yaml o .yml, in sottocartelle se vuoi
playbooks/ ANSIBLE_PATH I playbook dei moduli ansible, e la loro directory di lavoro
repositories/ REPO_PATH I cloni dei repository git
forms_backups/ FORMS_BACKUP_PATH Le copie che il Designer fa prima di salvare
backups/ BACKUP_PATH I backup del database
uploads/ UPLOAD_PATH I file caricati tramite i campi file
logs/ LOG_PATH ansibleforms.log e ansibleforms.errors.log
certificates/ HTTPS_CERT, HTTPS_KEY Il certificato e la chiave, quando HTTPS è 1
.env   Le variabili d’ambiente salvate dalle pagine delle impostazioni (a meno che ALLOW_ENV_EDIT non sia 0)

La chiave SSH generata si trova in HOME_PATH, per impostazione predefinita fuori dalla cartella persistente.