Ansible UI: confronto tra AWX e Semaphore UI
18 min di lettura
AWX e Semaphore UI forniscono interfacce web e API per eseguire l'automazione in un team. Questo confronto copre AWX 24.6.1 e Semaphore UI 2.20.0, dagli strumenti supportati e la distribuzione ai workflow, al controllo degli accessi e alla manutenzione continua.
Discuti questo articolo con l’IA
Panoramica
Un playbook Ansible può inizialmente essere un comando che un ingegnere esegue dal proprio portatile. Quando deployment, aggiornamenti correttivi e rinnovi dei certificati diventano responsabilità condivise, il team ha bisogno di un punto comune per avviare i job, fornire i parametri, gestire le credenziali e verificare i risultati. AWX e Semaphore UI offrono questo livello condiviso, con configurazioni dei job salvate, pianificazioni, autorizzazioni e cronologia di esecuzione.
AWX organizza l'automazione attorno ad Ansible. I team collegano i playbook archiviati in Git a inventari e credenziali, li salvano come modelli di job e combinano i job in workflow. Organizzazioni, team e autorizzazioni controllano chi può utilizzare ciascuna risorsa. AWX è un progetto open source, mentre Red Hat Ansible Automation Platform (AAP) è un'offerta commerciale separata con supporto e ciclo di vita propri.
Anche Semaphore UI si basa su attività riutilizzabili, con playbook Ansible e modelli dedicati a Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. I progetti riuniscono modelli, repository, inventari, credenziali e variabili. Un workflow può collegare il provisioning dell’infrastruttura come codice (IaC) alla configurazione degli host e alla successiva manutenzione, mantenendo le operazioni dei diversi strumenti in un’unica interfaccia.
Confronto rapido
I job, le credenziali e le pianificazioni salvate coprono le operazioni Ansible di routine in entrambi i prodotti. Le loro differenze più ampie riguardano la copertura degli strumenti, l'implementazione e la gestione delle risorse. Ecco le caratteristiche principali di ciascuno.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Strumenti di automazione | Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell, Python | AnsibleAltri strumenti attraverso i playbook |
| Installazione | Binario, pacchetti, Docker, Kubernetes | Kubernetes (Operatore), Docker (sviluppo/test) |
| Piattaforme server | Linux, macOS, Windows, FreeBSD | Contenitori Linux (Kubernetes / Docker) |
| Esecuzione delle attività | Sul server o su macchine di esecuzione remote | Su server di esecuzione o pod di job Kubernetes |
| Workflow | Sì, workflow visuali tra più strumenti di automazione | Sì, workflow Ansible visuali con workflow secondari riutilizzabili |
| Pianificazione | Espressioni Cron, esecuzioni una tantum | Pianificazioni singole e ricorrenti |
| Gestione degli inventari | Inventari statici e Git, plugin dinamici, NetBox e altre fonti esterne | Inventari statici e dinamici, aggiornamenti gestiti, inventari costruiti |
| Controllo degli accessi | RBAC, ruoli di progetto, ruoli personalizzati, autorizzazioni modelloLDAP, OIDC, TOTP locale | RBAC, ruoli dell'organizzazione e del team, autorizzazioni per risorsaLDAP, OIDC, SAML, MFA tramite un provider di identità |
| Credenziali | Key Store, chiavi SSH, password, integrazioni con vault esterni | Oggetti credenziali, chiavi SSH, password, integrazioni con vault esterni |
| Variabili | Gruppi di variabili riutilizzabili, variabili extra, variabili d’ambiente, moduli di avvio | Variabili di inventario, host e gruppi, variabili extra, moduli di avvio |
| Licenza | MIT (Community)Termini commerciali separati per le edizioni a pagamento | Apache 2.0 |
Per i job Ansible di routine, entrambi consentono l’avvio, la pianificazione e la consultazione della cronologia di esecuzione. Le differenze principali riguardano la gestione di inventari e autorizzazioni, gli strumenti eseguiti direttamente e le modalità di installazione.
Le funzionalità di Semaphore UI descritte qui comprendono Community, Pro ed Enterprise. Le indicazioni di disponibilità specificano l’edizione minima richiesta. La sezione «Licenze e supporto» illustra le opzioni commerciali.
Confronto delle funzionalità
Un deployment può richiedere il provisioning dell’infrastruttura, la configurazione degli host e un’approvazione prima di modificare la produzione. Dove vengono eseguiti questi passaggi, come si scambiano i risultati e chi li controlla chiarisce le differenze più utili tra i prodotti.
Installazione e configurazione
L'installazione consigliata di AWX utilizza Kubernetes. Semaphore UI supporta anche implementazioni autonome, quindi l'infrastruttura necessaria per ospitare il servizio è un primo punto di differenza.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Binario autonomo | Sì | No |
| Pacchetti Linux nativi | SìDEB / RPM | No |
| Distribuzione Docker | Sì | ParzialeSolo sviluppo e test |
| Distribuzione Kubernetes | SìChart Helm | SìAWX Operator |
| Server Windows nativo | SìAnsible richiede WSL, un container o un runner Linux | NoContenitori Linux |
| Alta disponibilità | SìEnterpriseDatabase condiviso, Redis, bilanciatore del carico | SìRepliche, configurare il failover del database separatamente |
La distribuzione consigliata di AWX combina l'operatore Kubernetes, PostgreSQL e l'esecuzione di job containerizzati. La sua configurazione Docker è destinata allo sviluppo e ai test. Per una squadra Kubernetes esistente, l'operatore segue un modello operativo familiare. L'introduzione di un cluster esclusivamente per AWX aggiunge l'infrastruttura da mantenere.
Semaphore UI supporta Kubernetes tramite Helm, oltre alle installazioni da binario, pacchetto nativo o Docker con SQLite, MySQL o PostgreSQL. Un’installazione autonoma può utilizzare un server esistente senza richiedere un cluster, offrendo una configurazione iniziale più contenuta e la possibilità di scegliere il modello operativo.
Il sistema operativo del server è separato dall'esecuzione del job. Semaphore UI ha un binario nativo del server per Windows, mentre Ansible necessita ancora di Linux, macOS, un contenitore adatto o WSL. Un runner Linux può eseguire job per un servizio web ospitato altrove. Entrambe le piattaforme possono gestire target Windows tramite Ansible.
Per l'elevata disponibilità, le opzioni di scalabilità di AWX e l'implementazione HA di Semaphore UI Enterprise richiedono il failover del database e la pianificazione del ripristino. Le installazioni disconnesse necessitano inoltre di un percorso di consegna per pacchetti, immagini di esecuzione, aggiornamenti ed eventuali attivazioni di licenze a pagamento.
Strumenti di automazione
Una distribuzione può eseguire il provisioning con Terraform/OpenTofu, configurare con Ansible e terminare con Python. AWX richiama gli altri strumenti tramite playbook, mentre Semaphore UI fornisce modelli di attività diretti.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Playbook Ansible | Sì | Sì |
| Terraform/OpenTofu | SìModello di attività nativo | ParzialeTramite playbook Ansible |
| Terragrunt | SìModello di attività nativo | ParzialeTramite playbook Ansible |
| Bash | SìModello di attività nativo | ParzialeTramite playbook Ansible |
| PowerShell | SìModello di attività nativo | ParzialeTramite playbook Ansible |
| Python | SìModello di attività nativo | ParzialeTramite playbook Ansible |
AWX mantiene Ansible al centro dell'esecuzione. I playbook possono richiamare Terraform/OpenTofu, Terragrunt, Bash, PowerShell o Python tramite moduli o comandi quando l'ambiente di esecuzione contiene le dipendenze. Questo è adatto ai team che già descrivono il loro processo di provisioning in Ansible.
Semaphore UI fornisce a questi strumenti i propri modelli. I team possono avviare direttamente l'automazione esistente e combinarla nei workflow senza mantenere playbook aggiuntivi solo per invocare un altro strumento. Un'attività OpenTofu può fornire l'infrastruttura, un'attività Ansible configurare gli host e un'attività Python completare un'operazione correlata, il tutto in un'unica interfaccia.
Semaphore UI Pro offre un backend HTTP integrato per lo state di Terraform/OpenTofu, oltre a workspace e opzioni di esecuzione. I team possono conservare lo state condiviso in Semaphore UI senza gestire un backend separato. Con AWX, il processo Terraform usa il backend configurato dal team. La sorgente di inventario Terraform State di AWX legge lo state per individuare gli host, ma non lo archivia.
L’esecuzione di Terraform in Semaphore UI 2.20 ha due limiti importanti. Un’esecuzione normale mostra un piano prima dell’applicazione, ma non lo salva automaticamente per applicare poi esattamente quel file. Se l’approvazione deve riguardare la modifica precisa proposta, occorre configurare il processo per salvare il piano e passarlo ad apply. Inoltre, i comandi Terraform predefiniti disabilitano il locking dello state, se non vengono modificati esplicitamente, anche quando il backend lo supporta. Verifica entrambe le impostazioni per le esecuzioni in produzione.
Modelli e pianificazione
AWX chiama una configurazione Ansible salvata Job Template. Semaphore UI la chiama Task Template. Ogni avvio crea un job distinto in AWX o un’attività distinta in Semaphore UI, con stato, log e risultato propri. Il modello conserva le impostazioni riutilizzabili, mentre i moduli di avvio e le pianificazioni controllano i parametri e il momento dell’esecuzione.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Configurazione dell’attività salvata | Sì | Sì |
| Moduli di avvio (parametri di esecuzione) | Sì | Sì |
| Insiemi di variabili riutilizzabili | SìVariable Groups condivisi tra modelli | ParzialeVariabili di inventario o file in Git |
| Ramo del repository all'avvio | Sì | Sì |
| Esecuzioni pianificate | SìEspressioni cron ed esecuzioni una tantum | SìPianificazioni singole e ricorrenti |
In AWX, un Job Template seleziona progetto, playbook, inventario e credenziali, insieme a un ambiente di esecuzione per le dipendenze di runtime. L’Ansible Task Template di Semaphore UI seleziona repository, playbook e inventario, con Variable Groups riutilizzabili e opzioni Ansible nello stesso modulo. Gli ingegneri preparano questa configurazione una volta. I colleghi possono poi avviare l’operazione senza doverla ricostruire ogni volta.
I moduli di avvio permettono ai colleghi di fornire i parametri senza modificare un playbook. AWX supporta validazioni come i limiti sulla lunghezza del testo. Le Survey Variables di Semaphore UI offrono campi tipizzati, testo su più righe, segreti e selezioni singole o multiple. I gruppi di variabili riutilizzabili separano la configurazione condivisa dai valori inseriti all’avvio. AWX condivide la configurazione tramite variabili di inventario, host e gruppo o file in Git, anziché tramite un oggetto Variable Groups separato selezionabile in più modelli.
Entrambi possono eseguire un altro branch del repository se la configurazione lo consente. AWX può richiedere inventario, credenziali e altre impostazioni del job all’avvio. Semaphore UI consente gli override configurati per l’inventario Ansible e la riga di comando. Queste opzioni offrono flessibilità agli ingegneri, permettendo al contempo di limitare i parametri esposti per le procedure approvate.
Le pianificazioni automatizzano questi lanci. AWX utilizza una data di inizio, ora e impostazioni di ricorrenza. Semaphore UI supporta espressioni cron ed esecuzioni una tantum. Ad esempio, 0 2 * * * viene eseguito ogni giorno alle 02:00 nel fuso orario dello scheduler configurato, che per impostazione predefinita è UTC. Entrambi gli approcci possono gestire backup, controlli dell'host o arrestare macchine non di produzione al di fuori dell'orario di lavoro.
Inventario
Entrambi i prodotti possono utilizzare file statici e rilevamento dinamico. La differenza principale è se gli host rilevati diventano record gestiti dalla piattaforma o vengono risolti dad Ansible durante l'esecuzione di un processo.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Inventari statici | SìEditor e file INI/YAML | SìRecord dell'host/gruppo e file importati |
| Inventari in Git | SìRepository di inventario identico o separato | SìFonti del progetto SCM |
| Inventari dinamici | SìPlugin Ansible e script eseguibili | SìPlugin, script e sorgenti gestite |
| Aggiornamento degli inventari | ParzialeScoperta durante l'esecuzione | SìAggiornamenti programmati e aggiornamento al lancio |
| Gruppi di inventario calcolati | SìPlugin Ansible constructed | SìInventari costruiti gestiti |
| Cache dei fact gestita | NoConfigura la memorizzazione nella cache Ansible separatamente | SìFact degli host conservati da AWX |
| Modifica di host e gruppi | ParzialeModifica le definizioni INI/YAML | SìControlli individuali di host e gruppi |
AWX conserva i record di host e gruppi e li aggiorna tramite processi di aggiornamento dell'inventario, utilizzando file statici, plug-in di inventario Ansible o script eseguibili. Semaphore UI consente ai team di modificare gli inventari INI/YAML o di caricarli da Git, incluso un repository separato. Plugin e script scoprono gli host durante l'esecuzione. La distinzione principale è se la piattaforma gestisce un ciclo di vita dell’inventario o riutilizza la configurazione Ansible del team.
Ad esempio, il plug-in netbox.netbox.nb_inventory rileva dispositivi e macchine virtuali, filtra target e crea gruppi dai dati NetBox. NetBox rimane la fonte della verità. AWX aggiunge controlli di aggiornamento e record memorizzati, mentre Semaphore UI passa la configurazione ad Ansible. Entrambi utilizzano il plug-in Ansible anziché un connettore NetBox nativo separato. Altre fonti includono AWS, Azure e Google Cloud e Semaphore UI documenta uno script Python ospitato da Git per Consul.
Gli inventari costruiti di AWX combinano inventari di origine salvati e gestiscono gli host risultanti. Semaphore UI può usare il plugin Ansible constructed per creare gruppi e variabili a partire dalle sorgenti precedenti. I plugin di cache Ansible possono conservare i fact, ma Semaphore UI non offre la cache dei fact gestita di AWX. Archiviazione, scadenza e condivisione della cache tra runner restano parte della configurazione Ansible.
Semaphore UI prevede di aggiungere report Ansible ispirati ad ARA nella versione 2.21.0. Questi completeranno le funzionalità di inventario con una vista dei singoli host e della loro cronologia di automazione, permettendo agli operatori di vedere quali attività sono state eseguite su ciascun server, quando e dove si sono verificati errori.
Scegli il modello di inventario di AWX quando gli operatori devono sfogliare, aggiornare e gestire i record degli host nella piattaforma. Semaphore UI si adatta a una configurazione in cui Git definisce l'inventario o Ansible rileva host da sistemi come NetBox e API cloud al momento dell'esecuzione.
Segreti
I job salvati devono ricevere le credenziali senza che gli operatori debbano incollare password o token cloud a ogni avvio. Le opzioni di archiviazione e recupero determinano come queste credenziali arrivano al job.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Archiviazione delle credenziali | Sì | Sì |
| HashiCorp Vault | SìPro | Sì |
| OpenBao | SìPro | NoNessuna integrazione integrata, la compatibilità con Vault deve essere testata |
| AWS Secrets Manager | SìEnterprise | Sì |
| Azure Key Vault | SìEnterprise | Sì |
| Devolutions Server | SìEnterprise | NoNessuna integrazione integrata, connessione personalizzata possibile |
Gli oggetti credenziali AWX e il Key Store di Semaphore UI forniscono credenziali per i job salvati senza richiedere a un operatore di incollarli a ogni avvio. Entrambi si integrano con HashiCorp Vault, AWS Secrets Manager e Azure Key Vault, così i team possono continuare a utilizzare i servizi esistenti.
Altre integrazioni contraddistinguono i prodotti. AWX offre CyberArk Central Credential Provider, CyberArk Conjur e tipi di credenziali personalizzate. Semaphore UI fornisce integrazioni OpenBao e Devolutions Server dedicate. La ricerca nel Vault di AWX potrebbe funzionare con un servizio compatibile, ma la compatibilità di OpenBao richiede la verifica per l'operazione richiesta.
Confronta l'integrazione per il vault già utilizzato dal tuo team, incluso il metodo di autenticazione e i tipi di segreto necessari per i tuoi job. I servizi senza integrazione incorporata potrebbero richiedere un codice di recupero personalizzato.
Esecuzione
Un job richiede capacità di esecuzione che possa raggiungere i sistemi di destinazione. Gli agenti remoti gestiscono il posizionamento nella rete, mentre le immagini dei container forniscono le dipendenze di runtime.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Esecuzione remota | Sì | Sì |
| Capacità di esecuzione dedicata | SìProRunner di progetto | SìGruppi di istanze assegnati alle risorse |
| Instradamento dell'esecuzione | SìProTag dei runner su modelli o inventari | SìGruppi di istanze assegnati alle risorse |
| Ruoli e collection Ansible | SìInstallazione da requirements.yml | SìInstallazione durante la sincronizzazione del progetto |
| Attività containerizzate | SìProEsecutore Docker | SìImmagini degli ambienti di esecuzione Ansible |
| Pod di job Kubernetes | SìEnterprise | Sì |
| Controllo della concorrenza | SìLimiti di template, progetti e istanze | SìJob simultanei e capacità dei gruppi di istanze |
AWX invia il job ai nodi di esecuzione, raggruppati in gruppi di istanze che possono essere assegnati a organizzazioni, inventari o modelli. Semaphore UI esegue i job sul proprio server o li invia ai runner. In entrambi i modelli, le macchine di esecuzione possono trovarsi vicino ai sistemi di destinazione mentre l'interfaccia web rimane centralizzata.
Un runner Semaphore UI in una rete privata può applicare patch agli host o rinnovare certificati senza una connessione diretta dal server web ai sistemi di destinazione. I runner di progetto assegnano capacità a un progetto, mentre i tag su modelli o inventari indirizzano i job ai runner corrispondenti. Questo supporta sedi distribuite e ambienti dei clienti. I tag di routing selezionano le macchine, ma non impongono l’isolamento delle reti o degli account cloud.
L’ambiente di esecuzione determina cosa può essere eseguito su queste macchine. AWX usa immagini degli ambienti di esecuzione con Ansible e le sue dipendenze, e i gruppi di container possono creare un pod Kubernetes per ogni job. Semaphore UI offre l’esecuzione delle singole attività in Docker con Pro e in Kubernetes con Enterprise. Queste opzioni sono distinte dall’hosting del servizio web in un container. Entrambi i prodotti possono installare ruoli e collection Ansible dichiarati nei requisiti del repository. Le altre librerie e gli altri strumenti devono trovarsi sulla macchina di esecuzione o nella sua immagine.
I controlli di concorrenza limitano il lavoro simultaneo. AWX combina le impostazioni dei processi simultanei con la capacità di esecuzione e i limiti dei gruppi di istanze. Semaphore UI applica i limiti di istanza, progetto e modello.
AWX può anche suddividere automaticamente un grande inventario in job paralleli. Semaphore UI può distribuire il lavoro su esecuzioni separate con limiti host Ansible, con tag runner che selezionano le macchine di esecuzione. Il team mantiene questi sottoinsiemi e li lancia. Per gli aggiornamenti progressivi, l'impostazione serial di Ansible controlla batch sequenziali. Questi coprono esecuzioni mirate e implementazioni graduali, mentre lo slicing AWX fornisce il partizionamento automatico per operazioni parallele sull’intero parco di sistemi.
Workflow
Provisioning può richiedere un piano, l'approvazione, l'implementazione e la configurazione dell'host, con percorsi diversi dopo il successo o il fallimento. La composizione del workflow determina il modo in cui questi passaggi si collegano.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Editor visuale di workflow | Sì | Sì |
| Nodi iniziali multipli | No | Sì |
| Ricongiungimento dei rami | Sì | Sì |
| Workflow come passaggi | No | Sì |
| Rami di successo ed errore | Sì | Sì |
| Passaggi di approvazione | Sì | Sì |
| Ruolo di approvatore separato | NoAnnunciato per la versione 2.21 | Sì |
| Passaggio dei valori del workflow | Sì | Sì |
I workflow AWX collegano tra loro i modelli di job Ansible. Gli altri strumenti vengono richiamati tramite playbook. Semaphore UI collega direttamente i modelli Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. Entrambi supportano i rami di successo/fallimento e le approvazioni, quindi un processo di provisioning può essere messo in pausa prima di una modifica della produzione.
Entrambi usano grafi senza cicli e, nei ricongiungimenti, consentono di richiedere che siano soddisfatte le condizioni di tutti i predecessori oppure di uno qualsiasi. AWX ammette più nodi iniziali. Semaphore UI parte da un solo nodo e offre nodi per attività, approvazioni, attese temporizzate e annotazioni.
AWX può riutilizzare un intero workflow all'interno di un altro, mantenendo una procedura condivisa in più fasi in un unico posto. Impedisce l'esecuzione ricorsiva e offre passaggi di aggiornamento del repository e dell'inventario. Semaphore UI riutilizza i singoli modelli di attività nei workflow, ma non può incorporare un workflow come passaggio. La differenza è importante quando più distribuzioni condividono una procedura anziché un singolo job.
AWX dispone di un ruolo di approvatore assegnabile separatamente. Anche gli amministratori possono approvare. In Semaphore UI 2.20, l’approvazione dipende dal permesso di eseguire le attività del progetto. È una differenza importante se il team deve assegnare l’approvazione indipendentemente dall’esecuzione. Un ruolo di approvatore separato è annunciato per Semaphore UI 2.21 e non è incluso in questo confronto.
Entrambi consentono le approvazioni tramite interfaccia e API autenticata, e AWX offre anche un modulo Ansible. L’approvazione interattiva in Slack richiede un’integrazione che chiami l’API, non basta una notifica.
Entrambi passano valori ai job successivi, ad esempio l’indirizzo di un host appena creato. AWX espone i valori definiti con set_stats nel playbook come variabili extra per i job successivi, anche sui nodi di esecuzione. Un playbook può acquisire in questo modo il risultato di un altro strumento. Semaphore UI raccoglie i valori Ansible set_stats, gli output di Terraform/OpenTofu/Terragrunt e il JSON prodotto da Bash, PowerShell o Python. I valori vengono quindi associati alle variabili del modulo di destinazione tramite nomi corrispondenti o mappature esplicite.
In Semaphore UI 2.20, la raccolta degli output del workflow funziona sul server e sui runner remoti che usano l’esecutore locale. Gli esecutori Docker e Kubernetes non producono ancora output del workflow. I valori vengono raccolti dopo le attività riuscite. I rami di errore non possono quindi dipendere dagli output di un’attività non riuscita. I valori sono visibili agli utenti autorizzati a consultare l’attività e non devono contenere segreti.
Il passaggio di valori non trasferisce file in nessuno dei due prodotti. Se passaggi separati scambiano un piano Terraform salvato o un altro artefatto, occorre uno spazio di archiviazione accessibile a entrambi. Riutilizzare un runner non garantisce che la directory di lavoro persista tra le attività.
Controllo degli accessi
Il personale di supporto potrebbe dover riavviare un servizio approvato senza un accesso al server generico. La delega deve vincolare sia l’operazione che i suoi obiettivi.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Controllo degli accessi basato sui ruoli | SìRuoli di progetto, ruoli personalizzati in Enterprise | SìRuoli dell'organizzazione, del team e delle risorse |
| Autorizzazioni indipendenti per inventari e credenziali | NoL'accesso alle risorse segue i ruoli del progetto | Sì |
| Autorizzazioni di esecuzione a livello di modello | SìEnterprise | Sì |
| LDAP e OIDC | SìPro | Sì |
| Single sign-on SAML | NoOIDC disponibile | Sì |
| Autenticazione a due fattori | SìProTOTP locale | SìAttraverso un provider di identità esterno |
AWX concede autorizzazioni in modo indipendente per inventari, credenziali e modelli di job. Semaphore UI organizza l'accesso in base ai progetti, con ruoli personalizzati Enterprise e autorizzazioni di esecuzione a livello di modello per una delega più precisa. Un modello preconfigurato può esporre un'operazione approvata utilizzando l'inventario, le credenziali e le impostazioni di esecuzione scelti.
Per esempio, Semaphore UI Enterprise può dare al personale di supporto accesso a un modello di riavvio di un servizio su determinati server di produzione. Un ruolo di base Guest, associato a un ruolo personalizzato senza permessi estesi all’intero progetto, può autorizzare l’esecuzione di quel modello. Limita gli override di inventario, selezione degli host, variabili e altri parametri di avvio. Verifica inoltre che altri ruoli non estendano l’accesso. Modello, permessi e automazione definiscono insieme l’operazione consentita. Il modulo si limita a raccogliere i parametri.
Questo permette di delegare operazioni specifiche senza introdurre autorizzazioni indipendenti per inventari o credenziali all’interno di un progetto. AWX è più adatto quando gli operatori devono combinare risorse soggette a regole di accesso separate. Le autorizzazioni per modello di Semaphore UI si prestano a un insieme definito di procedure approvate.
Entrambi supportano LDAP e OIDC per l'accesso. AWX supporta anche SAML e si affida a un provider di identità esterno per MFA. Semaphore UI offre l'autenticazione a due fattori locale TOTP. Un provider di identità con OIDC può coprire l'accesso Semaphore UI centralizzato, mentre un requisito solo SAML richiede un altro approccio di integrazione.
Log e audit
L'output del job spiega gli errori di esecuzione. La cronologia degli audit registra chi ha avviato un'operazione o ne ha modificato la configurazione, con diversi requisiti di visibilità e conservazione.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| Cronologia e registri delle attività | Sì | Sì |
| Conservazione della cronologia delle attività | SìMantieni le attività recenti per modello | SìPulizia pianificata in base all’anzianità dei record |
| Cronologia degli audit tra progetti | SìLog di audit per gli amministratori, registrazione da abilitare | SìFlusso di attività, visibilità basata sui ruoli |
| Inoltro SIEM | SìProTLS Syslog e Splunk HEC | SìRegistrazione esterna, incluso Splunk |
Entrambi i prodotti conservano la cronologia delle attività e l'output per la risoluzione dei problemi. La visibilità dell'audit è diversa: il flusso di attività di AWX segue le autorizzazioni delle risorse e i ruoli di amministratore o revisore. La vista di audit trasversale ai progetti di Semaphore UI è disponibile per gli amministratori, con gli eventi archiviati nel suo database quando la registrazione di audit è abilitata.
Per le indagini centralizzate, il logging esterno di AWX inoltra record di attività, job e server, anche a Splunk. Semaphore UI Pro aggiunge filtri di audit, esportazione in CSV o JSONL e inoltro tramite TLS Syslog o Splunk HEC. Entrambi possono inviare eventi a una piattaforma di logging o a un sistema SIEM per la gestione delle informazioni e degli eventi di sicurezza.
La conservazione locale utilizza controlli diversi. AWX fornisce una pulizia pianificata basata sull'età per la cronologia di esecuzione e il flusso di attività. Semaphore UI conserva un numero configurato di attività recenti per modello. Un sistema di registrazione centrale può conservare i record oltre tali limiti locali.
Integrazioni
Le modifiche al repository e le richieste del portale di servizio possono attivare l'automazione. API, webhook e notifiche collegano tali eventi ai job e ai relativi risultati.
| Criteri | Semaphore UI | AWX |
|---|---|---|
| REST API | Sì | Sì |
| Webhook di job | SìEndpoint generici, matcher, estrazione di valori | SìWebhook GitHub e GitLab |
| Notifiche dei job | Sì | Sì |
AWX offre webhook dei job integrati per GitHub e GitLab, per attivare l’automazione dal repository. Semaphore UI offre endpoint webhook generici che verificano le richieste secondo regole configurate ed estraggono i parametri delle attività. Questi endpoint possono ricevere eventi da sistemi diversi, mentre le API REST di entrambi i prodotti consentono l’accesso ad altri client.
Per le notifiche in uscita, AWX offre email, Slack, Rocket.Chat, Mattermost, PagerDuty, AWS SNS, Grafana, IRC, Twilio e webhook. Semaphore UI supporta email (SMTP), Telegram, Slack, Microsoft Teams, Rocket.Chat, DingTalk e Gotify. Questi canali comunicano gli eventi dei job a persone o servizi, mentre i webhook dei job in ingresso avviano l’automazione.
Un portale di servizi o un sistema ITSM può usare l’API REST di ciascun prodotto per avviare un job preparato e recuperarne il risultato. Ad esempio, un portale interno può inviare una richiesta di rinnovo di un certificato a un modello salvato e comunicarne il completamento al richiedente. Si tratta di un’integrazione tramite API configurata dal team, non di un connettore nativo dedicato.
Automazione assistita dall’IA
Entrambe le piattaforme offrono risorse utili agli assistenti di programmazione come Claude Code e Codex: documentazione pubblica, codice sorgente aperto e API documentate. Un assistente può consultare esempi di configurazione, esaminare come è implementata un’impostazione e usare le definizioni delle API per proporre codice di integrazione. Se dispone della configurazione pertinente e dell’output del job, può anche aiutare ad analizzare gli errori. Questo rende possibili la configurazione e la risoluzione dei problemi assistite dall’IA senza una funzione di IA dedicata integrata nella piattaforma.
Per AWX e Semaphore UI sono disponibili connettori MCP sviluppati dalla community. A seconda del connettore, consentono agli assistenti di interagire con la piattaforma per cercare modelli, avviare job e recuperare risultati. Il team può così usare automazioni già preparate tramite un assistente, mantenendo nella piattaforma le definizioni dei job e la loro esecuzione.
Semaphore UI ha annunciato il supporto MCP ufficiale per Pro nella versione 2.21.0.
Licenze e supporto
Sia AWX che Semaphore UI offrono software open source gratuito. La differenza principale è il modo in cui i team possono ottenere capacità commerciali, supporto da parte dei fornitori e impegni contrattuali man mano che l’automazione diventa più importante per le loro operazioni.
Opzioni open source e commerciali
AWX è distribuito con licenza Apache 2.0 e riceve supporto dalla community. È anche un progetto upstream del componente automation controller di Red Hat Ansible Automation Platform (AAP). Red Hat non vende abbonamenti di supporto per AWX stesso. L’offerta con supporto commerciale è AAP, una piattaforma enterprise distinta che combina automation controller, componenti aggiuntivi, contenuti certificati e un ciclo di vita del prodotto definito.
Semaphore UI segue un modello open-core. Community è gratuito e distribuito con licenza MIT, mentre Pro ed Enterprise aggiungono funzionalità commerciali e supporto del fornitore nella stessa famiglia di prodotti. Pro è pensato per piccoli team di ingegneria che integrano l’automazione nelle operazioni quotidiane. Enterprise risponde a requisiti più avanzati di accesso, esecuzione, disponibilità e supporto.
Le offerte commerciali rispondono quindi a diverse esigenze di acquisto. AAP rappresenta un investimento in una piattaforma aziendale più ampia. I piani commerciali di Semaphore UI sono rivolti a team di ingegneri e organizzazioni di medie dimensioni, con un'opzione Enterprise per ambienti complessi o critici per l'azienda. I team possono ottenere controlli avanzati e supporto da parte dei fornitori mantenendo l'investimento concentrato sul servizio di automazione di cui hanno bisogno.
Supporto e impegni contrattuali
Gli utenti di AWX possono porre domande, segnalare bug e contribuire con correzioni attraverso i canali della community. Questa assistenza non obbliga un fornitore a rispondere entro un tempo definito o a gestire gli incidenti. Un abbonamento AAP fornisce supporto Red Hat per AAP, ma non estende la copertura a un’installazione AWX esistente.
Anche Semaphore UI Community offre assistenza nei limiti delle possibilità, senza SLA di supporto. Pro include il supporto del fornitore durante l’orario lavorativo. Enterprise offre opzioni SLA personalizzate e assistenza per l’avvio, la configurazione, gli aggiornamenti e la migrazione. I clienti commerciali hanno quindi un rapporto diretto con il fornitore, con obblighi di supporto definiti dal piano e dall’accordo applicabili.
Pianificazione del rilascio e della manutenzione
AWX attualmente afferma che i rilasci sono sospesi durante un refactoring su larga scala. Semaphore UI continua a pubblicare versioni e mantiene una politica di sicurezza che identifica le versioni supportate. Queste differenze sono importanti quando si pianificano aggiornamenti e manutenzione continua. Esamina la cronologia dei rilasci, le politiche di sicurezza e le linee guida per l'aggiornamento per la versione che intendi utilizzare insieme a eventuali impegni di supporto contrattuale.
Come scegliere
Entrambe le piattaforme consentono ai team di condividere l'automazione, pianificare i job ed esaminare i risultati. Scegli in base a come gestisci le informazioni dell'host, deleghi le operazioni, ospiti il servizio e ottieni supporto.
Quando scegliere AWX
AWX è una buona scelta quando Ansible è centrale per l’automazione e il suo modello di gestione delle risorse si adatta alle operazioni quotidiane.
- Gestire gli inventari attraverso la piattaforma è un requisito fondamentale. Gli operatori usano la piattaforma ogni giorno per mantenere i record di host e gruppi, aggiornare gli inventari e conservare i fact degli host.
- Gli inventari e le credenziali necessitano delle proprie regole di accesso. Il tuo team deve assegnare autorizzazioni a inventari e credenziali individuali indipendentemente dai modelli di job, consentendo agli operatori di combinare solo le risorse che sono autorizzati a utilizzare.
- Kubernetes si adatta alla tua infrastruttura esistente. Il tuo team gestisce già un cluster, quindi il modello di implementazione consigliato da AWX si adatta ai sistemi e alle competenze che mantieni.
- Ansible orchestra già le tue procedure. I tuoi playbook coprono le operazioni richieste, comprese le chiamate ad altri strumenti, e gli ambienti di esecuzione Ansible forniscono le relative dipendenze.
- Il supporto Community soddisfa le tue esigenze. Il tuo team ha l'esperienza e la capacità di indagare sugli incidenti, valutare gli avvisi di sicurezza e mantenere l'installazione senza uno SLA di risposta del fornitore.
Quando scegliere Semaphore UI
Semaphore UI è una buona scelta se cerchi un servizio semplice per eseguire e condividere l’automazione con gli strumenti e l’infrastruttura già in uso.
- I tuoi inventari risiedono già in Git o in sistemi esterni. Desideri riutilizzare le definizioni e i plug-in dell'inventario Ansible che rilevano host da NetBox, API cloud o altre origini durante l'esecuzione dei processi.
- I colleghi hanno bisogno di accedere alle operazioni preparate. Gli ingegneri definiscono attività come distribuzioni, riavvii di servizi o rinnovi di certificati. Altri membri del team avviano tali attività con gli input richiesti, mentre gli inventari e le credenziali rimangono parte della configurazione preparata.
- Vuoi installare il servizio senza Kubernetes. Le installazioni binarie, con pacchetto nativo e Docker consentono di utilizzare un server esistente, evitando un cluster introdotto esclusivamente per il servizio di automazione.
- La tua automazione si estende su diversi strumenti. I modelli dedicati eseguono direttamente Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python, con workflow che collegano le loro operazioni.
- Desideri un percorso diretto al supporto commerciale. Le licenze commerciali aggiungono supporto del fornitore e funzionalità avanzate all'interno della stessa famiglia di prodotti, così puoi ottenere impegni di supporto continuando a utilizzare Semaphore UI.
Domande frequenti
Semaphore UI può sostituire AWX?
Sì, quando il modello di inventario, autorizzazione e workflow soddisfa le tue esigenze. I playbook esistenti possono spesso essere riutilizzati, mentre la configurazione del job e i controlli di accesso devono essere mappati e testati. Controlla eventuali dipendenze da funzionalità specifiche di AWX, in particolare workflow nidificati, inventario indipendente o autorizzazioni di credenziali e memorizzazione nella cache dei fact gestita.
Posso riutilizzare i miei playbook Ansible esistenti?
Parti dallo stesso repository e dagli stessi playbook. Configura in Semaphore UI inventario, credenziali, variabili, collection e dipendenze di runtime necessari, quindi prova esecuzioni rappresentative. Riutilizzare il codice non importa automaticamente tutte le impostazioni di AWX.
Cosa è necessario verificare durante la migrazione da AWX?
Inizia con un workflow rappresentativo. Riutilizza i suoi playbook ove possibile, quindi mappa gli inventari, le credenziali, le variabili, i moduli di avvio, le pianificazioni e le dipendenze di runtime. Verifica separatamente autorizzazioni, approvazioni, workflow nidificati e trasferimento di valori o file. Un'importazione può ridurre il job di configurazione, ma non dimostra che il job importato si comporti allo stesso modo. Testare prima di abilitare i pianificazioni di produzione.
Quali funzionalità di Semaphore UI richiedono una versione a pagamento?
Community offre l’interfaccia di base per le attività e i workflow. Runner di progetto, esecuzione in Docker e integrazioni con vault esterni sono disponibili a partire da Pro. Ruoli personalizzati, autorizzazioni per modello, esecuzione delle attività in Kubernetes e alta disponibilità richiedono Enterprise. Nella scelta del piano, verifica le funzionalità e la capacità necessarie.
Posso mantenere il Single Sign-On SAML dopo la migrazione?
AWX supporta direttamente SAML. Semaphore UI supporta LDAP e OIDC, ma non ha integrazione SAML nativa. Un provider di identità che offre anche OIDC può coprire i requisiti di accesso. Verificare la mappatura di utenti e gruppi separatamente, poiché la modifica del protocollo di autenticazione non ricrea le autorizzazioni AWX.
Semaphore UI richiede Kubernetes?
No. Sono disponibili installazioni binarie, a pacchetto e Docker. Kubernetes è una scelta di distribuzione opzionale. Gli strumenti di automazione e un database adeguato fanno ancora parte dell'ambiente.
AWX può eseguire Terraform o utilizzare HashiCorp Vault?
Sì. I playbook possono eseguire comandi Terraform o moduli di collection, e AWX supporta il recupero delle credenziali da HashiCorp Vault. Semaphore UI offre un modello diverso, con modelli Terraform/OpenTofu dedicati e un backend HTTP per lo state opzionale con Pro.
Una delle due piattaforme supporta l'esecuzione remota?
Entrambi possono eseguire attività su server remoti. AWX usa nodi di esecuzione raggruppati per team e carichi di lavoro diversi. Semaphore UI usa agenti runner. I modelli di configurazione e accesso differiscono.
Questo articolo è stato utile?
Fonti
- ARA Records Ansible, “ARA Records Ansible”. URL: https://ara.recordsansible.org/ (consultato il: ).
- Semaphore UI, “Semaphore runner output capture and executor limits”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/runners/job_pool.go#L167-L192 (consultato il: ).
- Semaphore UI, “Semaphore task dispatch, runner routing, concurrency and remote workflow outputs”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/TaskPool.go (consultato il: ).
- Semaphore UI, “Semaphore workflow input mapping model”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Workflow.go#L27-L44 (consultato il: ).
- Semaphore UI, “Semaphore task template options and survey field types”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Template.go (consultato il: ).
- Semaphore UI, “Semaphore NetBox dynamic inventory example”. URL: https://semaphoreui.com/docs/user-guide/inventory/netbox-dynamic-inventory (consultato il: ).
- Semaphore UI, “Semaphore Consul inventory script”. URL: https://semaphoreui.com/docs/user-guide/inventory/consul-dynamic-inventory (consultato il: ).
- Ansible community, “NetBox Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/netbox/netbox/nb_inventory_inventory.html (consultato il: ).
- Ansible community, “AWS EC2 Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/amazon/aws/aws_ec2_inventory.html (consultato il: ).
- Ansible community, “Azure Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/azure/azcollection/azure_rm_inventory.html (consultato il: ).
- Ansible community, “Google Cloud Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/google/cloud/gcp_compute_inventory.html (consultato il: ).
- Semaphore UI, “Semaphore cloning of inventory repositories”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/local_executor_inventory.go (consultato il: ).
- Semaphore UI, “Semaphore local execution, workflow outputs, inventory paths, host limits and branch overrides”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/local_executor.go (consultato il: ).
- Semaphore UI, “Semaphore survey field types”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/web/src/components/SurveyVars.vue (consultato il: ).
- Semaphore UI, “Semaphore survey inputs and task launch form”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/web/src/components/TaskForm.vue (consultato il: ).
- Semaphore UI, “What is Semaphore UI?”. URL: https://semaphoreui.com/docs/introduction/what-is-semaphore (consultato il: ).
- AWX project, “AWX user guide”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/index.html (consultato il: ).
- Semaphore UI, “Semaphore source and MIT license”. URL: https://github.com/semaphoreui/semaphore (consultato il: ).
- AWX project, “AWX source and Apache 2.0 license”. URL: https://github.com/ansible/awx (consultato il: ).
- Semaphore UI, “Semaphore setup and first run”. URL: https://semaphoreui.com/docs/getting-started (consultato il: ).
- Semaphore UI, “Semaphore installation methods and dependencies”. URL: https://semaphoreui.com/docs/admin-guide/installation (consultato il: ).
- AWX project, “AWX installation paths”. URL: https://github.com/ansible/awx/blob/24.6.1/INSTALL.md (consultato il: ).
- AWX project, “AWX Operator installation”. URL: https://docs.ansible.com/projects/awx-operator/en/latest/installation/basic-install.html (consultato il: ).
- Semaphore UI, “Semaphore high availability prerequisites”. URL: https://semaphoreui.com/docs/admin-guide/ha#prerequisites (consultato il: ).
- AWX project, “AWX web and task replica scaling”. URL: https://docs.ansible.com/projects/awx-operator/en/latest/user-guide/advanced-configuration/scaling-the-web-and-task-pods-independently.html (consultato il: ).
- Semaphore UI, “Semaphore automation applications”. URL: https://semaphoreui.com/docs/user-guide/apps (consultato il: ).
- Semaphore UI, “Semaphore task templates”. URL: https://semaphoreui.com/docs/user-guide/task-templates (consultato il: ).
- AWX project, “AWX job templates and surveys”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/job_templates.html (consultato il: ).
- Semaphore UI, “Survey variables”. URL: https://semaphoreui.com/docs/user-guide/task-templates/survey-vars (consultato il: ).
- Semaphore UI, “Terraform and OpenTofu in Semaphore”. URL: https://semaphoreui.com/docs/user-guide/apps/terraform (consultato il: ).
- Ansible community, “Ansible Terraform module”. URL: https://docs.ansible.com/projects/ansible/latest/collections/community/general/terraform_module.html (consultato il: ).
- Semaphore UI, “Semaphore Terraform HTTP backend”. URL: https://semaphoreui.com/docs/user-guide/apps/terraform/states (consultato il: ).
- Semaphore UI, “Semaphore workflow nodes and approvals”. URL: https://semaphoreui.com/docs/user-guide/workflows (consultato il: ).
- Semaphore UI, “Semaphore inventory types and stored resources”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Inventory.go (consultato il: ).
- AWX project, “AWX job slicing”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/job_slices.html (consultato il: ).
- Semaphore UI, “Semaphore workflow approval API routes”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/api/router.go (consultato il: ).
- AWX project, “AWX resource, workflow approval and activity-stream access control”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/access.py (consultato il: ).
- AWX project, “AWX workflow approval Ansible module”. URL: https://github.com/ansible/awx/blob/24.6.1/awx_collection/plugins/modules/workflow_approval.py (consultato il: ).
- AWX project, “AWX workflow branch convergence”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/scheduler/dag_workflow.py#L51-L112 (consultato il: ).
- AWX project, “AWX Terraform State inventory source”. URL: https://github.com/ansible/awx/blob/24.6.1/docs/docsite/rst/userguide/inventories.rst#L1092-L1121 (consultato il: ).
- AWX project, “AWX instance-group capacity limits”. URL: https://github.com/ansible/awx/blob/24.6.1/docs/docsite/rst/administration/containers_instance_groups.rst#L247-L263 (consultato il: ).
- AWX project, “AWX custom credential types”. URL: https://github.com/ansible/awx/blob/24.6.1/docs/credentials/custom_credential_types.md (consultato il: ).
- AWX project, “AWX workflows”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/workflow_templates.html (consultato il: ).
- AWX project, “AWX workflow branching and output variables”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/workflows.html (consultato il: ).
- AWX project, “AWX collection of Ansible workflow variables”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/tasks/callback.py#L156-L160 (consultato il: ).
- AWX project, “AWX processing of execution-node events”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/tasks/receptor.py#L544-L553 (consultato il: ).
- AWX project, “AWX inheritance of variables between workflow jobs”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/models/workflow.py#L324-L354 (consultato il: ).
- Semaphore UI, “Semaphore global runners”. URL: https://semaphoreui.com/docs/admin-guide/runners/ (consultato il: ).
- Semaphore UI, “Semaphore project runners”. URL: https://semaphoreui.com/docs/user-guide/projects/runners (consultato il: ).
- AWX project, “AWX execution and hop nodes”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/instances.html (consultato il: ).
- AWX project, “AWX execution environments”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/execution_environments.html (consultato il: ).
- AWX project, “AWX Kubernetes container groups”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/containers_instance_groups.html (consultato il: ).
- Semaphore UI, “Semaphore inventories”. URL: https://semaphoreui.com/docs/user-guide/inventory (consultato il: ).
- AWX project, “AWX inventories”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/inventories.html (consultato il: ).
- Semaphore UI, “Semaphore project access”. URL: https://semaphoreui.com/docs/user-guide/projects (consultato il: ).
- Semaphore UI, “Semaphore team roles and template-level permissions”. URL: https://semaphoreui.com/docs/user-guide/team#extended-rbac (consultato il: ).
- AWX project, “AWX role-based access controls”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/rbac.html (consultato il: ).
- Semaphore UI, “Semaphore LDAP and OIDC authentication”. URL: https://semaphoreui.com/docs/admin-guide/authentication (consultato il: ).
- AWX project, “AWX LDAP, OIDC and SAML authentication”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/ent_auth.html (consultato il: ).
- Semaphore UI, “Semaphore Key Store”. URL: https://semaphoreui.com/docs/user-guide/key-store (consultato il: ).
- AWX project, “AWX credentials and secret lookups”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/credentials.html (consultato il: ).
- AWX project, “AWX external secret management integrations”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/credential_plugins.html (consultato il: ).
- Semaphore UI, “Semaphore OpenBao secret storage”. URL: https://semaphoreui.com/docs/user-guide/key-store/openbao (consultato il: ).
- Semaphore UI, “Semaphore Devolutions Server secret storage”. URL: https://semaphoreui.com/docs/user-guide/key-store/devolutions-server (consultato il: ).
- Semaphore UI, “Semaphore webhook integrations”. URL: https://semaphoreui.com/docs/user-guide/integrations (consultato il: ).
- AWX project, “AWX webhooks”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/webhooks.html (consultato il: ).
- Semaphore UI, “Semaphore REST API”. URL: https://semaphoreui.com/api-docs (consultato il: ).
- Ansible community, “Ansible command execution”. URL: https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/command_module.html (consultato il: ).
- Ansible community, “Ansible PowerShell module”. URL: https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_powershell_module.html (consultato il: ).
- Semaphore UI, “Semaphore notification channels”. URL: https://semaphoreui.com/docs/admin-guide/notifications (consultato il: ).
- AWX project, “AWX notifications”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/notifications.html (consultato il: ).
- Semaphore UI, “Semaphore task history and output”. URL: https://semaphoreui.com/docs/user-guide/tasks (consultato il: ).
- Semaphore UI, “Semaphore scheduled tasks”. URL: https://semaphoreui.com/docs/user-guide/schedules (consultato il: ).
- AWX project, “AWX activity stream”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/main_menu.html (consultato il: ).
- Semaphore UI, “Semaphore Community, Pro and Enterprise”. URL: https://semaphoreui.com/pricing (consultato il: ).
- Red Hat, “Red Hat: AWX and Ansible Automation Platform”. URL: https://www.redhat.com/en/technologies/management/ansible/compare-awx-vs-ansible-automation-platform (consultato il: ).
- Red Hat, “Red Hat automation controller, formerly Ansible Tower”. URL: https://www.redhat.com/en/technologies/management/ansible/automation-controller (consultato il: ).
- Semaphore UI, “Semaphore stable releases”. URL: https://github.com/semaphoreui/semaphore/releases (consultato il: ).
- AWX project, “AWX release history”. URL: https://github.com/ansible/awx/releases (consultato il: ).
- Semaphore MCP contributors, “Semaphore MCP connector”. URL: https://github.com/cloin/semaphore-mcp (consultato il: ).
- Semaphore MCP contributors, “Semaphore MCP task execution and output”. URL: https://github.com/cloin/semaphore-mcp/blob/72f5b7008f6d560c74e01da9884e6fddbbf68999/src/semaphore_mcp/tools/tasks.py (consultato il: ).
- LY Corporation, “AWX MCP connector and compatibility”. URL: https://github.com/lycorp-jp/awx-mcp/tree/fa4d25ffa9e04967e98dc66b219a0481d61ea814 (consultato il: ).
- LY Corporation, “AWX MCP job template execution”. URL: https://github.com/lycorp-jp/awx-mcp/blob/fa4d25ffa9e04967e98dc66b219a0481d61ea814/awx_mcp/tools/job_templates.py (consultato il: ).
- LY Corporation, “AWX MCP job output”. URL: https://github.com/lycorp-jp/awx-mcp/blob/fa4d25ffa9e04967e98dc66b219a0481d61ea814/awx_mcp/tools/jobs.py (consultato il: ).
- HashiCorp, “Terraform local state backend”. URL: https://developer.hashicorp.com/terraform/language/backend/local (consultato il: ).
- HashiCorp, “Terraform state locking”. URL: https://developer.hashicorp.com/terraform/language/state/locking (consultato il: ).
- Semaphore UI, “Semaphore variable groups”. URL: https://semaphoreui.com/docs/user-guide/environment (consultato il: ).
- Semaphore UI, “Semaphore runner selection and capacity”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/RemoteJob.go (consultato il: ).
- Semaphore UI, “Semaphore cron and one-time schedule execution”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/schedules/SchedulePool.go (consultato il: ).
- AWX project, “AWX schedules”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/scheduling.html (consultato il: ).
- Ansible community, “Ansible constructed inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/constructed_inventory.html (consultato il: ).
- Ansible community, “Ansible cache plugins”. URL: https://docs.ansible.com/projects/ansible/latest/plugins/cache.html (consultato il: ).
- Semaphore UI, “View and export the Semaphore audit log”. URL: https://semaphoreui.com/docs/admin-guide/audit-log/view (consultato il: ).
- Semaphore UI, “Semaphore administrator audit-log access”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/api/audit_log.go (consultato il: ).
- AWX project, “AWX logging and aggregation”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/logging.html (consultato il: ).
- Semaphore UI, “Semaphore audit log”. URL: https://semaphoreui.com/docs/admin-guide/audit-log (consultato il: ).
- Semaphore UI, “Ansible role and collection installation”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db_lib/AnsibleApp.go (consultato il: ).
- Semaphore UI, “Task-history cleanup”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/sql/task.go (consultato il: ).
- Semaphore UI, “Ansible inventory overrides”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/TaskRunner.go (consultato il: ).
- AWX project, “Projects, Ansible Galaxy and collections”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/projects.html#ansible-galaxy-support (consultato il: ).
- AWX project, “Management jobs”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/management_jobs.html (consultato il: ).
- Semaphore UI, “Terraform plan and apply execution”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db_lib/TerraformApp.go (consultato il: ).
- Semaphore UI, “Repository working directories”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Repository.go (consultato il: ).
- HashiCorp, “Terraform plan command”. URL: https://developer.hashicorp.com/terraform/cli/commands/plan (consultato il: ).
- HashiCorp, “Terraform apply command”. URL: https://developer.hashicorp.com/terraform/cli/commands/apply (consultato il: ).
- Semaphore UI, “Security policy”. URL: https://github.com/semaphoreui/semaphore/security/policy (consultato il: ).
- AWX project, “Security policy”. URL: https://github.com/ansible/awx/security/policy (consultato il: ).
- AWX project, “Release status and project overview”. URL: https://github.com/ansible/awx/blob/devel/README.md (consultato il: ).
- Semaphore UI, “Semaphore notification channel implementation”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/alert.go (consultato il: ).
Confronto a cura del team Semaphore UI basato sulla documentazione, sui repository e sulle pagine dei prezzi elencati sopra. La data di consultazione è indicata per ogni fonte.
Collegamenti utili
Metti in pratica il confronto con uno dei tuoi job esistenti.