Wprowadzenie aplikacji

1. Zanim zaczniesz

Konfigurowanie środowiska we własnym tempie

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

  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 skopiuj ź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 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.

  1. Kopiowanie szablonu do katalogu roboczego

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

cd $WORK_DIR/app-templates

  1. Tworzenie pustego zdalnego repozytorium na koncie GitHub

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

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

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

  1. Kopiowanie szablonu do katalogu roboczego

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

cd $WORK_DIR/shared-kustomize

  1. Tworzenie pustego zdalnego repozytorium na koncie GitHub

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

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

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

  1. Tworzenie pustego zdalnego repozytorium na koncie GitHub

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

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

  1. Aby sprawdzić klucz, kliknij ten link.
  2. 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.

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

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

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

export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize

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

  1. 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ę znajdujegcloud 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 w konsoli Cloud Build aktywator, klikając ten link.
  3. 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

  1. Konfigurowanie webhooka w GitHub

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

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

  1. Upewnij się, że jesteś we właściwym 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.

Na tym etapie będzie można przejrzeć nowe repozytorium w GitHubie.

  1. Pobierz adres URL repozytorium GitHub, wykonując następujące polecenie

echo ${GIT_BASE_URL}/demo-app

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

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

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