Interfaccia Ansible: Semaphore UI e Ansible Automation Platform (AAP)

AAP 2.6 supporta un’installazione containerizzata con Podman su RHEL e un’installazione basata su Operator in OpenShift. Il precedente installer RPM rimane supportato su RHEL 9 in 2.6 per la migrazione, ma è deprecato. Red Hat documenta topologie supportate e ciclo di vita del prodotto per questi deployment. Kubernetes non è richiesto per ogni installazione AAP.

Semaphore UI può essere eseguito come binario o pacchetto nativo su un host esistente, oltre che tramite Docker o Kubernetes. Un team che introduce un’interfaccia condivisa per Ansible può scegliere un’installazione su server tradizionale e riutilizzare repository e infrastruttura già gestiti. Enterprise aggiunge alta disponibilità quando il servizio di automazione necessita di istanze applicative ridondanti. Il server Semaphore UI funziona anche nativamente su Windows, mentre l’esecuzione di Ansible richiede WSL, un container o un runner Linux.

Semaphore UI può condividere job di applicazione delle patch e deployment da un server esistente. La topologia di deployment di AAP dipende dai componenti selezionati e dalla capacità di esecuzione che il team deve mantenere.

AAP usa playbook Ansible ed execution environment, immagini container contenenti il runtime Ansible e le dipendenze necessarie. Le integrazioni Terraform includono collection per coordinare servizi Terraform e i playbook possono invocare altri strumenti da riga di comando. È un modello coerente quando Ansible orchestra già l’intera procedura.

Anche Semaphore UI è costruito intorno a operazioni Ansible pratiche, offrendo al contempo Task Template dedicati a Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. Per Terraform/OpenTofu, un ingegnere seleziona nell’interfaccia repository, directory di configurazione, workspace e gruppo di variabili. Lo strumento IaC viene eseguito direttamente, senza un playbook Ansible scritto soltanto per invocarlo. Un deployment Ansible, un job di provisioning Terraform e un’attività di verifica Python possono quindi condividere un progetto mantenendo impostazioni di esecuzione proprie.

Ad esempio, un ambiente di test temporaneo può richiedere creazione dell’infrastruttura, configurazione dell’applicazione e verifica della disponibilità. Semaphore UI mantiene questi passaggi negli strumenti esistenti e li collega mediante un workflow. È utile ai team la cui automazione è cresciuta tra più repository e linguaggi, ma che desiderano comunque un unico punto per avviare e consultare l’operazione.

Configurate indirizzi separati di stato/backend o workspace supportati per sviluppo, staging e produzione. Il supporto dei workspace dipende dal backend selezionato. Semaphore UI Pro può ospitare direttamente lo stato tramite il backend HTTP integrato, con cronologia delle versioni e gestione nell’interfaccia. Per un team che crea ambienti temporanei, template di provisioning, relativo stato e successiva configurazione Ansible rimangono nello stesso servizio. Le integrazioni Terraform documentate di AAP usano servizi Terraform o un backend esterno configurato per lo stato. Anche Semaphore UI può mantenere un backend esterno se il team ne possiede già uno.

Per un processo che deve approvare e applicare esattamente il piano Terraform salvato, configurate esplicitamente archiviazione e riutilizzo del piano. L’esecuzione predefinita di Semaphore UI pianifica e applica separatamente, e i comandi predefiniti usano -lock=false se non modificati. Fornire un backend di state non cambia queste impostazioni dei comandi delle attività.

Un Job Template di AAP salva progetto, playbook, inventario, credenziali e ambiente di esecuzione per un’operazione. Il suo avvio crea un job. Un survey raccoglie i dati abilitati per quell’avvio, così un operatore può eseguire una procedura preparata senza ricrearne la configurazione.

Semaphore UI usa i Task Template per lo stesso modello di avvio riutilizzabile, sia con Ansible sia con gli altri strumenti di automazione. Un template Ansible seleziona repository, playbook, inventario e credenziali. I gruppi di variabili con un nome conservano la configurazione riutilizzata tra i template, mentre i campi del survey raccolgono i valori necessari alla singola esecuzione. AAP può riutilizzare variabili attraverso inventari e file in Git.

Pensate a una procedura di riavvio di un servizio condivisa con i colleghi del supporto. Un ingegnere prepara playbook e configurazione dell’ambiente, poi richiede il nome del servizio e un riferimento alla modifica nel modulo di avvio. Il collega seleziona l’operazione, inserisce quei dati e ne segue stato e output. Template distinti possono rendere disponibili un deployment, un backup o un rinnovo di certificati usando le stesse risorse del progetto.

Entrambi i prodotti permettono anche di pianificare i template salvati. AAP offre pianificazioni singole e ricorrenti, mentre Semaphore UI supporta espressioni cron ed esecuzioni singole con parametri configurati. Il backup usato prima di una finestra di manutenzione manuale può anche essere eseguito di notte secondo una pianificazione. Il team riutilizza così la stessa procedura operativa, senza mantenere separatamente un comando cron e una configurazione per l’avvio dal web.

AAP sincronizza le sorgenti di inventario in host e gruppi gestiti, con facts conservati e inventari costruiti per operazioni Ansible più articolate. Un operatore può consultare e gestire le informazioni sui singoli host nella stessa piattaforma usata per avviare i job. È utile quando la manutenzione di questi dati e la combinazione di sorgenti di inventario fanno parte delle attività quotidiane. AAP può aggiornare le sorgenti secondo una pianificazione o prima dell’avvio e conservare facoltativamente i facts degli host in una cache gestita.

Semaphore UI riutilizza definizioni di inventario statiche o in Git e i plugin di discovery di Ansible, inclusi quelli per NetBox e le API cloud. Gli operatori possono modificare definizioni INI/YAML nell’interfaccia oppure mantenere Git e la discovery esterna come sorgente delle informazioni sugli host. Un template seleziona l’inventario necessario quando viene eseguita l’operazione. La discovery dinamica avviene durante l’esecuzione. Resta disponibile la cache dei facts configurata in Ansible, mentre Semaphore UI non fornisce una cache dei facts gestita dal controller.

Per un team che già gestisce la propria infrastruttura fuori dall’interfaccia di automazione, questo evita di introdurre un secondo processo di gestione degli host solo per condividere i job. Lo stesso inventario può servire per patch, controlli dei certificati e deployment, con template e parametri distinti per ogni operazione. La vista sincronizzata di host e gruppi di AAP resta preziosa quando gli operatori hanno bisogno di quella gestione, oltre a un inventario su cui eseguire le operazioni.

Entrambi i prodotti conservano i riferimenti alle credenziali insieme all’operazione preparata. Un ingegnere può configurare una sola volta l’accesso ai repository, le credenziali delle macchine e altri segreti, poi riutilizzarli nei deployment e nei job di manutenzione. I colleghi che avviano l’operazione non devono fornire di nuovo quelle credenziali a ogni esecuzione.

AAP supporta oggetti credenziale e recupero di segreti da sistemi esterni, con integrazioni per HashiCorp Vault, AWS Secrets Manager, Azure e CyberArk. Semaphore UI offre un Key Store di progetto e collega HashiCorp Vault o OpenBao in Pro. Enterprise aggiunge AWS Secrets Manager, Azure Key Vault, Devolutions Server e CyberArk tramite la sua API PVWA. AAP può usare la collection Ansible di Devolutions nei playbook, installandola nell’ambiente di esecuzione. I suoi connettori integrati per le credenziali non includono un lookup dedicato a OpenBao. AAP offre inoltre connettori per Centrify Vault e Thycotic Secret Server o DevOps Secrets Vault, che Semaphore UI non espone come archivi integrati. Una collection di lookup Ansible o un comando possono recuperare i segreti per un’operazione quando manca un connettore della piattaforma, mantenendo quell’integrazione nell’automazione. I team possono quindi scegliere in base al vault esistente e ai collegamenti che desiderano configurare nella piattaforma stessa.

AAP esegue i job in ambienti di esecuzione che contengono Ansible e le dipendenze dei playbook. I nodi di esecuzione svolgono il lavoro separatamente dai servizi di controllo. Automation mesh collega questi nodi e può usare nodi intermedi di inoltro per raggiungere reti remote. Questo supporta un’infrastruttura Ansible distribuita, con immagini di esecuzione e percorsi di rete definiti.

Semaphore UI può eseguire l’automazione sul proprio server o su runner collocati vicino ai sistemi di destinazione. Per esempio, un runner in una rete privata può eseguire un job di manutenzione Ansible sugli host locali mentre l’interfaccia condivisa resta altrove. I runner globali sono disponibili in Community, mentre Pro aggiunge runner assegnati ai progetti e instradamento tramite tag per diversi ambienti di esecuzione.

Un team può iniziare con l’esecuzione diretta e aggiungere macchine separate o container per singola attività quando i carichi di lavoro lo richiedono. Pro offre l’esecuzione delle attività in Docker ed Enterprise aggiunge l’esecuzione in Kubernetes. Un servizio che esegue playbook esistenti può così passare da un singolo host a un’esecuzione separata senza richiedere un’installazione di automation mesh. Eseguire il server applicativo in un container è una scelta distinta dall’eseguire ogni attività in un container.

I Workflow Job Template di AAP collegano Job Template, aggiornamenti dei progetti, aggiornamenti degli inventari e altri workflow. I passaggi di approvazione sospendono un’esecuzione e i valori Ansible set_stats possono essere passati ai job successivi. Incorporare un workflow è utile quando più procedure condividono un’intera sequenza da mantenere una sola volta.

I workflow di Semaphore UI collegano direttamente Task Template per Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python, con rami di successo e di errore, approvazioni e ritardi. Un workflow di provisioning può creare l’infrastruttura con Terraform/OpenTofu, configurarla con Ansible ed eseguire un controllo di disponibilità in Python. Un workflow di manutenzione può iniziare con un backup, applicare aggiornamenti ed eseguire verifiche, riutilizzando template che i colleghi possono avviare anche separatamente. AAP può orchestrare la stessa procedura tramite Job Template Ansible e integrazioni Terraform. La differenza è se la configurazione di esecuzione di ogni strumento risiede in un template dedicato oppure nei playbook e nelle integrazioni che stanno dietro ai job Ansible.

Semaphore UI 2.20 passa i valori Ansible set_stats, gli output di Terraform/OpenTofu/Terragrunt e JSON da Bash, PowerShell o Python agli input delle attività successive. Un indirizzo o un identificatore di risorsa restituito dal provisioning può quindi diventare un parametro dell’operazione seguente. AAP passa i valori set_stats tra job Ansible. Entrambi offrono un utile passaggio di valori, distinguendosi per il modo in cui il risultato viene prodotto e utilizzato. Il template ricevente dichiara l’input, che il suo playbook o la sua configurazione di inventario usa poi per indirizzare il nuovo host.

AAP offre un permesso Approve assegnabile per le approvazioni dei workflow. Semaphore UI 2.20 lega l’approvazione al permesso di eseguire attività del progetto. È stato annunciato un ruolo di approvatore separato per la versione 2.21.0. Questo conta quando la responsabilità di approvare richiede un permesso autonomo.

Un workflow di provisioning e configurazione può passare i valori raccolti tra attività di Semaphore UI usando l’esecutore locale, sul server o su un runner remoto. Gli esecutori Docker e Kubernetes non raccolgono questi output, quindi un workflow che ne dipende richiede un’altra modalità di esecuzione. I singoli Task Template restano riutilizzabili tra i workflow. Se più procedure devono riutilizzare un intero workflow con più passaggi, i workflow annidati di AAP evitano di mantenere separatamente quelle sequenze. In entrambe le piattaforme, file come i piani Terraform salvati richiedono uno spazio di archiviazione accessibile o un trasferimento esplicito tra job.

AAP concede accesso alle singole risorse e supporta ruoli personalizzati. Gli operatori possono ricevere il permesso di usare determinati inventari e credenziali indipendentemente dai Job Template. È adatto ai team il cui lavoro quotidiano comprende la combinazione di risorse Ansible autorizzate in nuove operazioni.

Semaphore UI organizza l’accesso attorno a progetti e operazioni preparate. I ruoli di progetto di Community consentono già di separare gli ingegneri che mantengono l’automazione dai colleghi che la eseguono. Un progetto può riunire i template di deployment, backup e manutenzione di un team, insieme alle risorse configurate.

Enterprise aggiunge ruoli personalizzati e permessi di esecuzione a livello di template quando l’accesso deve essere limitato a determinate operazioni. Per esempio, il personale di supporto può ricevere un template per il riavvio dei servizi, mentre il deployment resta affidato a un altro ruolo. Inventario, credenziali e modifiche consentite all’avvio fanno parte della configurazione preparata. È un modello mirato alla delega delle operazioni, mentre AAP offre permessi indipendenti sulle risorse sottostanti.

Entrambi supportano l’integrazione LDAP. Semaphore UI Pro offre anche l’accesso OIDC, mentre AAP supporta OIDC, SAML e altri identity provider configurati centralmente. Semaphore UI non fornisce un’integrazione SAML integrata. Semaphore UI Pro aggiunge inoltre l’autenticazione a due fattori TOTP per gli account locali.

I risultati operativi vengono prima di tutto quando un collega deve sapere se un deployment o un job di manutenzione è terminato. Entrambi i prodotti conservano output e cronologia delle esecuzioni. Semaphore UI registra stato dell’attività, revisione del repository e dettagli di avvio, e Pro aggiunge un riepilogo degli host Ansible che mostra le attività fallite per server. Dopo un job di patch o di gestione dei certificati, l’operatore può individuare gli host interessati e consultare l’output corrispondente.

L’audit amministrativo ha uno scopo diverso. Il flusso delle attività di AAP registra le modifiche alle risorse della piattaforma, e le integrazioni di logging inoltrano gli eventi dei job e di sistema. Semaphore UI offre un registro di audit amministrativo per accessi, modifiche ai permessi e altre azioni registrate. Pro aggiunge filtri, esportazione su file e inoltro tramite TLS Syslog o Splunk HEC, permettendo di includere questi eventi nelle indagini di sicurezza e nei registri SIEM dell’organizzazione.

Automation hub di AAP distribuisce collection e immagini di esecuzione, con accesso a contenuti Red Hat Certified e validati. Event-Driven Ansible valuta gli eventi tramite rulebook e avvia l’automazione. Sono servizi di piattaforma per gestire e avviare l’automazione in tutta l’organizzazione, oltre alle possibilità di un webhook in ingresso per un job salvato.

Semaphore UI si affianca ai sistemi esistenti di CI, monitoraggio e gestione delle richieste tramite la sua API REST e integrazioni webhook con regole di corrispondenza ed estrazione dei parametri. Una pipeline di build può pubblicare una versione e richiedere un deployment preparato, mentre un processore di eventi può richiedere un’operazione diagnostica. Semaphore UI conserva inventario, credenziali e registro di esecuzione di quell’operazione. Il chiamante gestisce l’autenticazione e controlla il risultato dell’attività quando il processo complessivo deve attenderne il completamento.

Sia Semaphore UI sia automation controller offrono moduli di avvio per job preparati. AAP offre anche Ansible automation portal, installato separatamente e basato su Red Hat Developer Hub, con un catalogo self-service, sincronizzazione dei template e integrazioni personalizzate. L’uso di Developer Hub per quel portale è incluso nell’abbonamento AAP. Per i team che hanno bisogno di esecuzione condivisa dei job senza quel catalogo, Semaphore UI offre un’interfaccia mirata ad Ansible e agli altri strumenti di automazione.

AAP offre un server MCP ufficiale che espone le operazioni della piattaforma agli assistenti compatibili. Può essere installato con la piattaforma o come container autonomo. AAP offre inoltre un assistente intelligente di automazione facoltativo nella propria interfaccia, collegato a un fornitore di modelli configurato. Questo estende il suo approccio di piattaforma integrata alle operazioni assistite dall’IA.

Semaphore UI dispone di un connettore MCP della community per la propria API e ha annunciato il supporto MCP ufficiale per Pro nella versione 2.21.0. Claude Code o Codex possono anche consultare documentazione pubblica, codice sorgente e definizioni API per aiutare a preparare template, scrivere codice di integrazione o indagare su un’esecuzione fallita a partire dalla configurazione e dall’output forniti. Un team può usare questa assistenza insieme al servizio di automazione esistente senza adottare una piattaforma più ampia.