1. Hinweis
Einrichten der Umgebung im eigenen Tempo
- 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.
- 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.
- 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
- Öffnen Sie den Cloud Shell-Editor über die folgende URL.
https://ide.cloud.google.com
- 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)')
- APIs aktivieren
gcloud services enable \
cloudbuild.googleapis.com \
secretmanager.googleapis.com
- 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}
- Klonen Sie im Terminalfenster die Anwendungsquelle mit dem folgenden Befehl:
git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git
- 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.
- Vorlage in das Arbeitsverzeichnis kopieren
cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR
cd $WORK_DIR/app-templates
- Leeres Remote-Repository in Ihrem GitHub-Konto erstellen
$BASE_DIR/scripts/git/gh.sh create mcd-app-templates
- 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
- 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.
- Vorlage in das Arbeitsverzeichnis kopieren
cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR
cd $WORK_DIR/shared-kustomize
- Leeres Remote-Repository in Ihrem GitHub-Konto erstellen
$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize
- 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
- 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
- Leeres Remote-Repository in Ihrem GitHub-Konto erstellen
$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}
- 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.
- Sie können den Schlüssel einsehen, indem Sie auf diesen Link klicken.
- 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.
- 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))
- Secret erstellen
printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-
- 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.
- 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
- Legen Sie den Speicherort des freigegebenen Basiskonfigurations-Repos fest.
export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize
- 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
- 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}`
- Rufen Sie den neu erstellten Cloud Build-Trigger in der Console auf, indem Sie diesen Link anklicken.
- 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
- Webhook in GitHub konfigurieren
$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL
- 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
- Prüfen, ob Sie sich im richtigen Verzeichnis befinden
cd $BASE_DIR
- 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.
- Rufen Sie die URL des GitHub-Repositorys mit dem folgenden Befehl ab:
echo ${GIT_BASE_URL}/demo-app
- Öffnen Sie die URL in Ihrem Webbrowser, um die neue Anwendung zu prüfen.
- 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
- 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
- Rufen Sie den Cloud Build-Trigger in der Console auf, indem Sie diesen Link anklicken.
- Auf dieser Seite können Sie den Build-Verlauf einsehen.