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


20.12.2018

Większa moc

QNAP Mustang-200
20.12.2018

Nowa era Wi-Fi

NETGEAR Nighthawk AX8
20.12.2018

Szybkie skanowanie

Brother ADS-1700W i ADS-1200
06.12.2018

Niższe moce

UPS Eaton 9SX
03.12.2018

Monitory dla MŚP

AOC E1
29.11.2018

Wykrycie szkodliwego...

Sophos Intercept X Advanced
27.11.2018

Automatyzacja zabezpieczeń

Red Hat Ansible Automation
23.11.2018

Nieograniczona skalowalność

SUSE Enterprise Storage 5.5
20.11.2018

Dwa procesory Threadripper

AMD Ryzen Threadripper 2970WX i 2920X

Ansible w służbie NOC

Data publikacji: 26-09-2018 Autor: Piotr Wojciechowski

Programowanie przypomina nieco puzzle, w których, łącząc ze sobą różne narzędzia i techniki, wykorzystując systemowe i zewnętrzne biblioteki, składamy sami lub jako zespół wszystkie te elementy razem, by powstała aplikacja. Równie ważna jak znajomość konstrukcji i obsługi poszczególnych elementów jest wiedza o tym, w jaki sposób optymalnie i bezpiecznie połączyć je ze sobą i stworzyć kompleksowy projekt.

 

W poprzednich częściach omówiliśmy ramowe założenia, które musi spełniać playbook automatyzujący diagnostyczne lub operacyjne działania zespołów nadzoru w NOC. Dowiedzieliśmy się także, w jaki sposób tworzyć i wykorzystywać pluginy typu Filter oraz zaprogramować dodatkowe akcje związane z wydarzeniami za pomocą wtyczek Callback. Uważny czytelnik zapewne zwrócił uwagę, że każde zadanie jest do zrealizowania więcej niż jedną metodą, co pozwala nam elastycznie dobierać sposoby realizacji w zależności od własnych umiejętności i preferencji. Na koniec cyklu artykułów stworzymy w pełni działający i przydatny w pracy operatora playbook, w którym połączymy wszystkie omawiane wcześniej elementy w całość. Nie zapomnimy też przyjrzeć się, w jaki sposób generuje się czytelne podsumowanie działania playbooka dla operatora.


> PRAWDZIWY PLAYBOOK DLA OPERATORA NOC


Nasz playbook ma realizować proste zadanie – ze wskazanych w inventory routerów Junipera uzyskać listę aktywowanych interfejsów z grupy ge-, czyli interfejsów Gigabit Ethernet, które mają problemy z działaniem połączenia fizycznego, i dla każdego z nich odczytać informację, od kiedy taki interfejs znajduje się w takim stanie. Dodatkowo playbook będzie wyświetlał ustrukturyzowaną informację z powyższymi informacjami dla każdego sprawdzanego urządzenia. Interfejs przyjmuje status link down, gdy wykryty zostanie problem w warstwie pierwszej modelu OSI, czyli warstwie fizycznej. Zobaczymy go przykładowo, gdy wypniemy z portu kabel lub zostanie on fizycznie uszkodzony.

 

Faktycznie proces działania playbooka będzie odzwierciedlać to, w jaki sposób zadanie realizowałby człowiek. Operator NOC, gdyby dostał takie zadanie, po zalogowaniu się na urządzenie najpierw wyświetliłby na ekranie listę interfejsów z rodziny ge- zawierającą minimalne informacje o każdym z nich. Najprościej wykorzystać w tym celu polecenie show interface ge-* terse


admin@vSRX> show interfaces ge-* terse
Interface      Admin Link Proto Local Remote
ge-0/0/0       up down
ge-0/0/0.0    up down inet 172.16.1.1/24

 

Status warstwy fizycznej wyświetlany jest w kolumnie Link. Następnie operator dla każdego interfejsu, którego wartość Link jest down, a Admin jest up, wyświetlałby poleceniem show interface podstawowe informacje o interfejsie. Wśród nich jako Last flapped zapisana jest data, informująca o tym, kiedy ostatni raz wykryto problem z połączeniem fizycznym wybranego interfejsu.

 

admin@vSRX> show interfaces ge-0/0/0
Physical interface: ge-0/0/0, Enabled, Physical link is Down
<ominięto nieważne linie>
Last flapped : 2017-02-21 13:03:13 CEST (3w2d 23:42 ago)

 

Tak zebrane informacje zapewne zapisywałby w arkuszu lub pliku tekstowym, by móc z nich skorzystać w trakcie innych czynności. Playbook wykonywać będzie te zadania w dokładnie taki sam sposób. Naszym zadaniem będzie zaplanowanie jego konstrukcji i przygotowanie odpowiednich niezbędnych skryptów. Nie zapomnijmy o tym, w jaki sposób Ansible wykonuje playbooka, gdyż będzie miało to duże znaczenie w sposobie zapisywania zebranych danych. Playbook realizowany jest zadanie po zadaniu. Oznacza to, że jeżeli w inventory zdefiniowane jest więcej niż jedno urządzenie, to Ansible wykonuje zadanie dla wszystkich urządzeń i dopiero wtedy przechodzi do następnego zadania z playbooka, które również wykonuje po kolei dla wszystkich urządzeń.


> ZBIERANIE DANYCH O INTERFEJSACH


Informację o interfejsach możemy wydobyć na wiele sposobów, choćby poprzez zdalne wykonanie polecenia show interface ge-* terse na urządzeniu, a następnie zaprogramowaniu funkcji, która odpowiednio przeanalizuje dane wyjściowe, czyli to, co operator widzi na ekranie konsoli. Takie podejście traktujmy jednak jako ostateczność, gdyż nie jest ono łatwe w implementacji – format wyświetlanego wyniku może się przecież zmienić pomiędzy różnymi wersjami oprogramowania. Zawsze powinniśmy najpierw sprawdzić, czy w standardowych bibliotekach Ansible jest moduł, za pomocą którego wykonamy konieczne operacje lub odczytamy z urządzenia niezbędne informacje. Jeżeli taki moduł nie istnieje, sprawdźmy, czy ktoś już nie stworzył roli realizującej oczekiwane zadanie i nie opublikował jej w ramach Ansible Galaxy. Jest to repozytorium, w którym niezależni programiści mogą publikować swoje role dla Ansible, o ile będą one dostępne na podstawie jednej z otwartych licencji. Jeżeli zadanie polega na odczytaniu z urządzenia wybranych informacji, poszukajmy modułu, który pozwala przesłać do niego dowolne polecenie, a wynik zwróci z ustrukturyzowanej postaci jako XML lub JSON. W naszym projekcie wykorzystamy dostarczane wraz z Ansible moduły dedykowane dla platformy JunOS, w których dane wyjściowe mogą być zwrócone w postaci XML lub JSON.


W playbooku musimy z każdego z urządzeń odczytać dwie informacje – numer wersji systemu operacyjnego JunOS oraz listę interfejsów, które są dostępne na urządzeniu. Wykonując dowolną komendę z linii wiersza poleceń urządzenia, możemy jej wynik wyświetlić w formie przyjaznej programistom. Oprogramowanie w wersji starszej niż 14.2 pozwalało na wyświetlenie danych w strukturze XML, nowsze także w postaci obiektu JSON. Wyboru dokonujemy, dodając odpowiedni parametr przy wywołaniu modułu Ansible lub w wierszu poleceń za pomocą opcji display. Skoro jednak XML jest nadal dostępny, to po co nam numer wersji? Z dwóch powodów – po pierwsze, nie wiemy, czy producent nie wycofa wsparcia dla XML w jednym z następnych wydań systemu. Powinniśmy się starać, aby kod naszego playbooka zawsze był możliwie najbardziej uniwersalny, a jego wykonanie nie było ograniczone do wąskiej grupy posiadanych urządzeń. A po drugie, w dalszej części pozwoli to nam na zaprezentowanie bardzo przydatnej, choć rzadko stosowanej konstrukcji warunkowej.
 

[...]

 

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 © 2013 Presscom / Miesięcznik "IT Professional"