Ansible – automatyzacja zarządzania serwerami

Witajcie ludzie :)
Ogromnie dawno tu nie pisałem, ale bardzo dużo pracy w pracy, a i po pracy sporo rzeczy do robienia co spowodowało, że blog odszedł na drugi tor… Ale, ale! W zakładce O mnie dodałem nową fotkę ;) Tak żeby blog nabrał jeszcze bardziej wyrazistego charakteru. Nie wiem czy liczy się to jako aktywność na blogu, więc postanowiłem, że część wolnego wykorzystam do napisania kilku słów o automatyzacji i programie o nazwie Ansible.

Zazwyczaj środowiska produkcyjne, chociaż w sumie developerskie również, są złożone z większej ilości maszyn, przez co szybko zachodzi konieczność obsługi dużej ich ilości, tj. dodawania nowych, aktualizacji oprogramowania itp. Nie ma problemu jeśli mamy trzy serwery do aktualizacji, ale robienie tego samego na trzydziestu serwerach… Może być lekko irytujące. Z odsieczą przychodzi nam Ansible.

Ansible umożliwia spisanie wszystkiego co należy zrobić na serwerze w formie playbooka’a, którego potem odpalamy, wskazując uprzednio jeszcze adresy IP serwerów, na których Ansible ma wykonać owego playbooka.

Aby zademonstrować działanie Ansible użyłem Vagranta aby postawić u siebie (Fedora 25) pięć osobnych maszyn wirtualnych z Centosem 7.
Oczywiście Vagrant dostarcza nam prosty provisioning tworzonych wirtualek, ale tutaj z niego nie będziemy korzystać, gdyż nie to jest naszym celem.

Vagrantfile:

Taki kawałek konfiguracji postawi nam czystego Centosa 7 i skopiuje nam do authorized_keys nasz klucz publiczny (na potrzeby tego wpisu na innym użytkowniku wygenerowałem sobie taki klucz).

Takim kawałkiem basha stawiam 5 wirtualek:

Ansible przy łączeniu się z serwerami wykonuje polecenia z użytkownika na który się logujemy. Tak jak polecenie ssh – korzysta z klucza z lokalizacji ~/.ssh.

Aby korzystać z Ansible konieczne jest stworzenie playbook’a. Takie pliki piszemy używając składni języka YAML. Playbook wyświetlający wersję interpretera Pythona na ekranie może wyglądać tak:

Strefa hosts odnosi się do pliku podanego przy uruchamianiu, w którym trzyma się adresy IP serwerów. Uruchomienie playbooka robi się poleceniem:

gdzie po poleceniu ansible-playbook podajemy nazwę pliku z naszą receptą i po przełączniku „i”, plik z naszymi hostami. Zawartość pliku inventory wygląda tak:

Z tym, że ja mam tutaj specyficzną sytuację – wszystkie moje serwery są na tym samym IP co powoduje konieczność wskazania tego w taki specyficzny sposób jak w sekcji ips. Przy normalnym układzie trzeba tutaj wpisać po enterze nazwy hostów/adresy IP. Sekcja all:vars to zestaw ustawień dla wszystkich sekcji. Ustawienie zmiennej ansbile_ssh_user każe Ansiblowi wykonać polecenie ssh vagrant@localhost -P 2222 zamiast ssh localhost -P 2222 :)

Wracając do naszego playbooka, pod sekcją hosts mamy sekcję tasks i to tutaj piszemy naszą receptę, czyli ten zestaw kroków co i jak zrobić. Ustawiamy nazwę, następnie dzięki poleceniu command wykonujemy polecenie uname -a co zwróci nam wersję jądra i wynik tej operacji rejestrujemy do zmiennej o nazwie linux_version. Drugim i ostatnim krokiem jest wypisanie tego co polecenie zwróciło na standardowe wyjście na ekran w przyjaznej formie. W zmiennej linux_version jest też standardowe wyjście błędów itp. ogólnie użyteczne funkcje. Odpalając tego playbooka zobaczymy coś takiego:

I pod tym podsumowanie:

Więc wszystkie ładnie :) Ale samo uzyskiwanie informacji jest mało dynamiczne. Zróbmy coś innego – zainstalujmy Pythonowego pipa:

Tutaj dochodzi pod sekcją hosts, sekcja become która pozwala uruchamiać polecenia z użytkownika root. Tutaj po kolei – sprawdzamy i wyświetlamy wersję Pythona, następne używając modułu yum instalujemy program wget. Pobieramy nim pliczek „get-pip.py”, uruchamiamy go i sprzątamy po sobie, usuwając ten plik. Takie operacje już by chwilkę zajeły, gdybyśmy mieli je robić ręcznie na 30 serwerach. Podgląd efektu:

I od teraz każdy z naszych pięciu serwerów posiada zainstalowanego pipa :)

Ważną rzeczą jest też kopiowanie plików na serwery zdalne. W ansiblu możemy napisać taki playbook który na każdy serwer skopiuje wskazane przez nas pliki do wskazanego przez nas miejsca. A przy okazji pokażę jak używać zmiennych dołączanych do playbooka.
A więc YAML:

Pierwszy task to dołączenie zmiennych z pliku znajdującego się w katalogu „vars” o nazwie „file_names.yml”. Wygląda on tak:

Definiujemy tutaj tablicę o nazwie „to_upload” o elementach index.html, readme.txt i smile.jpg.

W naszych playbooku, podczas taska numer 2 wypisujemy na ekran nazwy plików. Dyrektywa with_items pozwala na iterację po zmiennej, która jest w zewnętrznym pliku. Każdy element zmiennej to_upload jest dostępny pod nazwą item.

Trzeci i ostatni task to właściwe kopiowanie – kopiujemy elementy tablicy to_upload z folderu o tej samej nazwie do katalogu domowego serwera zdalnego. W pseudokodzie można by to zapisać tak:

Jeszcze taka mała dygresja – przed każdym naszym pierwszym taskiem jest wykonywany zawsze task o nazwie Gathering Facts. Zbiera on kilkanaście przydatnych informacji o każdym z hostów, takich jak nazwa dystrybucji systemu, procesor, wersja jądra itp. Całość można podejrzeć wykonując

przedstawione informacje będą odnosiły się do localhosta.

No i czas zrobić coś co ma wartość konkretną – załóżmy, że posiadamy stronę, która jest postawiona za loadballancerem. No i nagle klient odnotowuje nagły wzrost odwiedzin i każe nam szybciutko zwiększyć wydolność strony. Daje nam kasę, błogosławieństwo i termin na dziś wieczór. Idziemy więc do OVH, kupujemy cztery wirtualki, każda z innego Data Center, dostajemy cztery adresy IP i siadamy do napisania playbooka:

Dodajemy potrzebne nam repozytorium i instalujemy lighttpd. Wczytujemy listę plików do podgrania, wrzucamy je do katalogu głównego lighttpd i restartujemy usługę. I koniec.

A jak przeforwardujemy sobie port 80 z którejkolwiek wirtualki na hosta to możemy otworzyć przeglądarkę i zobaczyć np. coś takiego:

Ale idźmy dalej z automatyzacją tego!

Skoro odpalamy playbooka takim poleceniem:

to możemy pokusić się o przeniesienie playbooków do bardziej stronniczego miejsca, np. do /opt/playbooks/ co zmieni naszą komendę na

Dalej wrzućmy to w plik bash:

Zmieniliśmy nazwę pliku z hostami na „$1” co powoduje, że nazwę tę zaczyta z wywołania pliku bash:

ale idźmy dalej, przenieśmy plik install.sh do folderu /opt i stwórzmy na niego alias – tzn. w pliku .bashrc dopiszmy na końcu linijkę

i wykonajmy polecenie:

co spowoduje zaaplikowanie stworzonego właśnie aliasu, a naszego ansible’a będziemy mogli uruchomić jednym, krótkim poleceniem:

gdzie inventory to nazwa pliku z hostami.

Takie magie są fajne, bo skracają czas na ewentualne późniejsze użycia takiej funkcjonalności, a i ukrywają implementację co zabezpiecza przed ewentualnym zepsuciem tego procesu. Ale ma to też drugą stronę medalu, porobiliśmy sobie dwadzieścia takich komend, zatrudniamy Juniora i nagle dajemy mu dwadzieścia komend, które robią dosłownie wszystko iiii… Szok! Czarna dziura dla nowego gościa. Dostaje automagiczną komendę, która robi wszystko bez jakiegokolwiek zrozumienia całego procesu, bez świadomości jak on przebiega. I teraz mogą się stać dwie rzeczy, albo gość do końca swojego życia będzie używał tych poleceń bez zrozumienia, ale zacznie szukać jak to działa i albo ogranie (kosztem czasu) albo nie ogarnie. Chcę przez to powiedzieć, że takie skróty powinny być tłumaczone nowym osobom. Świadomość tego co się robi jest serio bardzo ważna i ogromnie poszerza wiedzę na temat systemu, przestaje on być ogromnie magicznym bytem, a staje się po prostu tym czym jest… Ogromną ilością sprytnych ifów, forów i while’ów.

Ansible to potężne narzędzie, które nie raz pozwoli Wam na zaoszczędzenie ogromnej ilości głupiej pracy. Tym miłym akcentem zakończę dzisiejszy wpis.