Auto DevOps z GitLab. Rozszerzone funkcje GitLab 11

Nowy GitLab 11 zużywa znacznie mniej pamięci, działa szybciej oraz bardzo przyspiesza proces developmentu. To wygodne narzędzie do realizacji projektów w oparciu o najlepsze praktyki DevOps. Daje możliwość pełnej i automatycznej kontroli nad całym procesem tworzenia.

Jak wspomniałem w poprzednim artykule, nowy GitLab 11 zasługuje na szczególną uwagę ze względu na zautomatyzowanie wszystkich funkcji związanych z DevOps. To zupełna nowość, która wyzwala potencjał twórczy każdego programisty, uwalniając go od manualnych operacji zgodnych z procedurami DevOps. Cały pomysł najnowszej wersji GitLab opiera się na zautomatyzowanych procesach Auto DevOps.

W pierwszej części naszego webinaru możecie dowiedzieć się w jaki sposób GitLab może ułatwić wygenerowanie w pełni automatycznego potoku (pipeline).

Jak Auto DevOps działa w praktyce?

Po zainstalowaniu najnowszej wersji GitLaba możemy przystąpić do realizacji nowego projektu (w wersji On-Premises, wersja Cloud oczywiście dostępna pod adresem Gitlab.com). Po utworzeniu nowego repozytorium GitLab od razu będzie sugerował uruchomienie nowej funkcji Auto DevOps dla naszego projektu (od wersji 11 usługa Auto DevOps jest już domyślnie uruchomiona).

W pierwszej kolejności musimy jednak zdefiniować miejsce wdrożenia naszej aplikacji. GitLab w tym zakresie integruje się z Kubernetesem.

Aby szybko rozpocząć konfigurację klastra Kubernetes, możemy posłużyć się jedną z dwóch opcji integracji:

• pierwsza możliwość – z istniejącym już klastrem gdzie wypełniamy wszystkie niezbędne dane,
• druga możliwość – wykorzystując Google Cloud Platform, w której stworzy się dla nas klaster Kubernetes.

Oczywiście drugie rozwiązanie jest bardzo wygodne i szybkie w działaniu. Jedynym niezbędnym warunkiem jest aktywne konto w ekosystemie Google np. Gmail. W tym miejscu warto zwrócić uwagę na darmowy okres próbny udostępniony przez GCP – jest to 12 miesięcy i 300$ budżetu do wykorzystania na dowolne działania w chmurze.

Zaraz po zalogowaniu się mamy możliwość utworzenia nowego klastra Kubernetes w chmurze Google. Bezpośrednio z GitLaba, wybieramy interesujący nas zone, w którym klaster zostanie utworzony oraz liczbę nodów, która wejdzie w skład nowego klastra, a także ich typ. Akceptując wszystkie ustawienia rozpoczynamy proces tworzenia klastra, który potrwa około 1 minuty – wszystko w zależności od wykorzystanych zasobów.

Kiedy nowy klaster jest już gotowy do działania, możemy łatwo nim zarządzać z pozycji samego GitLaba.

I tak po kolei:

1. Zaczniemy od instalacji na nim Helm Tillera, czyli menedżera aplikacji na klastrze Kubernetes.

2. Następnie zainstalujemy Ingressa, który będzie odpowiedzialny za organizację ruchu w ramach mojego klastra. Będzie on pełnił rolę entrypointa w naszej infrastrukturze. Chwilę po instalacji uzyskamy adres IP jaki został przydzielony dla tej usługi.

3. Na koniec zainstalujemy również Prometheusha odpowiedzialnego za monitoring całego klastra Kubernetes. Po kilku chwilach Prometheus zacznie dostarczać podstawowe informacje dotyczące infrastruktury, a w późniejszym etapie zakres monitoringu będzie znacznie szerszy.

4. Do skonfigurowania pozostała nam jeszcze domena, której używać będzie usługa autodevops w procesach Auto Review i Auto Deploy. W tym miejscu GitLab wyręcza nas, sugerując od razu skorzystanie z darmowego serwisu NIP.IO do wygenerowania tymczasowej domeny dla naszego środowiska.

Po zapisaniu ustawień możemy przejść do widoku repozytorium, a następnie do konfiguracji usługi autodevops.

Jeśli już jesteśmy przy ustawieniach, to w panelu Settings możemy rozszerzyć naszą konfigurację.

Do wyboru mamy trzy różne możliwości dotyczące strategii wdrożenia:

1. Zwykłe wdrożenie na produkcję.

2. Oparte o progi czasowe, systematyczne wdrożenia na produkcję.

3. Wdrożenie na staging i oczekiwanie na manualne triggerowanie wdrożenia na produkcję.

Wybierzmy pierwszą z możliwości i wróćmy do głównego widoku naszego repozytorium. Zakładając, że chcemy wykorzystać istniejący lokalnie projekt, wykonujemy właściwy fragmentu gotowej instrukcji i po chwili nasze repozytorium zdalne w GitLabie jest przygotowane do pracy. GitLab w momencie jakiejkolwiek zmiany w naszym repozytorium (np. push’a lub merge’a) informuje GitLab Runnera o tym, że należy zbudować projekt.

Edycja kodu

Wracając do GitLaba – widzimy, że nasz nowy kod jest już widoczny. Podane jest imię i nazwisko użytkownika, który ostatnio nad nim pracował.

W tym miejscu chciałbym zauważyć, że nasz projekt nie uwzględnia żadnych plików związanych z automatyzacją, które mogłyby cokolwiek sugerować GitLabowi. Po wprowadzeniu niewielkiej zmiany w naszym projekcie:

oraz utworzeniu merge requesta, Gitlab automatycznie stworzy i uruchomi dla nas pipeline CI/CD.

Co ciekawe, mimo że nie skonfigurowaliśmy zupełnie nic w zakresie CI / CD, dzięki nowej usłudze Auto DevOps pipeline zostanie utworzony automatycznie. W oknie obrazującym jego szczegóły będziemy mieli wgląd do wszystkich poszczególnych etapów procesu automatyzacji, która została dla nas przygotowana i uruchomiona.

Zasada działania jest stosunkowo prosta. W pierwszym etapie, do wykonania buildu naszego projektu, GitLab wykorzystuje BuildPack Heroku do wykrycia języka oraz stworzenia właściwego obrazu Dockera. W kolejnym etapie Gitlab przeprowadzi szereg testów i w naszym przypadku będą one dotyczyły jakości kodu oraz testów dostarczonych przez deweloperów wraz z repozytorium kodu. Następnie zostanie stworzone tymczasowe środowisko podglądowe, w którym nasza aplikacja zostanie wdrożona.

W ten sposób uzyskujemy dostęp do podglądu na żywo nowej wersji aplikacji zaraz po wdrożeniu. Na bieżącym etapie możemy ją ocenić i zdecydować czy chcemy kontynuować wdrażanie do środowiska docelowego, czy też w tym miejscu przerwać pracę. Jak wspomniałem Review App ma charakter czysto poglądowy i tymczasowy co oznacza że na jego końcu jest wygaszane a wszystkie wykorzystane zasoby zostają zwalniane.

Wracając jednak do początku i fazy buildu. Odbywa się ono przy wsparciu Heroku – Auto DevOps w GitLab 11 obsługuje wszystkie języki programowania oraz frameworki, które są dostępne za pomocą pakietów buildów Heroku, takich jak Ruby, Rails, Node, PHP, Python i Java. Dzięki temu GitLab automatycznie wykrywa język używany przez programistę i przeprowadza dedykowane dla niego domyślne testy.

Oferty pracy z

Zważywszy na fakt, iż pipeline został wygenerowany automatycznie musimy pamiętać, że bazuje on na domyślnych ustawieniach – w aktualnym etapie uruchomi Kubernetes używając domyślnych ustawień Helm Chart.

Wracając do okna dialogowego (Merge Requests) widzimy pełne zestawienie wykonanych zadań. Do dyspozycji mamy m.in.: wygenerowany adres URL z wdrożoną wersją naszego projekty (tylko do podglądu – nie jest to oczywiście jeszcze wersja produkcyjna) oraz Code Quality z sugestią zmian kodu w celu usprawnienia jego działania.

Jeśli nie mamy żadnych zastrzeżeń możemy przystąpić do mergowania. Po zakończeniu mergowania i przejściu do kategorii Pipelines (lewy panel w opcjach CI /CD) możemy zobaczyć nowy pipeline.

Zmianie ulegają ostatnie fazy działania pipeline’u. W miejscu podglądu wdrożenia (Review App), mamy tym razem ostateczny deployment na środowisku produkcyjnym. W kolejnym kroku, po wyborze Enviroments (lewy panel w opcjach CI /CD), widzimy nasz kod na etapie produkcyjnym. Do dyspozycji mamy domyślnie utworzoną jedną instancję naszego projektu. A co w przypadku gdybyśmy chcieli rozszerzyć skalę działania?

Secret variables

W kategorii Settings i zakładce CI / CD, która znajduje się również w głównym menu, do naszej dyspozycji jest opcja o nazwie Secret variables. Wpisując w polu Key “PRODUCTION_REPLICAS” możemy łatwo zadeklarować pożądaną liczbę instancji naszego projektu.

Wracając do zakładki Environments w kategorii CI / CD, uruchamiamy przycisk Re-deploy. W ten sposób odświeżamy proces wdrożenia w zdefiniowanej przed chwilą skali.

Na tym etapie GitLab udostępnia nam jeszcze jedną ciekawą opcję do monitorowania procesu deploymentu oraz wydajności naszej aplikacji.

Dane są generowane automatycznie i prezentowane w formie wykresów graficznych, za pomocą których możemy dokonać szczegółowej analizy. Tym właśnie jest Auto DevOps – od buildu, poprzez testowanie, weryfikację jakości, następnie wdrożenie do środowiska produkcyjnego, na monitoringu całego procesu kończąc.

Jeżeli chcecie bardziej zgłębić ten temat i jeszcze lepiej poznać możliwości GitLaba – więcej informacji znajdziecie w drugiej części webinaru.

https://www.youtube.com/watch?v=vtXfKY6FLEU

Rozszerzone funkcje GitLab 11 stanowią bardzo dobre wsparcie całego procesu developmentu w ramach dobrych praktyk DevOps. Pełna automatyzacja pozwala zaoszczędzić czas i zwrócić uwagę na większą optymalizację. Nie musimy już myśleć o procedurach i etapach, bo te pojawiają się same i we właściwym momencie. Skontaktuj się z nami jeśli chcesz dowiedzieć się więcej o możliwościach nowego GitLab 11.

Artykuł został pierwotnie opublikowany na deviniti.com. Zdjęcie główne artykułu pochodzi z pexels.com.