Ciągłe wdrażanie w Google Kubernetes Engine (GKE) za pomocą Cloud Build

1. Przegląd

W tym module dowiesz się, jak skonfigurować potok trybu ciągłego dostarczania dla GKE za pomocą Cloud Build. W tym module pokazujemy, jak wywoływać zadania Cloud Build w przypadku różnych zdarzeń Git, a także prosty wzorzec automatycznych wydań kanaryjnych w GKE.

Wykonaj te czynności:

• Tworzenie aplikacji GKE
• Automatyzacja wdrażania w przypadku gałęzi Git
• Automatyzacja wdrożeń w przypadku głównej gałęzi Git
• Automatyzacja wdrożeń w przypadku tagów Git

2. Zanim zaczniesz

Aby skorzystać z tego przewodnika, musisz mieć projekt Google Cloud. Możesz utworzyć nowy projekt lub wybrać już utworzony:

1. Wybierz lub utwórz projekt Google Cloud.

OTWÓRZ STRONĘ WYBORU PROJEKTU

1. Włącz płatności w projekcie.

WŁĄCZ PŁATNOŚCI

3. Przygotowywanie środowiska

1. Utwórz zmienne środowiskowe, których będziesz używać w tym samouczku:

   export PROJECT_ID=$(gcloud config get-value project)
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
   
   export ZONE=us-central1-b
   export CLUSTER=gke-progression-cluster
   export APP_NAME=myapp
   

2. Włącz te interfejsy API:
   • Menedżer zasobów
   • GKE
   • Cloud Source Repositories
   • Cloud Build
   • Container Registry

   gcloud services enable \
       cloudresourcemanager.googleapis.com \
       container.googleapis.com \
       sourcerepo.googleapis.com \
       cloudbuild.googleapis.com \
       containerregistry.googleapis.com \
       --async
   

3. Sklonuj przykładowe źródło i przejdź do katalogu modułu:

   git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git gke-progression
   
   cd gke-progression/labs/gke-progression
   rm -rf ../../.git
   

4. Zastąp wartości zmiennych w przykładowym repozytorium swoimi wartościami PROJECT_ID: w tym kroku utworzysz instancje różnych plików konfiguracyjnych, które są unikalne dla Twojego bieżącego środowiska. Aby sprawdzić przykład aktualizowanych szablonów, uruchom to polecenie:

   cat k8s/deployments/dev/frontend-dev.yaml.tmpl
   

   Wykonaj podstawienie zmiennych, uruchamiając to polecenie.

   for template in $(find . -name '*.tmpl'); do envsubst '${PROJECT_ID} ${ZONE} ${CLUSTER} ${APP_NAME}' < ${template} > ${template%.*}; done
   

   Aby sprawdzić, jak wygląda plik po zastąpieniu, uruchom to polecenie.

   cat k8s/deployments/dev/frontend-dev.yaml
   

5. Jeśli nie używasz jeszcze Git w Cloud Shell, ustaw wartości user.name i user.email, których chcesz używać:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_USERNAME"
   

6. Przechowuj kod z przykładowego repozytorium w Cloud Source Repositories:

   gcloud source repos create gke-progression
   git init
   git config credential.helper gcloud.sh
   git remote add gcp https://source.developers.google.com/p/$PROJECT_ID/r/gke-progression
   git branch -m main
   git add . && git commit -m "initial commit"
   git push gcp main
   

7. Utwórz klaster GKE.

   gcloud container clusters create ${CLUSTER} \
       --project=${PROJECT_ID} \
       --zone=${ZONE}
   

8. Przyznaj Cloud Build uprawnienia do klastra.Cloud Build będzie wdrażać aplikację w klastrze GKE i potrzebuje do tego uprawnień.

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
       --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role=roles/container.developer
   

Środowisko jest gotowe.

4. Tworzenie aplikacji GKE

W tej sekcji skompilujesz i wdrożysz początkową aplikację produkcyjną, której będziesz używać w tym samouczku.

1. Skompiluj aplikację za pomocą Cloud Build:

   gcloud builds submit --tag gcr.io/$PROJECT_ID/$APP_NAME:1.0.0 src/
   

2. Ręczne wdrażanie w środowiskach Canary i produkcyjnych:utwórz wdrożenia i usługi produkcyjne oraz Canary za pomocą poleceń kubectl apply.

   kubectl create ns production
   kubectl apply -f k8s/deployments/prod -n production
   kubectl apply -f k8s/deployments/canary -n production
   kubectl apply -f k8s/services -n production
   

   Usługa wdrożona w tym miejscu będzie kierować ruch zarówno do wdrożenia do wczesnych testów, jak i do wdrożenia w środowisku produkcyjnym.
3. Sprawdź liczbę uruchomionych podów. Upewnij się, że masz 4 uruchomione pody frontendu, w tym 3 do obsługi ruchu produkcyjnego i 1 do wersji testowych. Oznacza to, że zmiany w wersji do wczesnych testów będą miały wpływ tylko na 1 z 4 użytkowników (25%).

   kubectl get pods -n production -l app=$APP_NAME -l role=frontend
   

4. Pobierz zewnętrzny adres IP usług produkcyjnych.

   Uwaga: zanim zobaczysz zewnętrzny adres IP systemu równoważenia obciążenia, może minąć kilka minut.

   kubectl get service $APP_NAME -n production
   

   Gdy system równoważenia obciążenia zwróci adres IP, przejdź do następnego kroku.
5. Zapisz zewnętrzny adres IP do późniejszego użycia.

   export PRODUCTION_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=production services $APP_NAME)
   

6. Sprawdź aplikację. Sprawdź dane wyjściowe wersji usługi. Powinien brzmieć „Hello World v1.0”.

   curl http://$PRODUCTION_IP
   

Gratulacje! Przykładowa aplikacja została wdrożona. Następnie skonfigurujesz aktywatory, które będą ciągle wdrażać zmiany.

5. Automatyzacja wdrażania w przypadku gałęzi Git

W tej sekcji skonfigurujesz wyzwalacz, który będzie wykonywać zadanie Cloud Build po zatwierdzeniu zmian w dowolnej gałęzi innej niż main. Użyty tutaj plik Cloud Build automatycznie utworzy przestrzeń nazw i wdrożenie dla wszystkich istniejących i nowych gałęzi, co umożliwi programistom wyświetlanie podglądu kodu przed integracją z gałęzią główną.

1. Skonfiguruj regułę:kluczowym elementem tej reguły jest użycie parametru branchName do dopasowania main oraz parametru invertRegex, który jest ustawiony na wartość „true” (prawda) i zmienia wzorzec branchName, aby dopasować wszystko, co nie jest main. W build/branch-trigger.json znajdziesz te wiersze.

     "branchName": "main",
     "invertRegex": true
   

   Dodatkowo kilka ostatnich wierszy pliku Cloud Build używanego z tym aktywatorem tworzy przestrzeń nazw o nazwie gałęzi, która wywołała zadanie, a następnie wdraża aplikację i usługę w nowej przestrzeni nazw. W build/branch-cloudbuild.yaml znajdziesz te wiersze:

     kubectl get ns ${BRANCH_NAME} || kubectl create ns ${BRANCH_NAME}
     kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/deployments/dev
     kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/services
   

   Teraz, gdy znasz już używane mechanizmy, utwórz aktywator za pomocą polecenia gcloud poniżej.

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/branch-trigger.json
   

2. Aby sprawdzić aktywator, otwórz stronę Aktywatory Cloud Build w konsoli.Otwórz Aktywatory
3. Tworzenie nowej gałęzi:

   git checkout -b new-feature-1
   

4. Zmodyfikuj kod, aby wskazywał wersję 1.1.Edytuj src/app.py i zmień odpowiedź z 1.0 na 1.1.

   @app.route('/')
   def hello_world():
       return 'Hello World v1.1'
   

5. Zatwierdź zmianę i wypchnij ją do repozytorium zdalnego:

   git add . && git commit -m "updated" && git push gcp new-feature-1
   

6. Aby sprawdzić postęp kompilacji, otwórz stronę Historia Cloud Build w konsoli.Otwórz KompilacjePo zakończeniu kompilacji przejdź do następnego kroku.
7. Pobierz zewnętrzny adres IP nowo wdrożonej usługi gałęzi.

   Uwaga: zanim zobaczysz zewnętrzny adres IP systemu równoważenia obciążenia, może minąć kilka minut.

   kubectl get service $APP_NAME -n new-feature-1
   

   Gdy system równoważenia obciążenia zwróci adres IP, przejdź do następnego kroku.
8. Zapisz zewnętrzny adres IP do późniejszego użycia.

   export BRANCH_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=new-feature-1 services $APP_NAME)
   

9. Sprawdź aplikację. Sprawdź dane wyjściowe wersji usługi. Powinien brzmieć „Hello World v1.0”.

   curl http://$BRANCH_IP
   

6. Automatyzacja wdrażania w przypadku głównej gałęzi Git

Zanim kod zostanie udostępniony w środowisku produkcyjnym, często jest on udostępniany niewielkiej części ruchu na żywo, a dopiero potem cały ruch jest przenoszony do nowej bazy kodu.

W tej sekcji zaimplementujesz aktywator, który jest aktywowany, gdy kod zostanie zatwierdzony w gałęzi głównej. Wywołanie wdraża wdrożenie do wczesnych testów, które otrzymuje 25% całego aktualnego natężenia ruchu do nowej wersji.

1. Skonfiguruj aktywator dla głównej gałęzi:

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/main-trigger.json
   

2. Aby sprawdzić nowy aktywator, otwórz stronę Aktywatory Cloud Build w konsoli.Otwórz Aktywatory
3. Scal gałąź z linią główną i wypchnij do repozytorium zdalnego:

   git checkout main
   git merge new-feature-1
   git push gcp main
   

4. Aby sprawdzić postęp kompilacji, otwórz stronę Historia Cloud Build w konsoli.Kliknij KompilacjePo zakończeniu kompilacji przejdź do następnego kroku.
5. Sprawdź wiele odpowiedzi z serwera. Uruchom to polecenie i zwróć uwagę, że około 25% odpowiedzi zawiera nową odpowiedź Hello World w wersji 1.1.

   while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
   

   Gdy wszystko będzie gotowe, naciśnij Ctrl+c, aby wyjść z pętli.

7. Automatyzowanie wdrożeń w przypadku tagów Git

Po sprawdzeniu wdrożenia do wczesnych testów na niewielkiej części aktualnego natężenia ruchu wdrażasz je na pozostałej części aktualnego natężenia ruchu.

W tej sekcji skonfigurujesz aktywator, który uruchamia się, gdy utworzysz tag w repozytorium. Wywołanie oznacza obraz odpowiednim tagiem, a następnie wdraża aktualizacje w środowisku produkcyjnym, zapewniając, że 100% ruchu uzyskuje dostęp do otagowanego obrazu.

1. Skonfiguruj regułę uruchamiającą tag:

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/tag-trigger.json
   

2. Aby sprawdzić nowy aktywator, otwórz stronę Aktywatory Cloud Build w konsoli.Otwórz Aktywatory
3. Utwórz nowy tag i wypchnij go do repozytorium zdalnego:

   git tag 1.1
   git push gcp 1.1
   

4. Aby sprawdzić postęp kompilacji, otwórz stronę Historia Cloud Build w konsoli.Otwórz kompilacje
5. Sprawdź wiele odpowiedzi z serwera. Uruchom to polecenie i zwróć uwagę, że 100% odpowiedzi zawiera nową odpowiedź Hello World w wersji 1.1. Może to chwilę potrwać, ponieważ nowe pody są wdrażane i sprawdzane w GKE.

   while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
   

   Gdy wszystko będzie gotowe, naciśnij Ctrl+c, aby wyjść z pętli.Gratulacje! W Cloud Build utworzono aktywatory CI/CD dla gałęzi i tagów, aby wdrażać aplikacje w GKE.

8. Czyszczenie

Usuwanie projektu

Ostrzeżenie: usunięcie projektu spowoduje, że wszystkie dane projektu zostaną usunięte. Jeśli w tym samouczku używasz istniejącego projektu, po jego usunięciu usuniesz też wszystkie inne prace wykonane w tym projekcie.

1. W Cloud Console otwórz stronę Zarządzanie zasobami.
2. Z listy projektów wybierz projekt do usunięcia, a potem kliknij Usuń.
3. W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.