W czasie mojego ostatniego webinaru pokazałem jak zainstalować, skonfigurować i używać AWX, czyli darmową wersję Ansible Automation Platform (dawniej Ansible Tower). Jest to bardzo zaawansowany i rozbudowany produkt, ale nie jedyny na rynku, dlatego dziś kilka słów o jego alternatywach.

GitLab Runner

GitLab Runner jest częścią ekosystemu GitLaba. Sam GitLab pozwala na prowadzenie projektów i kontrolę wersji zgodnie ze standardem git-a. Z kolei GitLab Runner pozwala na wykonanie zadań zdefiniowanych w potokach CI/CD w repozytoriach umieszczonych na serwerze GitLaba. Zadania w nim uruchamiane mogą obejmować takie czynności jak kompilowanie kodu, testowanie oprogramowania, wdrażanie aplikacji lub inne zadania zdefiniowane przez użytkowników. GitLab Runnery są niezależnymi aplikacjami, które instalujemy natywnie w systemie operacyjnym lub zamykamy w kontenerach Dockera. Z pojedynczą instalacją GitLaba może być powiązanych wiele Runnerów, zainstalowanych nawet w odległych centrach przetwarzania danych i na różnych platformach sprzętowych.

Nic nie stoi na przeszkodzie by w takim potoku wykonać playbook Ansible. Jednak najpierw musimy w kontenerze z GitLab Runnerem doinstalować Ansible lub wykorzystać do uruchomienia playbooka obraz kontenera z zainstalowanym Ansible. Jeżeli wybierzemy pierwsze rozwiązanie to proces instalacji Ansible wewnątrz kontenera z GitLab Runnerem możemy wykonać z linii poleceń i proces ten w niczym nie różni się od instalacji Ansible w systemie operacyjnym. 

Następnie tworzymy w repozytorium projektu z naszym playbookiem plik .gitlab-ci.yml. Odpowiadać on będzie za konfigurację potoku CI/CD, czyli listę operacji, które mają zostać wykonane. Potok ten wykona się za każdym razem, gdy zostanie wprowadzona zmiana w repozytorium. Oczywiście możemy go również wywołać ręcznie albo za pomocą mechanizmu webhook wysłać żądanie jego wykonania z innego systemu. Sam plik konfiguracyjny, w zależności od tego co chcemy osiągnąć, może być prosty lub skomplikowany. Najprostszy sposób wykonania playboka umieściłem poniżej:

Pamiętajmy, że zarówno sam skrypt Ansible, znajdujący się w pliku playbook.yml, jak i plik inventory w pliku hosts, muszą znajdować się w repozytorium, z którego będzie wykonywany potok CI/CD. 

GitLab Runner jest idealnym rozwiązaniem dla małych sieci oraz administratorów, którzy dopiero rozpoczynają swoją przygodę z automatyzacją i wybrali GitLab jako swój produkt do utrzymywania repozytorium ze skryptami. Nie wymaga instalacji żadnych dodatkowych komponentów czy programów, ponieważ Runner sam jest częścią gotowego rozwiązania. Zarówno GitLab jak i GitLab Runner mogą być zamknięte w kontenerach Dockera, dlatego takim rozwiązaniem można w bardzo prosty sposób zarządzać oraz w miarę potrzeb je skalować.

Jenkins

Jenkins jest narzędziem do automatyzacji procesów budowania i wdrażania oprogramowania, ale równie dobrze sprawdzi się jako platforma do uruchamiania prostych i zaawansowanych scenariuszy automatyzacji z wykorzystaniem playbooków Ansible. Jenkins pozwala także na monitorowanie stanu projektu oraz wysyłanie powiadomień o błędach i innych ważnych zdarzeniach. Napisany jest w języku Java, a jego szeroka funkcjonalność opiera się o ekosystem wtyczek, które tworzą zarówno producenci, jak i niezależni developerzy. Dlatego aby uruchamiać playbooki Ansible musimy przede wszystkim zainstalować wtyczkę o nazwie „Ansible Plugin”. Dopiero po poprawnej instalacji w kreatorze procesu tworzenia potoku CI\CD, zobaczymy opcje pozwalające na uruchomienie playbooków Ansible. Sam Ansible musi też być zainstalowany na maszynie lub w kontenerze, w którym uruchomiony jest Jenkins, alternatywnie w kontenerze agenta, który odpowiedzialny będzie za wykonanie zadań opisanych w konfiguracji potoku.

Następnie musimy przygotować konfigurację samego potoku CI\CD, rozpoczynając od wskazania repozytorium, z którego ma zostać pobrany kod playbooka.

Jenkins jest na pewno o wiele bardziej rozbudowany i elastyczny niż GitLab, lecz jego obsługa może sprawiać nieco trudności początkującym. Jednakże jego niewątpliwą zaletą jest to, że (podobnie jak w AWX) w Jenkins mamy bardzo dużą kontrolę nad tym kto jest uprawniony do uruchomienia każdego ze skryptów. Takiej szczegółowej kontroli nie daje nam GitLab Runner. Co więcej, osoba uruchamiająca skrypt nie musi mieć dostępu do samego repozytorium, zatem może być odpowiedzialna jedynie za jego wykonanie – bez możliwości wglądu w jego kod źródłowy.