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


14.05.2019

Bezpłatna konferencja OSEC...

Jako patron medialny serdecznie zapraszamy na bezpłatną konferencję OSEC Forum 2019, któa...
23.04.2019

Optymalizacja zużycia chmury

HPE GreenLake Hybrid Cloud
23.04.2019

Zarządzanie wydajnością

VMware vRealize Operations 7.5
19.04.2019

Technologie open source

SUSECON 2019
19.04.2019

Wyjątkowo małe

OKI seria C800
19.04.2019

Łatwy montaż

Rittal AX i KX
18.04.2019

Technologie wideo

Avaya IX Collaboration Unit
18.04.2019

Krótki rzut

Optoma W318STe i X318STe
18.04.2019

Do mobilnej pracy

Jabra Evolve 65e

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