Ansible è uno strumento molto potente che ti consente di automatizzare un'ampia varietà di piattaforme su server, cloud, reti, container e altro ancora.
Spesso sarai in grado di automatizzare ciò che desideri semplicemente riutilizzando ruoli e raccolte esistenti.
E ci sono molti moduli tra cui scegliere che puoi utilizzare nei tuoi playbook.
Ma quando inizi a sviluppare e testare playbook più complessi, alla fine avrai bisogno di alcuni metodi di risoluzione dei problemi. Cose come:
- Verifica del flusso delle attività Ansible.
- Conferma dei tipi di dati delle tue variabili.
- Anche fare una pausa in un punto particolare per controllare i loro valori.
Alcuni dei suggerimenti discussi in questo articolo si applicheranno solo all'esecuzione di Ansible tramite la riga di comando. Altri sono validi anche quando si esegue da Ansible Tower.
1. Il tuo ambiente e parametri Ansible
Se hai bisogno di indagare sul motivo per cui qualcosa non si comporta come previsto nei tuoi playbook, di solito è bene iniziare controllando il tuo ambiente Ansible.
Quali versioni e percorsi dei binari Ansible e di Python stai utilizzando?
Se hai aggiunto pacchetti OS o moduli Python richiesti dai tuoi playbook, l'interprete Ansible li "vede"?
È possibile ottenere queste informazioni di base in molti modi diversi. Dalla riga di comando, esegui ansible --version comando.
❯ ansible --version
ansible 2.9.10
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.6/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Mar 18 2021, 08:58:41) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]
Puoi ottenere le stesse informazioni eseguendo altri comandi Ansible come ansible-playbook o ansible-config con il --version opzione.
In Ansible Tower, queste informazioni vengono mostrate se il modello di lavoro viene eseguito con VERBOSITY 2 (più dettagliato) o superiore.
Oltre alle versioni e alla posizione dei binari Ansible e Python, è sempre bene ricontrollare i percorsi utilizzati per i moduli, incluso se l'esecuzione sta usando un ansible.cfg file che non è quello predefinito (cioè non /etc/ansible/ansible.cfg ).
Per esaminare le opzioni provenienti da un ansible.cfg personalizzato file, puoi eseguire quanto segue dalla riga di comando:
❯ ansible-config dump --only-changed
DEFAULT_BECOME(/home/admin/ansible/ansible.cfg) = True
DEFAULT_BECOME_USER(/home/admin/ansible/ansible.cfg) = root
DEFAULT_FORKS(/home/admin/ansible/ansible.cfg) = 10
DEFAULT_HOST_LIST(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/inventory']
DEFAULT_ROLES_PATH(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/roles']
HOST_KEY_CHECKING(/home/admin/ansible/ansible.cfg) = False Come suggerisce il nome, questo elencherà i parametri che sono diversi da quelli predefiniti.
2. Esecuzione in modalità dettagliata
L'esecuzione dei playbook in modalità debug può essere il passaggio successivo per ottenere maggiori dettagli su ciò che sta accadendo nelle attività e nelle variabili.
Dalla riga di comando, puoi aggiungere -v (o -vv , -vvv , -vvvv , -vvvvv ). I livelli di verbosità più alti a volte possono essere troppe informazioni, quindi è meglio aumentare gradualmente in più esecuzioni fino a ottenere ciò di cui hai bisogno.
Il livello 4 può aiutare nella risoluzione dei problemi di connettività e il livello 5 è utile per i problemi di WinRM.
Da Tower, puoi selezionare la VERBOSITÀ livello dalla definizione del modello di lavoro.
Nota :Ricorda di disabilitare la modalità di debug dopo aver risolto la situazione perché le informazioni dettagliate sono utili solo per la risoluzione dei problemi.
Inoltre, in modalità debug, verranno visualizzati i valori di alcune variabili (password, ad esempio) a meno che non utilizzi il no_log opzione nell'attività, quindi cancella gli output quando hai finito.
3. Usare il debug per mostrare le variabili
Se hai una buona idea di dove i problemi potrebbero essere, puoi usare un approccio più chirurgico:mostra solo le variabili che devi vedere.
(...)
- name: Display the value of the counter
debug:
msg: "Counter={{ counter }} / Data type={{ counter | type_debug }}"
(...)
TASK [Display the value of the counter] ****************************************************************************
ok: [node1] => {
"msg": "Counter=42 / Data type=AnsibleUnicode"
}
Questo ecco perché non ho potuto incrementare il contatore. Il filtro type_debug mostra che il tipo di dati è testo e non int come supponevo.
[ Potrebbe piacerti anche: Guida introduttiva ad Ansible per gli amministratori di sistema Linux ]
4. Assicurarsi che le var abbiano il contenuto e il tipo di dati corretti
Puoi utilizzare l'affermazione modulo per confermare che le variabili abbiano il contenuto/tipo previsto e causare il fallimento dell'attività se qualcosa non va.
Il seguente playbook lo illustra:
---
- name: Assert examples
hosts: node1
gather_facts: no
vars:
var01: 13
tasks:
- debug:
msg: "Parameter 01 is {{ (param01 | type_debug) }}"
- name: Make sure that we have the right type of content before proceeding
assert:
that:
- "var01 is defined"
- "(var01 | type_debug) == 'int' "
- "param01 is defined "
- "(param01 | type_debug) == 'int' " Se eseguo il playbook dalla riga di comando, senza fornendo le extra-var:
❯ ansible-playbook xassert.yml
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is AnsibleUndefined"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "param01 is defined ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Se eseguo il playbook dalla riga di comando, con l'extra-var:
❯ ansible-playbook xassert.yml -e "param01=99"
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is str"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "(param01 | type_debug) == 'int' ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Vedere il tipo di dati arrivare come str è stata una sorpresa per me, ma qui c'è una spiegazione e una soluzione.
Inoltre, se esegui lo stesso playbook da Tower, passando il parametro come extra-vars o un campo da un sondaggio, il tipo di dati del parametro sarà int .
Sì, può essere complicato... ma se sai cosa cercare, queste "caratteristiche" non saranno un problema per te.
5. Ottenere un elenco dei fatti e delle varianti
Sia che tu abbia definito variabili nel tuo inventario (per host e/o gruppi) o creato e assegnato variabili aggiuntive durante l'esecuzione del tuo playbook, a un certo punto potrebbe essere utile controllarne i valori.
---
- name: vars
hosts: node1,node2
tasks:
- name: Dump vars
copy:
content: "{{ hostvars[inventory_hostname] | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_vars.txt"
delegate_to: control
- name: Dump facts
copy:
content: "{{ ansible_facts | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_facts.txt"
delegate_to: control Ciò salverà le variabili e i fatti (se stai raccogliendo fatti) in singoli file da analizzare.
Per l'esecuzione della riga di comando, ho delegato l'attività al mio host di controllo (localhost) per salvare i file in locale invece di salvare i file in ciascun nodo separatamente. Se corri da Tower, dovrai selezionarne anche uno server dove archiviare i file (a meno che tu non abbia un solo nodo di destinazione e non ti dispiaccia analizzare il file lì).
6. Utilizzo del debugger delle attività per la risoluzione dei problemi dalla riga di comando
Puoi anche utilizzare il debugger Ansible per eseguire i playbook in una modalità passo passo ed esaminare il contenuto di variabili e argomenti in modo interattivo.
Oltre a ciò, puoi anche modificare i valori delle variabili al volo e continuare l'esecuzione.
Il debugger può essere abilitato a livello di attività o di riproduzione, come nell'esempio seguente:
---
- name: Example using debugger
hosts: localhost
gather_facts: no
vars:
radius: "5.3"
pi: "3.1415926535"
debugger: on_failed
tasks:
- name: Calculate the area of a circle
debug:
msg:
- "Radius.............: {{ radius }}"
- "pi................: {{ pi }}"
- "Area of the circle: {{ (pi * (radius * radius)) }}" Avviso spoiler:ho definito le variabili come stringhe, che ovviamente causeranno un errore quando provo a fare il calcolo.
❯ ansible-playbook xdebugger.yml
PLAY [Example using debugger] ****************************************************************************
TASK [Calculate the area of a circle] ****************************************************************************
fatal: [localhost]: FAILED! => {"msg": "Unexpected templating type error occurred on (Area of the circle: {{ (pi * (radius * radius)) }}): can't multiply sequence by non-int of type 'AnsibleUnicode'"}
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['pi']
'3.1415926535'
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
'5.3'
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['radius']=5.3
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
5.3
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> redo
ok: [localhost] => {
"msg": [
"Radius............: 5.3",
"pi................: 3.1415926535",
"Area of the circle: 88.247337636815"
]
}
PLAY RECAP ****************************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Cosa è successo qui:
- Inizialmente, l'attività non è riuscita, lamentandosi delle variabili non int.
- Il debugger è stato richiamato.
- Ho usato la stampa (p ) comando per visualizzare i valori delle variabili.
- In questo caso, sapevo che il problema era nel tipo di dati, ma si potrebbe pensare che i valori siano corretti (se non prestando attenzione alle virgolette attorno ai valori).
- In seguito ho aggiornato il contenuto delle variabili, assegnando loro dei numeri.
- Poi, ho usato il
redocomando per rieseguire l'attività con i nuovi valori e l'operazione è terminata correttamente.
Questo era uno scenario semplice, poiché sappiamo che nessuno userebbe davvero Ansible per calcolare l'area di un cerchio. Ma in una situazione più complessa, potrebbe essere utile trovare il contenuto di una variabile nel mezzo di una lunga esecuzione di playbook, e poter procedere da quel punto senza ricominciare da capo.
[ Ottieni questo ebook gratuito:Gestione dei cluster Kubernetes per i manichini. ]
Concludi
Incorporare un buon arsenale di opzioni per la risoluzione dei problemi può aiutarti a identificare più rapidamente i problemi nei tuoi playbook Ansible. A seconda di dove ti trovi nell'indagine, alcuni metodi sono più adatti.
Ad esempio, quando stai solo cercando di farti un'idea di cosa potrebbe essere sbagliato e dove , potresti voler iniziare aumentando gradualmente il livello di debug.
Una volta che hai un'idea migliore della posizione del problema, può essere conveniente diminuire il livello di debug (in modo da avere meno output di fronte a te) e utilizzare opzioni specifiche per l'attività che stai analizzando.
Risoluzione dei problemi di Ansible può essere complicato, ma utilizzando un approccio metodico combinato con gli strumenti di risoluzione dei problemi integrati puoi renderti molto più semplice. Conferma l'ambiente Ansible e il flusso delle attività, quindi cerca i tipi di dati appropriati e infine considera la possibilità di mettere in pausa e scorrere ogni attività.