Technologia konteneryzacji poczyniła ogromne postępy w obszarze technologii tworzenia oprogramowania jako najbardziej akceptowana metoda pakowania i wdrażania aplikacji w środowiskach chmurowych. Stało się to konieczne ze względu na potrzebę ciągłej integracji (CI) i ciągłego wdrażania (CD), które są definiującymi aspektami DevOps. Programiści i inżynierowie oprogramowania korzystają z kontenerów, aby realizować aspekt CI/CD architektury oprogramowania. Kontener to w zasadzie w pełni spakowana, przenośna i niezależna platforma obliczeniowa. Choć w sieci dostępnych jest kilka platform kontenerowych, najpopularniejszą z nich jest Docker.
Docker to platforma kontenerowa o otwartym kodzie źródłowym, która sprawia, że programowanie jest wydajne i przewidywalne. Docker oferuje publiczne repozytorium obrazów Docker dostępne pod adresem Docker Hub. Zawiera ono wiele otwartoźródłowych obrazów Docker dla najpopularniejszych wdrożeń, które można pobrać i z nich korzystać. Ponieważ jest to repozytorium publiczne, możesz również bezpłatnie dodawać własne obrazy Docker, aby udostępniać je publicznie. Jeśli jednak posiadasz prywatny/własnościowy kod, być może będziesz musiał zapłacić za prywatne repozytorium obrazów lub zbudować własną usługę repozytorium obrazów. W tym miejscu do gry wkracza GitLab.
GitLab to internetowe repozytorium Git, które jest czymś więcej niż tylko narzędziem do kontroli wersji. Zapewnia narzędzia DevOps do ciągłej integracji i wdrażania, śledzenia problemów, rejestrów obrazów Docker i nie tylko. Oferuje trzy opcje: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) oraz GitLab SaaS. GitLab CE i GitLab EE to rozwiązania zarządzane samodzielnie (self-managed), które pozwalają na samodzielne pobranie, instalację i zarządzanie instancją GitLab. GitLab SaaS jest hostowany przez GitLab Inc. i nie musisz się martwić o instalowanie czegokolwiek, aby z niego korzystać.
W poprzednim samouczku pokazaliśmy, jak skonfigurować instancję GitLab na serwerze CloudSigma i hostować własne repozytorium Git. Pokazaliśmy również, jak wdrożyć potoki ciągłej integracji (CI) za pomocą GitLab Runner, aby automatycznie budować i uruchamiać testy przy każdym nowym commicie. Jeśli nie zapoznałeś się ze wspomnianymi samouczkami, zrób to, ponieważ stanowią one podstawę tego samouczka.
W tym samouczku zademonstrujemy, jak zbudować prosty obraz Docker i hostować go na własnej instancji GitLab (niezależnie od tego, czy używasz wersji Community Edition, czy Enterprise Edition – kolejność kroków jest taka sama).
Wymagania wstępne
Aby móc wykonać każdy krok tego samouczka, upewnij się, że posiadasz GitLab CI runner oraz samodzielnie hostowany serwer GitLab , jak wyjaśniono poniżej.
1. Bezpieczny serwer GitLab
Użyjemy go do przechowywania kodu źródłowego, uruchamiania zadań CI/CD i hostowania rejestru obrazów Docker. Powinieneś posiadać serwer z co najmniej 2 rdzeniami procesora (CPU) i 4 GB pamięci RAM, zgodnie z zaleceniami GitLab dotyczącymi instalacji samodzielnie zarządzanej instancji GitLab. Będziesz także potrzebować zarejestrowanej nazwy domeny wskazującej na serwer, ponieważ użyjemy jej do uzyskania certyfikatu SSL od Let’s Encrypt w celu zabezpieczenia serwera. Poniżej znajduje się kilka linków, z których możesz skorzystać, aby skonfigurować samodzielnie hostowaną instancję GitLab.
- Zarejestruj nazwę domeny u dowolnego wybranego rejestratora domen i skieruj ją na CloudSigma.
- Postępuj zgodnie z tym samouczkiem w celu wstępnej konfiguracji serwera Ubuntu, dodania użytkownika bez uprawnień roota oraz włączenia zapory sieciowej UFW w systemie Ubuntu.
- Na koniec postępuj zgodnie z tym samouczkiem, aby zainstalować i skonfigurować samodzielnie hostowaną instancję GitLab.
2. GitLab CI runner
GitLab CI runner jest niezbędny do uruchamiania zautomatyzowanych zadań dla Twoich przypadków testowych. Samouczek dotyczący tego, jak skonfigurować potoki ciągłej integracji GitLab na Ubuntu 20.04 zawiera omówienie serwera GitLab CI i pokazuje, jak wyzwalać zadania. Wykonaj kroki opisane w samouczku, aby skonfigurować usługę GitLab CI runner, jeśli jeszcze tego nie zrobiłeś. Samouczek zawiera aplikację demonstracyjną Node.js z przypadkami testowymi – będziemy z niej korzystać w tym samouczku.
Zaczynajmy!
Krok 1: Konfiguracja uprzywilejowanego GitLab CI Runnera
W samouczku dotyczącym konfiguracji GitLab CI Runnera skonfigurowaliśmy runnera GitLab za pomocą polecenia sudo gitlab-runner register polecenie, które pozwoliło nam na interaktywne dodanie wymaganych parametrów. Chociaż działało to w naszym poprzednim przypadku użycia, którym było uruchamianie kompilacji i testów w odizolowanych kontenerach Docker, może nie poradzić sobie z budowaniem obrazów Docker. Budowanie obrazów Docker wymaga, aby runner miał pełny dostęp do usługi Docker. Możesz osiągnąć tę konfigurację, używając oficjalnego docker-in-docker obrazu do uruchamiania zadań. Taka konfiguracja wiąże się z przyznaniem runnerowi uprzywilejowanego trybu wykonywania.
Podczas gdy przyznanie uprzywilejowanego trybu wykonywania jest niezbędne do budowania obrazów Docker, wiąże się to z problemami z bezpieczeństwem. Wynika to z faktu, że wiąże się to z rezygnacją z zalet bezpieczeństwa kontenerów. Możesz myśleć, że inne runnery Dockera są bezpieczne, ale okazuje się, że mają one te same problemy, jak wyjaśniono w oficjalnej dokumentacji Dockera.
Utworzymy kolejny runner z uprzywilejowanym trybem wykonywania. Będzie to runner specyficzny dla projektu ze względu na wspomniane wyżej implikacje bezpieczeństwa. Będzie on akceptował zadania z projektu Node Pipeline utworzonego w samouczku dotyczącym jak skonfigurować ciągłe potoki CI z GitLab.
Pierwszą rzeczą, którą powinieneś zrobić, jest sprawdzenie, czy Shared Runners są wyłączone w projekcie. Na stronie projektu Node Pipeline kliknij Settings w lewym dolnym menu i wybierz CI/CD w podmenu:
Znajdź przycisk Expand w sekcji Runners i kliknij go, aby wyświetlić szczegóły dotyczące dostępnych runnerów:
Kliknij przełącznik, aby wyłączyć Shared Runners dla tego projektu. Jeśli w poprzedniej sekcji dodałeś runner specyficzny dla projektu, również go wyłącz. Będziemy dodawać uprzywilejowany runner specyficzny dla projektu do uruchamiania zadań dla tego projektu. Gwarantuje to, że nie skończymy z błędami kompilacji w przypadku, gdy GitLab losowo przypisze zadania do runnerów, które nie zostały zarejestrowane z uprzywilejowanym trybem wykonywania. Na powyższym zrzucie ekranu, w zakładce Specific runners powinieneś zobaczyć token rejestracyjny swojego projektu. Zanotuj go, ponieważ użyjesz go poniżej.
| Uwaga: Runner specyficzny dla projektu może być również przypisany do innych projektów z sekcji Admin panel > Runners. Po wybraniu runnera z listy przejdziesz do strony konfiguracji runnera. Przewiń w dół, aby wyświetlić sekcję Restrict projects for this runner: |
Czas uruchomić terminal. Jeśli nie wykonałeś kroków z samouczka dotyczącego tego, jak skonfigurować potoki ciągłej integracji GitLab na Ubuntu 20.04, zrób przerwę w tym samouczku i wykonaj te kroki, aby mieć serwer z usługą runnera GitLab CI. W przeciwnym razie zaloguj się przez SSH na serwer runnera GitLab CI jako użytkownik sudo w celu wykonania kolejnych kroków.
Aby skonfigurować uprzywilejowany runner specyficzny dla projektu, wprowadź następujące polecenie w terminalu, zastępując swoją nazwę domeny i skopiowany powyżej token rejestracyjny:
|
1 2 3 4 5 6 7 |
sudo gitlab-runner register -n \ --url https://your-gitlab-instance-domain.com/ \ --registration-token your-project-specifc-registration-token \ --executor docker \ --description "docker-privileged-builder" \ --docker-image "docker:latest" \ --docker-privilegedh |
Ten wynik pokazuje pomyślną rejestrację:
Aby zweryfikować, czy Twoja instancja GitLab wykryła runner, wróć do przeglądarki i odśwież stronę Settings > CI/CD. Rozwiń sekcję Runners i powinieneś zobaczyć swój runner w sekcji Specific Runners:
Opcjonalnie, jeśli przejdziesz do Admin Panel (klikając przycisk Menu na górnym pasku i wybierając Admin), a następnie wybierzesz Runners w opcjach menu:
Powinieneś trafić na tę stronę pokazującą wszystkie dostępne runnery połączone z Twoją instancją GitLab, zarówno runnery współdzielone, jak i specyficzne dla projektu:
Do tego momentu pomyślnie skonfigurowałeś runner, który może budować obrazy Docker.
Krok 2: Konfiguracja rejestru Docker GitLab
Niektóre kluczowe przepływy pracy wymagają niezależności od usług zewnętrznych. W tym miejscu z pomocą przychodzi samodzielnie zarządzany Docker Registry GitLaba. Jest on nie tylko bezpieczny, ale także zapewnia elastyczność dostosowywania zadań i potoków do własnych potrzeb. Aby skonfigurować Docker Registry, będziesz modyfikować plik konfiguracyjny GitLaba. Najpierw połącz się przez SSH z instancją GitLab, a następnie otwórz plik za pomocą następującego polecenia:
|
1 |
sudo nano /etc/gitlab/gitlab.rb |
Przewiń w dół, aż zobaczysz Container Registry Settings:
Odkomentuj linię z registry_external_url i ustaw ją na nazwę domeny swojej instancji GitLab, określając port 8888 na końcu:
|
1 |
registry_external_url 'https://your-gitlab-domain.com:8888' |
Następnie musimy określić, gdzie rejestr znajdzie certyfikaty Let’s Encrypt, dodając następujące linie. Pamiętaj, aby edytować je, wpisując rzeczywistą nazwę domeny swojej instancji GitLab:
|
1 2 |
registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/your-gitlab-domain.com/fullchain.pem" registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/your-gitlab-domain.com/privkey.pem" |
Po zakończeniu zapisz i zamknij plik. Wprowadź następujące polecenie w terminalu, aby zrekonfigurować GitLab:
|
1 |
sudo gitlab-ctl reconfigure |
Następnie odczekaj kilka sekund na zakończenie wykonywania polecenia. W przypadku powodzenia powinieneś zobaczyć następujące dane wyjściowe:
Następnie musimy upewnić się, że zapora sieciowa (ufw) zezwala na ruch do przypisanego portu rejestru za pomocą polecenia:
|
1 |
sudo ufw allow 8888 |
Następnie musisz przetestować, czy Docker Registry działa, logując się do niego z innej maszyny z zainstalowanym Dockerem za pomocą polecenia docker login. Jeśli nie skonfigurowałeś Dockera w swoim lokalnym środowisku, możesz połączyć się przez SSH z serwerem GitLab CI runner, ponieważ ma on już zainstalowanego Dockera. Następnie wykonaj następujące polecenie, oczywiście podając nazwę domeny swojej instancji GitLab:
|
1 |
docker login your-gitlab-domain.com:8888 |
W danych wyjściowych pojawi się komunikat Login Succeeded, taki jak ten:
Oznacza to, że rejestr został pomyślnie skonfigurowany i działa. Podczas tworzenia obrazów będą one przechowywane lokalnie w systemie plików serwera GitLab. Jest to wystarczające w przypadku prywatnego rejestru firmowego. Jeśli jednak planujesz udostępnić swój rejestr publicznie, możesz potrzebować większej przestrzeni dyskowej. Na szczęście GitLab oferuje opcje łączenia się z kontenerami pamięci masowej (storage buckets). Więcej informacji znajdziesz w oficjalnej GitLab container registry docs, aby dowiedzieć się, jak skonfigurować kontener pamięci masowej dla swojej instancji GitLab.
Krok 3: Zmodyfikuj plik gitlab-ci.yml i zbuduj obraz Dockera
Aby przejść do tego kroku, powinieneś mieć projekt Node Pipeline w swojej instancji GitLab. Oto widok projektu w GitLabie:
Wspominaliśmy o gitlab-ci.yml jako o pliku, który GitLab CI runner odczytuje po uruchomieniu, aby dowiedzieć się, jak zbudować aplikację i przeprowadzić automatyczne testy. Musimy zmodyfikować ten plik, aby dodać instrukcje dotyczące budowania obrazów Dockera. Możesz edytować ten plik bezpośrednio w interfejsie GitLab. Możesz go również sklonować na swoją lokalną maszynę i edytować w swoim ulubionym edytorze, a następnie wykonać zatwierdzenie (commit) i przesłać (git push) z powrotem do GitLab. Dla uproszczenia użyjemy instancji GitLab.
Kliknij plik, aby go otworzyć, a następnie kliknij przycisk Edytuj :
Spowoduje to otwarcie pliku gotowego do edycji. Usuń wszystko z pliku i dodaj następujący kod:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
image: docker:20-dind services: - name: docker:20-dind alias: docker command: ["--tls=false"] stages: - build - test - release variables: TEST_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:$CI_COMMIT_REF_NAME RELEASE_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:latest DOCKER_HOST: tcp://docker:2375 DOCKER_DRIVER: overlay2 DOCKER_TLS_CERTDIR: "" before_script: - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab-domain.com:8888 build: stage: build script: - docker build --pull -t $TEST_IMAGE . - docker push $TEST_IMAGE test: stage: test script: - docker pull $TEST_IMAGE - docker run $TEST_IMAGE npm test release: stage: release script: - docker pull $TEST_IMAGE - docker tag $TEST_IMAGE $RELEASE_IMAGE - docker push $RELEASE_IMAGE only: - master |
Podczas dodawania powyższego fragmentu kodu pamiętaj o zaktualizowaniu wyróżnionej części swoimi rzeczywistymi danymi. Po zakończeniu zapisz zmiany, naciskając przycisk Commit changes. Jeśli pracowałeś poza GitLabem, zatwierdź i wypchnij swoje zmiany.
Zrozummy, co robi kod, który dodaliśmy do pliku .gitlab-ci.yml. Pierwsza linia mówi GitLabowi, aby użył oficjalnego Docker-in-Docker image i dołącza go do usługi docker-in-docker (docker:dind). Następnie definiujemy etapy dla build, test, oraz release. Etap build buduje obraz, korzystając z instrukcji w pliku Dockerfile a następnie przesyła go do Docker Registry, który skonfigurowaliśmy w poprzednim kroku.
Gdy etap build zakończy się pomyślnie, etap test pobiera obraz, uruchamia go jako kontener i wykonuje polecenie npm test, aby przeprowadzić w nim automatyczne testy. Jeśli etap test zakończy się pomyślnie, kontrolę przejmuje etap release. W etapie release obraz jest pobierany i oznaczany tagiem node_pipeline:latest. Następnie jest on ponownie przesyłany do rejestru.
To jest tylko podstawowa konfiguracja dla projektu demonstracyjnego. W rzeczywistych projektach możesz mieć inne etapy, na przykład staging, production, itp. Po zapisaniu pliku po edycji uruchamiany jest potok (pipeline). Następnie rozpoczyna się uruchamianie zadań. Wróć do strony Node Pipeline. Powinieneś zobaczyć, że zadanie jest obecnie uruchomione:
Kliknij ikonę wskaźnika CI, aby wyświetlić różne etapy zadania:
Jak widać na powyższym zrzucie ekranu, wszystkie etapy zakończyły się pomyślnie, co potwierdzają zielone ikony wyboru. Możesz kliknąć każdy etap, aby wyświetlić dane wyjściowe zadania:
W menu po lewej stronie kliknij Packages & Registries i wybierz Container Registry:
Spowoduje to wyświetlenie strony z listą dostępnych obrazów Docker dla wybranego projektu. Obraz, który zbudowaliśmy i wydaliśmy, powinien pojawić się na liście z tagiem przypisanym:
Kliknij, aby wyświetlić różne tagi dla obrazu:
Jeśli masz zainstalowanego Dockera w swoim lokalnym środowisku, możesz pobrać obraz i przetestować, czy działa zgodnie z oczekiwaniami. Kliknij ikonę Copy obok nazwy tagu obrazu. Spowoduje to skopiowanie do schowka pełnej nazwy obrazu, której można użyć z poleceniem docker pull:
|
1 2 |
docker pull feetspark.com:8888/hackins/node_pipeline:latest docker run -it --rm -p 8090:8090 feetspark.com:8888/hackins/node_pipeline:latest |
Powyższe polecenia pobiorą obraz i uruchomią go wewnątrz kontenera:
Aplikacja jest teraz udostępniana na porcie 8090. Jeśli otworzysz przeglądarkę i przejdziesz pod adres twój-adres-IP:8090 powinna wyświetlić się strona:
Jeśli widzisz taką stronę w swojej przeglądarce, oznacza to, że pomyślnie zbudowałeś obraz Docker i udostępniłeś go w prywatnym Docker Registry. W przyszłości, jeśli wprowadzisz jakiekolwiek zmiany w gałęzi master, etapy zdefiniowane w pliku .gitlab-ci.yml zostaną uruchomione, a jeśli zakończą się sukcesem, nowy obraz Docker z tagiem latest zostanie ponownie zbudowany i przesłany do rejestru.
Podsumowanie
W tym projekcie dowiedziałeś się, jak dodać uprzywilejowany runner GitLab do swojej własnej instancji GitLab (self-managed), aby móc budować obrazy Docker. Skonfigurowałeś również prywatny rejestr obrazów Docker do hostowania swoich obrazów. Używając projektu Node pipeline, byłeś w stanie przetestować każdy komponent konfiguracji i upewnić się, że łączą się i komunikują zgodnie z oczekiwaniami. Gdy Twój obraz był już dostępny w rejestrze, mogłeś go pobrać i potwierdzić, że działa wewnątrz kontenera.
To jest samouczek wprowadzający, dający podstawy do dalszego rozwoju. Postępuj zgodnie z oficjalną dokumentacją GitLab, aby dowiedzieć się więcej o GitLab. Ten link może dostarczyć informacji o GitLab Container Registry.
Aby uzyskać więcej zasobów na temat korzystania z Dockera, możesz zapoznać się z innymi samouczkami na naszym blogu:
- Udostępnianie danych między kontenerami Docker
- Konfiguracja prywatnego rejestru Docker na Ubuntu 18.04
- Jak udostępniać dane między kontenerem Docker a hostem
- Czyszczenie zasobów Dockera – obrazy, kontenery i wolumeny
Udanego kodowania!
Komentarze
Brak komentarzy. Bądź pierwszy.