Diese Anleitung ist der zweite Teil einer Reihe, in der die Erstellung einer automatisierten CI-Pipeline (Continuous Integration, CI) zum Erstellen von Container-Images mit mehreren Architekturen in Google Cloud erläutert wird.
In dieser Anleitung implementieren Sie eine Pipeline zum Erstellen von Container-Images mit mehreren Architekturen mithilfe von Cloud Build und Container Registry. In dieser Anleitung wird die Build-Strategie mit mehreren Architekturen beschrieben, die im Abschnitt Pipeline für die Erstellung von Containern für mehrere Architekturen implementieren in Teil 1 dieser Reihe beschrieben werden.
Angenommen, Sie verwalten mehrere Geräte im Internet der Dinge (IoT). Wenn sich neue Anforderungen für Ihre IoT-Lösung ergeben, benötigen Sie neue Hardwaregeräte. Wenn die neuen Geräte eine andere Hardwarearchitektur als Ihre vorhandene haben, müssen Sie Ihre Build-Pipeline ändern, damit die neue Architektur unterstützt wird.
Diese Anleitung richtet sich an IT-Fachleute, die komplexe Pipelines zum Erstellen von Container-Images vereinfachen oder optimieren möchten, oder um diese Pipelines zu erweitern, damit Images für mehrere Architekturen erstellt werden können.
In dieser Anleitung wird davon ausgegangen, dass Sie über Grundkenntnisse zu folgenden Themen verfügen:
- Terraform zum Erstellen von Infrastruktur in Google Cloud
- Google Cloud CLI für die Ausführung von Plattformaufgaben in Google Cloud
- Cloud Shell zum Ausführen von Befehlen in dieser Anleitung. Alle in dieser Anleitung verwendeten Tools sind in Cloud Shell vorinstalliert.
- Cloud Build zum Einrichten einer CI-Pipeline
- Docker als Plattform zur Containerverwaltung
- Container Registry zum Speichern der Container-Images, die vom Build-Prozess erzeugt werden
In dieser Anleitung verwenden Sie Terraform, um die Ressourcen einzurichten, die Sie zum Bereitstellen und Konfigurieren der Pipeline zum Erstellen von Container-Images benötigen.
Architektur
Das folgende Diagramm veranschaulicht den Workflow für die Pipeline, die Sie in dieser Anleitung zum Erstellen von Container-Images erstellen.
Änderungen am Quellcode des Container-Images lösen Cloud Build so aus, dass es ein Container-Image mit mehreren Architekturen erstellt. Nach Abschluss des Builds wird das Container-Image mit mehreren Architekturen in Container Registry gespeichert.
Ziele
- Stellen Sie die Pipeline mithilfe von Terraform zum Erstellen von Container-Images in Google Cloud bereit.
- Ändern Sie den Quellcode des Container-Images, um einen neuen Build auszulösen.
- Prüfen Sie, ob das Container-Image in Container Registry gespeichert ist.
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Vorbereitung
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.
Umgebung vorbereiten
In dieser Anleitung führen Sie alle Befehle in Cloud Shell aus.
-
Aktivieren Sie Cloud Shell in der Google Cloud Console.
Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
Klonen Sie das Beispielcode-Repository:
cd "$HOME" git clone \ https://github.com/GoogleCloudPlatform/solutions-build-multi-architecture-images-tutorial.gitGenerieren Sie Standardanmeldedaten für Anwendungen:
gcloud auth application-default login --quietDie Ausgabe sieht etwa so aus:
Go to the following link in your browser: https://accounts.google.com/o/oauth2/auth?code_challenge=... Enter verification code:Öffnen Sie in einem Browserfenster die URL, die in der Ausgabe angezeigt wird, und generiert Sie die Standardanmeldedaten für Anwendungen (den vorherigen Schritt).
Wählen Sie Zulassen aus, um fortzufahren.
Kopieren Sie den Code auf dem Bildschirm und geben Sie ihn in Cloud Shell ein.
Die Ausgabe sieht etwa so aus:
/tmp/tmp.xxxxxxxxxx/application_default_credentials.json
Notieren Sie sich den Pfad zur Datei
application_default_credentials.json. Mit diesem Pfad legen Sie im nächsten Abschnitt eine Umgebungsvariable fest.
Umgebungsvariablen festlegen
Bevor Sie die für diese Anleitung erforderliche Infrastruktur bereitstellen können, müssen Sie die folgenden Umgebungsvariablen initialisieren und exportieren:
Erstellen Sie in Cloud Shell eine Umgebungsvariable, die den Namen des Google Cloud-Dienstkontos speichert, mit dem Terraform Ressourcen bereitstellt:
export TF_SERVICE_ACCOUNT_NAME=tf-service-accountErstellen Sie eine Umgebungsvariable, in der die Google Cloud-Projekt-ID gespeichert wird, die von Terraform zum Speichern des Status verwendet wird:
export TF_STATE_PROJECT=${DEVSHELL_PROJECT_ID}Erstellen Sie eine Umgebungsvariable, in der der Cloud Storage-Bucket gespeichert wird, den Terraform zum Speichern der Statusdateien verwendet:
export TF_STATE_BUCKET=tf-state-bucket-${TF_STATE_PROJECT}Erstellen Sie eine Umgebungsvariable, in der die Google Cloud-Projekt-ID gespeichert ist, die die Ressourcen für die Build-Pipeline für Container-Images enthält:
export GOOGLE_CLOUD_PROJECT=${DEVSHELL_PROJECT_ID}Erstellen Sie eine Umgebungsvariable, die den Pfad zu den Standardanmeldedaten der Google Cloud-Anwendung speichert. Dies ist der Wert, den Sie im vorherigen Abschnitt notiert haben:
export GOOGLE_APPLICATION_CREDENTIALS=PATH
Ersetzen Sie dabei Folgendes:
PATH: Pfad zur Dateiapplication_default_credentials.json
Umgebung bereitstellen
Sie müssen das Shell-Skript generate-tf-backend.sh ausführen, das die Terraform-Back-End-Konfiguration, die erforderlichen Google Cloud-Dienstkonten und den Cloud Storage-Bucket generiert, um Informationen über den Remote-Status von Terraform zu speichern.
Stellen Sie Ihre Build-Umgebung in Cloud Shell bereit:
cd $HOME/solutions-build-multi-architecture-images-tutorial/ ./generate-tf-backend.shDas Skript ist idempotent und kann mehrmals sicher ausgeführt werden.
Nachdem Sie das Skript zum ersten Mal erfolgreich ausgeführt haben, sieht die Ausgabe in etwa so aus:
Generating the descriptor to hold backend data in terraform/backend.tf terraform { backend "gcs" { bucket = "tf-state-bucket-project-id" prefix = "terraform/state" } }
Build-Pipeline erstellen
Die Terraform-Vorlagendatei terraform/main.tf definiert die Ressourcen, die für diese Anleitung erstellt werden. Wenn Sie Terraform mit diesem Deskriptor ausführen, erstellen Sie die folgenden Google Cloud-Ressourcen:
- Ein Cloud Source Repositories-Code-Repository zum Speichern des Container-Image-Deskriptors und der Cloud Build-Build-Konfigurationsdatei.
- Ein Pub/Sub-Thema, in dem Cloud Build Nachrichten bei jeder Änderung des Quellcodes veröffentlicht.
- Ein Cloud Build-Build, der das Container-Image mit mehreren Architekturen erstellt
- Ein Container Registry-Repository zum Speichern von Container-Images
Gehen Sie in Cloud Shell so vor:
Führen Sie den Befehl terraform init aus, um das Terraform-Arbeitsverzeichnis zu initialisieren:
cd terraform terraform init(Optional) Führen Sie den Befehl terraform plan aus, um die Änderungen zu prüfen, die Terraform anwendet:
terraform planDie Ausgabe ist eine Liste aller Aktionen, die Terraform voraussichtlich in der Google Cloud-Umgebung ausführen wird. Die Zusammenfassung aller Aktionen sieht in etwa so aus:
Plan: 8 to add, 0 to change, 0 to destroy.
Die Gesamtzahl der Hinzufügen-Aktionen ist acht, ohne Änderungen und ohne Löschungen.
Führen Sie den Terraform-Befehl apply aus, um die Ressourcen in Ihrem Google Cloud-Projekt zu erstellen:
terraform applyGeben Sie
yesein, um mit der Ausführung des Befehls fortzufahren.
Quelldateien in Cloud Source Repositories hochladen
Damit die Build-Pipeline den Build ausführen kann, müssen das Dockerfile und die Cloud Build-Konfigurationsdateien in einem Quellcode-Repository von Cloud Source Repositories gespeichert werden.
Klonen Sie in Cloud Shell das Quell-Repository:
cd $HOME gcloud source repos clone cross-buildKopieren Sie das Dockerfile und die Cloud Build-Konfigurationsdatei in das Quellcode-Repository:
cp -r "$HOME"/solutions-build-multi-architecture-images-tutorial/terraform/cloud-build/. "$HOME"/cross-buildFühren Sie einen Commit durch und laden Sie die Dateien per Push in das Quellcode-Repository hoch:
cd "$HOME"/cross-build git add . git commit -m "Initial commit" git push
Ergebnisse prüfen
Während der Cloud Build-Job ausgeführt wird und nachdem er abgeschlossen wurde, können Sie die Ausführung jedes Build-Schritts im Build-Verlauf von Cloud Build prüfen.
Cloud Build-Build
Auf der Seite Build-Verlauf erhalten Sie einen Überblick über die Build-Schritte, inklusive der Zeit, die für die einzelnen Schritte erforderlich ist, wie in der folgenden Abbildung dargestellt.
Wenn Sie einen Build-Schritt öffnen, sehen Sie die Ausgabe für diesen Schritt. Die Build-Details des Schritts buildx inspect im vorherigen Diagramm zeigen beispielsweise die unterschiedliche Zielplattformarchitektur, die von der Plattform unterstützt wird:
12 Name: mybuilder0 13 Endpoint: unix:///var/run/docker.sock 14 Status: running 15 Platforms: linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
Die Build-Details für den vierten Schritt zeigen die Ausgabe des Builds für jede Zielarchitektur an:
#8 0.268 I am running on linux/amd64, building for linux/amd64 #12 0.628 I am running on linux/amd64, building for linux/arm/v7 #10 0.279 I am running on linux/amd64, building for linux/arm/v6 #14 0.252 I am running on linux/amd64, building for linux/arm64
Image-Manifest in Container Registry
Nach Abschluss des Builds können Sie das Image-Manifest in der Google Cloud Console auf der Seite Images von Container Registry prüfen, wie in der folgenden Abbildung dargestellt.
Wenn Sie das Repository test in der Repository-Liste öffnen, sehen Sie alle Container-Image-Versionen, die zum Repository test gehören, wie in der folgenden Abbildung gezeigt.
Sie können das mit latest getaggte Image öffnen, um die Seite Digest-Details zu öffnen und detaillierte Informationen zum Image zu sehen, wie in der folgenden Abbildung dargestellt.
Auf der Seite Digest-Details können Sie den Abschnitt Manifest maximieren und prüfen, ob die vom Build erstellte Zielarchitektur in der Datei angegeben ist, wie das folgende Beispiel zeigt:
{
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:839024acb1038509e3bc66f3744857840951d0d512be54fd6670ea1e8babdcb6",
"size": 735,
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:33489767c29efb805e446a61d91cc55e042d3cfadcd186d9a1c8698f2f12309d",
"size": 735,
"platform": {
"architecture": "arm64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:f1958815778ca8c83d324bad3fc68a9e3e9d5ea48b5bb27a8aca7d8da20cf8d4",
"size": 735,
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
}
]
}
Sie können das Image-Manifest auch direkt in Cloud Shell ansehen.
Rufen Sie in Cloud Shell das Image-Manifest auf:
DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect gcr.io/"${DEVSHELL_PROJECT_ID}"/test:latestDie Ausgabe entspricht der Manifestdatei, die Sie auf der Seite Digest-Details maximieren können.
Kontinuierliche Bereitstellung aus der Build-Pipeline konfigurieren
Ändern Sie zum Erstellen des Container-Images für die neue Hardwarearchitektur die Build-Konfigurationsdatei, indem Sie die neue Zielarchitektur hinzufügen. Nachdem Sie die Änderung per Commit in das Quell-Repository in Cloud Source Repositories übertragen haben, startet Cloud Build einen neuen Build. Der Build erzeugt eine neue Version des Container-Images mit mehreren Architekturen, einschließlich der Unterstützung für die neu hinzugefügte Hardwarearchitektur.
Fügen Sie in Cloud Shell der neuen Konfigurationsdatei die neue Zielplattform hinzu:
cd "$HOME"/cross-build sed -i -e 's/linux\/arm\/v7/linux\/arm\/v7,linux\/386/g' build-docker-image-trigger.yamlFühren Sie ein Commit durch und laden Sie die Änderung per Push in das Quellcode-Repository hoch:
git add . git commit -m "add a new target platform" git pushSehen Sie sich das neueste Manifest an, um zu prüfen, ob die neue Zielplattform Teil des aktuellen Container-Images ist:
DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect gcr.io/${DEVSHELL_PROJECT_ID}/test:latestPrüfen Sie, ob sich die neu hinzugefügte Zielplattform in der Manifestdatei befindet, ähnlich wie in der folgenden Ausgabe:
{ "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json", "schemaVersion": 2, "manifests": [ { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:bc80d063fccb4c370df9b505cbf4f8a814a366d99644de09ebee98af2ef0ff63", "size": 735, "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:be10e4f01f529149815ebad7eb09edaa84ebef5b7d70d51f7d1acb5ceb1f61cd", "size": 735, "platform": { "architecture": "arm64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:f6ba5d5d3bc1ea0177e669517ea15a0d4fb97c06c7eca338afa43734d87af779", "size": 735, "platform": { "architecture": "arm", "os": "linux", "variant": "v7" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:a3c34621cca10974026f8ad0782af78539cd7bb0ebfa0082a27b2c3ed4418ca0", "size": 735, "platform": { "architecture": "386", "os": "linux" } } ] }
Bereinigen
Am einfachsten können Sie die Abrechnung deaktivieren, wenn Sie das Google Cloud-Projekt löschen, das Sie für die Anleitung erstellt haben. Alternativ haben Sie die Möglichkeit, die einzelnen Ressourcen zu löschen.
Projekt löschen
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Einzelne Ressourcen löschen
Wenn Sie das in dieser Anleitung verwendete Projekt behalten möchten, gehen Sie folgendermaßen vor, um die in dieser Anleitung erstellten Ressourcen zu löschen.
Löschen Sie in Cloud Shell die Container-Images:
gcloud container images delete gcr.io/${DEVSHELL_PROJECT_ID}/test --quietLöschen Sie die Ressourcen, die Sie mit Terraform bereitgestellt haben:
cd $HOME/solutions-build-multi-architecture-images-tutorial/terraform terraform destroyGeben Sie
yesein, um den Löschvorgang zu bestätigen.
Nächste Schritte
- Container-Images mit mehreren Architekturen für IoT-Geräte
- Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten
- Weitere Informationen zu DevOps finden Sie auf der DevOps-Seite
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center