App-Onboarding

1. Hinweis

Einrichten der Umgebung im eigenen Tempo

  1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der nicht von Google APIs verwendet wird. Sie können ihn jederzeit aktualisieren.
  • Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und kann nach der Festlegung nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen, die normalerweise als PROJECT_ID gekennzeichnet ist. Wenn Ihnen die ID nicht gefällt, generieren Sie eine andere zufällige ID oder versuchen Sie, Ihre eigene zu verwenden und prüfen Sie, ob sie verfügbar ist. Nach dem Erstellen des Projekts wird es „eingefroren“.
  • Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu allen drei Werten finden Sie in der Dokumentation.
  1. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Ausführung dieses Codelabs sollte nur wenige Kosten verursachen, wenn überhaupt. Wenn Sie die Ressourcen herunterfahren möchten, damit keine Kosten über diese Anleitung hinaus anfallen, folgen Sie der Anleitung zum Bereinigen am Ende des Codelabs. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

2. Arbeitsbereich wird vorbereitet

  1. Öffnen Sie den Cloud Shell-Editor über die folgende URL.

https://ide.cloud.google.com

  1. Prüfen, ob der Projektname in der Befehlszeile festgelegt ist

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

gcloud services enable \

cloudbuild.googleapis.com \

secretmanager.googleapis.com

  1. CloudDeploy Berechtigungen erteilen

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. Klonen Sie im Terminalfenster die Anwendungsquelle mit dem folgenden Befehl:

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

  1. Wechseln Sie in das Verzeichnis und legen Sie den IDE-Arbeitsbereich auf das Repository-Stammverzeichnis fest.

cd software-delivery-workshop && rm -rf .git

cd delivery-platform && cloudshell workspace .

3. Vordefinierte und benutzerdefinierte App-Vorlagen verwenden

Entwickler sollten in der Lage sein, aus einer Reihe von Vorlagen auszuwählen, die in der Organisation häufig verwendet werden. Beim Onboarding wird eine zentrale Gruppe von Vorlagen-Repositories erstellt, die in Ihrem GitHub-Konto gespeichert werden. In späteren Schritten werden diese Vorlagen-Repositories kopiert und zur Verwendung als Grundlage für neue Anwendungen geändert. Für dieses Lab füllen Sie Ihr Vorlagen-Repository mit einer hier bereitgestellten Beispielstruktur. Sie können eigene Vorlagen hinzufügen, indem Sie zusätzliche Ordner hinzufügen, die dem Beispiel entsprechen.

In diesem Schritt erstellen Sie aus den bereitgestellten Beispieldateien ein eigenes Repository für App-Vorlagen. Ein Hilfsskript vereinfacht die Interaktionen mit GitHub.

Dies sind einmalige Schritte, die zum Befüllen Ihrer Vorlagen-Repositories verwendet werden. Diese Repositories werden in zukünftigen Schritten wiederverwendet.

GitHub-Zugriff konfigurieren

In den Schritten in dieser Anleitung wird die GitHub API aufgerufen, um Repositories zu erstellen und zu konfigurieren. An den folgenden Stellen sind Ihr GitHub-Nutzername und ein persönliches Zugriffstoken erforderlich. Das folgende Skript hilft Ihnen, die Werte abzurufen und zur späteren Verwendung als lokale Variablen zu speichern.

source ./onboard-env.sh

echo Git Username: $GIT_USERNAME

echo Git Base URL: $GIT_BASE_URL

App-Vorlagen-Repository erstellen

In diesem Lab finden Sie Beispielanwendungsvorlagen, die zeigen, wie Sie Ihre eigenen Basisvorlagen einbinden können. In diesem Schritt erstellen Sie eine eigene Kopie dieser Dateien in einem Repository namens mcd-app-templates in Ihrem GitHub-Konto.

  1. Vorlage in das Arbeitsverzeichnis kopieren

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

cd $WORK_DIR/app-templates

  1. Leeres Remote-Repository in Ihrem GitHub-Konto erstellen

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

  1. Vorlagen-Repository in das Remote-Repository pushen

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

cd $BASE_DIR

rm -rf $WORK_DIR/app-templates

Repository für freigegebene Basiskonfigurationen erstellen

In dieser Anleitung wird das Tool Kustomize verwendet, das Basiskonfigurationsdateien von mehreren Teams verwendet und dann anwendungsspezifische Konfigurationen darüber legt. So können Plattformteams für viele Teams und Umgebungen skaliert werden.

In diesem Schritt erstellen Sie das freigegebene Konfigurations-Repository mcd-shared_kustomize aus den bereitgestellten Beispielen.

  1. Vorlage in das Arbeitsverzeichnis kopieren

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

cd $WORK_DIR/shared-kustomize

  1. Leeres Remote-Repository in Ihrem GitHub-Konto erstellen

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

  1. Vorlagen-Repository in das Remote-Repository pushen

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

cd $BASE_DIR

rm -rf $WORK_DIR/shared-kustomize

Nachdem Sie Ihre Vorlagen-Repositories erstellt haben, können Sie damit eine App-Instanz erstellen.

4. Neue Instanz einer Anwendung erstellen

Wenn Sie eine neue Anwendung aus einer Vorlage erstellen, müssen Platzhaltervariablen in mehreren Dateien in der Vorlagenstruktur häufig durch echte Werte ersetzt werden. Sobald die Substitution abgeschlossen ist, wird für die neue App-Instanz ein neues Repository erstellt. Dieses App-Instanzen-Repository wird von den Entwicklern geklont und bei der täglichen Entwicklung verwendet.

In diesem Schritt ersetzen Sie Werte in einer App-Vorlage und veröffentlichen die resultierenden Dateien in einem neuen Repository.

Geben Sie einen Namen für die neue Anwendung ein.

export APP_NAME=my-app

Golang-Vorlagen-Repository abrufen

cd $WORK_DIR/

git clone -b main $GIT_BASE_URL/mcd-app-templates app-templates

rm -rf app-templates/.git

cd app-templates/golang

Platzhalterwerte ersetzen

Eine der häufigsten Anforderungen beim Onboarding besteht darin, Variablen in Vorlagen durch tatsächliche Instanzen zu ersetzen, die in der Anwendung verwendet werden. Geben Sie beispielsweise den Namen der Anwendung an. Mit dem folgenden Befehl werden Instanzen aller .tmpl-Dateien mit den in Umgebungsvariablen gespeicherten Werten erstellt.

for template in $(find . -name '*.tmpl'); do envsubst < ${template} > ${template%.*}; done

Neues Repository erstellen und aktualisierte Dateien speichern

  1. Leeres Remote-Repository in Ihrem GitHub-Konto erstellen

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

  1. Vorlagen-Repository in das Remote-Repository pushen

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

Nachdem die App-Instanz erstellt wurde, ist es an der Zeit, kontinuierliche Builds zu implementieren.

5. Automatische Pipelineausführung konfigurieren

Der zentrale Teil eines Continuous-Integration-Systems ist die Möglichkeit, die Pipelinelogik basierend auf den Ereignissen aus dem Quellcodeverwaltungssystem auszuführen. Wenn ein Entwickler Code in seinem Repository committet, werden Ereignisse ausgelöst, die so konfiguriert werden können, dass sie Prozesse in anderen Systemen auslösen.

In diesem Schritt konfigurieren Sie GitHub so, dass Google Cloud Build aufgerufen und Ihre Pipeline ausgeführt wird, wenn Nutzer ein Commit oder Tag-Code in ihrem Repository ausführen.

Sicheren Zugriff aktivieren

Sie benötigen zwei Elemente, um den sicheren Zugriff auf Ihre Anwendungspipeline zu konfigurieren. Ein API-Schlüssel und ein Secret, die nur für die Pipeline verwendet werden.

API-Schlüssel

Der API-Schlüssel dient dazu, den Client zu identifizieren, der eine bestimmte API aufruft. In diesem Fall ist GitHub der Kunde. Eine Best Practice, die hier nicht behandelt wird, besteht darin, den Gültigkeitsbereich des API-Schlüssels auf die APIs zu beschränken, auf die der Client zugreift. Sie haben den Schlüssel in einem vorherigen Schritt erstellt.

  1. Sie können den Schlüssel einsehen, indem Sie auf diesen Link klicken.
  2. Sie können mit dem folgenden Befehl prüfen, ob der Wert festgelegt wurde:

echo $API_KEY_VALUE

Pipeline-Secret

Mit den Secrets wird ein Aufrufer autorisiert und es wird sichergestellt, dass er Berechtigungen für den jeweiligen Cloud Build-Zieljob hat. Möglicherweise haben Sie zwei verschiedene Repositories in GitHub, die nur Zugriff auf ihre eigenen Pipelines haben sollten. Mit dem API_KEY wird eingeschränkt, welche APIs von GitHub verwendet werden können (in diesem Fall wird die Cloud Build API aufgerufen). Mit dem Secret wird eingeschränkt, welcher Job in der Cloud Build API vom Client ausgeführt werden kann.

  1. Name, Standort und Wert des Secrets definieren

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

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

  1. Cloud Build Lesezugriff auf das Secret gewähren

gcloud secrets add-iam-policy-binding ${SECRET_NAME} \

--member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com \

--role='roles/secretmanager.secretAccessor'

Cloud Build-Trigger erstellen

Der Cloud Build-Trigger ist die Konfiguration, die die CICD-Prozesse tatsächlich ausführt.

Beim Erstellen des Jobs müssen einige Schlüssel/Wert-Paare angegeben werden, damit der Trigger richtig konfiguriert werden kann.

  1. Geben Sie den Namen des Triggers und den Speicherort der Konfigurationsdatei an

export TRIGGER_NAME=${APP_NAME}-clouddeploy-webhook-trigger

export BUILD_YAML_PATH=$WORK_DIR/app-templates/golang/build/cloudbuild-cd.yaml

  1. Legen Sie den Speicherort des freigegebenen Basiskonfigurations-Repos fest.

export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize

  1. Im Script „onboard-env.sh“ wurde eine Variable festgelegt, die die Containerregistrierung des Projekts definiert. Überprüfen Sie den Wert mit dem folgenden Befehl.

echo $IMAGE_REPO

  1. Erstellen Sie einen Cloud Build-Webhook-Trigger mit den zuvor erstellten Variablen. Der Speicherort des Anwendungs-Repositorys wird aus dem Textkörper der Anfrage von GitHub abgerufen. Ein Wert unten verweist auf den Pfad im Anfragetext, in dem er sich befindet.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. Rufen Sie den neu erstellten Cloud Build-Trigger in der Console auf, indem Sie diesen Link anklicken.
  3. Variable für die Endpunkt-URL definieren, die im nächsten Schritt von GitHub verwendet wird

WEBHOOK_URL="https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY_VALUE}&secret=${SECRET_VALUE}"

GitHub-Webhook konfigurieren

  1. Webhook in GitHub konfigurieren

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

  1. Rufen Sie das Anwendungs-Repository auf und prüfen Sie den neu konfigurierten Webhook.

REPO_URL=${GIT_BASE_URL}/${APP_NAME}/settings/hooks

echo $REPO_URL

Nachdem Sie nun alle Schritte zur Erstellung einer neuen Anwendung manuell ausgeführt haben, ist es an der Zeit, diese in einem Skript zu automatisieren.

6. Alle Onboarding-Schritte automatisieren

In der Praxis ist es nicht möglich, jeden der oben genannten Schritte für jede neue Anwendung auszuführen. Stattdessen sollte die Logik in ein Skript integriert werden, um eine einfache Ausführung zu ermöglichen. Die oben genannten Schritte sind bereits in einem Script enthalten.

In diesem Schritt erstellen Sie mit dem bereitgestellten Script eine neue Anwendung.

Neue Anwendung erstellen

  1. Prüfen, ob Sie sich im richtigen Verzeichnis befinden

cd $BASE_DIR

  1. Neue Anwendung erstellen

export APP_NAME=demo-app

./app.sh create ${APP_NAME}

Alle Schritte werden automatisch ausgeführt.

GitHub-Repository ansehen

Sie können sich das neue Repository jetzt in GitHub ansehen.

  1. Rufen Sie die URL des GitHub-Repositorys mit dem folgenden Befehl ab:

echo ${GIT_BASE_URL}/demo-app

  1. Öffnen Sie die URL in Ihrem Webbrowser, um die neue Anwendung zu prüfen.
  2. Beachten Sie Beispiele, in denen die Vorlagenvariablen durch Instanzwerte ersetzt wurden (siehe URL unten)

echo ${GIT_BASE_URL}/demo-app/blob/main/k8s/prod/deployment.yaml#L24

  1. Prüfen Sie den Webhook, der unter der folgenden URL konfiguriert ist.

echo ${GIT_BASE_URL}/demo-app/settings/hooks

Cloud Build-Trigger überprüfen

Der Trigger wurde automatisch vom Skript eingerichtet

  1. Rufen Sie den Cloud Build-Trigger in der Console auf, indem Sie diesen Link anklicken.
  2. Auf dieser Seite können Sie den Build-Verlauf einsehen.