Czytając i ucząc się OpenStack co chwilę natrafiłam na coś co nazywa się Ansible – ba nawet na jednych warsztatach stawiałem na OpenStack wordpressa w pełni wykorzystując Ansible. Stwierdziłem więc, że lepiej opiszę na początku co to jest zanim powiem no i odpalamy playbook. A, że okazało się iż Ansible to coś więcej niż odpalamy playbook, sądzę, że na tym czym jest a czym nie jest, każdy skorzysta. Nie wybiegajmy jednak za bardzo w przyszłość.

Pytanie czy ktoś z was czytał/oglądał Grę Endera? Jak nie, to pora to nadrobić. Już teraz. Post poczeka. Praca też ;) Ansible było użyte w książce do komunikacji Endera z flotą kosmiczną. Jak to jednak w świecie bywa, nie było to pierwsze użycie ansible. Wcześniej, Ansible zostało użyte przez Ursula K. Leguin w powieści Świat Rocannona i opisane jako fikcyjny komputer/technologia umożliwiająca natychmiastową (szybszą od światła) komunikację – wysyłanie i odbierania wiadomości nie ważne z jak daleka.

Autor oprogramowania, wziął sobie do serca klasyki Si-Fi i użył słowa Ansible, do określenia aplikacji/narzędzia które umożliwia natychmiastową komunikację z serwerami i przekazywanie i odbierania od nich wiadomości. Brzmi trochę skomplikowanie – choć wcale takie nie jest. Ansible to narzędzie które działa na zasadzie komunikacji kontroler <-> node. Przy czym, kontroler to miejsce odpalenia aplikacji, zaś node to komputer, do którego chcemy się podłączyć. Node nie musi posiadać, żadnego dodatkowego softu, wystarczy ssh. Komunikacja tutaj polega na wykonaniu pewnych kroków/zadań po stronie serwera. Ot tyle i aż tyle.

Oczywiście, samo odpalanie skryptów zdalnie jakoś wcale nie zachęca do tego by z aplikacji skorzystać. Dlatego też ansible działa trochę inaczej niż odpalenie skrytpu PowerShell, to co robi to:

  • Podłącza się do node
  • Wgrywa tam małe aplikacje moduły
  • Moduły to zasoby wykorzystywane w opisie deklaratywnym stan systemu
  • Moduły są następnie wykonywane
  • Po wykonaniu moduły są kasowane

Słowo klucz tutaj to deklaratywny stan systemu. Czyli coś co nam opisuje jaki jest pożądany końcowy stan – jeżeli coś odbiega od założeń my mamy prawo odpowiednio zareagować, jak? zależy od nas.

Z czego składa się więc ansible?

Można wyróżnić kilka elementów ansible.

Moduły

To małe aplikacje napisane w dowolnym języku skryptowym, które wykonują jakąś konkretną pojedynczą czynność. Najlepiej jakby były idempotentne. Moduły można odpalać pojedynczo (imperatywnie) lub deklaratywnie za pomocą opisanego stanu końcowego.

Inventory

To nic innego jak lista serwerów, do których ansible będzie się podłączało i które będzie “monitorowało”. Serwery można łączyć w grupy i potem do grup się odwoływać. Plusem jest to, że na podstawie takiej ów listy potem można budować zbiór różnych konfiguracji w zależności od serwera.

Lista serwerów zaś może pochodzić z zewnętrznego źródła – na przykład Azure, OpenStack czy Google Cloud.

Playbook

To nic innego jak opis deklaratywny stanu systemu – narzędzie orchiestracji tego co ma być zrobione. To jak bardzo to będzie skomplikowane to zależy już od nas. Może to być tak proste jak odpalenie komendy restartu komputera czy bardziej skompilowane jak i deployment wordpressa ze wszystkimi zależnościami.

Proste w opisie, bardzo złożone z wieloma opcjami w rzeczywistości. Przy prostych zastosowaniach, playbooki mogą być naprawdę super banalne. To co jednak daje nam ansible to możliwość modelowania dużo bardziej złożonych deklaratywnych opisów stanu systemu. Dla przykładu nasz playbook może zawierać listę tasków, ale także zamiast tego może się odwoływać do re-używalnych ról – które same w sobie są taksami. Może też na początku wykonywać zadania dla grupy serwerów web a potem dla grupy serwerów data.

Możliwości są, trzeba wiedzieć tylko co chce się osiągnąć.

Instalacja ansible

By móc korzystać z ansible, musimy go zainstalować. W zależności od systemu różnie się go instaluje. Na przykład mac to banalne:

brew install ansible

Nie liczcie za dużo na systemie windows. Ansible jest produktem na systemy *nix. Są moduły do komunikacji z windows jednak to nie jest takie piękne i ładne jak z *nix i do tego wymaga czasami pewnej ekstra konfiguracji. Aktualnie możemy skorzystać z Ansible wykorzystując Linux Bash, więc dla chętnych polecam.

Podsumowanie

Jedyny problem jaki ja mam z ansible to według autorów oni chcieli mieć proste narzędzie, które nie będzie stało na przeszkodzie tworzenia skryptów. Jednak patrząc na dokumentację mam wrażenie, że coś gdzieś poszło źle.

Nie zmienia to faktu, że ansible szybko staje się coraz popularniejsze – nie tylko wśród linuxowców, ale także wśród ludzi tworzących rozwiązania pod Azure, OpenStack, AWS czy Google Cloud.

Jako wprowadzenie do Ansible chyba wystarczy. Następnym razem zrobimy mały playbook by zobaczyć jak to się je i co jest możliwe. A tak kompletnie z ciekawości, kto w zaś korzysta już z ansible? Kto o nim słyszał?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

10 KOMENTARZE

  1. Słyszałem, widziałem, ale nigdy nie korzystałem osobiście, a chciałbym poznać bliżej. Fajnie się składa, że akurat poruszasz ten temat :)

  2. Natknąłem się na niego pierwszy raz w Grze Endera. Jak dotąd najlepsza rzacz jaką czytałem (dotyczy wszystkich części). Chociaż minęło już naprawdę dużo czasu i książek, nic nie “wessało” mnie bardziej niż to. Dla tych, którzy, chcą spróbować nie polecam zaczynać od filmu. Nie żeby był totalnie do bani, ale bez tła, które daje książka, może być błędnie odebrany jako zwykły film akcji. A wracając do Ansible, to drugie spotkanie nastąpiło kiedy szukałem rozwiązania do szybkiego konfigurowania środowiska na Linuksie (automatyzacja wielu powtarzalnych czynności na nowych maszynach). Z kilku dostępnych rozwiązań (https://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html) Ansible wydał mi się jednym z lepszych, chociaż w podlinkowanym rozwiązaniu wyszło inaczej. Niestety temat zostal odłożony na bliżej nieokreśloną przysłość ze względu na inne proprytety, ale mam nadzieję, że dzięki Twoim wpisom, wróci na mój radar :)

    • tak, pierwsza jest najlepsza. reszta to… ;)

      najlepsza opcja natrafienia na produkt jest wtedy kiedy jest nam on potrzebny :) fajnie ze z niego natrafiłeś. to do przeczytania wiec niebawem :) postaram się kilka rzeczy o ansible opublikować.

  3. Używam od pół roku w Azure. Wcześniej pracowałem też z SaltStack. Na plus prostsza konfiguracja zmiennych i zadań do wykonania na środowisku oraz brak konieczności instalowania na klientach. Jeśli utworzymy sobie obraz dla Dockera to nie musimy instalować na Windows wszystkich zależności – odpalamy kontener ze współdzielonym katalogiem z konfiguracją dla Ansible i vou la. A i będzie to działać z każdym CI jak np. VSTS.

    Ale jest pewno “ale” jeśli chodzi o pracę ze środowiskami dynamicznymi. Ansible jak i pozostałe tego typu narzędzia najlepiej sobie radzi z konfiguracją istniejących środowisk. Jeśli planujemy wykorzystać Ansible do dynamicznego budowania np. w Azure to możemy się rozczarować. Moduł Azure dla Ansible ma braki, błędy, generuje ostrzeżenia i najlepszą metodą jest wywoływanie poleceń Azure CLI. Jako “must have” polecam korzystanie z biblioteki jq, która umożliwi nam pracę w danymi typu JSON, które zwraca Azure CLI.

    • Trochę nie zgodzę się, że najlepiej radzi sobie z konfiguracją istniejących środowisk – w końcu i tak trzeba to uruchomić wobec czegoś co istnieje, chociażby minimalnego obrazu linuxa :). Nie stoi jednak nic na przeszkodzie aby mieć role, która tworzy całe środowisko (instaluje niezbędne aplikacje na minimalnym iso) a następnie generuje z tego kolejny obraz dysku, vagrant bardzo dobrze się tu sprawdza.
      Z dockerem przy ansible bym uważał, o ile wiem to narzędzie nie ma wbudowanego trzymania stanu zależności dockerowych – zatem odpada największa zaleta ansible, którą jest właśnie weryfikacja stanu platformy i podejmowanie decyzji o instalacji. Docker świetnie się sprawdza o ile śledzimy kolejne wersje obrazów. Łatwo też o problemy gdy rola ansiblowa oczekuje modułu z docker image, który ktoś usunął albo zmienił w definicji obrazu. Ciężko to wykryć przy code review, zatem ponownie odpalenie na virtualce + bardzo dobre testy są koniecznością.
      Fakt jednak, że prędzej czy później kończy się na wgrywaniu na środowiska binarek (jak wspominane Azure CLI), z drugiej strony nie jest to jakaś nowość jeżeli chodzi o zarządzanie stanem środowisk.

  4. Wspaniały opis Ansible! Wreszcie ktoś przemówił zrozumaiłym językiem na ten temat. Czekam na kolejną część z niecierpliwością!

  5. Hej, zabanet wspomnial o tworzeniu wielu maszyn, jaka jest wiec roznica miedzy takim ansiblowym playbookiem, a skryptem shellowym?

Comments are closed.