Każdy mechanizm automatyzacji musi mieć swój centralny układ, który mówi mu, jakie czynności ma wykonać. Do takich zaliczamy między innymi skrypty powłoki, małe programy w interpretowanych językach takich jak Perl czy Python lub playbooki Ansible. Odwołują się one bardzo często do innych plików zawierających na przykład szablony konfiguracji w Jinja2. Naszym zadaniem jest zapewnić odpowiednie bezpieczeństwo tym wszystkim plikom. Gdy mówimy o automatyzacji, to na bezpieczeństwo składa się nie tylko kontrola dostępu, lecz także proces śledzenia i akceptacji zmian wprowadzanych do plików, czy sprawdzanie poprawności ich konstrukcji. Z administratorów stajemy się zatem programistami infrastruktury i musimy postępować tak jak oni. Dlatego centralnym i zarazem krytycznym punktem infrastruktury do automatyzacji jest serwer Git.

Nie może być to jednak byle który serwer. Chcemy prowadzić nie tylko repozytorium, ale korzystać z dobrodziejstw grupowej pracy nad projektem. Możemy skorzystać zarówno z komercyjnych rozwiązań, takich jak Atlassian Bitbucket, ja jednak polecam na początek darmowy GitLab. Tak, ten sam GitLab, największy konkurent popularnego GitHub-a. W podstawowej wersji jest on darmowy i przystosowany do instalacji wewnątrz własnej sieci. Uruchomimy go zarówno w postaci natywnej instalacji na serwerze z Linuksem, jak i w kontenerach Dockera. Darmowa licencja zawiera takie funkcjonalności jak zarządzanie kodem (SCM), repozytoria NPM i Maven, prowadzenie projektów w modelu Agile, tworzenie procesów CI/CD, integrację z Kubernetes i wiele innych. Jeżeli przytoczone nazwy Ci niewiele mówią, to warto zagłębić się w ich szczegółowy opis, gdyż często się z nimi będziesz spotykał. Warto też wspomnieć, że GitLab to projekt bardzo intensywnie rozwijany. Nowa wersja wydawana jest 22. dnia każdego miesiąca!

Co prawda scenariusze CI/CD wykonamy w GitLabie, ale do bardziej skomplikowanych będziemy potrzebowali dedykowanego narzędzia. Zainteresujmy się zatem Jenkinsem. Jest to jedno z najstarszych narzędzi tego typu, a jednocześnie dzięki formule wtyczek funkcjonalnych o największych możliwościach. Proces (pipeline) CI/CD to seria czynności, które prowadzą do możliwie częstego wdrażania zmian w głównej linii kodu (Continuous Integration) oraz natychmiastowego ich testowania. Continuous Delivery to kolejny krok polegający na automatyzacji wdrażania wprowadzonych zmian w infrastrukturze. Proces obudowany musi być serią testów walidacyjnych i weryfikacyjnych.

Nie wszystkie zautomatyzowane procesy warto uruchamiać bezpośrednio z Jenkinsa. Automatyzując zadania w swojej infrastrukturze, na pewno często będziemy posługiwać się playbookami Ansible. Większość z nich wymagać będzie podania zróżnicowanych parametrów wejściowych, na przykład listy kont do utworzenia wraz z przydzielanym im poziomem uprawnień. Takie dane da się przekazać do procesu zdefiniowanego w Jenkins, lecz prościej playbooki uruchamiać w Ansible Tower. Jest to stworzony przez RedHat graficzny interfejs do Ansible. Jego zaletą jest prostota używania i elementy bezpieczeństwa minimalizujące ryzyko wykonania playbooka przez osobę nieuprawnioną lub przekazania niepoprawnego typu danych wejściowych, na przykład ciągu znaków zamiast wartości numerycznej. I co, niestety, w dzisiejszych czasach dość istotne, osoba uruchamiająca playbook nie musi mieć dostępu ani umieć korzystać z linii poleceń systemu operacyjnego.

Wszystkie wspomniane aplikacje mają ze sobą kilka wspólnych cech. Po pierwsze są darmowe, co nie znaczy, że na jednej z licencji open-source. Funkcjonalności zawarte w bezpłatnych wersjach są wystarczające by zacząć tworzyć swoje pierwsze mechanizmy automatyzacji. I nie musimy ograniczać się jedynie do tych najprostszych – sam GitLab w darmowej wersji jest wystarczająco rozbudowanym projektem sprawdzającym się nie tylko w firmowym labie, ale i systemach produkcyjnych.

Wszystkie wspomniane produkty uruchomimy w kontenerach Dockera. Zarówno w instalacjach typu stand alone, jak i na przykład klastrze Docker Swarm. Konteneryzacja to ich druga zaleta. Nie tylko dlatego, że pozwala na lepszą skalowalność czy przenaszalność aplikacji, lecz zmusi nas do codziennego obcowania z Dockerem, który jest podstawą działania wielu aplikacji. Ponadto dzięki konteneryzacji w prosty sposób przetestujemy nie tylko różne wersje tego samego narzędzia, lecz elastycznie będziemy mogli dobierać i testować różne produkty. Jenkins okazał się dla nas zbyt skomplikowanym lub niewystarczającym produktem? W prosty sposób możemy go wymienić na przykład na TeamCity, które także uruchomimy w kontenerach.

Trzecią zaletą przedstawionego rozwiązania jest mnogość przykładów konfiguracji i ich wykorzystania zarówno w środowiskach programistycznych, jak i do zarządzania infrastrukturą. Znajdziemy w sieci zatem wiele przykładów wykorzystania, instrukcji czy całych gotowych rozwiązań, które z drobnymi modyfikacjami przeniesiemy do własnej infrastruktury. Gdybyśmy korzystali z niszowych produktów, to potencjalna pomoc mogłaby być mocno ograniczona.