{"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 sorprende costantemente con nuovi contenuti \u2013 plugin e moduli \u2013 creando al contempo molto nuovo lavoro per chi \u00e8 impegnato nella gestione di Ansible, poich\u00e9 il nuovo codice deve essere integrato il pi\u00f9 rapidamente possibile nei repository. Non sempre \u00e8 possibile rispettare le scadenze, e il lancio di alcuni prodotti completamente pronti per il rilascio viene rinviato all'uscita della prossima versione ufficiale di Ansible Engine. Fino a poco tempo fa, l'unico modo per gli utenti finali di ottenere nuovi contenuti Ansible era con il rilascio della nuova versione di Ansible Engine.<\/p>\n

\"Ansible:
\n
\nPer risolvere questi inconvenienti, 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 dei contenuti Ansible<\/h3>\n

\nIn risposta alle richieste degli utenti, in Ansible Engine 2.8 sono state introdotte modifiche relative alla gestione dei contenuti, che non fanno parte del rilascio ufficiale.<\/b>Queste modifiche consentiranno di realizzare un nuovo modo di consegnare contenuti agli utenti, che non dipender\u00e0 da chi gestisce Ansible nella gestione sia dei contenuti Ansible che del codice stesso della piattaforma.<\/p>\n

Si prevede che nelle prossime versioni i Creatori di contenuti potranno fornire il loro lavoro sotto forma di pacchetti speciali, noti come Collezioni, che potranno essere installati nel posto appropriato per l'esecuzione sul nodo principale di Ansible o su un nodo gestito. Il creatore delle collezioni definir\u00e0 direttamente nel pacchetto i dettagli di esecuzione utilizzando ruoli e playbook. Grazie alle suddette modifiche nell'Ansible Engine, le collezioni diventeranno uno degli strumenti che permetteranno di slegare il rilascio dei contenuti dal rilascio delle versioni ufficiali di Ansible Engine<\/b>.<\/p>\n

Nuova costruzione Become<\/h4>\n

\nLa costruzione Become \u00e8 stata introdotta da tempo, ma a partire dalla versione 2.8 la parola BECOME viene utilizzata per impostazione predefinita nell'Ansible Engine per richiedere la password durante l'elevarsi dei privilegi (privilegi sudo nei sistemi *nix o modalit\u00e0 enable sui dispositivi di rete). In altre parole, ora BECOME \u00e8 lo strumento standard per l'elevazione dei privilegi 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, con 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 per conto di un determinato utente. 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 del genere:<\/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 assumeva per impostazione predefinita che l'interprete Python principale (quello utilizzato di default) si trovasse nella cartella \/usr\/bin\/python. A partire dalla versione 2.8, Ansible cerca l'interprete su ciascun sistema target, inizialmente confrontando con la tabella dei percorsi e dei nomi del file eseguibile dell'interprete Python principale in diverse distribuzioni, per poi utilizzare elenchi ordinati di interpreti di riserva (fallback list), per maggiori dettagli, consultare il 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 i file .retry sul disco? Se utilizzi Ansible da un po', probabilmente 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 puoi annullare modificando il file ansible.cfg di default).<\/p>\n
Riepilogo Play aggiornato<\/h4>\n
\nEstratto da Guide per la migrazione a Ansible 2.8<\/a><\/noindex>:<\/p>\n
Il Riepilogo Play ora conta le attivit\u00e0 (tasks) con stato ignored e rescued, oltre a ok, changed, unreachable, failed e skipped, grazie a due nuovi contatori statistici nel plugin di callback default. Le attivit\u00e0 failed, per le quali \u00e8 stato impostato il flag ignore_errors: yes, vengono considerate come ignored. Le attivit\u00e0 failed, per le quali \u00e8 stata successivamente eseguita la sezione rescue, vengono considerate come rescued. Si prega di notare che, a differenza delle versioni precedenti di Ansible, le attivit\u00e0 rescued non vengono pi\u00f9 considerate come failed.<\/p><\/blockquote>\n
\nE nella tabella del Riepilogo Play a seguito dell'esecuzione del playbook sono comparsi colonne aggiuntive per gli host: skipped, rescued e ignored:<\/p>\n
\"Ansible:<\/p>\n
Cloud e container<\/h4>\n
\nNella versione 2.8 sono state implementate migliorie 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>. Inoltre, \u00e8 importante notare che ora si possono utilizzare file TOML come sorgente inventory.<\/p>\n
Paramiko<\/h4>\n
\nUtilizzi Red Hat Ansible Network Automation? Ansible Engine 2.8 non include pi\u00f9 paramiko e non dipende da esso. Per impostazione predefinita, 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'uso di paramiko all'interno della sottoscrizione Red Hat, fai riferimento all'articolo della base di conoscenza Pacchetto paramiko mancante dopo le nuove installazioni di Ansible Engine<\/a><\/noindex>.<\/p>\n
Cos\u00ec, la nuova versione di Red Hat Ansible Engine \u00e8 stata arricchita con un'impressionante lista di miglioramenti e modifiche, che puoi consultare in dettaglio qui<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5: pi\u00f9 automazione<\/h3>\n
\nA partire dalla fine di maggio, \u00e8 disponibile anche la nuova versione Red Hat Ansible Tower 3.5, che offre diversi miglioramenti significativi per l'automazione, di cui parleremo se non hai ancora avuto modo di verificarli di persona.<\/p>\n
Quindi, iniziamo con i punti chiave:<\/p>\n