Se scrivi o usi playbook Ansible, sei abituato a leggere i file di configurazione YAML. YAML può essere ingannevolmente semplice e tuttavia stranamente travolgente tutto in una volta, specialmente se consideri gli infiniti possibili moduli Ansible a tua disposizione. Sembra che dovrebbe essere facile annotare alcune opzioni in un file YAML e quindi eseguire Ansible, ma quali opzioni richiede il tuo modulo preferito? E perché alcune coppie chiave-valore mentre altre sono elenchi?
YAML per Ansible può diventare complesso, quindi capire come i moduli Ansible si traducono in YAML è una parte importante per migliorare in entrambi. Prima di poter capire come funziona YAML per i moduli Ansible, devi comprendere le basi di YAML.
Se non conosci la differenza tra un blocco di mappatura e un blocco di sequenza in YAML, leggi questa rapida introduzione alle basi dell'articolo YAML.
Sintassi dei comandi
A parte l'uso ad hoc, Ansible viene utilizzato attraverso playbook . Un playbook è composto da una o più play in un elenco ordinato (una YAML sequenza ). Ogni riproduzione può eseguire una o più attività e ogni attività richiama un modulo Ansible.
I moduli Ansible sono fondamentalmente front-end per i comandi. Se hai familiarità con il terminale Linux o Powershell di Microsoft, allora sai come costruire un comando usando le opzioni (come --long o -s ) insieme agli argomenti (chiamati anche parametri ).
Ecco un semplice esempio:
$ mkdir foo
Questo comando utilizza mkdir comando per creare una directory chiamata foo .
Un playbook Ansible costruisce anche comandi. Sono gli stessi comandi, ma vengono invocati utilizzando una sintassi diversa da quella a cui sei abituato in un terminale.
[ Potrebbe interessarti anche: Iniziare con Ansible ]
Moduli Ansible e YAML
Come attività in un playbook Ansible, tuttavia, la sintassi è molto diversa. In primo luogo, allo spettacolo viene assegnato un nome, che è una descrizione leggibile dall'uomo di ciò che viene eseguito. Una riproduzione accetta molte parole chiave, inclusi hosts per limitare gli host su cui deve essere eseguito e remote_user per definire il nome utente che Ansible deve utilizzare per accedere agli host remoti.
Le parole chiave per i giochi sono definite da Ansible stesso e nella documentazione di Ansible Play Parole chiave è disponibile un elenco di chiavi (e i tipi di informazioni che ciascuna si aspetta come valore).
Queste chiavi non sono voci di elenco separate. Nella terminologia YAML, sono mapping incorporato nella sequenza di riproduzione .
Ecco una semplice dichiarazione di gioco:
---
- name: “Create a directory”
hosts: localhost
Il blocco di mappatura finale in una dichiarazione di riproduzione è il tasks parola chiave, che apre una nuova sequenza per definire quale modulo Ansible verrà eseguito dal gioco e con quali argomenti. È qui che stai usando comandi familiari in un modo YAML sconosciuto. In effetti, ti è così sconosciuto che probabilmente devi leggere il modulo per scoprire quali argomenti si aspetta da te.
In questo esempio, utilizzo il modulo file integrato. Dalla documentazione del modulo, puoi vedere che il parametro richiesto è path , che prevede un percorso file POSIX valido. Grazie a queste informazioni, puoi generare un playbook Ansible molto semplice che assomiglia a questo:
---
- name: "Create a directory"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "foo"
Se ti stai ancora abituando al significato del rientro di YAML, nota che il nome dell'attività non è rientrato rispetto a tasks perché name è l'inizio di un nuovo blocco di sequenza YAML (che, come succede, funge da valore per le tasks chiave). La parola file identifica quale modulo viene utilizzato, che fa parte della definizione dell'attività e path è un parametro obbligatorio del file modulo.
In altre parole, il compito di un gioco è un blocco sequenza YAML (cioè un elenco ordinato) di definizioni che invocano un modulo ei suoi parametri.
Puoi testare questa riproduzione per verificare che funzioni come previsto, ma prima esegui yamllint su di esso per evitare sorprese sintattiche:
$ yamllint folder.yaml || echo “fail”
$ ansible-playbook folder.yaml
[…]
TASK [Instantiate] ******************
fatal: [localhost]:
FAILED! => {“changed”: false,
“msg”: “file (foo) is absent, cannot continue” …
Il playbook è stato elaborato, ma l'attività non è riuscita. Lettura dell'elenco dei parametri del file modulo rivela che il suo comportamento dipende in gran parte dal valore di state . In particolare, l'azione predefinita è restituire lo stato di path .
Modifica il tuo file YAML di esempio per includere uno state mappatura:
---
- name: "Create a directory"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "foo"
state: directory Eseguilo di nuovo per il successo:
$ yamllint folder.yaml || echo “fail”
$ ansible-playbook folder.yaml
[…]
$ ls
foo Moduli di controllo
Non tutti i moduli Ansible vengono mappati direttamente a un singolo comando. Alcuni moduli modificano il modo in cui Ansible elabora il tuo playbook. Ad esempio, il with_items module enumera gli elementi su cui si desidera far funzionare un altro modulo. Potresti pensarlo come una sorta di do while o for ciclo.
La sua documentazione indica che accetta solo un parametro:un elenco di elementi. Una "lista" nella terminologia YAML è una sequenza , quindi sai senza nemmeno guardare il codice di esempio nei documenti che ogni elemento deve iniziare con un trattino (- ).
Ecco una nuova iterazione della creazione di cartelle, questa volta con più sottocartelle (usando il recurse parametro nel file module) e un parametro aggiuntivo per impostare i permessi dei file. Non lasciarti ingannare dalle righe aggiuntive. Questo è essenzialmente lo stesso codice di prima, solo con parametri extra come descritto nel file documentazione del modulo, più il with_items modulo per abilitare l'iterazione:
---
- name: "Create directory structure"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "{{ item }}"
recurse: true
mode: "u=rwx,g=rwx,o=r"
state: directory
with_items:
- "foo/src"
- "foo/dist"
- "foo/doc" Esegui il playbook per vedere i risultati:
$ yamllint folder.yaml
$ ansible-playbook folder.yaml
[…]
$ ls foo
dist doc src [ Hai bisogno di più su Ansible? Partecipa a un corso di panoramica tecnica gratuito di Red Hat. Ansible Essentials:Semplicità nell'automazione Panoramica tecnica. ]
Principi Ansible
Un playbook Ansible è una sequenza YAML , che a sua volta è costituito da mapping e sequenze .
I playbook contengono anche moduli Ansible, ognuno dei quali accetta parametri definiti dal suo sviluppatore. Sia i parametri obbligatori che quelli facoltativi sono elencati nella documentazione di un modulo.
Per costruire un playbook Ansible, avvia una sequenza YAML che denomina la riproduzione, quindi elenca (in una sequenza) una o più attività. In ogni attività possono essere richiamati uno o più moduli.
Presta molta attenzione al rientro comprendendo il tipo di dati che stai inserendo nel tuo file YAML. Potrebbe essere utile evitare pensare all'indentazione come un'indicazione di ereditarietà logica e, invece, vedere ogni riga come il suo tipo di dati YAML (cioè una sequenza o una mappatura).
Usa yamllint per verificare i tuoi file YAML.
Una volta compresa la struttura di un playbook, è solo questione di seguire la documentazione del modulo per eseguire le attività che si desidera che il playbook esegua. Ci sono centinaia di moduli disponibili, quindi inizia a esplorarli e guarda cosa puoi fare con questo fantastico strumento.