Wprowadzenie aplikacji

1. Zanim zaczniesz

Samodzielne konfigurowanie środowiska

  1. 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ć.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • 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.
  1. 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

  1. Otwórz edytor Cloud Shell, klikając ten adres URL:

https://ide.cloud.google.com

  1. 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)')

  1. Włącz interfejsy API

gcloud services enable \

cloudbuild.googleapis.com \

secretmanager.googleapis.com

  1. 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}

  1. W oknie terminala sklonuj źródło aplikacji za pomocą tego polecenia:

git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git

  1. 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.

  1. Skopiuj szablon do katalogu roboczego

cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR

cd $WORK_DIR/app-templates

  1. Utwórz puste repozytorium zdalne na koncie GitHub.

$BASE_DIR/scripts/git/gh.sh create mcd-app-templates

  1. 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

  1. 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.

  1. Skopiuj szablon do katalogu roboczego

cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR

cd $WORK_DIR/shared-kustomize

  1. Utwórz puste repozytorium zdalne na koncie GitHub.

$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize

  1. 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

  1. 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.

  1. Utwórz puste repozytorium zdalne na koncie GitHub.

$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}

  1. 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.

  1. Klucz możesz sprawdzić, klikając ten link.
  2. 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.

  1. 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))

  1. Tworzenie obiektu tajnego

printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-

  1. 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.

  1. 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

  1. Określ lokalizację repozytorium udostępnionej konfiguracji podstawowej.

export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize

  1. W skrypcie onboard-env.sh ustawiono zmienną definiującą rejestr kontenerów projektu. Sprawdź wartość za pomocą polecenia poniżej.

echo $IMAGE_REPO

  1. 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}`
    
  2. Sprawdź nowo utworzony aktywator kompilacji Cloud Build w konsoli, klikając ten link.
  3. 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

  1. Konfigurowanie webhooka w GitHubie

$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL

  1. 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ę

  1. Upewnij się, że jesteś w odpowiednim katalogu.

cd $BASE_DIR

  1. 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.

  1. Pobierz adres URL repozytorium GitHub, wykonując to polecenie:

echo ${GIT_BASE_URL}/demo-app

  1. Otwórz adres URL w przeglądarce, aby sprawdzić nową aplikację.
  2. 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

  1. 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

  1. Sprawdź aktywator kompilacji Cloud Build w konsoli, klikając ten link.
  2. Sprawdź historię kompilacji na tej stronie.