Potoki CI/CD z GitLab na NSIS Kubernetes - tworzenie obrazu Docker
GitLab zapewnia odizolowany, prywatny rejestr kodu i przestrzeń do współpracy nad kodem przez zespoły. Oferuje również szeroki zakres możliwości automatyzacji wdrażania kodu. W tym artykule wyjaśnimy, jak zautomatyzować tworzenie obrazu Docker aplikacji.
Co będziemy omawiać
Dodaj swój klucz publiczny do GitLab i uzyskaj dostęp do GitLab z wiersza poleceń.
Utwórz projekt w GitLab i dodaj przykładowy kod aplikacji
Definiowanie zmiennych środowiskowych za pomocą współrzędnych DockerHub w GitLab
Tworzenie potoku do tworzenia obrazu Docker aplikacji przy użyciu Kaniko
Wyzwalanie kompilacji potoku
Wymagania wstępne
Nr 1 Konto
Potrzebne jest 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 dostępna dla Twojego użytkownika GitLab.
W tym artykule zakładamy konfigurację zgodną z tym 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 będziemy używać gitlab.mysampledomain.info jako instancji gitlab. Pamiętaj, aby zastąpić ją własną domeną.
Nr 4 git CLI operacyjne
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 is a tool to build container images based on a provided Dockerfile. For more elaborate overview of kaniko refer to its documentation.
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 OpenStack Horizon do jej utworzenia. Aby uzyskać więcej informacji, zobacz:
Zobacz Jak utworzyć parę kluczy w OpenStack Dashboard na NSIS Cloud.
Tutaj używamy pary kluczy, aby połączyć się z instancją GitLab, którą wcześniej zainstalowaliśmy w warunku wstępnym nr 3.
Krok 1 Dodaj swój klucz publiczny do GitLab i uzyskaj dostęp do GitLab z wiersza poleceń
Aby uzyskać 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 folderze ~/.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 przewiń do „Preferencji”, wybierz „Klucze SSH” z menu po lewej stronie i wklej zawartość swojego klucza publicznego w polu „Klucz”.
* * Jeśli instancja GitLab, z której korzystasz, jest hostowana, powiedzmy, w domenie mysampledomain.info, możesz użyć polecenia w następujący sposób
ssh -T [email protected]
aby sprawdzić, czy masz dostęp do GitLab z interfejsu CLI.
Powinieneś zobaczyć wynik podobny do poniższego:
* * 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 towarzyszącego tej bazie wiedzy.
Jako pierwszy krok w tej sekcji, zainicjujemy zdalne pochodzenie 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.
* * In that view, project URL will be pre-filled and corresponding to the URL of your GitLab instance. In the place denoted with a red rectangle, you should enter your user name; usually, it will be root but can be anything else. If there already are some users defined in GitLab, their names will appear in a drop-down menu.
* * 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 „Utwórz projekt” 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 wyodrębnij podfolder o nazwie HelloWorld-Docker-image-Flask. Dla przejrzystości zmieniamy nazwę jego zawartości na nowy folder GitLabCI-sample. Użyj
mkdir ~/GitLabCI-sample
jeśli jest to pierwsza praca z tym artykułem, aby folder był gotowy na następujący zestaw 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 folder GitLabCI-sample z 3 plikami:
app.py, który jest kodem naszej aplikacji Python Flask,
a Dockerfile i
plik zależności requirements.txt.
Następnie możemy cd do tego folderu, zainicjować git repo, zatwierdzić lokalnie i wypchnąć do zdalnego za pomocą następujących poleceń (zamień domenę i nazwę użytkownika):
cd GitLabCI-sample
git init
git remote add origin [email protected]:myusername/GitLabCI-sample.git
git add .
git commit -m "First commit"
git push origin master
Najprawdopodobniej nazwa użytkownika myusername będzie tutaj po prostu root.
Kiedy wejdziemy do GUI GitLab, możemy zobaczyć, że nasze zmiany zostały zatwierdzone:
* * Krok 3 Zdefiniuj zmienne środowiskowe za pomocą współrzędnych DockerHub w GitLab ——————————————————————————–
Chcemy utworzyć potok CI/CD, który po nowym zatwierdzeniu zbuduje obraz Docker naszej aplikacji i wypchnie 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, które może być hasłem do konta lub specjalnie utworzonym access token. Aby utworzyć taki token, zobacz opcję Account Settings –> Security w witrynie Docker:
* *
Wróć do interfejsu użytkownika GitLab, z menu Ustawienia w widoku projektu przejdź do podmenu CI/CD:
* * Przewiń w dół do sekcji „Zmienne” i wypełnij odpowiednie formularze. W graficznym interfejsie użytkownika będzie to wyglądać podobnie do tego:
* * Teraz, gdy wartości zmiennych są już skonfigurowane, użyjemy ich w naszym potoku CI/CD.
Krok 4 Utwórz potok, aby zbudować obraz Docker aplikacji przy użyciu Kaniko
Potok CI/CD, który tworzymy w GitLab, będzie miał tylko jedno zadanie, które
tworzy obraz i
wypycha go do rejestru obrazów Docker.
W rzeczywistych scenariuszach potoki mogą również obejmować dodatkowe zadania, np. związane z testami jednostkowymi lub integracyjnymi.
GitLab rozpoznaje, że repozytorium/projekt jest skonfigurowany do wdrożenia potoku CI/CD poprzez obecność 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 folderze GitLabCI-sample. Plik zawiera konfigurację naszego potoku 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 naszym projekcie są zatwierdzane w GitLab, potok CI/CD jest uruchamiany automatycznie.
Zadania są wykonywane przez runner GitLab. Jeśli korzystasz z instancji GitLab zgodnie z warunkiem 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 potoku. Jeden z kontenerów uruchomionych w pod 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ą uruchamiane podczas startu kontenera Kaniko. Oba przyjmą wartości po 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.
- Zbuduj i opublikuj obraz kontenera w serwisie DockerHub
Drugie polecenie kompiluje i publikuje obraz kontenera w serwisie DockerHub.
Krok 5 Wyzwalanie kompilacji potoku
Zatwierdzenie powoduje uruchomienie potoku. 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 tym zatwierdzeniu, jeśli przejdziemy do ekranu CI/CD naszego projektu, powinniśmy zobaczyć, że potok jest najpierw w stanie uruchomionym, a następnie ukończonym:
* * Również podczas przeglądania naszego rejestru Docker obraz jest publikowany:
* * Co robić dalej ————–
Dodaj testy jednostkowe i integracyjne do tego potoku. 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/