Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Ansible w służbie NOC

Data publikacji: 29-08-2018 Autor: Piotr Wojciechowski

Operowanie zróżnicowanymi zbiorami danych to koszmar niejednego programisty. Tworząc własne skrypty czy playbooki, nie unikniemy jednak pracy ze zmiennymi czy ustrukturyzowanymi zbiorami danych, w których zapisane będą informacje zebrane w trakcie pracy playbooka lub niezbędne do jego poprawnego wykonania. Jeżeli połączymy ze sobą wbudowane w Ansible filtry i uzupełnimy je własnymi skryptami w języku Python, to zadanie stanie się znacznie prostsze.

 

Gdy zaczniemy tworzyć własne playbooki, nie uciekniemy od konieczności przeprowadzania różnych operacji na zebranych w poszczególnych zadaniach danych. Mogą to być zarówno proste operacje, takie jak odczytanie wartości zmiennych i ich porównanie czy znalezienie największej lub najmniejszej wartości w zbiorze, jak i bardzo skomplikowane czynności analityczne wymagające skorelowania pozyskanych danych z informacjami zapisanymi w zewnętrznych systemach. Wiele prostych operacji zaprogramujemy bezpośrednio w kodzie playbooka, wykorzystując do tego dostępne w Ansible filtry (ang. Filter). Aby wykonać bardziej zaawansowane operacje, musimy napisać własne filtry. Dają nam one bardzo dużą elastyczność, pozwalając na wykorzystanie dowolnej dostępnej biblioteki języka Python. W trakcie pracy możemy także zaprogramować połączenie z zewnętrznymi systemami, by pobrać z nich lub zapisać informacje. Zasadniczo jedynym poważnym ograniczeniem jest liczba zmiennych, które możemy przekazać z playbooka do filtra – jedna. Jeżeli chcemy, aby nasz filtr przetworzył więcej niż jedną informację, to musimy najpierw je wszystkie zapisać w pojedynczej strukturze, na przykład JSON. Przyjrzyjmy się, jak w praktyce działają filtry i jak je tworzymy.

> Moduły przetwarzające dane

W repozytorium Ansible znajdziemy kilka wtyczek tego typu, na przykład ipaddr przeznaczoną do operacji związanych z adresami IP. Większość filtrów pochodzi z projektu Jinja 2 i to z nich zazwyczaj korzystamy w playbookach. Warto zapoznać się z ich dokumentacją (tinyurl.com/ansible-playbooks-filters).

Im bardziej zaawansowany jest nasz projekt, tym większe prawdopodobieństwo, że będziemy musieli napisać własne filtry, by wyłuskać z różnych struktur danych interesujące nas informacje lub je zmodyfikować. Sytuacje takie najczęściej występują, gdy:

 

  • w Ansible lub Jinja2 brakuje filtru wykonującego wymagane przez nas operacje;
  • musimy przeprowadzić skomplikowaną analizę danych, często wykorzystując do tego dodatkowe, zewnętrzne informacje niedostępne dla playbooka;
  • wykonanie tej samej czynności w playbooku wymagałoby wykonania wielu zadań lub powodowałoby w inny sposób, że kod stałby się mało zrozumiały, skomplikowany i powodowałby znacznie dłuższy czas wykonania playbooka.


Dane wejściowe do filtra zapisane są w zmiennej (var lub fact) playbooka. Tylko jedna zmienna może być przekazana jako parametr działania filtra, lecz jednocześnie do pojedynczej zmiennej możemy zaaplikować kolejno wiele filtrów, a wynik zapisać w nowej zmiennej.

---
- hosts: localhost
connection: local
tasks:
– set_fact: moj_url="https://serwer.domena.pl/jakis/url"
– debug: msg="{{ moj_url | urlsplit('hostname') | upper }}"

Powyższy kod jest kompletnym playbookiem, który można wykonać na swoim komputerze. Znajduje się on w udostępnionym repozytorium w pliku filtry-demo-1.yml. W pierwszym zadaniu za pomocą set_fact tworzymy zmienną moj_url i przypisujemy jej dowolny prawidłowy URL. W drugim zadaniu wywołujemy moduł debug, za pomocą którego wyświetlimy tekst na ekranie. Gdybyśmy za pomocą konstrukcji
{{ moj_url }} odwołali się bezpośrednio do utworzonej zmiennej, na ekranie wypisana zostałaby przypisana jej wartość, czyli wprowadzony URL. My natomiast zapisaną w zmiennej wartość poddaliśmy działaniu dwóch filtrów – tak jak w potokach języka powłoki bash kolejne operacje rozdzielamy znakiem | (pipe), a kolejność wykonywania operacji jest zgodnie z zapisem od lewej do prawej. W powyższym przykładzie wartość zapisaną w zmiennej najpierw przetwarzamy za pomocą filtru urlsplit, który wywołany z parametrem hostname wyłuska dla nas nazwę serwera. Otrzymaną w ten sposób wartość nie zapisujemy w nowej zmiennej, lecz od razu przekazujemy do filtra upper, który w zadanym ciągu znaków zmienia małe litery na wielkie. Efekt złożenia tych dwóch filtrów widać w wyniku wykonania zadania playbooka:

ok: [localhost] => {
"msg": "SERWER.DOMENA.PL"
}

Wywołując wiele filtrów, w pojedynczym zadaniu możemy zoptymalizować jego rozmiar, lecz pamiętajmy, że musimy być bardzo uważni, by nie popełnić błędów. Wskazane jest, aby początkowo rozbić tego typu operacje na mniejsze moduły, które dopiero potem będziemy łączyć w całość.

> Numer seryjny urządzenia

Pluginy typu Filter zawsze wywołujemy w kodzie playbooka jawnie. Nie działają one w tle, tak jak przedstawione w poprzednim numerze wtyczki CallBack. Dlatego kod naszych wtyczek zazwyczaj umieszczamy w folderze filter_plugins całego projektu. Wywołać będziemy mogli je wtedy w play­bookach, zarówno tych umieszczonych w głównym folderze projektu, jak i w folderach ról. Jeżeli plugin zapiszemy w folderze filter_plugins w katalogu wybranej przez nas roli, to filtr będzie dostępny jedynie dla playbooków korzystających z tej roli. Pluginy typu Filter tworzymy w obiektowym języku Python. W przeciwieństwie do kodu wtyczek CallBack nie będziemy wykorzystywać w nich właściwości dziedziczenia i nadpisywać domyślnych dla klasy metod własnymi.

[...]

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Pracuje m.in. w międzynarodowej instytucji finansowej, dla której projektuje rozwiązania sieciowe, a także jako niezależny konsultant IT. Posiada certyfikat CCIE

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"