1. Zanim zaczniesz
Samodzielne konfigurowanie środowiska
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.



- Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Możesz go w dowolnym momencie zaktualizować.
- Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i jest niezmienny (nie można go zmienić po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się nim przejmować. W większości modułów z kodem musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako
PROJECT_ID). Jeśli Ci się nie podoba, wygeneruj inny losowy identyfikator lub spróbuj użyć własnego i sprawdź, czy jest dostępny. Po utworzeniu projektu jest on „zamrażany”. - Istnieje też trzecia wartość, czyli numer projektu, którego używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Ukończenie tego laboratorium nie powinno wiązać się z dużymi kosztami, a nawet z żadnymi. Aby wyłączyć zasoby i uniknąć naliczenia opłat po zakończeniu tego samouczka, postępuj zgodnie z instrukcjami „czyszczenia” na końcu ćwiczenia. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.
2. Przygotowywanie obszaru roboczego
- Otwórz edytor Cloud Shell, klikając ten adres URL:
https://ide.cloud.google.com
- Sprawdź, czy nazwa projektu jest ustawiona w CLI.
gcloud config set project {{project-id}}
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
- Włącz interfejsy API
gcloud services enable \
cloudbuild.googleapis.com \
secretmanager.googleapis.com
- Przyznawanie uprawnień do CloudDeploy
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.admin ${PROJECT_ID}
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/container.developer ${PROJECT_ID}
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/iam.serviceAccountUser ${PROJECT_ID}
gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.jobRunner ${PROJECT_ID}
- W oknie terminala sklonuj źródło aplikacji za pomocą tego polecenia:
git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git
- Przejdź do katalogu i ustaw obszar roboczy IDE na katalog główny repozytorium.
cd software-delivery-workshop && rm -rf .git
cd delivery-platform && cloudshell workspace .
3. Korzystanie z wstępnie zdefiniowanych i niestandardowych szablonów aplikacji
Deweloperzy powinni mieć możliwość wyboru spośród zestawu szablonów powszechnie używanych w organizacji. Proces konfiguracji utworzy scentralizowany zestaw repozytoriów szablonów przechowywanych na Twoim koncie GitHub. W dalszych krokach te repozytoria szablonów zostaną skopiowane i zmodyfikowane, aby można było ich używać jako podstawy nowych aplikacji. W tym module wypełnisz repozytorium szablonu przykładową strukturą podaną tutaj. Możesz dodać własne szablony, dodając kolejne foldery wzorowane na przykładzie.
W tym kroku utworzysz własne repozytorium, w którym będziesz przechowywać szablony aplikacji na podstawie podanych plików przykładowych. Aby uprościć interakcje z GitHubem, udostępniamy skrypt pomocniczy.
Są to jednorazowe czynności służące do wypełniania repozytoriów szablonów. W kolejnych krokach będziemy używać tych repozytoriów.
Konfigurowanie dostępu do GitHub
Czynności opisane w tym samouczku wywołują interfejs GitHub API w celu utworzenia i skonfigurowania repozytoriów. W różnych miejscach wymagana jest nazwa użytkownika GitHuba i osobisty token dostępu. Poniższy skrypt pomoże Ci uzyskać wartości i zapisać je jako zmienne lokalne do późniejszego wykorzystania.
source ./onboard-env.sh
echo Git Username: $GIT_USERNAME
echo Git Base URL: $GIT_BASE_URL
Tworzenie repozytorium szablonów aplikacji
W tym module znajdziesz przykładowe szablony aplikacji, które pokazują, jak możesz zintegrować własne szablony podstawowe. W tym kroku utworzysz własną kopię tych plików w repozytorium o nazwie mcd-app-templates na swoim koncie GitHub.
- Skopiuj szablon do katalogu roboczego
cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR
cd $WORK_DIR/app-templates
- Utwórz puste repozytorium zdalne na koncie GitHub.
$BASE_DIR/scripts/git/gh.sh create mcd-app-templates
- Prześlij repozytorium szablonów do zdalnego repozytorium
git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"
git remote add origin $GIT_BASE_URL/mcd-app-templates
git push origin main
- Zwalnianie miejsca w katalogu roboczym
cd $BASE_DIR
rm -rf $WORK_DIR/app-templates
Tworzenie repozytorium udostępnionych konfiguracji podstawowych
W tym samouczku użyjemy narzędzia Kustomize, które korzysta z podstawowych plików konfiguracyjnych udostępnianych przez wiele zespołów, a następnie nakłada na nie konfiguracje specyficzne dla aplikacji. Umożliwia to zespołom platformy skalowanie w wielu zespołach i środowiskach.
W tym kroku utworzysz repozytorium konfiguracji udostępnionej o nazwie mcd-shared_kustomize na podstawie podanych przykładów.
- Skopiuj szablon do katalogu roboczego
cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR
cd $WORK_DIR/shared-kustomize
- Utwórz puste repozytorium zdalne na koncie GitHub.
$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize
- Prześlij repozytorium szablonów do zdalnego repozytorium
git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"
git remote add origin $GIT_BASE_URL/mcd-shared_kustomize
git push origin main
- Zwalnianie miejsca w katalogu roboczym
cd $BASE_DIR
rm -rf $WORK_DIR/shared-kustomize
Po utworzeniu repozytoriów szablonów możesz ich użyć do utworzenia instancji aplikacji.
4. Tworzenie nowej instancji aplikacji
Tworzenie nowej aplikacji na podstawie szablonu często wymaga zastąpienia zmiennych zastępczych rzeczywistymi wartościami w wielu plikach w strukturze szablonu. Po zakończeniu zamiany dla nowej instancji aplikacji zostanie utworzone nowe repozytorium. To właśnie to repozytorium instancji aplikacji deweloperzy będą klonować i z nim pracować na co dzień.
W tym kroku zastąpisz wartości w szablonie aplikacji i opublikujesz wynikowe pliki w nowym repozytorium.
Określ nazwę nowej aplikacji.
export APP_NAME=my-app
Pobieranie repozytorium szablonu Golang
cd $WORK_DIR/
git clone -b main $GIT_BASE_URL/mcd-app-templates app-templates
rm -rf app-templates/.git
cd app-templates/golang
Podstawianie wartości zmiennych
Jedną z najczęstszych potrzeb związanych z wdrażaniem jest zamiana zmiennych w szablonach na rzeczywiste instancje używane w aplikacji. Na przykład podaj nazwę aplikacji. To polecenie tworzy instancje wszystkich plików .tmpl z wartościami przechowywanymi w zmiennych środowiskowych.
for template in $(find . -name '*.tmpl'); do envsubst < ${template} > ${template%.*}; done
Utwórz nowe repozytorium i zapisz w nim zaktualizowane pliki.
- Utwórz puste repozytorium zdalne na koncie GitHub.
$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}
- Prześlij repozytorium szablonów do zdalnego repozytorium
git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"
git remote add origin $GIT_BASE_URL/${APP_NAME}
git push origin main
Po utworzeniu instancji aplikacji nadszedł czas na wdrożenie ciągłych kompilacji.
5. Konfigurowanie automatycznego wykonywania potoku
Centralną częścią systemu ciągłej integracji jest możliwość wykonywania logiki potoku na podstawie zdarzeń pochodzących z systemu kontroli źródła. Gdy deweloper zatwierdzi kod w repozytorium, wywoływane są zdarzenia, które można skonfigurować tak, aby uruchamiały procesy w innych systemach.
W tym kroku skonfigurujesz GitHub tak, aby wywoływał Google Cloud Build i wykonywał potok za każdym razem, gdy użytkownicy zatwierdzą lub otagują kod w swoim repozytorium.
Włączanie bezpiecznego dostępu
Aby skonfigurować bezpieczny dostęp do potoku aplikacji, potrzebujesz 2 elementów. Klucz interfejsu API i tajny klucz unikalny dla potoku.
Klucz interfejsu API
Klucz interfejsu API służy do identyfikowania klienta, który wywołuje dany interfejs API. W tym przypadku klientem będzie GitHub. Nie wspomnieliśmy tu o sprawdzonej metodzie, która polega na ograniczeniu zakresu klucza interfejsu API tylko do tych interfejsów API, do których klient będzie mieć dostęp. Klucz został utworzony w poprzednim kroku.
- Klucz możesz sprawdzić, klikając ten link.
- Aby sprawdzić, czy wartość została ustawiona, uruchom to polecenie:
echo $API_KEY_VALUE
Obiekt tajny potoku
Obiekty tajne służą do autoryzacji wywołującego i zapewniają, że ma on uprawnienia do konkretnego zadania docelowego Cloud Build. Możesz mieć w GitHubie 2 różne repozytoria, które powinny mieć dostęp tylko do własnych potoków. Klucz API_KEY ogranicza interfejsy API, z których może korzystać GitHub (w tym przypadku wywoływany jest interfejs Cloud Build API), a tajny klucz ogranicza zadania w interfejsie Cloud Build API, które mogą być wykonywane przez klienta.
- Zdefiniuj nazwę, lokalizację i wartość obiektu tajnego
SECRET_NAME=${APP_NAME}-webhook-trigger-cd-secret
SECRET_PATH=projects/${PROJECT_NUMBER}/secrets/${SECRET_NAME}/versions/1
SECRET_VALUE=$(sed "s/[^a-zA-Z0-9]//g" <<< $(openssl rand -base64 15))
- Tworzenie obiektu tajnego
printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-
- Zezwól Cloud Build na odczytanie obiektu tajnego
gcloud secrets add-iam-policy-binding ${SECRET_NAME} \
--member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com \
--role='roles/secretmanager.secretAccessor'
Tworzenie aktywatora Cloud Build
Aktywator Cloud Build to konfiguracja, która będzie wykonywać procesy CICD.
Aby prawidłowo skonfigurować wyzwalacz, podczas tworzenia zadania musisz podać kilka kluczowych wartości.
- Określ nazwę reguły i miejsce, w którym można znaleźć plik konfiguracji.
export TRIGGER_NAME=${APP_NAME}-clouddeploy-webhook-trigger
export BUILD_YAML_PATH=$WORK_DIR/app-templates/golang/build/cloudbuild-cd.yaml
- Określ lokalizację repozytorium udostępnionej konfiguracji podstawowej.
export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize
- W skrypcie onboard-env.sh ustawiono zmienną definiującą rejestr kontenerów projektu. Sprawdź wartość za pomocą polecenia poniżej.
echo $IMAGE_REPO
- Utwórz aktywator webhooka Cloud Build, używając utworzonych wcześniej zmiennych. Lokalizacja repozytorium aplikacji jest pobierana z treści żądania z GitHuba. Wartość poniżej odnosi się do ścieżki w treści żądania, w której się znajduje.
gcloud alpha builds triggers create webhook \`--name=${TRIGGER_NAME} \` `--substitutions='_APP_NAME='${APP_NAME}',_APP_REPO=$(body.repository.git_url),_CONFIG_REPO='${GIT_BASE_URL}'/'${CLUSTER_CONFIG_REPO}',_DEFAULT_IMAGE_REPO='${IMAGE_REPO}',_KUSTOMIZE_REPO='${GIT_BASE_URL}'/'${SHARED_KUSTOMIZE_REPO}',_REF=$(body.ref)' \` `--inline-config=$BUILD_YAML_PATH \` `--secret=${SECRET_PATH}` - Sprawdź nowo utworzony aktywator kompilacji Cloud Build w konsoli, klikając ten link.
- Zdefiniuj zmienną adresu URL punktu końcowego, która będzie używana przez GitHub w następnym kroku.
WEBHOOK_URL="https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY_VALUE}&secret=${SECRET_VALUE}"
Konfigurowanie webhooka GitHub
- Konfigurowanie webhooka w GitHubie
$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL
- Otwórz repozytorium aplikacji i sprawdź nowo skonfigurowany webhook.
REPO_URL=${GIT_BASE_URL}/${APP_NAME}/settings/hooks
echo $REPO_URL
Po ręcznym wykonaniu wszystkich czynności potrzebnych do utworzenia nowej aplikacji możesz zautomatyzować ten proces za pomocą skryptu.
6. Automatyzacja wszystkich etapów procesu wprowadzania nowych pracowników
W praktyce nie jest możliwe wykonanie wszystkich powyższych kroków w przypadku każdej nowej aplikacji. Zamiast tego logikę należy włączyć do skryptu, aby ułatwić jego wykonanie. Powyższe kroki zostały już uwzględnione w skrypcie, którego możesz użyć.
W tym kroku użyjesz podanego skryptu, aby utworzyć nową aplikację.
Utwórz nową aplikację
- Upewnij się, że jesteś w odpowiednim katalogu.
cd $BASE_DIR
- Utwórz nową aplikację
export APP_NAME=demo-app
./app.sh create ${APP_NAME}
Wszystkie kroki są wykonywane automatycznie.
Sprawdź repozytorium GitHub
W tym momencie możesz przejrzeć nowe repozytorium w GitHubie.
- Pobierz adres URL repozytorium GitHub, wykonując to polecenie:
echo ${GIT_BASE_URL}/demo-app
- Otwórz adres URL w przeglądarce, aby sprawdzić nową aplikację.
- Zwróć uwagę na przykłady, w których zmienne szablonu zostały zastąpione wartościami instancji, jak pokazano w adresie URL poniżej.
echo ${GIT_BASE_URL}/demo-app/blob/main/k8s/prod/deployment.yaml#L24
- Sprawdź webhooka skonfigurowanego pod adresem URL poniżej.
echo ${GIT_BASE_URL}/demo-app/settings/hooks
Sprawdź aktywator Cloud Build
Reguła została skonfigurowana automatycznie przez skrypt
- Sprawdź aktywator kompilacji Cloud Build w konsoli, klikając ten link.
- Sprawdź historię kompilacji na tej stronie.