1. Zanim zaczniesz
Konfigurowanie środowiska we własnym tempie
- 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 projektu. Jest to ciąg znaków, którego nie używają interfejsy API Google, i który możesz zaktualizować w dowolnym momencie.
- Identyfikator projektu musi być niepowtarzalny we wszystkich projektach Google Cloud i jest niezmienny (nie można go zmienić po jego ustawieniu). Konsole Google Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie ma znaczenia, jaki to ciąg. W większości laboratoriów z kodem musisz podać identyfikator projektu (zazwyczaj jest to
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. Następnie po utworzeniu projektu jest „zamrażany”. - Występuje trzecia wartość – numer projektu – używany przez niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w konsoli Cloud, aby móc korzystać z zasobów i interfejsów API usługi Cloud. Przejście przez ten Codelab nie powinno wiązać się z wielkimi kosztami, jeśli w ogóle będą jakieś. Aby wyłączyć zasoby, aby nie naliczać opłat po zakończeniu tego samouczka, postępuj zgodnie z instrukcjami dotyczącymi czyszczenia, które znajdziesz na końcu tego samouczka. 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. Przygotowuję obszar roboczy
- 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 skopiuj ź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 szablonów aplikacji wstępnie zdefiniowanych i niestandardowych
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 późniejszych krokach te repozytoria szablonów zostaną skopiowane i zmodyfikowane do użycia jako podstawy dla nowych aplikacji. W tym laboratorium zainicjujesz repozytorium szablonów, korzystając z podanej tutaj przykładowej struktury. Możesz dodać własne szablony, dodając dodatkowe foldery na podstawie przykładu.
W tym kroku utworzysz własne repozytorium, które będzie przechowywać szablony aplikacji, na podstawie podanych przykładowych plików. Udostępniliśmy skrypt pomocniczy, który upraszcza interakcję z GitHubem.
Są to jednorazowe kroki służące do wypełniania repozytoriów szablonów. W kolejnych krokach będziesz używać tych repozytoriów.
Konfigurowanie dostępu do GitHuba
W tym samouczku kroki wywołują interfejs API GitHuba, aby utworzyć i skonfigurować repozytoria. W różnych miejscach poniżej będziesz potrzebować swojej nazwy użytkownika w GitHub i osobowego tokena dostępu. Poniższy skrypt pomoże Ci pobrać wartości i przechowywać je jako zmienne lokalne do późniejszego użycia.
source ./onboard-env.sh
echo Git Username: $GIT_USERNAME
echo Git Base URL: $GIT_BASE_URL
Tworzenie repozytorium szablonów aplikacji
Wraz z tym modułem udostępniamy przykładowe szablony aplikacji, które pokazują, jak można 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.
- Kopiowanie szablonu do katalogu roboczego
cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR
cd $WORK_DIR/app-templates
- Tworzenie pustego zdalnego repozytorium na koncie GitHub
$BASE_DIR/scripts/git/gh.sh create mcd-app-templates
- Przesyłanie 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
- Czyszczenie katalogu roboczego
cd $BASE_DIR
rm -rf $WORK_DIR/app-templates
Tworzenie repozytorium wspólnych konfiguracji bazowych
W tym samouczku używamy narzędzia Kustomize, które korzysta z podstawowych plików konfiguracji udostępnianych przez wiele zespołów, a następnie nakłada na nie konfiguracje specyficzne dla aplikacji. Dzięki temu zespoły zajmujące się platformami mogą korzystać z rozwiązania w wielu zespołach i środowiskach.
W tym kroku utwórz na podstawie podanych przykładów repozytorium współdzielonej konfiguracji o nazwie mcd-shared_kustomize
.
- Kopiowanie szablonu do katalogu roboczego
cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR
cd $WORK_DIR/shared-kustomize
- Tworzenie pustego zdalnego repozytorium na koncie GitHub
$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize
- Przesyłanie 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
- Czyszczenie katalogu roboczego
cd $BASE_DIR
rm -rf $WORK_DIR/shared-kustomize
Po utworzeniu repozytoriów szablonów możesz ich używać do tworzenia 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 zastępowania zostanie utworzone nowe repozytorium dla nowej instancji aplikacji. Jest to repozytorium instancji aplikacji, które deweloperzy będą klonować i z którym będą korzystać podczas codziennego programowania.
W tym kroku zastąpisz wartości w szablonie aplikacji i opublikujesz utworzone pliki w nowym repozytorium.
Określ nazwę nowej aplikacji.
export APP_NAME=my-app
Pobieranie repozytorium szablonów 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
Zastępowanie wartości obiektów zastępczych
Jednym z najczęstszych potrzeb podczas wdrażania jest zastąpienie zmiennych w szablonach rzeczywistymi instancjami używanymi w aplikacji. Na przykład podając nazwę aplikacji. To polecenie tworzy instancje wszystkich plików .tmpl z wartościami zapisanymi w zmiennych środowiskowych.
for template in $(find . -name '*.tmpl'); do envsubst < ${template} > ${template%.*}; done
Utwórz nowe repozytorium i przechowuj w nim zaktualizowane pliki.
- Tworzenie pustego zdalnego repozytorium na koncie GitHub
$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}
- Przesyłanie 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 możesz wdrożyć ciągłe kompilacje.
5. Konfigurowanie automatycznego wykonywania potoku
Centralnym elementem systemu ciągłej integracji jest możliwość wykonywania logiki potoku na podstawie zdarzeń pochodzących z systemu kontroli źródła. Gdy deweloper zapisuje kod w swoim repozytorium, wyzwala to zdarzenia, które można skonfigurować tak, aby uruchamiały procesy w innych systemach.
W tym kroku skonfigurujesz GitHuba tak, aby wywoływał Google Cloud Build i wykonywał przepływ pracy, gdy użytkownicy będą zgłaszać zmiany lub tagować kod w swoim repozytorium.
Włącz bezpieczny dostęp
Aby skonfigurować bezpieczny dostęp do potoku aplikacji, musisz użyć 2 elementów. klucz interfejsu API i tajny klucz, które są unikalne dla potoku;
Klucz interfejsu API
Klucz interfejsu API służy do identyfikacji klienta wywołującego dany interfejs API. W tym przypadku klientem będzie GitHub. Sprawdzoną metodą, która nie została tu opisana, jest ograniczenie zakresu klucza interfejsu API tylko do konkretnych interfejsów API, do których będzie mieć dostęp klient. Klucz został utworzony w poprzednim kroku.
- Aby sprawdzić klucz, kliknij ten link.
- Aby sprawdzić, czy wartość została ustawiona, uruchom to polecenie:
echo $API_KEY_VALUE
Obiekt tajny potoku
Obiekty tajne są używane do autoryzacji wywołującego i sprawdzania, czy ma on uprawnienia do określonego zadania docelowego Cloud Build. Możesz mieć 2 różne repozytoria w GitHub, które powinny mieć dostęp tylko do własnych ścieżek. Parametr API_KEY określa, które interfejsy API mogą być używane przez GitHub (w tym przypadku jest wywoływany interfejs Cloud Build API), natomiast obiekt tajny określa, które zadania w Cloud Build API 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=-
- Zezwalanie Cloud Build na odczyt 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 rzeczywiście wykonywać procesy CICD.
Aby prawidłowo skonfigurować regułę, musisz podać kilka kluczowych wartości podczas jej tworzenia.
- Podaj nazwę aktywatora i lokalizację pliku 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 bazowej konfiguracji udostępnionej.
export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize
- W skrypcie onboard-env.sh została ustawiona zmienna definiująca rejestr kontenerów projektu. Sprawdź wartość za pomocą poniższego polecenia.
echo $IMAGE_REPO
- Utwórz aktywator webhooka Cloud Build, używając wcześniej utworzonych zmiennych. Lokalizacja repozytorium aplikacji jest pobierana z treści żądania z GitHuba. Wartość poniżej odwołuje się do ścieżki w treści żądania, gdzie 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 w konsoli Cloud Build aktywator, klikając ten link.
- Zdefiniuj zmienną dla 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 GitHub
$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL
- Otwórz repozytorium aplikacji i sprawdź nowo skonfigurowany webhooka
REPO_URL=${GIT_BASE_URL}/${APP_NAME}/settings/hooks
echo $REPO_URL
Gdy już wykonasz wszystkie czynności potrzebne do utworzenia nowej aplikacji, możesz ją zautomatyzować za pomocą skryptu.
6. Automatyzacja wszystkich kroków procesu rejestracji
W praktyce nie da się wykonać każdego z powyższych kroków w przypadku każdej nowej aplikacji. Zamiast tego taką logikę należy zintegrować w skrypcie, aby można było je łatwo wykonać. Opisane powyżej kroki zostały już uwzględnione w skrypcie.
W tym kroku użyjesz przesłanego skryptu do utworzenia nowej aplikacji.
Utwórz nową aplikację
- Upewnij się, że jesteś we właściwym 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.
Na tym etapie będzie można przejrzeć nowe repozytorium w GitHubie.
- Pobierz adres URL repozytorium GitHub, wykonując następujące polecenie
echo ${GIT_BASE_URL}/demo-app
- Otwórz adres URL w przeglądarce, aby przejrzeć nową aplikację.
- Zwróć uwagę, że w przykładach zmienne szablonu zostały zastąpione wartościami wystąpienia, jak w adresie URL poniżej
echo ${GIT_BASE_URL}/demo-app/blob/main/k8s/prod/deployment.yaml#L24
- Sprawdź webhook skonfigurowany pod adresem URL podanym poniżej.
echo ${GIT_BASE_URL}/demo-app/settings/hooks
Sprawdź aktywator Cloud Build
Reguła została skonfigurowana automatycznie przez skrypt
- Sprawdź aktywator Cloud Build w konsoli, klikając ten link.
- Sprawdź historię kompilacji na tej stronie.