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



20.07.2018

Laserowe benefity

Brother TonerBenefit
17.07.2018

Laptop konwertowalny

HP ProBook x360 440 G1
13.07.2018

Wiele kanałów komunikacji

Avaya IP Office
10.07.2018

Konwersja VM

Xopero Image Tool (XIT)
06.07.2018

Bezpieczne testy chmury

Usługi Oracle w modelu PAYG
03.07.2018

Centrum innowacji

Nokia Garage
29.06.2018

Trzecia generacja dysków

Samsung SSD NVMe 970 PRO i 970 EVO
26.06.2018

Druk mono

Drukarki Konica Minolta
22.06.2018

Monitor z USB-C

AOC I1601FWUX

Ansible w służbie NOC

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

Rosnące skomplikowanie systemów IT wymusza na architektach standaryzację wdrażanych usług i rozwiązań. Powtarzalność architektury czy jej składników pozwala zautomatyzować proces wdrażania lub usuwania konfiguracji zarówno na urządzeniach sieciowych, hypervisorach, jak i w samych systemach operacyjnych serwerów. Najpopularniejszym z wykorzystywanych do tego celu narzędzi jest Ansible. A gdybyśmy tak spróbowali użyć go jako narzędzia pracy dla inżynierów działu nadzoru?

Praca w centrach operacyjnych takich jak NOC (Network Operations Center), SOC (Security Operations Center), ITOC (IT Operations Center), a także zwykłego działu administracyjnego w przedsiębiorstwie składa się z wielu powtarzalnych czynności. Zadania takie wynikają na przykład z konieczności wykonywania rutynowych czynności związanych z monitorowaniem parametrów pracy infrastruktury IT. Nazywamy je zadaniami BAU (Business As Usual), gdyż służą do weryfikacji, czy wdrożone mechanizmy pracują prawidłowo, urządzenia nie są przeciążone, a cała infrastruktura spełnia przyjęte w projekcie parametry, co na końcu przekłada się na bezproblemowe prowadzenie biznesu. Drugą grupę stanowią zadania wynikające z procedur obsługi alarmów generowanych przez systemy monitoringu lub same urządzenia, reagowania na incydenty bezpieczeństwa oraz inne nieprzewidziane sytuacje. Diagnostyka problemów opiera się na wykonywaniu powtarzalnych, charakterystycznych dla obsługiwanego alertu, czynności.

 
Automatyzacja zadań intensywnie wkracza w obszar zarządzania infrastrukturą IT. Główne powody to:
 
  • konieczność odciążenia inżynierów centrów nadzoru od powtarzalnych czynności i zagospodarowanie ich pracy w innych obszarach;
  • przyspieszenie procesu obsługi incydentu;
  • unifikacja sposobu wykonywania procedur i reagowania na zdarzenia;
  • konieczność wygenerowania raportu w ustandaryzowanej formie zrozumiałej dla mniej i bardziej doświadczonych pracowników.
 
Każdy manager IT zapewne do tej listy dopisałby także wiele swoich własnych argumentów. Nikt natomiast już nie kwestionuje konieczności zmiany podejścia i metody pracy zespołów odpowiedzialnych za bieżącą obsługę systemów IT.
 
Gdy myślimy o Ansible, zazwyczaj w głowie rodzi nam się scenariusz, w którym na podstawie wprowadzonych parametrów szybko i automatycznie budujemy całą infrastrukturę nowej aplikacji. Ale czy stoi coś na przeszkodzie, aby Ansible pomógł w wykonaniu codziennych zadań operacyjno-diagnostycznych? Z całą pewnością nie, choć takie zastosowanie ma kilka ograniczeń i wymagać będzie nieco innego podejścia do tworzenia playbooków. 
 
W pierwszej części przyjrzymy się charakterystyce wymagań stawianych przed automatyzacją procesów operacyjnych, w jaki sposób rozpocząć tworzenie tego typu projektów z wykorzystaniem Ansible oraz jakie dodatkowe narzędzia warto zastosować. 
 
> Struktura projektu dla NOC w Ansible
 
Jedną z podstawowych zasad tworzenia czytelnego kodu jest przygotowywanie możliwie małych elementów funkcjonalnych (na przykład funkcji), które będziemy mogli z powodzeniem wykorzystywać w różnych obszarach naszego projektu czy też w innych projektach. Taka sama idea przyświecała twórcom Ansible i została opisana w dokumentacji. Jednym z jej elementów jest struktura samego projektu. W sekcji Best Practices (tinyurl.com/ansible-bestpr) znajdziemy rekomendowany do zastosowania w projektach układ katalogów oraz jego alternatywną, nieco uproszczoną wersję. Autor preferuje pierwszy z nich, gdyż daje o wiele więcej swobody i lepszą granulację projektu, czyli jego podział na małe funkcjonalne elementy. Pliki z kodem play­booków umieszczamy w głównym folderze – jest to wygodne, gdybyśmy chcieli uruchamiać je z AWX-a, o którym piszemy w dalszej części artykułu. Znaleźć powinny się tam też pliki ze statycznie przygotowanymi danymi do inventory oraz lokalna konfiguracja Ansible w pliku ansible.cfg. Początkowo oba pliki powinny być puste. Zgodnie z wytycznymi zmienne odnoszące się do zdefiniowanych w inventory grup urządzeń oraz do poszczególnych systemów umieszczamy odpowiednio w folderach group_vars oraz host_vars.
 
Segmentację w Ansible uzyskuje się za pomocą podziału na rolę (role). Nieco upraszczając, możemy myśleć o roli jak o bibliotece, która zapewnia określone funkcje, jeżeli zastosujemy ją w naszym playbooku. Role zapisujemy jako podkatalogi w folderze roles, pamiętając, że zarówno struktura każdego z podkatalogów, jak i nazewnictwo głównych plików wewnątrz roli są ściśle zdefiniowane. Różne przykłady wykorzystania ról znajdziemy w dokumentacji (tinyurl.com/ansible-pbroles). My wykorzystamy je, aby stworzyć moduły funkcjonalne, które zróżnicują wykonanie playbooka oraz zapewnią izolację zasięgu działania tworzonych pluginów.
 
Za ilustrację niech posłuży rola, która definiuje sposób wyświetlania podsumowania działania playbooka dla inżyniera centrum nadzoru. Nazwiemy ją Podsumowanie_dla_NOC. Zawiera ona skrypty niezbędne do zebrania informacji, które potem na podstawie szablonu w Jinja2 wyświetlane są w podsumowaniu wykonania playbooka. Aby działanie skryptu zostało zakończone dodatkowym podsumowaniem, wystarczy, że dodamy stworzoną rolę do playbooka. 
 
---
- name: Mój playbook
roles:
– Podsumowanie_dla_NOC
 
Drugim z zastosowań ról jest ograniczenie zasięgu działania naszych pluginów. Kod wtyczki umieszczamy w odpowiednim dla jej typu folderze, który znajduje się w głównym folderze projektu lub folderze wybranej roli. Decyzja o miejscu, w którym umieścimy wtyczkę, ma bardzo duże znaczenie. Wybierając lokalizację w głównym folderze projektu, spowodujemy, że będzie ona domyślnie wykorzystywana przez każdy nasz playbook.
 
Umieszczając ją w folderze wewnątrz roli, jej działanie będzie ograniczone jedynie do playbooków, które się do danej roli odwołują. Zilustrujmy to przykładem pluginu typu Callback, w którym programujemy akcje wyzwalane określonym zdarzeniem, na przykład zakończeniem wykonywania zadania czy całego playbooka. Umieszczenie kodu wtyczki na poziomie projektu spowoduje, że nasz kod będzie wykonywany dla każdego playbooka, co niekoniecznie jest działaniem pożądanym. Lepiej, gdy wykorzystamy go jako element roli. Dzięki temu nasz autorski kod zostanie wykonany jedynie wtedy, gdy odwołamy się do zdefiniowanej roli.
 
[...]
 
Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Pracuje w międzynarodowej instytucji finansowej, dla której projektuje rozwiązania sieciowe, a także jako niezależny konsultant IT. Posiada certyfikat CCIE

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"