Dlaczego Ansible lubi wcięcia ?

Początki przygody z nauką nowych technologii bywają trudne, czasami nawet bardzo… Ansible nie odbiega od tej reguły 😉

Wcięcia w kodzie- niby nic takiego, a potrafią uprzykrzyć życie. Niezależnie jakiego języka programowania by się tyczyły- PHP, Powershell, C, pomagają w odnalezieniu się, poprawiają czytelność kodu i nawet gdy ich nie stosujemy kod działa.
Ansible w tej kwestii uczy pokory i to bardzo! Nie ma wcięć ?! Nie pogadamy!

Wyobraź sobie, że napisałeś zadanie, które ma kilka deklaracji i tak na prawdę nie ma możliwości by nie działało, a tu nagle bęc- czerwony komunikat błędu. Przeszukałem czeluści internetu by rozwiązać swój problem. Zmieniałem wielkości liter, dodawałem „ciapciaki” czyli cudzysłów 😉 Oglądałem kod z lewej, prawej, zaglądałem pod spód i nic. Byłem o krok od znienawidzenia, rzucenia tego wszystkiego w kąt i popełnienia samobójstwa.

Postanowiłem przekopiować przykład z dokumentacji i zmienić wartości na swoje. Ku mojemu zdziwieniu zadziałało. W dalszym ciągu nie wiedziałem co jest nie tak, po prostu nie widziałem tego, że nie zrobiłem wcięć. W końcu, przy pomocy mojego ulubionego edytora- Notepad++ wkleiłem oba taski, zaznaczyłem w opcjach programu widoczność nowych linii, tabulacji spacji itp. i wtedy zauważyłem różnicę pomiędzy moim a tym z dokumentacji, której wcześniej nie dostrzegałem- wcięcia! Zacząłem testować playbooka w różnych konfiguracjach, z taskami posiadającymi wcięcia i tymi bez. Mój świat nabrał zupełnie nowego kolorytu, już nie był szkarłatnoczerwony, był zielony i prezentował piękne OK 😉

Przykład:

Poniżej kawałek kodu, jeden z pierwszych tasków który debugowałem… godzinę… dwie… ? Ciężko powiedzieć ile. Ale idealnie zobrazuje z czym się zmagałem.

Piękne zielone ok, jak poniżej:

Wyświetla kod z wcięciami, który prezentuje się następująco:

Niestety na ogół widziałem czerwony komunikat, który ma w swojej treści podpowiedź, gdzie szukać problemu. Jednak podpowiedź na pierwszy rzut oka może wprowadzać w błąd, w związku z czym myślimy, że chodzi o linię kodu, która jest o 1 wiersz wyżej. Wszystko dzięki ^, które może mówić, że chodzi o miejsce linię wyżej.

Poniższy kod błędu może wskazywać na błąd z linią zawierającą - firewalld:

W rzeczywistości jest to problem ze składnią kodu po wierszu zawierającym - firewalld: Dodatkowo komunikat wskazuje na problem z atrybutem ‚state’, co może wprowadzić nas w błąd i skupimy się na rozwiązywaniu problemu tylko w tym wierszu, nie zwracając uwagi na problemy z innymi wierszami/atrybutami.

Kolejny przykład, już z innym komunikatem, również na pierwszy rzut oka wprowadzającym nas w błąd. Poniższy komunikat wskazuje na problem modułu ‚notify’, w rzeczywistości jest to brak wcięcia w wierszu zawierającym ‚notify’. Komunikat mówił prawdę w jednej kwestii, że mamy do czynienia z modułem. Na początku ciężko wywnioskować, że każdy moduł powinien być w równej linii z innym modułem, w tym przypadku powinien mieć wcięcie na wysokości firewalld

Problematyczny kod wygląda następująco:

 

Jestem ciekaw ile osób borykało się z podobnym problemem 😉 Pozdrawiam!