1. Omówienie
W tym module dowiesz się, jak skonfigurować potok ciągłego dostarczania dla GKE za pomocą Cloud Build. W tym module dowiesz się, jak aktywować zadania Cloud Build dla różnych zdarzeń git, a także poznasz prosty wzorzec automatycznych wersji do wczesnych testów w GKE.
Wykonaj te czynności:
- Tworzenie aplikacji GKE
- Automatyzacja wdrożeń w gałęziach Git
- Automatyzacja wdrożeń w głównej gałęzi Git
- Automatyzacja wdrażania tagów Git
2. Zanim zaczniesz
Aby skorzystać z tego przewodnika, potrzebujesz projektu Google Cloud. Możesz utworzyć nowy lub wybrać już utworzony:
- Wybierz lub utwórz projekt Google Cloud.
- Włącz płatności w projekcie.
3. Przygotowuję środowisko
- 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
- Włącz następujące 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
- Skopiuj przykładowe źródło i przełącz się 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
- Zastąp wartości obiektów zastępczych w przykładowym repozytorium identyfikatorem
PROJECT_ID
:w tym kroku utworzysz instancje różnych plików konfiguracyjnych, które są unikalne dla Twojego bieżącego środowiska.Aby zobaczyć przykład aktualizowanych szablonów, uruchom to polecenie.
Zastąp zmienną, wykonując następne polecenie.cat k8s/deployments/dev/frontend-dev.yaml.tmpl
Aby sprawdzić przykładowy plik po zastąpieniu, uruchom następujące polecenie.for template in $(find . -name '*.tmpl'); do envsubst '${PROJECT_ID} ${ZONE} ${CLUSTER} ${APP_NAME}' < ${template} > ${template%.*}; done
cat k8s/deployments/dev/frontend-dev.yaml
- Jeśli po raz pierwszy korzystasz z Gita w Cloud Shell, ustaw wartości
user.name
iuser.email
, których chcesz użyć:git config --global user.email "YOUR_EMAIL_ADDRESS" git config --global user.name "YOUR_USERNAME"
- 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
- Utwórz klaster GKE.
gcloud container clusters create ${CLUSTER} \ --project=${PROJECT_ID} \ --zone=${ZONE}
- Przyznaj usłudze Cloud Build uprawnienia do klastra.Cloud Build będzie wdrażać aplikację w Twoim klastrze GKE i będzie potrzebować do tego uprawnień.
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role=roles/container.developer
Twoje środowisko jest gotowe.
4. Tworzę aplikację GKE
W tej sekcji skompilujesz i wdrożysz początkową aplikację produkcyjną, której będziesz używać w tym samouczku.
- Kompilowanie aplikacji za pomocą Cloud Build:
gcloud builds submit --tag gcr.io/$PROJECT_ID/$APP_NAME:1.0.0 src/
- Ręczne wdrażanie w środowiskach do wczesnych testów i w środowisku produkcyjnym:utwórz wdrożenia oraz usługi produkcyjne i do wczesnych testów za pomocą poleceń
kubectl apply
.
Wdrożona tutaj usługa będzie kierować ruch zarówno do wdrożeń do wczesnych testów, jak i do wdrożeń produkcyjnych.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
- Sprawdź liczbę uruchomionych podów. Upewnij się, że dla frontendu uruchomione są 4 pody, w tym 3 dla ruchu produkcyjnego i 1 dla wersji do wczesnych testów. Oznacza to, że zmiany w Twojej wersji do wczesnych testów wpłyną tylko na 1 na 4 (25%) użytkowników.
kubectl get pods -n production -l app=$APP_NAME -l role=frontend
- Pobierz zewnętrzny adres IP usług produkcyjnych..
Gdy system równoważenia obciążenia zwróci adres IP, przejdź do następnego krokukubectl get service $APP_NAME -n production
- Przechowuj 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)
- Przeglądanie aplikacji Sprawdź dane wyjściowe wersji usługi. Powinien pojawić się komunikat Hello World v1.0
curl http://$PRODUCTION_IP
Gratulacje! Udało Ci się wdrożyć przykładową aplikację. Następnie skonfigurujesz aktywatory do ciągłego wdrażania zmian.
5. Automatyzacja wdrożeń w gałęziach Git
W tej sekcji skonfigurujesz aktywator, który uruchomi zadanie Cloudbuild w przypadku zatwierdzenia dowolnej gałęzi innej niż main
. Użyty tutaj plik Cloud Build automatycznie utworzy przestrzeń nazw i wdrożenie dla istniejących lub nowych gałęzi, co pozwoli programistom wyświetlić podgląd kodu przed integracją z gałęzią główną.
- Skonfiguruj regułę:kluczowym komponentem tej reguły jest użycie parametru
branchName
do dopasowaniamain
i parametruinvertRegex
, który ma wartość prawda, i zmienia wzorzecbranchName
tak, aby pasował do dowolnych wartości innych niżmain
. Te wiersze znajdziesz w dokumentacjibuild/branch-trigger.json
."branchName": "main", "invertRegex": true
Dodatkowo w ostatnich kilku wierszach pliku Cloud Build użytego z tym aktywatorem powstaje przestrzeń nazw o nazwie odpowiadającej gałęzi, która aktywowała zadanie, a następnie wdraża aplikację i usługę w nowej przestrzeni nazw. Dodatkowe informacje znajdziesz w artykulebuild/branch-cloudbuild.yaml
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
: Znasz już używane mechanizmy, możesz więc utworzyć aktywator za pomocą poniższego polecenia gcloud.gcloud beta builds triggers create cloud-source-repositories \ --trigger-config build/branch-trigger.json
- Aby sprawdzić aktywator, otwórz w konsoli stronę Aktywatory Cloud Build.Otwórz stronę Aktywatory
- Utwórz nową gałąź:
git checkout -b new-feature-1
- Zmodyfikuj kod, dodając do niego wersję v1.1Edit
src/app.py
, a następnie zmień odpowiedź z 1.0 na 1.1.@app.route('/') def hello_world(): return 'Hello World v1.1'
- Zatwierdź zmianę i wypchnij do repozytorium zdalnego:
git add . && git commit -m "updated" && git push gcp new-feature-1
- Aby sprawdzić postęp kompilacji, otwórz w konsoli stronę Historia Cloud Build. Otwórz kompilacjePo zakończeniu kompilacji przejdź do następnego kroku.
- Pobierz zewnętrzny adres IP nowo wdrożonej usługi gałęzi..
Gdy system równoważenia obciążenia zwróci adres IP, przejdź do następnego krokukubectl get service $APP_NAME -n new-feature-1
- Przechowuj 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)
- Przejrzyj aplikację Sprawdź dane wyjściowe wersji usługi. Powinien wyświetlać się tekst Hello World v1.0
curl http://$BRANCH_IP
6. Automatyzacja wdrożeń w głównej gałęzi Git
Przed udostępnieniem kodu do środowiska produkcyjnego często zwalnia się go z niewielkiego podzbioru aktywnego ruchu, a następnie przenosi cały ruch do nowej bazy.
W tej sekcji wdrożysz aktywator, który będzie aktywowany po zatwierdzeniu kodu w gałęzi głównej. Aktywator wdraża wdrożenie do wczesnych testów, które odbiera 25% całego bieżącego ruchu do nowej wersji.
- Skonfiguruj aktywator dla gałęzi głównej:
gcloud beta builds triggers create cloud-source-repositories \ --trigger-config build/main-trigger.json
- Aby sprawdzić nowy aktywator, otwórz w konsoli stronę Aktywatory Cloud Build.Otwórz stronę Aktywatory
- Scal gałąź z wierszem głównym i wypchnij do repozytorium zdalnego:
git checkout main git merge new-feature-1 git push gcp main
- Aby sprawdzić postęp kompilacji, otwórz w konsoli stronę Historia Cloud Build. Otwórz kompilacje. Gdy kompilacja się zakończy, przejdź do następnego kroku.
- Sprawdź wiele odpowiedzi z serwera, korzystając z tego polecenia, i pamiętaj, że około 25% odpowiedzi zawiera nową odpowiedź Hello World w wersji 1.1
Jeśli uznasz, że chcesz kontynuować, naciśnijwhile true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1; done
Ctrl+c
, aby zakończyć cykl.
7. Automatyzacja wdrażania tagów Git
Po zweryfikowaniu wdrożenia do wczesnych testów z wykorzystaniem niewielkiego podzbioru ruchu zwolnisz wdrożenie dla pozostałego ruchu.
W tej sekcji skonfigurujesz regułę, która będzie aktywowana, gdy utworzysz tag w repozytorium. Aktywator oznacza obraz odpowiednim tagiem, a następnie wdraża aktualizacje w środowisku produkcyjnym, tak aby 100% ruchu miało dostęp do otagowanego obrazu.
- Skonfiguruj regułę tagu:
gcloud beta builds triggers create cloud-source-repositories \ --trigger-config build/tag-trigger.json
- Aby sprawdzić nowy aktywator, otwórz w konsoli stronę Aktywatory Cloud Build.Otwórz stronę Aktywatory
- Utwórz nowy tag i wypchnij do repozytorium zdalnego:
git tag 1.1 git push gcp 1.1
- Aby sprawdzić postęp kompilacji, otwórz w konsoli stronę Historia Cloud Build.Otwórz kompilacje
- Sprawdź wiele odpowiedzi z serwera, uruchom to polecenie i zwróć uwagę, że wszystkie odpowiedzi zawierają nową odpowiedź Hello World w wersji 1.1. Może to chwilę potrwać, ponieważ nowe pody są wdrażane i sprawdzane w GKE
Gdy wszystko będzie gotowe, naciśnijwhile true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1; done
Ctrl+c
, aby wyjść z pętli.Gratulacje! W Cloud Build zostały przez Ciebie utworzone aktywatory CI/CD dla gałęzi i tagów do wdrażania aplikacji w GKE.
8. Czyszczenie
Usuwanie projektu
- W konsoli Cloud otwórz stronę Zarządzanie zasobami.
- Na liście projektów wybierz projekt do usunięcia, a potem kliknij Usuń.
- W oknie wpisz identyfikator projektu i kliknij Wyłącz, aby usunąć projekt.