6 dovedností pro odstraňování problémů pro Ansible playbooky

Ansible je velmi výkonný nástroj, který vám umožňuje automatizovat obrovské množství platforem napříč servery, cloudy, sítěmi, kontejnery a dalšími.

Často budete schopni automatizovat, co chcete, pouhým opětovným použitím existujících rolí a kolekcí.

A na výběr je mnoho modulů, které můžete použít ve svých příručkách.

Ale když začnete vyvíjet a testovat složitější příručky, budete nakonec potřebovat nějaké metody odstraňování problémů. Věci jako:

• Kontrola toku úkolů Ansible.
• Potvrzení datových typů vašich proměnných.
• Dokonce i když se v určitém bodě zastavíte, abyste zkontrolovali jejich hodnoty.

Některé z tipů uvedených v tomto článku se budou vztahovat pouze na spouštění Ansible prostřednictvím příkazového řádku. Ostatní platí také při běhu z Ansible Tower.

1. Vaše prostředí a parametry Ansible

Pokud potřebujete prozkoumat, proč se něco ve vašich příručkách nechová podle očekávání, obvykle je dobré začít kontrolou prostředí Ansible.

Které verze a cesty binárních souborů Ansible a Pythonu používáte?

Pokud jste přidali balíčky operačního systému nebo moduly Python, které vaše příručky vyžadují, „vidí“ je interpret Ansible?

Tyto základní informace můžete získat mnoha různými způsoby. Z příkazového řádku spusťte ansible --version příkaz.

❯ 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)]

Stejné informace můžete získat spuštěním dalších příkazů Ansible, jako je ansible-playbook nebo ansible-config s --version možnost.

V Ansible Tower se tato informace zobrazí, pokud je šablona úlohy spuštěna s VERBOSITY 2 (Více upovídanější) nebo vyšší.

Kromě verzí a umístění binárních souborů Ansible a Python je vždy dobré znovu zkontrolovat cesty používané pro moduly, včetně toho, zda spuštění používá ansible.cfg soubor, který není výchozí (tj. ne /etc/ansible/ansible.cfg ).

Pro zkoumání možností pocházejících z vlastního ansible.cfg soubor, můžete z příkazového řádku provést následující:

❯ 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

Jak název napovídá, zobrazí se seznam parametrů, které jsou odlišné z výchozích.

2. Spuštění v podrobném režimu

Spuštění příruček v režimu ladění může být dalším krokem k získání dalších podrobností o tom, co se děje v úlohách a proměnných.

Z příkazového řádku můžete přidat -v (nebo -vv , -vvv , -vvvv , -vvvvv ). Nejvyšší úrovně výřečnosti mohou někdy představovat příliš mnoho informací, takže je lepší postupně zvyšovat počet spouštění, dokud nezískáte to, co potřebujete.

Úroveň 4 může pomoci při odstraňování problémů s připojením a úroveň 5 je užitečná pro problémy s WinRM.

Ve věži můžete vybrat VÝŘEDNOST úroveň z definice šablony úlohy.

Poznámka :Nezapomeňte po vyřešení situace deaktivovat režim ladění, protože podrobné informace jsou užitečné pouze pro odstraňování problémů.

V režimu ladění se také zobrazí hodnoty určitých proměnných (například hesla), pokud nepoužijete no_log možnost v úloze, takže po dokončení vymažte výstupy.

3. Použití ladění k zobrazení proměnných

Pokud máte dobrou představu o tom, kde problémy mohou být, můžete použít chirurgičtější přístup:Zobrazte pouze proměnné, které potřebujete vidět.

(...)

  - 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"

}

Toto proto jsem nemohl zvýšit počítadlo. Filtr type_debug ukazuje, že typ dat je text a ne int jak jsem předpokládal.

[ Také by se vám mohlo líbit: Stručný průvodce pro správce systému Ansible pro Linux ]

4. Ujistěte se, že proměnné mají správný obsah a typ dat

Můžete použít tvrzení modul pro potvrzení, že proměnné mají očekávaný obsah/typ a způsobí selhání úlohy, pokud je něco špatně.

Ilustruje to následující příručka:

---

- 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' "

Pokud spustím playbook z příkazového řádku, bez poskytování extra-vars:

❯ 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  

Pokud spustím playbook z příkazového řádku, s 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 

Typ dat přicházející jako str bylo pro mě překvapením, ale existuje zde vysvětlení a řešení.

Také, pokud spustíte stejnou příručku z Toweru, buď předáte parametr jako extra-vars nebo pole z průzkumu, datový typ parametru bude int .

Ano, může to být složité... ale pokud víte, co hledat, nebudou pro vás tyto „funkce“ žádný problém.

5. Získání seznamu faktů a proměnných

Ať už jste ve svém inventáři definovali proměnné (pro hostitele a/nebo skupiny) nebo jste vytvořili a přiřadili další proměnné během provádění vaší příručky, může být užitečné v určitém okamžiku zkontrolovat jejich hodnoty.

---
- 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

Tím se uloží vars a fakta (pokud shromažďujete fakta) do jednotlivých souborů, abyste je mohli analyzovat.

Pro spuštění příkazového řádku jsem delegoval úkol na svého řídicího hostitele (localhost), aby byly soubory uloženy lokálně, místo aby byly soubory uloženy v každém uzlu samostatně. Pokud spouštíte z Toweru, budete také muset vybrat jeden server, kam uložit soubory (pokud nemáte pouze jeden cílový uzel a nevadí vám analyzovat soubor tam).

6. Použití ladicího programu úloh pro odstraňování problémů z příkazového řádku

Můžete také použít Ansible debugger ke spouštění playbooků v režimu krok za krokem a k interaktivnímu zkoumání obsahu proměnných a argumentů.

Kromě toho můžete také měnit hodnoty proměnných za běhu a pokračovat v provádění.

Ladicí program lze povolit na úrovni úlohy nebo na úrovni hry, jako v následujícím příkladu:

---

- 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)) }}"

Upozornění na spoiler:Proměnné jsem definoval jako řetězce, což zjevně způsobí chybu, když se pokusím provést výpočet.

❯ 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  

Co se stalo zde:

1. Zpočátku úloha selhala a stěžovala si na proměnné jiné než int.
2. Byl spuštěn ladicí program.
3. Použil jsem tisk (p ) příkaz pro zobrazení hodnot proměnných.
4. V tomto případě jsem věděl, že problém je v datovém typu, ale člověk by si mohl myslet, že hodnoty jsou správné (pokud nevěnujeme pozornost uvozovkám kolem hodnot).
5. Později jsem aktualizoval obsah proměnných a přiřadil jim čísla.
6. Potom jsem použil redo příkaz k opětovnému provedení úlohy s novými hodnotami a ta byla úspěšně dokončena.

Toto byl jednoduchý scénář, protože víme, že nikdo by opravdu použil Ansible k výpočtu plochy kruhu. Ale ve složitější situaci by mohlo být užitečné najít obsah proměnné uprostřed dlouhého provádění playbooku a být schopen pokračovat od tohoto bodu bez restartování od nuly.

[ Získejte tuto bezplatnou e-knihu:Správa clusterů Kubernetes pro figuríny. ]

Sbalit

Začlenění dobrého arzenálu možností řešení problémů vám může pomoci rychleji identifikovat problémy ve vašich příručkách Ansible. V závislosti na tom, kde se ve vyšetřování nacházíte, jsou určité metody vhodnější.

Například když se jen snažíte získat představu o tom, co může být špatně a kde , možná budete chtít začít s postupným zvyšováním úrovně ladění.

Jakmile budete mít lepší představu o umístění problému, může být vhodné snížit úroveň ladění (abyste měli před sebou méně výstupu) a použít možnosti, které jsou specifické pro úlohu, kterou analyzujete.

Odstraňování problémů Ansible může být složité, ale pomocí metodického přístupu v kombinaci s vestavěnými nástroji pro řešení problémů si to můžete značně usnadnit. Potvrďte Ansible prostředí a tok úloh, poté vyhledejte správné datové typy a nakonec zvažte pozastavení a procházení jednotlivých úloh.