Ansible - Rozwiązywanie problemów
Najpopularniejsze strategie debugowania Playbooków Ansible wykorzystują moduły podane poniżej -
Debuguj i zarejestruj
Te dwa to moduły dostępne w Ansible. W celu debugowania musimy rozsądnie używać tych dwóch modułów. Przykłady przedstawiono poniżej.
Używaj gadatliwości
Za pomocą polecenia Ansible można określić poziom szczegółowości. Polecenia można uruchamiać z poziomem szczegółowości pierwszym (-v) lub dwoma (-vv).
Ważne punkty
W tej sekcji omówimy kilka przykładów, aby zrozumieć kilka pojęć.
Jeśli nie cytujesz argumentu, który zaczyna się od zmiennej. Na przykład,
vars:
age_path: {{vivek.name}}/demo/
{{vivek.name}}
Spowoduje to wyświetlenie błędu.
Rozwiązanie
vars:
age_path: "{{vivek.name}}/demo/" – marked in yellow is the fix.
How to use register -> Copy this code into a yml file say test.yml and run it
---
#Tsting
- hosts: tomcat-node
tasks:
- shell: /usr/bin/uptime
register: myvar
- name: Just debugging usage
debug: var = myvar
Kiedy uruchamiam ten kod za pomocą polecenia Ansible-playbook -i hosts test.yml, otrzymuję dane wyjściowe, jak pokazano poniżej.
Jeśli widzisz yaml, zarejestrowaliśmy wyjście polecenia w zmiennej - myvar i po prostu wydrukowali wynik.
Tekst zaznaczony na żółto informuje nas o właściwości zmiennej –myvar, której można użyć do dalszej kontroli przepływu. W ten sposób możemy dowiedzieć się, jakie właściwości są uwidocznione w danej zmiennej. Pomaga w tym poniższe polecenie debugowania.
$ ansible-playbook -i hosts test.yml
PLAY [tomcat-node] ***************************************************************
**************** ****************************************************************
*************** ******************************
TASK [Gathering Facts] *****************************************************************
************** *****************************************************************
************** **************************
Monday 05 February 2018 17:33:14 +0530 (0:00:00.051) 0:00:00.051 *******
ok: [server1]
TASK [command] ******************************************************************
************* ******************************************************************
************* **********************************
Monday 05 February 2018 17:33:16 +0530 (0:00:01.697) 0:00:01.748 *******
changed: [server1]
TASK [Just debugging usage] ******************************************************************
************* ******************************************************************
************* *********************
Monday 05 February 2018 17:33:16 +0530 (0:00:00.226) 0:00:01.974 *******
ok: [server1] => {
"myvar": {
"changed": true,
"cmd": "/usr/bin/uptime",
"delta": "0:00:00.011306",
"end": "2018-02-05 17:33:16.424647",
"rc": 0,
"start": "2018-02-05 17:33:16.413341",
"stderr": "",
"stderr_lines": [],
"stdout": " 17:33:16 up 7 days, 35 min, 1 user, load average: 0.18, 0.15, 0.14",
"stdout_lines": [
" 17:33:16 up 7 days, 35 min, 1 user, load average: 0.18, 0.15, 0.14"
]
}
}
PLAY RECAP ****************************************************************************
**********************************************************************************
**************************************
server1 : ok = 3 changed = 1 unreachable = 0 failed = 0
Typowe problemy z poradnikiem
W tej sekcji poznamy kilka typowych problemów z poradnikiem. Problemy są -
- Quoting
- Indentation
Poradnik jest napisany w formacie yaml, a powyższe dwa są najczęstszymi problemami w yaml / playbook.
Yaml nie obsługuje wcięć opartych na tabulatorach i obsługuje wcięcia oparte na spacji, więc należy uważać na to samo.
Note - kiedy skończysz pisać yaml, otwórz tę stronę (https://editor.swagger.io/) i skopiuj, wklej swój yaml po lewej stronie, aby upewnić się, że yaml kompiluje się poprawnie. To tylko wskazówka.
Swagger kwalifikuje zarówno błędy w ostrzeżeniach, jak i błędach.