Interfaccia Terraform: Semaphore UI e Gaia

Gaia separa applicazione web Java, database MongoDB e runner di esecuzione. Il runner avvia Terraform in container Docker o pod Kubernetes, con un limite configurabile di job paralleli. Docker Compose riunisce questi servizi, mentre un chart Helm sperimentale offre un’opzione di installazione Kubernetes.

Semaphore UI viene eseguito come binario o pacchetto nativo, oltre che in Docker o Kubernetes. Un team che sposta l’automazione ordinaria dai portatili degli ingegneri può iniziare su un server esistente e usare lo stesso servizio per provisioning Terraform e manutenzione Ansible. La modalità di esecuzione selezionata determina se servono container per i job.

Gaia esegue i moduli Terraform attraverso una sequenza generata di comandi Terraform. I provisioner Terraform possono chiamare Ansible o programmi da riga di comando quando l’immagine del runner o la destinazione remota fornisce gli strumenti necessari. Questo può configurare una risorsa appena creata, ma il comando rimane associato a un’esecuzione Terraform anziché diventare un’operazione Gaia indipendente. La costruzione standard dei comandi non offre un template OpenTofu o Terragrunt separato.

Semaphore UI ha template diretti per Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. Un team può creare infrastruttura con OpenTofu, configurare pacchetti con Ansible ed eseguire una verifica di disponibilità in Python. In seguito, la configurazione Ansible o l’operazione di manutenzione PowerShell può essere eseguita autonomamente, senza avviare un altro ciclo Terraform. Il backend dello stato integrato in Pro mantiene inoltre stato Terraform/OpenTofu e cronologia accanto a questi job.

L’autore di un modulo Gaia definisce repository sorgente, versione Terraform e schema delle variabili. Gli utenti creano stack dal modulo e forniscono valori e credenziali cloud appropriati al proprio ambiente. Lo stack diventa un’istanza persistente con stato e job propri, adatta a un catalogo di infrastrutture richieste indipendentemente. Gaia valida i valori obbligatori ed espressioni regolari configurabili. I questionari Semaphore UI validano campi obbligatori, numeri interi e scelte, senza una regola regex configurabile equivalente.

Semaphore UI chiama l’operazione salvata Task Template. Riunisce repository, configurazione dello strumento, variabili e gli eventuali inventari o credenziali necessari. I gruppi di variabili con nome riutilizzano impostazioni degli ambienti tra template, mentre i campi del questionario raccolgono input all’avvio. Ad esempio, un template di riavvio del servizio può offrire una scelta di servizio e ambiente invece di chiedere al collega di costruire un comando. Un template di provisioning può usare lo stesso modello per i parametri dell’ambiente.

Gaia esegue plan, apply e destroy sul modulo, sugli input e sulle credenziali cloud configurati nello stack. Il backend integrato conserva lo stato dello stack, mentre la pagina dello stack raccoglie output e cronologia dei job. Ambienti di test separati possono quindi mantenere stato e registri di esecuzione indipendenti anche quando derivano dallo stesso modulo.

Semaphore UI usa un Task Template per selezionare repository, workspace e configurazione Terraform/OpenTofu. I gruppi di variabili riutilizzano impostazioni tra job correlati e i questionari raccolgono input all’avvio. Un ingegnere può preparare un’operazione di provisioning dell’ambiente una volta, quindi consentire ai colleghi di richiederla tramite quella configurazione salvata. Ogni ambiente necessita anche di variabili, credenziali e stato del backend propri. Gaia li rappresenta come istanze separate di stack. In Semaphore UI il team prepara la corrispondente configurazione di template, workspace e backend. L’isolamento dei workspace dipende dal backend, quindi selezionare un workspace non separa da solo lo stato per qualsiasi backend. Terragrunt e OpenTofu sono opzioni dirette dei template accanto a Terraform.

Lo stato è una parte separata di questa configurazione. Gaia include un backend dello stato per ogni stack senza licenza commerciale. Semaphore UI usa il backend configurato per il codice Terraform/OpenTofu e Pro offre anche un backend HTTP dello stato integrato con cronologia e gestione nell’interfaccia. Mantenere questo backend in Semaphore UI colloca lo stato condiviso accanto ai job che lo modificano, anziché aggiungere un altro servizio di stato.

Nessuno dei prodotti applica per impostazione predefinita un file di piano salvato in precedenza. Gaia 2.4.0 mostra il risultato della pianificazione, ma il comando apply non usa il file di piano salvato. Anche l’esecuzione predefinita di Semaphore UI esegue plan e apply separatamente. Se l’approvazione deve coprire la modifica esatta proposta, la procedura richiede archiviazione e riutilizzo espliciti del piano.

Gaia conserva risorse e output Terraform con ogni stack. Un output Terraform può fornire l’indirizzo host necessario a un provisioner o a un altro sistema, ma non crea una risorsa inventario Ansible nell’interfaccia Gaia. Ansible invocato tramite un provisioner deve ricevere o generare l’inventario come parte di quella automazione.

Semaphore UI conserva gli inventari Ansible come risorse di progetto riutilizzabili. I team possono modificare una definizione statica, usare un file da Git o lasciare che i plugin di inventario Ansible rilevino gli host durante l’esecuzione di un job. Lo stesso inventario può servire deployment, applicazione delle patch e verifiche dei certificati. È particolarmente utile quando il provisioning è solo l’inizio del lavoro e gli operatori tornano su un parco macchine esistente per tutta la sua vita.

Gaia separa l’applicazione dal runner. Il runner richiede i passaggi Terraform in attesa e li esegue in container Docker o pod Kubernetes, con concorrenza configurabile. Può essere eseguito vicino a infrastrutture private purché raggiunga l’API Gaia e i servizi usati dal modulo. L’immagine selezionata fornisce Terraform e gli eventuali programmi aggiuntivi richiesti dai provisioner.

Semaphore UI può eseguire job sul proprio server applicativo o su runner collocati vicino alle destinazioni. Questo consente a una piccola installazione di iniziare senza una piattaforma container e a una più grande di raggiungere reti separate attraverso runner. Pro aggiunge runner di progetto ed esecuzione dei job in Docker, mentre Enterprise aggiunge pod Kubernetes per i job. Installare l’applicazione web in Docker ed eseguire ogni job nel proprio container rimangono scelte separate.

Semaphore UI salva pianificazioni cron e una tantum associate ai template predisposti. Un backup notturno, una verifica ricorrente dei certificati o un job di applicazione delle patch può riutilizzare inventario, credenziali e impostazioni di avvio selezionati dall’autore. Esecuzioni manuali e pianificate compaiono nella stessa cronologia.

Gaia 2.4.0 non include un’interfaccia di pianificazione. Uno scheduler esterno può creare un job RUN o DESTROY tramite POST /api/stacks/{id}/{jobType}, quindi avviarne il piano tramite POST /api/jobs/{jobId}/plan. Applicare la modifica richiede una POST separata a /api/jobs/{jobId}/apply dopo la conclusione del piano. Uno scheduler deve gestire questo ciclo e verificare il risultato finale del job, senza considerare la creazione di un ID job come un’esecuzione completata.

Gaia guida uno stack attraverso pianificazione e applicazione. L’interfaccia offre una conferma separata dopo il piano, anche per la distruzione di uno stack. I provisioner Terraform possono eseguire ulteriori azioni all’interno di quel ciclo e un sistema esterno può coordinare più job tramite l’API. Gaia non offre un grafo visuale di operazioni Ansible, Terraform e script riutilizzabili indipendentemente.

Semaphore UI collega template salvati tramite un workflow visuale, con approvazioni e percorsi di successo ed errore. Un rollout può creare infrastruttura, attendere l’approvazione, configurare host ed eseguire una verifica, mentre ogni template resta disponibile per la manutenzione successiva. I valori raccolti possono passare tra i passaggi usando l’esecutore locale sul server o su un runner. File generati e piani Terraform salvati richiedono comunque archiviazione accessibile o trasferimento esplicito. Nessuno dei prodotti applica un piano Terraform salvato in precedenza per impostazione predefinita.

Gaia usa organizzazioni per condividere moduli, con ruoli amministratore e utente. Un autore può rendere disponibile al team una definizione Terraform approvata, mentre gli utenti forniscono la configurazione dei propri stack. Le integrazioni GitHub e GitLab combinano accesso OAuth2 e importazione dei repository, ed è supportato anche LDAP.

Semaphore UI Community organizza l’automazione condivisa all’interno di progetti. I ruoli di progetto controllano chi può visualizzare, eseguire o modificare l’automazione al loro interno. I colleghi con autorizzazione di esecuzione possono avviare un deployment, un backup o un job di manutenzione e consultarne il risultato. L’ingegnere prepara l’operazione, mentre il collega usa la configurazione salvata e gli input di avvio.

Enterprise aggiunge ruoli personalizzati e autorizzazioni di esecuzione a livello di template quando l’accesso deve essere limitato a operazioni selezionate. Ad esempio, un team può delegare un template di riavvio del servizio senza concedere all’operatore diritti generali di modifica del progetto. Questo confine deriva insieme dalle autorizzazioni del ruolo e dalla configurazione dell’operazione, non dal solo questionario. Pro aggiunge accesso LDAP e OIDC per i team che usano un provider di identità centrale. Semaphore UI Pro aggiunge anche autenticazione a due fattori TOTP per gli account locali.

Gaia fornisce credenziali cloud per AWS, Google Cloud e Azure. L’integrazione Vault facoltativa usa il motore Transit per la crittografia e può richiedere credenziali AWS dinamiche a un motore di segreti Vault. Queste credenziali supportano il ciclo di vita degli stack Terraform.

Il Key Store di Semaphore UI supporta le credenziali usate nelle procedure del team, incluse chiavi SSH e password per gli host Ansible. Un’operazione predisposta fa riferimento alle voci salvate invece di richiedere all’operatore di incollare credenziali a ogni avvio. Pro aggiunge recupero dei segreti da HashiCorp Vault e OpenBao, mentre Enterprise aggiunge integrazioni AWS Secrets Manager, Azure Key Vault e Devolutions Server, oltre a CyberArk tramite l’API PVWA.

Ad esempio, un ambiente può usare credenziali cloud per il provisioning e una chiave SSH per la successiva configurazione Ansible. Rimangono credenziali separate associate all’operazione pertinente. Entrambe le piattaforme possono lavorare con Vault, ma crittografia e credenziali dinamiche di Gaia differiscono dal recupero di un segreto salvato per un job. I tipi di credenziali integrati di Gaia non includono connettori per gli altri archivi di segreti elencati sopra. Il codice Terraform può recuperare segreti tramite proprie fonti dati o comandi esterni, con tale recupero configurato e mantenuto nell’automazione anziché nell’interfaccia delle credenziali di Gaia.

Gaia registra utente, stato, tempi e passaggi plan/apply di un job dello stack. Questa cronologia aiuta il team a esaminare le modifiche di provisioning di un ambiente e indagare l’output Terraform. È un registro delle operazioni sugli stack, non un’interfaccia di report degli host Ansible o di audit amministrativo.

Semaphore UI mantiene la cronologia delle attività per gli strumenti supportati. I riepiloghi Ansible Pro aggiungono risultati di host e attività, aiutando l’operatore a identificare quali server hanno fallito l’applicazione di una patch o una verifica dei certificati. Il log di audit registra accessi e azioni amministrative supportate separatamente dall’output delle attività. Un team che esegue provisioning e manutenzione degli host può quindi indagare queste operazioni nello stesso servizio, senza considerare lo stato Terraform come un report di ogni azione su un server. Pro aggiunge filtri ed esportazione dell’audit, inclusa consegna a Syslog e Splunk HEC per la pipeline SIEM del team.

Gaia importa moduli da GitHub o GitLab ed espone API per stack, job e relativi risultati. Una pipeline CI o un servizio esterno di richieste può creare un job dello stack, avviare la pianificazione e decidere quando applicarlo. Una configurazione basata su webhook richiede un adattatore che esegua queste chiamate e ne segua l’esito. Semaphore UI offre un’API REST e webhook di integrazione in ingresso che riconoscono le richieste e ne associano i valori agli input delle attività predisposte.

Per un team che mantiene il catalogo Terraform di Gaia, un’integrazione API può attivare un template Semaphore UI di configurazione Ansible o manutenzione dopo il completamento del provisioning. Semaphore UI gestisce quindi inventario, credenziali e registro di esecuzione di quell’operazione. È una connessione implementata dal team, non un’integrazione Gaia-Semaphore nativa. Entrambi i progetti espongono inoltre documentazione e codice sorgente consultabili da un assistente di programmazione per preparare la connessione o indagare configurazione e output dei job.