Pipelines CI/CD w GitLab na NSIS Kubernetes - tworzenie obrazu Docker
GitLab zapewnia odizolowany, prywatny rejestr kodu i przestrzeń do współpracy zespołów nad kodem. Oferuje również szeroki zakres możliwości automatyzacji wdrażania kodu. W tym artykule wyjaśnimy, jak zautomatyzować tworzenie obrazu Docker aplikacji.
Co zostanie omówione?
Dodawanie klucza publicznego do GitLab i uzyskiwanie dostępu do GitLab z wiersza poleceń.
Tworzenie projektu w GitLab i dodawanie przykładowego kodu aplikacji.
Definiowanie zmiennych środowiskowych za pomocą parametrów DockerHub w GitLab.
Tworzenie pipeline do tworzenia obrazów Docker aplikacji przy użyciu Kaniko.
Uruchamianie kompilacji pipeline
Wymagania wstępne
Nr 1 Konto
Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Klaster Kubernetes
Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
Nr 3 Dostępna lokalna wersja GitLab
Twoja lokalna instancja GitLab jest dostępna i poprawnie osiągalna dla Twojego użytkownika GitLab.
W tym artykule zakładamy konfigurację zgodną z artykułem Instalacja GitLab na platformie NSIS Kubernetes. Jeśli używasz innej instancji GitLab, mogą wystąpić pewne różnice, np. gdzie niektóre funkcje znajdują się w GUI.
W tym artykule jako instancji gitlab będziemy używać gitlab.mysampledomain.info. Pamiętaj, aby ją zastąpić nazwą własnej domeny.
Nr 4 Działający git CLI
Polecenie git zainstalowane lokalnie. Można go używać z GitHub, GitLab i innymi platformami kontroli źródła opartymi na git.
Nr 5 Konto w DockerHub
Dostęp do DockerHub (lub innego rejestru obrazów kontenerów).
Nr 6 Użycie Kaniko
Kaniko to narzędzie do budowania obrazów kontenerów na podstawie dostarczonego pliku Dockerfile. Bardziej szczegółowy przegląd Kaniko można znaleźć w jego dokumentacji.
Nr 7 Dostępne klucze prywatne i publiczne
Aby połączyć się z naszą instancją GitLab, potrzebujemy kombinacji klucza prywatnego i publicznego. Możesz użyć dowolnej pary kluczy, jedną z opcji jest użycie do jej utworzenia OpenStack Horizon. Aby uzyskać więcej informacji, zobacz artykuł:
Jak utworzyć parę kluczy w OpenStack Dashboard na NSIS Cloud
Tutaj, aby połączyć się z instancją GitLab, używamy pary kluczy, którą wcześniej zainstalowaliśmy zgodnie z Wymaganiem wstępnym nr3.
Krok 1 Dodaj swój klucz publiczny do GitLab i uzyskaj dostęp do GitLab z wiersza poleceń
Aby umożliwić dostęp do instancji GitLab z wiersza poleceń, GitLab używa uwierzytelniania opartego na SSH. Aby upewnić się, że konsola domyślnie używa tych kluczy do uwierzytelniania, upewnij się, że klucze są przechowywane w katalogu ~/.ssh i nazywają się id_rsa (klucz prywatny) i id_rsa.pub (klucz publiczny).
Klucz publiczny powinien następnie zostać dodany do autoryzowanych kluczy w GUI GitLab. Aby dodać klucz publiczny, kliknij ikonę swojego awatara:
Następnie przejdź do „Preferences”, wybierz pozycję „SSH Keys” z menu po lewej stronie i wklej zawartość swojego klucza publicznego w polu „Key”.
Jeśli używana instancja GitLab jest hostowana na przykład w domenie mysampledomain.info, można użyć polecenia
ssh -T git@gitlab.mysampledomain.info
aby sprawdzić, czy masz dostęp do GitLab z interfejsu CLI.
Wynik powinien być podobny do tego:
Krok 2 Utwórz projekt w GitLab i dodaj przykładowy kod aplikacji
Najpierw dodamy przykładową aplikację w GitLab. Jest to minimalna aplikacja Python-Flask, której kod można pobrać z repozytorium NSIS GitHub dołączonego do bazy wiedzy.
W pierwszym kroku tej sekcji zainicjujemy zdalne źródło GitLab. Zaloguj się do GUI GitLab i przejdź do domyślnego ekranu, kliknij przycisk „New Project”, a następnie „Create blank project”. Spowoduje to przeniesienie do poniższego widoku.
W tym widoku adres URL projektu będzie wstępnie uzupełniony i będzie odpowiadał adresowi URL Twojej instancji GitLab. W miejscu zaznaczonym czerwonym prostokątem należy wpisać nazwę użytkownika; zazwyczaj będzie to root, ale może to być również inna nazwa. Jeśli w GitLabie są już zdefiniowani jacyś użytkownicy, ich nazwy pojawią się na liście rozwijanej.
Wprowadź preferowaną nazwę projektu i slug, w naszym przypadku odpowiednio „GitLabCI Sample” i „GitLabCI-sample”. Wybierz poziom widoczności zgodnie z własnymi preferencjami. Odznacz pole „Initialize repository with a README”, ponieważ zainicjujemy repozytorium z istniejącego kodu. (Nie inicjujemy repozytorium, tylko tworzymy projekt w źródle).
Po przesłaniu formularza „Create project” otrzymasz listę poleceń do pracy z repozytorium. Przejrzyj je i przełącz się na CLI. Sklonuj całe repozytorium CloudFerro K8s samples, a następnie rozpakuj podkatalog o nazwie HelloWorld-Docker-image-Flask. Dla większej przejrzystości zmieniamy nazwę jego zawartości na nowy folder GitLabCI-sample. Jeśli po raz pierwszy pracujesz z tym artykułem, użyj polecenia
mkdir ~/GitLabCI-sample
aby katalog był gotowy do wykonania następującego zestawu poleceń:
git clone https://github.com/CloudFerro/K8s-samples
mv ~/K8s-samples/HelloWorld-Docker-image-Flask/* ~/GitLabCI-sample
rm K8s-samples/ -rf
Po wykonaniu powyższej sekwencji kroków mamy katalog GitLabCI-sample z 3 plikami:
app.py, który zawiera kod naszej aplikacji Python Flask,
plik Dockerfile oraz
plik zależności requirements.txt.
Następnie możemy przejść do tego folderu (cd), zainicjować repozytorium git, zatwierdzić je lokalnie i wysłać je do zdalnego za pomocą następujących poleceń (zamień w nich domenę i nazwę użytkownika):
cd GitLabCI-sample
git init
git remote add origin git@gitlab.mysampledomain.info:myusername/GitLabCI-sample.git
git add .
git commit -m "First commit"
git push origin master
Najprawdopodobniej nazwą użytkownika myusername będzie w tym przypadku po prostu root.
Po przejściu GUI GitLab możemy zobaczyć, że nasze zmiany zostały zatwierdzone:
Krok 3 Zdefiniuj zmienne środowiskowe za pomocą parametrów DockerHub w GitLab
Chcemy utworzyć pipeline CI/CD, który po kolejnym zatwierdzeniu utworzy obraz Docker naszej aplikacji i prześle go do rejestru kontenerów Docker Hub. Użyjmy zmiennych środowiskowych w GitLab, aby umożliwić połączenie z rejestrem Docker. Użyj następujących kluczy i wartości:
CI_COMMIT_REF_SLUG=latest
CI_REGISTRY=https://index.docker.io/v1/
CI_REGISTRY_IMAGE=index.docker.io/yourdockerhubuser/gitlabci-sample
CI_REGISTRY_USER=yourdockerhubuser
CI_REGISTRY_PASSWORD=yourdockerhubrepo
Pierwsze dwa, CI_COMMIT_REF_SLUG i CI_REGISTRY są zakodowane na stałe dla DockerHub. Pozostałe trzy to:
- CI_REGISTRY_IMAGE
Nazwa obrazu Docker, który ma zostać utworzony. Wprowadź nazwę użytkownika dla witryny Docker Hub (yourdockerhubuser). Jeśli na przykład nazwa użytkownika to paultur, obraz w rejestrze Docker będzie miał nazwę /paultur/gitlabci-sample, jak widać na końcu tego artykułu.
- CI_REGISTRY_USER
Wpisz yourdockerhubuser, która jest nazwą użytkownika w Docker Hub.
- CI_REGISTRY_PASSWORD
Wpisz yourdockerhubrepo, może to być hasło do konta lub specjalnie utworzony access token. Aby utworzyć taki token, zobacz opcję Account Settings –> Security w witrynie Docker:
Wróć do interfejsu użytkownika GitLab, z menu Settings w widoku projektu przejdź do podmenu CI/CD:
Przejdź do sekcji „Variables” poniżej i wypełnij odpowiednie formularze. W graficznym interfejsie użytkownika będzie to wyglądać mmniej więcej tak:
Teraz, gdy wartości zmiennych są już skonfigurowane, użyjemy ich w naszym pipeline CI/CD.
Krok 4 Utwórz pipeline, aby utworzyć obraz Docker aplikacji przy użyciu Kaniko
Pipeline CI/CD, który tworzymy w GitLab, będzie miał tylko jedno zadanie, które
tworzy obraz i
wysyła go do rejestru obrazów Docker.
W rzeczywistych scenariuszach pipelines mogą również zawierać dodatkowe zadania, na przykład testy jednostkowe lub integracyjne.
GitLab rozpoznaje, że repozytorium/projekt są skonfigurowane do wdrożenia pipeline CI/CD na podstawie obecności pliku .gitlab-ci.yml w katalogu głównym projektu. Można zastosować CI/CD do projektu również z GUI GitLab (pozycja menu CI/CD → Pipelines), używając jednego z dostarczonych domyślnych szablonów. Rezultatem będzie jednak dodanie specjalnie skonfigurowanego pliku .gitlab-ci.yml do katalogu głównego projektu.
Utwórz teraz plik .gitlab-ci.yml o zawartości jak poniżej i umieść go w katalogu GitLabCI-sample. Plik zawiera konfigurację naszego pipeline i definiuje pojedyncze zadanie o nazwie docker_image_build.
.gitlab-ci.yml
docker_image_build:
image:
name: gcr.io/kaniko-project/executor:v1.14.0-debug
entrypoint: [""]
script:
- echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\" }}}" > /kaniko/.docker/config.json
- >-
/kaniko/executor
--context "${CI_PROJECT_DIR}"
--cache=false
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}"
Gdy zmiany w projekcie zostaną zatwierdzane w GitLab, pipeline CI/CD jest uruchamiany automatycznie.
Zadania są wykonywane przez runner GitLab. Jeśli korzystasz z instancji GitLab zgodnie z Wymaganiem wstępnym nr 3 Dostępna lokalna wersja GitLab, domyślny runner zostanie już wdrożony w klastrze. W takim przypadku runner wdraża krótkotrwały pod dedykowany do uruchomienia tego konkretnego pipeline. Jeden z kontenerów uruchomionych w podzie jest oparty na obrazie Kaniko i służy do budowania obrazu Docker naszej aplikacji.
W kluczu script znajdują się dwa kluczowe polecenia, które są wykonywane podczas uruchamiania kontenera Kaniko. Oba przyjmą wartości według zmiennych środowiskowych, które wcześniej wprowadziliśmy do GitLab.
- Wypełnienie i zapisanie zawartości standardowego pliku konfiguracyjnego
Pierwsze polecenie wypełnia i zapisuje zawartość pliku config.json, który jest standardowym plikiem konfiguracyjnym używanym do uwierzytelniania w DockerHub.
- Utworzenie i publikacja obrazu kontenera w DockerHub
Drugie polecenie kompiluje i publikuje obraz kontenera w DockerHub.
Krok 5 Uruchamianie kompilacji pipeline
Zatwierdzenie powoduje uruchomienie pipeline. Po dodaniu pliku należy opublikować zmiany w repozytorium za pomocą następującego zestawu poleceń:
git add .
git commit -m "Add .gitlab-ci.yml"
git push origin master
Po zatwierdzeniu, jeśli przejdziemy do ekranu CI/CD naszego projektu, powinniśmy zobaczyć, że pipeline jest najpierw w stanie uruchomionym, a następnie ukończonym:
Również podczas przeglądania rejestru Docker obraz jest publikowany:
Co można zrobić dalej?
Dodaj do tego pipeline testy jednostkowe i integracyjne. Można je dodać jako dodatkowe kroki w pliku gitlab-ci.yml. Pełne odniesienie można znaleźć tutaj: https://docs.gitlab.com/ee/ci/yaml/