{"id":35513,"date":"2019-10-31T22:04:46","date_gmt":"2019-10-31T19:04:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira\/"},"modified":"2019-10-31T22:04:46","modified_gmt":"2019-10-31T19:04:46","slug":"ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","title":{"rendered":"Ansible: aggiornamenti nelle soluzioni chiave per automatizzare il tuo mondo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La comunit\u00e0 Ansible offre costantemente nuovo contenuto - plugin e moduli - creando cos\u00ec molto lavoro per chi si occupa del supporto di Ansible, poich\u00e9 il nuovo codice deve essere integrato il pi\u00f9 rapidamente possibile nei repository. Non sempre \u00e8 facile rispettare le scadenze e il rilascio di alcuni prodotti pronti viene rinviato alla prossima versione ufficiale di Ansible Engine. Fino a poco tempo fa, l'unico modo per gli utenti finali di ottenere nuovo contenuto Ansible era attraverso una nuova versione di Ansible Engine.<\/p>\n

\"Ansible:
\n
\nPer alleviare questo inconveniente, la comunit\u00e0 Ansible ha iniziato a lavorare su opzioni pi\u00f9 flessibili per la creazione e l'ottenimento di contenuti.
\n<\/a><\/noindex><\/p>\n

Red Hat Ansible Engine 2.8: verso nuovi metodi di gestione del contenuto Ansible<\/h3>\n

\nIn risposta alle richieste degli utenti, Ansible Engine 2.8 ha introdotto modifiche riguardanti la gestione dei contenuti, non inclusi nell'uscita ufficiale<\/b>. Queste modifiche consentiranno di implementare un nuovo metodo di distribuzione dei contenuti agli utenti, che non dipender\u00e0 dai manutentori di Ansible nella gestione sia del contenuto Ansible che del codice stesso della piattaforma.<\/p>\n

\u00c8 previsto che nelle future versioni i creatori di contenuti possano fornire i loro materiali sotto forma di pacchetti speciali, noti come Collezioni, che potranno essere installati nella posizione appropriata per l'esecuzione sul nodo principale Ansible (control node) o sul nodo gestito (managed node). Il creatore delle collezioni definir\u00e0 direttamente i dettagli dell'esecuzione all'interno del pacchetto utilizzando ruoli e playbook. Grazie alle modifiche menzionate in Ansible Engine, le collezioni diventeranno uno degli strumenti che permetteranno di dissociare il rilascio dei contenuti dal rilascio delle versioni ufficiali di Ansible Engine.<\/b>.<\/p>\n

La nuova struttura Become<\/h4>\n

\nLa struttura Become \u00e8 stata introdotta da tempo, ma a partire dalla versione 2.8 la parola BECOME \u00e8 utilizzata di default in Ansible Engine per richiedere la password durante l'innalzamento dei privilegi (privilegi sudo su sistemi *nix o modalit\u00e0 enable su dispositivi di rete). In altre parole, ora BECOME \u00e8 lo strumento standard per l'innalzamento dei diritti, che gestisce autonomamente il sistema target.<\/p>\n

Ecco come appare un esempio del suo utilizzo:<\/p>\n

ansible-playbook --become --ask-become-pass site.yml\nBECOME password:\n<\/code><\/pre>\n
\nInoltre, in Ansible Engine 2.8 \u00e8 stato introdotto il plugin BECOME, che funziona come doas su Linux e come runas su Windows, e consente di eseguire azioni a nome di un utente specifico. Per l'elevazione dei privilegi sui dispositivi di rete si utilizza il plugin become enable.<\/p>\n
Ricerca dell'interprete Python<\/h4>\n
\nPotresti aver incontrato un errore simile a questo:<\/p>\n
\/usr\/bin\/python: bad interpreter: No such file or directory\n<\/code><\/pre>\n
\nIl fatto \u00e8 che nelle versioni precedenti di Ansible Engine si presumeva per default che l'interprete Python principale (quello utilizzato per default) fosse situato nella cartella \/usr\/bin\/python. A partire dalla versione 2.8, Ansible cerca l'interprete su ogni sistema target, inizialmente confrontandosi con la tabella dei percorsi e dei nomi dei file eseguibili dell'interprete Python principale in diverse distribuzioni, e poi utilizzando elenchi ordinati di interpreti di riserva (fallback list), ulteriori dettagli possono essere trovati in Guida al porting su Ansible 2.8<\/a><\/noindex>.<\/p>\n
I file di retry non vengono pi\u00f9 creati di default<\/h4>\n
\nHai cercato a lungo file .retry sul disco? Se hai utilizzato Ansible per un po', sicuramente ce ne sono molti e occupano solo spazio utile. A partire dalla versione 2.8, Ansible Engine non crea pi\u00f9 questi file di default (cosa che pu\u00f2 essere annullata modificando il file ansible.cfg di default utilizzato).<\/p>\n
Play Recap aggiornato<\/h4>\n
\nEstratto da Guida al porting su Ansible 2.8<\/a><\/noindex>:<\/p>\n
Play Recap ora considera i task con stato ignored e rescued, oltre a ok, changed, unreachable, failed e skipped, grazie a due nuovi contatori statistici nel callback plugin default. I task failed a cui \u00e8 stato impostato il flag ignore_errors: yes vengono considerati come ignored. I task failed per i quali \u00e8 stata poi eseguita la sezione rescue vengono considerati come rescued. Si noti che, a differenza delle versioni precedenti di Ansible, i task rescued non vengono pi\u00f9 conteggiati come failed.<\/p><\/blockquote>\n
\nE nella tabella Play Recap alla fine dell'esecuzione del playbook sono apparse colonne aggiuntive per i host: skipped, rescued e ignored:<\/p>\n
\"Ansible:<\/p>\n
Cloud e container<\/h4>\n
\nNella versione 2.8 sono stati implementati miglioramenti e aggiunte nei moduli cloud e container per lavorare con Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman<\/a><\/noindex> e kubevirt<\/a><\/noindex>. \u00c8 anche importante notare che i file TOML possono ora essere utilizzati come sorgente inventory.<\/p>\n
Paramiko<\/h4>\n
\nStai utilizzando Red Hat Ansible Network Automation? Ansible Engine 2.8 non contiene pi\u00f9 paramiko e non dipende pi\u00f9 da esso. Di default, Ansible Engine utilizza ssh. Se hai bisogno di paramiko, puoi installarlo con il comando pip install paramiko<\/p>\n
Se hai bisogno di supporto per l'utilizzo di paramiko nell'ambito dell'abbonamento Red Hat, fai riferimento all'articolo della base di conoscenza Pacchetto Paramiko mancante dopo nuove installazioni di Ansible Engine<\/a><\/noindex>.<\/p>\n
Pertanto, la nuova versione di Red Hat Ansible Engine si arricchisce di un'impressionante lista di miglioramenti e modifiche, di cui puoi prendere visione qui<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5: maggiore automazione<\/h3>\n
\nDalla fine di maggio \u00e8 disponibile anche la nuova versione di Red Hat Ansible Tower 3.5, che offre subito diversi importanti miglioramenti per l'automazione, di cui parleremo, se non hai gi\u00e0 avuto modo di controllarli.<\/p>\n
Quindi, iniziamo con i punti chiave:<\/p>\n