Roadmap

Flussi di lavoro #

Semaphore attualmente tratta ogni modello di attivita come un’unita indipendente – non esiste un modo integrato per concatenare piu modelli in una pipeline di esecuzione multi-step. Questa funzionalita introduce i Flussi di lavoro – grafi aciclici diretti (DAG) di modelli di attivita che vengono eseguiti con ramificazione condizionale, passaggio di variabili tra i passaggi e porte di approvazione umana opzionali. Il design si ispira agli AWX Workflow Job Templates, ai flussi di lavoro di Rundeck e ai concetti di pipeline di Jenkins/GitLab CI.

Pro #

• Modelli di flusso di lavoro – introduce una nuova entita di livello superiore che definisce un DAG di nodi di modelli di attivita collegati da archi diretti con condizioni (on_success, on_failure, always), consentendo pipeline di automazione multi-step all’interno di un progetto. (#3182, #2334, #1383, #836)
• Motore di esecuzione dei flussi di lavoro – esegue i nodi del flusso di lavoro in ordine topologico, rispettando le condizioni degli archi ed eseguendo rami indipendenti in parallelo, con convergenza ALL per i nodi con piu genitori. (#2281, #3088)
• Dashboard di esecuzione dei flussi di lavoro – fornisce una vista unificata dell’esecuzione del flusso di lavoro mostrando il grafo DAG con stato per nodo (in attesa, in esecuzione, riuscito, fallito, saltato), log dei nodi cliccabili e tempi complessivi.
• Passaggio di variabili tra nodi – consente ai modelli di attivita di emettere variabili di output (tramite un file noto o Ansible set_stats) che vengono automaticamente iniettate come variabili extra nei nodi a valle. (#3182)
• Pianificazione dei flussi di lavoro e trigger API – supporto per pianificazione cron, esecuzioni attivate via API e trigger webhook per i flussi di lavoro, con variabili survey opzionali a livello di flusso di lavoro. (#3088)
• Editor visuale dei flussi di lavoro – editor grafico drag-and-drop per progettare flussi di lavoro nell’interfaccia, con validazione DAG in tempo reale, posizionamento dei nodi e selettori di condizioni sugli archi.
• Override per nodo – sovrascrive inventario, credenziali, gruppi di variabili o argomenti CLI di un modello a livello di nodo del flusso di lavoro, consentendo di riutilizzare lo stesso modello in ambienti diversi all’interno di un singolo flusso di lavoro.
• Porte di approvazione – mette in pausa l’esecuzione del flusso di lavoro in punti designati per attendere l’approvazione umana, con timeout configurabili, notifica agli approvatori e azioni di approvazione/rifiuto dall’interfaccia o API.

Enterprise #

• RBAC dei flussi di lavoro – permessi granulari per creare, modificare, eseguire e approvare flussi di lavoro, con assegnazione delle porte di approvazione basata sui ruoli e registrazione di audit.
• Flussi di lavoro tra progetti – referenzia modelli di attivita da altri progetti in un flusso di lavoro, consentendo pipeline di automazione a livello organizzativo che coprono progetti di infrastruttura, applicazione e monitoraggio.
• Versionamento dei flussi di lavoro e rollback – mantiene una cronologia delle versioni delle definizioni dei flussi di lavoro con diff, ripristina le versioni precedenti e registra quale versione e stata utilizzata per ogni esecuzione.

Mappatura dei gruppi LDAP e OpenID #

Semaphore supporta LDAP e OpenID Connect (OIDC) per l’autenticazione, ma l’integrazione si ferma al login – non esiste un’assegnazione automatica di ruoli o progetti basata sull’appartenenza ai gruppi del provider di identita. Ogni utente OIDC/LDAP deve essere assegnato manualmente a progetti e ruoli dopo il primo accesso. Inoltre, ci sono numerosi bug nella gestione del redirect OIDC, nel parsing dei claim e nella configurazione LDAP che rendono l’esperienza di autenticazione inaffidabile.

Community #

• Limitazione del login OIDC per claim – consente l’accesso solo agli utenti con valori di claim specifici (ad esempio, appartenenza a un gruppo richiesto o dominio email). (#2626, #2938)
• Auto-login SSO – salta la schermata di login e reindirizza direttamente al provider OIDC/SSO, con un URL di sicurezza per il recupero se SSO non e disponibile. (#2548, #2899)
• Supporto OIDC PKCE – aggiunge il Proof Key for Code Exchange al flusso del codice di autorizzazione OIDC come raccomandato dalla RFC 9700. (#3072)
• Configurazione OIDC tramite variabili di ambiente – consente di configurare i provider OIDC tramite variabili di ambiente invece che solo tramite file di configurazione, semplificando la gestione dei segreti nei container. (#2528, #3120)
• Correzione del redirect OIDC con web_host/web_root – risolve gli errori 404 dopo il login OIDC quando web_host e vuoto o web_root e impostato su un sottopercorso. (#2681, #1524, #2532, #3121)
• Correzione della gestione dei claim OIDC – risolve i problemi con username_claim ignorato, il claim email non riconosciuto e client_secret_file che produce richieste malformate. (#1731, #2818, #3122)
• Correzione delle espressioni dei claim LDAP – risolve le espressioni template non funzionanti nella mappatura LDAP (ad esempio, mail | {{ .username }}@domain.com che si risolve in <no value>). (#3127)
• Correzione dell’assegnazione del nome utente LDAP – assicura che gli utenti LDAP ottengano il loro effettivo nome utente LDAP invece di una stringa generata casualmente. (#3688)
• Fallback autenticazione locale LDAP – consente agli account amministratore locali di effettuare comunque il login quando LDAP e abilitato, prevenendo il blocco se il server LDAP non e raggiungibile. (#1363)
• Logging di debug LDAP – aggiunge output di log utili per i fallimenti di autenticazione LDAP per rendere possibile la risoluzione dei problemi. (#2932)
• Collegamento utente OIDC/LDAP ad account locale – consente di convertire o collegare account locali esistenti a provider di identita esterni senza creare duplicati. (#3339)
• Logout dal provider OIDC – termina la sessione IdP (ad esempio, Keycloak) quando si esce da Semaphore, consentendo il corretto cambio di account. (#1496)

Pro #

• Sincronizzazione delle credenziali LDAP con le chiavi di accesso – aggiorna opzionalmente in automatico la password della chiave di accesso quando la password LDAP cambia al login, mantenendo le credenziali Ansible sincronizzate. (#3696)

Enterprise #

• Mappatura gruppo-ruolo OIDC – assegna automaticamente ruoli Semaphore e appartenenze ai progetti in base ai claim OIDC (ad esempio, claim groups), eliminando la configurazione manuale dell’utente dopo il primo accesso. (#1499, #2483)
• Mappatura gruppo-ruolo LDAP – mappa i gruppi Active Directory / LDAP sui ruoli Semaphore, inclusa l’assegnazione del ruolo di amministratore tramite appartenenza al gruppo. (#3226, #1316)
• RBAC completo con integrazione LDAP/OIDC – implementa un controllo degli accessi granulare basato sui ruoli (amministratore globale, amministratore del progetto, utente del progetto, sola lettura) con assegnazione automatica dei ruoli dai gruppi del provider di identita esterno. (#891)
• Architettura di autenticazione pluggable – astrae l’autenticazione in un’interfaccia provider per supportare piu backend di autenticazione e semplificare l’aggiunta di nuovi provider. (#465, #1820)
• Correzione dell’eliminazione utente che lascia dati orfani – assicura che l’eliminazione di un utente pulisca le mappature project__user per prevenire crash nella vista Team. (#3514)

Sistema integrato di gestione dell’inventario #

Oggi Semaphore tratta l’inventario come un blocco opaco: gli utenti incollano contenuto INI/YAML grezzo in un’unica casella di testo oppure puntano a un file in un repository. Non esiste un modo strutturato per aggiungere un host, organizzare gli host in gruppi o impostare variabili di host e di gruppo dall’interfaccia. Questa funzionalita introduce un sistema integrato di gestione dell’inventario: un editor di inventario strutturato e gestito dall’interfaccia (simile agli inventari di AWX) in cui host, gruppi e variabili sono oggetti di prima classe archiviati in Semaphore e modificabili direttamente nell’interfaccia web, pur rimanendo completamente esportabili in un inventario Ansible standard.

Community #

• Editor strutturato di host e gruppi – gestisce host, i loro indirizzi/alias e i gruppi di host tramite l’interfaccia invece di modificare a mano una casella di testo di inventario grezza, con azioni di aggiunta/rimozione/rinomina per host e gruppi. (#836)
• Variabili di host e di gruppo nell’interfaccia – definisce host_vars e group_vars come coppie chiave/valore strutturate per host e per gruppo, in modo che le impostazioni di connessione e le variabili personalizzate non debbano piu essere incorporate a mano nel corpo dell’inventario.
• Editor di inventario inline migliorato – sostituisce la piccola casella di testo dell’inventario con un editor piu grande e ridimensionabile, dotato di evidenziazione della sintassi YAML/INI e di validazione, rendendo realmente utilizzabile la modalita di modifica inline esistente. (#698, #1650)
• Importazione di un inventario esistente – inizializza un inventario gestito importando un file di inventario INI/YAML esistente o incollandone il contenuto, analizzandolo in host, gruppi e variabili strutturati.
• Definizioni di inventario dichiarative – definisce gli inventari (host, gruppi, variabili) in modo dichiarativo tramite un documento YAML gestito da Semaphore, consentendo una configurazione dell’inventario riproducibile e sotto controllo di versione insieme a progetti e modelli. (#3109)
• Esportazione in inventario Ansible standard – genera l’inventario gestito come file di inventario Ansible standard al momento dell’esecuzione dell’attivita, in modo che i playbook e ansible-inventory vedano esattamente la stessa struttura indipendentemente da come e stata creata.

Pro #

• Gruppi di host riutilizzabili – definisce i gruppi di host una sola volta e li condivide tra piu inventari e progetti, cosi che una modifica all’appartenenza al gruppo o alle variabili di gruppo si propaghi ovunque il gruppo venga utilizzato.
• Cronologia delle modifiche all’inventario – mantiene una cronologia delle revisioni per inventario con le differenze delle modifiche a host, gruppi e variabili, e consente di ripristinare una versione precedente.

Enterprise #

• Ruolo di gestione host con ambito limitato – introduce un ruolo di tipo operatore in grado di aggiungere, modificare e rimuovere host in inventari designati (ed eseguire modelli predefiniti) senza concedere l’amministrazione completa del progetto. (#2989)
• Approvazione delle modifiche all’inventario – richiede revisione/approvazione prima che le modifiche agli inventari protetti abbiano effetto, con una traccia di audit di chi ha modificato quale host, gruppo o variabile e quando.

Sistema di notifica flessibile #

L’attuale sistema di notifica nell’interfaccia utente di Semaphore e configurato esclusivamente tramite config.json, supporta un set limitato di canali (Email, Telegram, Slack, MS Teams) e opera a livello globale con una personalizzazione minima per progetto. Questa funzionalita riprogetta le notifiche da zero per renderle gestite dall’interfaccia utente, estensibili e configurabili a livello di granularita di progetto e modello.

Community #

• Architettura di canale estensibile – definisce un’interfaccia comune per i canali di notifica con implementazioni per canale, semplificando l’aggiunta di nuovi canali senza modificare la logica di base. Si consideri l’adozione di una libreria di notifica universale (ad esempio, nikoksr/notify) o di un gateway (ad esempio, Apprise) per coprire molti provider contemporaneamente. (#2325, #1290)
• Configurazione delle notifiche gestita dall’interfaccia utente – sposta la configurazione delle notifiche dai file di configurazione nell’interfaccia Web con granularita per progetto e per modello, supportando piu istanze dello stesso tipo di canale. (#3387, #1821, #3588)
• Personalizzazione dei messaggi basata su modelli – supporta modelli di messaggio definiti dall’utente archiviati come file su disco anziche nel database.
• Selezione del canale per progetto – consente agli utenti di configurare quali canali di notifica sono attivi per progetto tramite le impostazioni del progetto. (#3588)
• Eventi webhook in uscita – definisce i tipi di evento (START, SUCCESS, FAILURE) e consente la creazione di modelli webhook per progetto con URL, intestazioni e autenticazione HMAC configurabili. (#1825, #2594, #3066)
• Nuovi canali di notifica – aggiunge il supporto per Discord (#2924), Ntfy (#3383), Google Chat (#1148), Rocket.Chat (#1091) e Pushover (#2594).
• Notifiche “Fixed” – invia una notifica alla prima esecuzione riuscita dopo un fallimento, simile agli avvisi di recovery di GitLab CI. (#3380)
• Disabilita tutte le notifiche per modello – aggiunge un’opzione “Disabilita tutte le notifiche” accanto alla casella di controllo esistente “Disabilita notifiche di successo”. (#3724)
• Email in caso di successo – include l’email nel percorso di notifica di successo (attualmente solo Telegram/Slack/MS Teams si attivano in caso di successo). (#3503)
• Correzione dell’URL dell’attivita nelle notifiche – assicura che tutti i canali (email, Slack, MS Teams) ricevano un URL dell’attivita completo con schema e host, non un percorso relativo. (#2097, #2311, #3292)
• Correzione dei problemi di consegna email – risolve il supporto della porta SMTP 465 (TLS implicito), l’ordine autenticazione-prima-di-TLS e la formattazione dell’intestazione Date. (#2201, #2971, #3542, #3209)
• Supporto thread/topic di Telegram – consente di inviare notifiche a thread specifici di gruppi Telegram tramite message_thread_id, configurabile per progetto e per modello. (#3493, #1456)
• Miglioramenti al modello Slack – espone i campi di livello superiore (title, text, color) per la compatibilita con Slack Workflow Builder. (#2607)
• Supporto proxy per gli avvisi – consente di configurare un proxy HTTP per le richieste di notifica in uscita senza richiedere un proxy a livello di sistema. (#1484)

Pro #

• Canali di notifica esclusivi Pro – supporta canali di notifica specifici esclusivamente nel piano Pro.
• Avvisi per attivita di lunga durata – attiva una notifica quando un’attivita supera una soglia di durata configurabile. (#1393)

Enterprise #

• Registro di audit per le notifiche – mantiene un registro ricercabile di tutte le notifiche inviate con stato di consegna, timestamp e dettagli del destinatario. Migliora la registrazione degli errori per includere il contesto del destinatario in caso di fallimento. (#3410)
• Integrazione con piattaforme di gestione degli incidenti – integrazioni native con PagerDuty, Opsgenie e ServiceNow per la creazione automatica degli incidenti e il tracciamento del ciclo di vita.
• Controllo degli accessi alle notifiche basato sui ruoli – limita chi puo configurare regole e canali di notifica in base ai ruoli e alle autorizzazioni dell’organizzazione.

Segreti di proprieta dell’utente #

Il key store di Semaphore e attualmente condiviso tra tutti i membri del progetto. Qualsiasi utente con accesso al progetto puo utilizzare (e in alcuni casi visualizzare) tutte le credenziali archiviate. Questo crea problemi di sicurezza in ambienti multi-utente dove i membri del team dovrebbero avere accesso solo alle proprie credenziali. Inoltre, il key store presenta numerosi bug relativi alla crittografia, agli aggiornamenti dei segreti e all’integrita dei riferimenti, e manca di integrazione con sistemi esterni di gestione dei segreti.

Community #

• Key store personale – fornisce un key store per utente cosi che le credenziali personali (chiavi SSH, password sudo) siano isolate dagli altri membri del progetto e non condivise tramite il key store a livello di progetto. (#1483, #1373)
• Correzione del comportamento di aggiornamento dei segreti – risolve il problema per cui la modifica di una variabile di ambiente segreta sembra avere successo ma il valore non viene effettivamente salvato. (#2546)
• Nascondere i segreti dalla lista dei processi – impedisce il passaggio di extra-vars segreti tramite argomenti della riga di comando visibili nella lista dei processi del sistema operativo; utilizza un meccanismo sicuro (ad esempio, file temporanei, stdin). (#3219)
• Supporto certificati SSH nel key store – consente di archiviare certificati SSH insieme alle chiavi SSH per flussi di lavoro di autenticazione basata su certificati. (#3171)
• Visualizzazione della chiave pubblica SSH – mostra la parte della chiave pubblica delle chiavi SSH archiviate nell’interfaccia del key store per comodita. (#1643)
• Supporto per i segreti Docker – supporta il pattern env var _FILE (ad esempio, POSTGRES_PASSWORD_FILE) cosi che i segreti Docker/Kubernetes possano essere montati e letti invece di essere passati tramite variabili di ambiente. (#1268)
• Correzione della gestione della chiave di crittografia in Docker – assicura che la env var SEMAPHORE_ACCESS_KEY_ENCRYPTION sia rispettata e non venga sovrascritta con una chiave casuale al riavvio del container. (#2228, #3068, #3204)
• Correzione della rinomina del key store che rompe i riferimenti – risolve il problema per cui la rinomina di una voce del key store interrompe tutti gli inventari e i modelli collegati. (#3188)
• Correzione dell’API per le password Vault – consente di impostare e aggiornare le password Ansible Vault tramite API REST senza errori di vincolo di chiave duplicata. (#3413, #2773)

Pro #

• Integrazione con secret store esterni – recupera i segreti a runtime da HashiCorp Vault, Azure Key Vault, AWS KMS o Bitwarden invece di archiviarli nel database di Semaphore. (#2248, #658)

Enterprise #

• Chiavi di accesso globali – condivide le voci del key store tra progetti senza duplicazione, con gestione centralizzata e collegamento tra progetti. (#110)
• Audit trail per l’accesso ai segreti – registra tutti gli accessi e l’utilizzo delle voci del key store e delle variabili segrete per conformita e analisi forense.

Credenziali per requirements.yml Leggi #

I playbook Ansible dichiarano spesso ruoli e collezioni privati in requirements.yml che risiedono in repository Git privati. Semaphore attualmente non dispone di un modo nativo per autenticare ansible-galaxy install contro tali repository – gli utenti ricorrono a incorporare token negli URL, integrare chiavi SSH nelle immagini dei runner o mantenere script di preparazione personalizzati. Questa funzionalita consente agli utenti di allegare una o piu credenziali del key store a un modello di attivita (o a un’esecuzione di playbook) e di utilizzarle automaticamente durante la fase di preparazione quando vengono risolti ruoli e collezioni.

Community #

• Allegare credenziali a un’esecuzione di playbook – consente di selezionare una o piu voci del key store (chiave SSH, token Git, nome utente/password) su un modello di attivita che vengono applicate durante ansible-galaxy install cosi che i ruoli e le collezioni privati elencati in requirements.yml possano essere recuperati da repository Git privati. (#3677, #3708, #897)
• Mappatura delle credenziali per pattern di host – quando sono allegate piu credenziali, le mappa a pattern di hostname (ad esempio, github.com, gitlab.internal) cosi che ogni origine privata utilizzi la chiave o il token corretto senza collisioni. (#3677)
• Correzione della propagazione delle variabili di ambiente alla fase di galaxy install – assicura che le variabili di ambiente (incluse quelle segrete) vengano esportate durante ansible-galaxy install, non solo durante l’esecuzione del playbook, cosi che l’autenticazione basata su token funzioni per requirements.yml. (#2966, #3178)
• File requirements per playbook – consente di sovrascrivere il percorso predefinito roles/requirements.yml / collections/requirements.yml a livello di modello per i progetti che raggruppano piu playbook con diversi set di dipendenze. (#1366)
• Argomenti CLI ansible-galaxy personalizzati – espone un campo per argomenti aggiuntivi passati a ansible-galaxy install (ad esempio, --ignore-certs, --force, server personalizzato), coprendo configurazioni air-gapped e mirror Galaxy interni. (#2348)

Cache persistente del repository #

Attualmente, Semaphore clona (o esegue il pull) del repository in una directory separata per ogni modello di attivita, il che puo essere lento per repository di grandi dimensioni e spreca operazioni di I/O su disco. Questa funzionalita aggiunge un flag per repository che passa a un clone condiviso e persistente, aggiornato periodicamente in background – simile a come AWX gestisce gli aggiornamenti dei progetti. Quando abilitato, tutti i modelli che fanno riferimento al repository condividono una singola copia di lavoro (lo stesso modello gia utilizzato per i repository locali in Semaphore), e le singole esecuzioni delle attivita non attivano piu un clone o un pull.

Community #

• Flag “Cache Repository” nelle impostazioni del repository – aggiunge un toggle a ciascun repository che, quando abilitato, mantiene un singolo clone persistente invece di clonare per ogni esecuzione di attivita. Il clone e condiviso tra tutti i modelli che utilizzano il repository, replicando il comportamento gia presente per i repository locali. (#1212)
• Sincronizzazione periodica in background – quando il flag della cache e abilitato, esegue il pull degli aggiornamenti a un intervallo configurabile (ad esempio, ogni 5 minuti) in un worker in background anziche all’avvio dell’attivita, cosi che le attivita vengano sempre avviate istantaneamente su un checkout recente.
• Azione di sincronizzazione manuale – fornisce un pulsante “Sincronizza ora” nell’interfaccia del repository e un endpoint API corrispondente per attivare un pull immediato al di fuori della pianificazione periodica.
• Resilienza a force-push / riscrittura della cronologia – gestisce i force-push upstream in modo corretto (ad esempio, git fetch --all && git reset --hard origin/<branch>) invece di fallire con un pull normale. (#800)
• Recupero dell’albero di lavoro sporco – rileva e pulisce automaticamente un albero di lavoro sporco (ad esempio, file .retry residui) prima del pull, prevenendo errori di “modifiche locali”. (#308)
• Pulizia dei cloni obsoleti – raccolta dei cloni nella cache per repository che sono stati eliminati o il cui URL e cambiato, recuperando spazio su disco. (#1497, #2679)
• Visibilita dello stato di sincronizzazione – mostra il timestamp e lo stato dell’ultima sincronizzazione (successo/fallimento) nella pagina dei dettagli del repository, cosi che gli utenti sappiano quanto e aggiornata la copia di lavoro.
• Pianificazione di sincronizzazione per repository – consente di sovrascrivere l’intervallo di sincronizzazione globale sui singoli repository (ad esempio, repository ad alto tasso di modifiche ogni minuto, repository stabili ogni ora).

Inventari multipli per modello #

La CLI di Ansible supporta nativamente il passaggio di piu argomenti -i per comporre inventari (ad esempio, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Semaphore attualmente limita ogni modello di attivita a un singolo inventario, costringendo gli utenti a soluzioni alternative come script di inventario, file uniti o variabili di ambiente aggiuntive. Questa funzionalita rimuove tale restrizione e affronta l’insieme piu ampio di lacune nella gestione dell’inventario.

Community #

• Supporto multi-inventario – consente di allegare piu inventari a un singolo modello di attivita, passati come argomenti -i sequenziali ad Ansible (ad esempio, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Risolve la limitazione di un inventario per modello. (#2093)
• Campo inventario opzionale – rende il campo inventario nei modelli opzionale per i casi in cui ansible.cfg specifica gia l’origine dell’inventario. (#1574)
• Origine inventario URL/HTTP – supporta il recupero dell’inventario da un URL remoto o un endpoint API, essenziale per ambienti ospitati/SaaS senza accesso al filesystem. (#1924)
• Selezione dell’inventario a runtime – consente agli utenti di selezionare un inventario al momento dell’avvio dell’attivita tramite un menu a discesa, sostituendo l’attuale soluzione alternativa con testo libero. (#1354)
• Correzione della persistenza dell’inventario nelle attivita pianificate – assicura che l’inventario selezionato nella finestra di pianificazione venga salvato e utilizzato al momento dell’esecuzione, invece di tornare al modello predefinito. (#3566, #3293)
• Correzione dell’esportazione/ripristino del progetto che perde il collegamento al repository dell’inventario – le associazioni inventario-repository vengono perse durante l’esportazione del progetto e non ripristinate all’importazione. (#3369, #3177)
• Passaggio delle variabili di ambiente all’inventario dinamico – assicura che le variabili di ambiente container/host siano disponibili per script e plugin di inventario dinamico (ad esempio, script Python, microsoft.ad.ldap). (#2724, #2783)
• Correzione dell’autenticazione dell’inventario basato su git – utilizza le credenziali del repository durante il recupero dei branch remoti per l’inventario, correggendo i tentativi di accesso non autenticati. (#3539)
• Override delle credenziali per host – impedisce l’override di ansible_user per host e delle variabili di connessione definite nell’inventario con --extra-vars globali. Consente pattern di inventario multi-utente. (#1464, #1621)
• Visualizzazione del contenuto dell’inventario nell’interfaccia – visualizza i contenuti dell’inventario basato su file e dinamico nell’interfaccia per ispezione e debug, con un collegamento al file sorgente nel repository esterno. (#3169, #1555, #3543)
• Esposizione del nome dell’inventario nel contesto dell’attivita – rende il nome dell’inventario disponibile in semaphore_vars o come variabile di ambiente cosi che i playbook possano fare riferimento all’inventario attivo. (#1580)

Pro #

• Affinita inventario-runner – associa gli host dell’inventario ai tag dei runner cosi che le attivita vengano inviate solo ai runner con accesso di rete agli host di destinazione, evitando fallimenti in ambienti multi-rete. (#3322)
• Chiavi SSH multiple per inventario – consente di assegnare piu voci del key store a un singolo inventario per flotte in cui ogni host utilizza una chiave SSH univoca. (#3336)
• Integrazione inventario con hypervisor – integrazione nativa con le API degli hypervisor (VMware, Proxmox) per generare e aggiornare automaticamente gli inventari dinamici. (#2709)
• API di gestione dei gruppi host – fornisce un’API per aggiungere/rimuovere host dai gruppi di inventario senza riscrivere l’intero payload dell’inventario. (#1560)

Enterprise #

• Limitazione degli inventari consentiti per modello – quando un modello ha abilitato “chiedi l’inventario”, limita gli inventari selezionabili a una lista consentita definita dall’amministratore, prevenendo il targeting accidentale di ambienti errati. (#3587)
• Registro host centrale – fornisce un livello di gestione host condiviso cosi che le modifiche agli host (ad esempio, aggiornamenti di hostname o IP) si propaghino a tutti gli inventari che fanno riferimento a quell’host senza modifiche manuali. (#564)
• Archiviazione e visualizzazione dei fatti sugli host – archivia i fatti Ansible per host e visualizza lo stato prima/dopo le esecuzioni delle attivita con funzionalita di diff e cronologia. (#930)