Utilizzo dell'inventario constructed, una nuova funzione di Ansible Automation Platform 2.4

La nuova funzione inventario constructed

In un precedente articolo del blog avevamo presentato l'idea di un metodo più intelligente per la gestione dell'inventario, basato sul plugin constructed di Ansible. Ora il metodo è incluso in Ansible Automation Platform 2.4 come funzione completamente supportata. Questo articolo del blog ha lo scopo di presentarlo. 

L'inventario constructed è il successore della funzione inventario smart ed  è quindi un'ulteriore scelta per la creazione di un inventario in un controller Ansible Automation Platform. La funzione utilizza come input un elenco di inventari "normali", esegue operazioni definite dall'utente, applica i filtri e permette di ottenere un inventario con i contenuti degli inventari di input.

Cos'è l'inventario constructed?

L'inventario constructed è simile all'inventario smart già esistente, in quanto consente agli utenti di eseguire i processi sugli host in più inventari. 

Il nuovo inventario introduce però ulteriori funzionalità, inclusa la capacità integrata di definire e utilizzare hostvars e groupvars:

• L'inventario constructed prevede i gruppi, che svolgono un ruolo chiave nella sua configurazione.
• La logica definita dall'utente (per aggiungere gruppi e variabili e selezionare gli host) viene eseguita tramite ansible-inventory (sarà il controller a farlo per te)e viene visualizzata nell'interfaccia utente tramite un aggiornamento dell'inventario.
• Il formato della logica definita dall'utente è il diffuso jinja2, in stile Ansible.

Il principio chiave per creare un inventario constructed è quello di utilizzare lo stesso approccio usato per la scrittura dei playbook, al contrario di quanto avviene con l'inventario smart, in cui dobbiamo immaginare l'inventario dal punto di vista dell'applicazione.

Inventario constructed nell'interfaccia utente

Dopo aver fatto clic su "Add constructed inventory" in Inventories, visualizzerai il menu:

Potrai notare tre voci esclusive dell'inventario constructed.

• In Input inventories puoi elencare gli inventari esistenti dai quali l'inventario constructed acquisisce i contenuti (host, gruppi, e così via).
• Il valore Limit viene passato direttamente ad ansible-inventory e permette di filtrare gli host utilizzando la sintassi standard dei modelli di host Ansible.
• Source vars è l'input per il plugin di inventario ansible.builtin.constructed.

NOTA: gli inventari di input sono ordinati in modo che in caso di conflitto tra nome host e variabile, prevalgano le variabili dell'ultimo inventario. Le variabili vengono unite per non disabilitare una variabile di un inventario di input precedente. Questa nota non ha rilevanza se non ci sono conflitti tra i nomi degli host, come nel nostro esempio.

Non preoccuparti troppo di questi aspetti, perché li esamineremo meglio in un esempio più avanti.

Inventario constructed in forma semplice

È necessario avere almeno un inventario di input, ma non occorre compilare gli altri campi. In alcuni casi può essere utile fornire due o più inventari di input e lasciare vuoti i campi limit e source-vars. Potrai quindi eseguire processi che agiscono sulla combinazione dei contenuti dell'inventario acquisiti da entrambi gli inventari di input. 

Scenari di utilizzo più avanzati dell'inventario constructed

Per spiegare la funzione delle variabili limit e source, che offrono grandi potenzialità alla funzione, è utile procedere con un esempio concreto.

Configurazione dell'inventario constructed

Immagina di avere due inventari che provengono dallo stesso provider di servizi cloud, ma che coprono aree geografiche diverse e hanno quindi diversi set di host. Questi inventari vengono mantenuti separati, perché hanno account, funzioni e posizioni separate. Nel nostro esempio immaginiamo semplici inventari di input per le regioni East/West.

Gli inventari provengono da file .ini Git, gestiti con un approccio config-as-code che utilizza procedure di tipo devops.

Innanzitutto configura un nuovo progetto e sincronizzalo in modo da sapere dove reperire le informazioni sull'inventario. Nell'interfaccia utente seleziona Projects e fai clic su Add:

Una volta compilato e salvato, il progetto viene sincronizzato automaticamente:

Ora creiamo i nuovi inventari che faranno riferimento alle informazioni dei file del progetto. In Inventories, fai clic su Create:

Ora fai clic su Inventory Sources e Add:

Fornisci un Nome per questa sorgente, in questo caso per gli host East Region, definisci Source come Sourced from a Project, e indica al progetto appena aggiunto il file sorgente east.ini appropriato:

Dopo aver salvato, fai clic sul pulsante Sync per inserire le informazioni:

Terminata la sincronizzazione, potrai vedere il risultato dell'elaborazione visualizzando l'output del processo:

In questo caso, puoi notare che sono stati rilevati e aggiunti automaticamente 3 host e 3 gruppi. Queste informazioni sono visualizzate nell'interfaccia utente, in Hosts.

Ora applichiamo la stessa procedura per gli host West Region. Completa questo esercizio seguendo l'esempio precedente, ma utilizza le informazioni del file west.ini come sorgente.

In questo scenario ipotetico, vorremmo eseguire i processi su alcuni host delle regioni East e West contemporaneamente, in base a criteri che definiremo.

Creiamo un nuovo inventario constructed nell'interfaccia utente:

Come input, aggiungiamo entrambi gli inventari cloud. Utilizzeremo source-vars per creare un nuovo gruppo "target_group", quindi limit per applicare un filtro su quel gruppo:

Dopo la sincronizzazione, puoi vedere il risultato dell'elaborazione visualizzando l'output del processo:

Abbiamo quindi 4 gruppi con 4 host, che puoi visualizzare nell'interfaccia utente, in Host e Groups, per confermare il risultato. Diamo un'occhiata ai gruppi di questo particolare esempio:

Durante l'aggiornamento dell'inventario constructed, i gruppi "account_1234", "account_4321" e "account" sono stati copiati dagli inventari di input all'inventario constructed risultante. 

Vediamo anche che l'inventario constructed include il gruppo "target_group", di cui parleremo tra poco.

Se l'inventario constructed è stato utilizzato da un modello di processo per eseguire un processo, qualsiasi gruppo tra quelli definiti potrà essere utilizzato dal processo.

Ed ecco la magia: facendo riferimento a source-vars nel modulo dell'inventario constructed, puoi trovare la definizione del nuovo gruppo target_group".

     plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev" 

Il "target_group" non era presente negli inventari East e West originali. È stato creato dal plugin dell'inventario constructed al momento dell'aggiornamento. 

In questo caso, gli host vengono aggiunti al gruppo quando il modello jinja2 {{ account_alias | default("") == "product_dev" }} si risolve in un valore true (come 1, "1" o True) per un determinato host. 

Durante l'aggiornamento, Ansible esegue il rendering di questi modelli affinché ogni host negli inventari di input esegua le valutazioni. Per gli inventari di input di maggiori dimensioni, il completamento dell'aggiornamento può richiedere alcuni minuti. 

Gli inventari constructed vengono aggiornati automaticamente prima dell'esecuzione di un processo di qualsiasi modello che lo utilizza; se gli aggiornamenti richiedono troppo tempo, puoi ridurne la frequenza con l'opzioneUpdate cache timeout nelle impostazioni dell'inventario constructed nell'interfaccia utente. Impostando questa opzione su un valore > di 1, i risultati dell'aggiornamento dell'inventario vengono memorizzati nella cache per il numero di secondi indicato.

Il modello jinja2 che crea "target_group" includerà un host se, durante l'ispezione di tale host, la hostvar di "account_alias” esiste ed è uguale a "product_dev". 

La sintassi "| default" è necessaria nel caso in cui la variabile non sia definita per alcuni host. 

La sintassi "strict: true" indica che la presenza di un riferimento a una variabile non definita impedirà la riuscita dell'aggiornamento dell'inventario, rendendo "| default" necessario. 

Per forzare l'esplicitazione del caso non definito, è quindi consigliabile utilizzare "|default| e il parametro strict.

La creazione di gruppi è un metodo utile per aggiungere all'istante gruppi a cui possono fare riferimento i playbook. A cosa può servire? A volte è utile semplificare i gruppi dalle hostvars, perché con i gruppi puoi eseguire operazioni non eseguibili con le hostvars, come utilizzare i modelli nell'host, come facciamo con limit in questo esempio. 

Osserviamo tutti gli host generati per il nostro inventario constructed:

In questo esempio possiamo vedere che host3 nell'inventario east e host5 nell'inventario west non sono inclusi. Questo accade perché, negli inventari di input, si trovano in un account diverso (account_4321) che ha un "alias_account" non corrispondente al valore "product_dev" specificato. Anche se il gruppo dell'account_4321 è stato importato nell'inventario constructed, nessun host di quel gruppo ha soddisfatto il nostro requisito. Perciò nell'inventario constructed il gruppo importato è vuoto.

L'input delle variabili source può includere variabili host, oltre ad aggiungere gruppi.

Il repository Github di Alan contiene anche un altro esempio che potresti trovare utile. In construct.yml risolviamo lo "stato" di un host e lo assegniamo a un numero di gruppi in funzione del fatto che l'host sia stato arrestato o sia parte di un ambiente specifico (dev). La sorgente di questo file .yml può provenire da altri sistemi esterni ad Ansible Automation Platform e può essere utilizzata per eseguire all'istante processi di automazione su sottoinsiemi di host.

Suggerimenti per il debug

Per utilizzare l'esempio precedente, durante lo sviluppo dell'inventario constructed valuta se eliminare il valore limit e modificare le variabili source con il contenuto seguente.

Viene eseguito un modello simile a {{ account_alias | default(“”) }} che sarà salvato in una variabile denominata "effective_account_alias". Se limit è vuoto, saremo sicuri di ottenere tutti gli host dagli inventari di input. In questo modo potremmo esaminare i dettagli dei criteri di inclusione dei singoli host, come quelli mostrati di seguito per host3.

In questo caso, il valore "effective_account_alias" elaborato per hostvar è "sustaining" e non "product_dev". 

Il plugin dell'inventario constructed presenta numerose altre opzioni molto utili ed efficienti. Consulta la documentazione del plugin all'indirizzo https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html per ulteriori dettagli.

Altri esempi sono reperibili nella guida utente all'indirizzo https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed

Riepilogo

Mi auguro di aver fornito un quadro sull'utilizzo pratico dell'inventario constructed in Ansible Automation Platform. 

Poiché i concetti alla base, come il modello di host e il plugin dell'inventario constructed, sono concetti generali di Ansible, gli utenti potranno aggiungere gruppi, variabili o includere host scegliendo liberamente criteri complessi.

I vantaggi includono:

• La possibilità di creare gruppi in modo dinamico da più fonti di attendibilità.
• La possibilità di filtrare, analizzare e limitare gli host da più inventari, consentendone tuttavia l'utilizzo nei processi di automazione.
• La possibilità di utilizzare hostvars predefinite durante l'applicazione dei filtri.
• Ogni team può disporre di un proprio inventario e dei metadati associati ai propri host, utilizzandoli in maniera centralizzata tramite Ansible Automation Platform.