block<\/code> e cos\u00ec via. Pi\u00f9 conosci Ansible, pi\u00f9 sfumature potrai identificare per una soluzione \"astuta\". E una soluzione semplice \u2014 utilizzare una separazione naturale tra pre\/roles\/post \u2014 non comporta sfumature.<\/p>\n<\/p>\n
E torniamo al nostro 'foo'. Dove collocarlo? In pre, post o in roles? Ovviamente, dipende se abbiamo bisogno dei risultati del gestore per foo. Se non servono, allora foo non deve essere posizionato n\u00e9 in pre n\u00e9 in post: queste sezioni hanno un significato specifico \u2014 l'esecuzione dei task prima e dopo l'array di codice principale.<\/p>\n
<\/p>\n
Ora la risposta alla domanda \"ruolo o task\" dipende da ci\u00f2 che \u00e8 gi\u00e0 presente nel play: se ci sono tasks, allora bisogna aggiungere nei tasks. Se ci sono roles, bisogna creare un ruolo (anche se composto da un solo task). Ricordo che tasks e roles non vengono usati insieme.<\/p>\n
<\/p>\n
La comprensione delle basi di Ansible fornisce risposte ben fondate a quelle che sembrano domande soggettive.<\/p>\n
<\/p>\n
Tasks e ruoli (parte seconda)<\/h1>\n <\/p>\n
Discutiamo ora la situazione in cui stai iniziando a scrivere un playbook. Devi fare foo, bar e baz. Sono tre task, un ruolo o tre ruoli? In sintesi, quando dovresti iniziare a scrivere ruoli? Qual \u00e8 il significato di scrivere ruoli quando puoi scrivere task? \u2026 E cos'\u00e8 un ruolo?<\/p>\n
<\/p>\n
Uno degli errori pi\u00f9 gravi (ne ho gi\u00e0 parlato) \u00e8 considerare che un ruolo sia come una funzione in una libreria di un programma. Come appare la descrizione generalizzata di una funzione? Essa accetta argomenti in input, interagisce con cause collaterali, produce effetti collaterali e restituisce un valore.<\/p>\n
<\/p>\n
Ora, attenzione. Cosa si pu\u00f2 fare in un ruolo? Chiamare side effects \u2014 sempre, \u00e8 proprio questo il senso di Ansible: generare side effects. Avere side causes? Elementare. Ma con \"passare un valore e restituirlo\" \u2014 qui non \u00e8 possibile. In primo luogo, non potete passare un valore a un ruolo. Potete impostare una variabile globale con una durata pari al play nella sezione vars per il ruolo. Potete impostare una variabile globale con una durata nel play all'interno del ruolo. O addirittura con una durata dell'intero playbook.set_fact<\/code>\/register<\/code>). Ma non puoi avere "variabili locali". Non puoi "assumere un valore" e "restituirlo".<\/p>\n<\/p>\n
Questo porta alla conclusione principale: non si pu\u00f2 scrivere nulla in ansible senza generare side effects. La modifica delle variabili globali \u00e8 sempre un side effect per una funzione. In Rust, per esempio, cambiare una variabile globale \u00e8 unsafe<\/code>. E in Ansible \u2014 l'unico modo per influenzare i valori per il ruolo. Nota le parole utilizzate: non "passare un valore al ruolo", ma "modificare i valori che utilizza il ruolo". Non c'\u00e8 isolamento tra i ruoli. Non c'\u00e8 isolamento tra i task e i ruoli.<\/p>\n<\/p>\n
In totale: il ruolo non \u00e8 una funzione<\/strong>.<\/p>\n<\/p>\n
Quali sono i vantaggi di un ruolo? Innanzitutto, un ruolo ha dei valori predefiniti (\/default\/main.yaml<\/code>), in secondo luogo, un ruolo dispone di cataloghi aggiuntivi per l'archiviazione dei file.<\/p>\n<\/p>\n
Quali sono dunque i vantaggi dei valori predefiniti? Nel contesto piuttosto distorto della piramide di Maslow riguardante le priorit\u00e0 delle variabili in Ansible, i valori predefiniti dei ruoli sono i meno prioritari (esclusi i parametri della riga di comando di Ansible). Ci\u00f2 significa che se devi fornire valori predefiniti senza preoccuparti che possano sovrascrivere i valori delle variabili di inventario o delle variabili di gruppo, i valori predefiniti del ruolo sono l'unico posto giusto per te. (Sto esagerando un po' \u2014 ce ne sono anche altri |d(your_default_here)<\/code>, ma se parliamo di posizioni fisse, allora solo i valori predefiniti dei ruoli).<\/p>\n<\/p>\n
Cosa rende ancora migliori i ruoli? Il fatto che abbiano i propri cataloghi. Si tratta di cataloghi per le variabili, sia statiche (ossia calcolate per il ruolo) che dinamiche (c'\u00e8 un certo pattern o anti-pattern chiamato \u2014 include_vars<\/code> insieme a {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). Questi sono cataloghi per files\/<\/code>, templates\/<\/code>. Inoltre, consente ai ruoli di avere i propri moduli e plugin (library\/<\/code>). Ma, rispetto ai task nel playbook (che pu\u00f2 avere anche tutto questo), il vantaggio qui \u00e8 solo che i file non sono accumulati in un unico posto, ma in diverse pile separate.<\/p>\n<\/p>\n
Un altro aspetto: si possono cercare di realizzare ruoli che saranno disponibili per il riutilizzo (tramite galaxy). Dopo l'introduzione delle raccolte, la distribuzione dei ruoli pu\u00f2 considerarsi quasi dimenticata.<\/p>\n
<\/p>\n
Cos\u00ec, i ruoli presentano due caratteristiche importanti: hanno dei valori predefiniti (una caratteristica unica) e permettono di strutturare il codice.<\/p>\n
<\/p>\n
Tornando alla domanda originale: quando utilizzare i task e quando i ruoli? I task nel playbook sono spesso usati o come \"colla\" prima\/dopo i ruoli, oppure come elementi costitutivi autonomi (in tal caso nel codice non dovrebbero esserci ruoli). Una mescolanza di task normali con i ruoli \u00e8 decisamente disordinata. \u00c8 necessario mantenere uno stile specifico: o task, o ruoli. I ruoli offrono una separazione delle entit\u00e0 e valori predefiniti, i task permettono di leggere il codice pi\u00f9 rapidamente. Di solito, nei ruoli si colloca codice pi\u00f9 \"stazionario\" (importante e complesso), mentre nello stile dei task si scrivono script ausiliari.<\/p>\n
<\/p>\n
\u00c8 possibile fare l'importazione di un ruolo come attivit\u00e0, ma se lo fai, preparati a giustificare il tuo bisogno di farlo.<\/p>\n
<\/p>\n
Un lettore pignolo potrebbe dire che i ruoli possono importare ruoli, che i ruoli possono avere una dipendenza tramite galaxy.yml, e c'\u00e8 anche il terribile e spaventoso include_role<\/code> \u2014 ricordo che stiamo migliorando le competenze di base in Ansible, non nella ginnastica ritmica.<\/p>\n<\/p>\n
Gestori e attivit\u00e0<\/h1>\n <\/p>\n
Discutiamo un'altra cosa ovvia: i gestori. Saperli usare correttamente \u00e8 quasi un'arte. Qual \u00e8 la differenza tra un gestore e un'attivit\u00e0?<\/p>\n
<\/p>\n
Poich\u00e9 stiamo rinfrescando le basi, ecco un esempio:<\/p>\n
<\/p>\n
- hosts: group1\n tasks:\n - foo:\n notify: handler1\n handlers:\n - name: handler1\n bar:<\/code><\/pre>\n<\/p>\n
Nei ruoli, i handler si trovano in rolename\/handlers\/main.yaml. Gli handler vengono condivisi tra tutti i partecipanti al play: pre\/post_tasks possono richiamare gli handler del ruolo, mentre il ruolo pu\u00f2 richiamare gli handler dal play. Tuttavia, le chiamate agli handler \"cross-ruolo\" suscitano molto pi\u00f9 wtf rispetto alla ripetizione triviale di un handler. (Un altro elemento delle best practices \u00e8 cercare di evitare ripetizioni nei nomi degli handler).<\/p>\n
<\/p>\n
La principale differenza \u00e8 che un'attivit\u00e0 viene eseguita (idempotentemente) sempre (pi\u00f9\/meno tag e when<\/code>), e un handler \u2014 per la modifica dello stato (notify si attiva solo se \u00e8 stato cambiato). Qual \u00e8 il rischio? Ad esempio, se al successivo avvio non c'\u00e8 stato nessun cambiamento, allora non ci sar\u00e0 nemmeno l'handler. Perch\u00e9 potremmo avere bisogno di eseguire l'handler quando non ci sono stati cambiamenti nel task generante? Ad esempio, perch\u00e9 qualcosa \u00e8 andato storto e c'\u00e8 stato un cambiamento, ma l'esecuzione non \u00e8 arrivata all'handler. Ad esempio, perch\u00e9 la rete era momentaneamente gi\u00f9. La configurazione \u00e8 cambiata, ma il servizio non \u00e8 stato riavviato. Al successivo avvio, la configurazione non cambier\u00e0 pi\u00f9 e il servizio rimarr\u00e0 con la vecchia versione della configurazione.<\/p>\n<\/p>\n
La situazione con la configurazione non \u00e8 risolvibile (o meglio, si potrebbe inventare un protocollo speciale di riavvio con flag di file e simili, ma questo non \u00e8 pi\u00f9 'basic ansible' in nessun modo). Tuttavia, c'\u00e8 un'altra storia comune: abbiamo installato un'applicazione, l'abbiamo registrata. .service<\/code>-file, e ora vogliamo daemon_reload<\/code> e state=started<\/code>. E il posto naturale per questo sembra essere il handler. Ma se lo rendi non un handler ma un task alla fine della lista dei task o una funzione, allora verr\u00e0 eseguito idempotentemente ogni volta. Anche se il playbook si \u00e8 interrotto a met\u00e0. Questo non risolve affatto il problema di restarted (non puoi impostare un task con l'attributo restarted, poich\u00e9 si perde l'idempotenza), ma \u00e8 sicuramente utile impostare state=started, in quanto la stabilit\u00e0 complessiva del playbook aumenta, poich\u00e9 si riducono le interconnessioni e lo stato dinamico.<\/p>\n<\/p>\n
Un'altra caratteristica positiva del handler \u00e8 che non intasa l'output. Se non ci sono state modifiche, non ci sono output aggiuntivi come skipped o ok, il che rende la lettura pi\u00f9 facile. Tuttavia, questo \u00e8 anche un difetto: se trovi un errore di battitura in un task eseguito linearmente al primo tentativo, gli handlers verranno eseguiti solo se ci sono stati cambiamenti, ovvero in determinate condizioni \u2014 molto raramente. Ad esempio, la prima volta nella vita dopo cinque anni. E, naturalmente, ci sar\u00e0 un errore nel nome e tutto si romper\u00e0. La seconda volta non si pu\u00f2 riavviare \u2014 non ci sono cambiamenti.<\/p>\n
<\/p>\n
\u00c8 importante considerare la disponibilit\u00e0 delle variabili. Ad esempio, se si utilizza notify per un'attivit\u00e0 con ciclo, quali variabili saranno disponibili? Si pu\u00f2 dedurre analiticamente, ma non \u00e8 sempre banale, specialmente se le variabili provengono da fonti diverse.<\/p>\n
<\/p>\n
\u2026 Quindi, gli handlers sono molto meno utili e molto pi\u00f9 problematici di quanto sembri. Se \u00e8 possibile scrivere qualcosa di bello (senza trucchi) senza handlers, \u00e8 meglio farlo senza di essi. Se non riesci a farlo bene, \u00e8 meglio usarli.<\/p>\n
<\/p>\n
Un lettore attento fa giustamente notare che non abbiamo discusso listen<\/code>, che un handler pu\u00f2 chiamare notify per un altro handler, che un handler pu\u00f2 includere import_tasks (che pu\u00f2 utilizzare include_role con with_items), che il sistema di handler in Ansible \u00e8 turing-completo, che gli handler provenienti da include_role si intrecciano curiosamente con gli handler del play, ecc. \u2014 tutto questo chiaramente non \u00e8 \"fondamentale\".<\/p>\n<\/p>\n
Tuttavia, c'\u00e8 un certo WTF che in realt\u00e0 \u00e8 una funzionalit\u00e0 e di cui bisogna tenere conto. Se avete un'attivit\u00e0 che viene eseguita con delegate_to<\/code> e ha un notify, l'handler corrispondente viene eseguito senza delegate_to<\/code>, cio\u00e8 sull'host assegnato al play. (Anche se l'handler, ovviamente, potrebbe avere delegate_to<\/code> anch'esso).<\/p>\n<\/p>\n
Voglio dire due parole sui ruoli riutilizzabili. Prima dell'arrivo delle collezioni, si pensava che fosse possibile creare ruoli universali, che si potessero ansible-galaxy install<\/code> e via. Funziona su tutti i sistemi operativi in tutte le situazioni. Tuttavia, la mia opinione \u00e8 che non funziona. Qualsiasi ruolo con supporto per 100500 casi \u00e8 destinato a essere sommerso da bug corner case. Possono essere mitigati con test approfonditi, ma come per qualsiasi testing, o avete il prodotto cartesiano dei valori in ingresso con una funzione totale, oppure avete \"coperti singoli scenari\". La mia opinione \u00e8 che \u00e8 molto meglio avere un ruolo lineare (complessit\u00e0 ciclomatica 1). include_vars<\/code>, il supporto per 100500 casi \u00e8 destinato ad abissi di bug corner case. Possono essere affrontati con massicci test, ma come per qualsiasi test, o avete un prodotto cartesiano degli input e una funzione totale, oppure \"scenari specifici coperti\". Secondo me, \u00e8 molto meglio se il ruolo \u00e8 lineare (complessit\u00e0 ciclomatica 1).<\/p>\n<\/p>\n
Meno if ci sono (espliciti o dichiarativi \u2014 nella forma when<\/code> in base a un insieme di variabili), migliore \u00e8 il ruolo. A volte \u00e8 necessario fare ramificazioni, ma, ripeto, meno ce ne sono, meglio \u00e8. Quindi, sembra un buon ruolo con galaxy (funziona, giusto!) con una serie di include_vars<\/code> per il set di variabili), tanto migliore \u00e8 il ruolo. A volte \u00e8 necessario fare delle diramazioni, ma, ripeto, meno ce ne sono, meglio \u00e8. Quindi sembra essere un buon ruolo con galaxy (funziona, dopotutto!) con un sacco di when<\/code> pu\u00f2 essere meno preferibile rispetto a un \"proprio\" ruolo di cinque attivit\u00e0. Il momento in cui un ruolo con galaxy \u00e8 migliore \u2014 \u00e8 quando si inizia a scrivere qualcosa. Il momento in cui diventa peggiore \u2014 \u00e8 quando qualcosa si rompe, e sospettate che sia a causa di \"un ruolo con galaxy\". Lo aprite e trovate cinque inclusioni, otto elenchi di attivit\u00e0 e una pila when<\/code>\u2018\u2026 E bisogna capirci dentro. Invece di 5 attivit\u00e0 in un elenco lineare, dove non c'\u00e8 nemmeno nulla da rompere.<\/p>\n<\/p>\n
Nelle parti successive<\/h1>\n <\/p>\n
\nUn po' di inventario, variabili di gruppo, plugin host_group_vars, hostvars. Come legare un nodo gordiano dagli spaghetti. Ambito e precedenza delle variabili, modello di memoria di Ansible. \"Ma dove dobbiamo tenere il nome utente per il database?\".<\/li>\n jinja: {{ jinja }}<\/code> \u2014 nosql notype nosense plastilina morbida. \u00c8 ovunque, anche nei posti in cui non te lo aspetti. Un po' su !!unsafe<\/code> e delizioso yaml.<\/li>\n<\/ul>\nFonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f \u0434\u0435\u043b\u0430\u044e \u043c\u043d\u043e\u0433\u043e \u0440\u0435\u0432\u044c\u044e \u0434\u043b\u044f \u0447\u0443\u0436\u043e\u0433\u043e \u043a\u043e\u0434\u0430 \u043d\u0430 \u0410\u043d\u0441\u0438\u0431\u043b \u0438 \u043c\u043d\u043e\u0433\u043e \u043f\u0438\u0448\u0443 \u0441\u0430\u043c. \u0412 \u0445\u043e\u0434\u0435 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u043e\u0448\u0438\u0431\u043e\u043a (\u043a\u0430\u043a \u0447\u0443\u0436\u0438\u0445, \u0442\u0430\u043a \u0438 \u0441\u0432\u043e\u0438\u0445), \u0430 \u0442\u0430\u043a \u0436\u0435 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0439, \u044f \u043f\u043e\u043d\u044f\u043b \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u043e\u0448\u0438\u0431\u043a\u0443, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0410\u043d\u0441\u0438\u0431\u043b\u0430 \u2014 \u043e\u043d\u0438 \u043b\u0435\u0437\u0443\u0442 \u0432 \u0441\u043b\u043e\u0436\u043d\u043e\u0435, \u043d\u0435 \u043e\u0441\u0432\u043e\u0438\u0432 \u0431\u0430\u0437\u043e\u0432\u043e\u0433\u043e. \u0414\u043b\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u044d\u0442\u043e\u0439 \u0432\u0441\u0435\u043b\u0435\u043d\u0441\u043a\u043e\u0439 \u043d\u0435\u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u043e\u0441\u0442\u0438 \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0410\u043d\u0441\u0438\u0431\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87084","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t