Container-Image-Neuerstellungen automatisieren, um Basis-Image-Updates zu synchronisieren

Mit Cloud Workstations können Sie benutzerdefinierte Images für Ihre Workstations erstellen und verwenden. Nachdem ein benutzerdefiniertes Image verwendet wurde, ist es sinnvoll, einen Neuerstellungsprozess des benutzerdefinierten Images zu automatisieren, um Korrekturen und Updates zu übernehmen, die in den Basis-Images verfügbar sind.

In dieser Anleitung erfahren Sie, wie Sie eine automatisierte Pipeline erstellen, um sicherzustellen, dass Sicherheitsupdates und Patches in Ihre benutzerdefinierten Workstation-Images aufgenommen werden.

Ziele

In dieser Anleitung erstellen Sie eine automatisierte Pipeline für Ihr Basis-Image. Dazu führen Sie die folgenden Schritte aus:

  1. Erstellen Sie ein Artifact Registry-Repository, um Ihr benutzerdefiniertes Image zu speichern und zu scannen.
  2. Konfigurieren Sie GitHub mit Google Cloud , um Ihre Image-Konfigurationen zu speichern.
  3. Erstellen Sie einen Cloud Build-Trigger, um die Erstellung und Bereitstellung benutzerdefinierter Images in Artifact Registry zu automatisieren.
  4. Konfigurieren Sie Cloud Scheduler so, dass Builds regelmäßig initiiert werden.
  5. Überprüfen Sie die Ergebnisse der automatisierten Prozesse.

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.

Neuen Nutzern von Google Cloud steht möglicherweise eine kostenlose Testversion zur Verfügung.

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.

Hinweis

  1. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  7. To initialize the gcloud CLI, run the following command:

    gcloud init
  8. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  11. Install the Google Cloud CLI.

  12. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  13. To initialize the gcloud CLI, run the following command:

    gcloud init

Umgebung vorbereiten

Legen Sie die folgenden Umgebungsvariablen fest, bevor Sie fortfahren.

  1. Legen Sie die Projekt-ID für das Cloud-Projekt fest, das Sie verwenden möchten:

    PROJECT_ID=$PROJECT_ID
    
  2. Legen Sie den GitHub-Nutzernamen fest, unter dem Sie Ihr Repository speichern möchten:

    GITHUB_USER=$GITHUB_ID
    
  3. Legen Sie die Variablen PROJECT_NUMBER und REGION fest, die im gesamten Prozess verwendet werden sollen:

    PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
        --format='value(projectNumber)')
    
    REGION=$REGION
    

    Ersetzen Sie im vorherigen Beispiel $REGION durch den Namen der Region, die Sie verwenden möchten, z. B. us-central1.

    Weitere Informationen zu verfügbaren Regionen finden Sie unter Cloud Workstations-Standorte.

Artifact Registry-Repository erstellen

In dieser Anleitung verwenden Sie Artifact Registry zum Speichern und Scannen Ihrer Images.

  1. Erstellen Sie mit dem folgenden Befehl ein Repository:

    gcloud artifacts repositories create custom-images \
          --repository-format=docker \
          --location=$REGION \
          --description="Docker repository"
    

    Ersetzen Sie $REGION durch den Namen der Region, die Sie verwenden möchten.

  2. Konfigurieren Sie Docker so, dass Ihre gcloud-CLI-Anmeldedaten für den Zugriff auf Artifact Registry verwendet werden.

    gcloud auth configure-docker $REGION-docker.pkg.dev
    

    Führen Sie den folgenden Befehl aus, um Artefaktanalyse zu deaktivieren:

    gcloud services disable containerscanning.googleapis.com
    

GitHub-Repository konfigurieren

In der Praxis speichern Sie das Dockerfile für Ihre benutzerdefinierten Images in einem Git-Repository. Der automatisierte Prozess greift während des Build-Prozesses auf dieses Repository zu, um die relevanten Konfigurationen und das Dockerfile abzurufen.

Beispiel-Repository verzweigen

So forken Sie ein Beispiel-Repository, das Containerdefinitionen enthält:

  1. Klicken Sie auf diesen Link, um einen neuen Fork des Repositorys software-delivery-workshop zu erstellen.
  2. Wenn Sie dazu aufgefordert werden, melden Sie sich bei GitHub an.
  3. Wählen Sie Ihren GitHub-Nutzernamen als Inhaber aus. Der Repository-Name wird als software-delivery-workshop angezeigt.
  4. Klicken Sie auf Fork erstellen und warten Sie einige Sekunden, bis der Vorgang abgeschlossen ist.

Cloud Build mit GitHub verbinden

Verbinden Sie dieses Repository dann über die integrierte GitHub-Verbindungsfunktion mit Cloud Build. Klicken Sie auf den Link zum GitHub-Repository und folgen Sie der Anleitung, um den Vorgang abzuschließen. Sie müssen den Trigger nicht im letzten Schritt des Assistenten erstellen und können die letzten Schritte überspringen, da Sie dies später über die Befehlszeile tun können.

Wenn Sie eine andere Git-Repository-Lösung verwenden, können Sie auch der Anleitung zum Verbinden von Cloud Build mit GitLab oder Bitbucket folgen.

Cloud Build-Trigger erstellen

Das Beispiel-Repository enthält eine Containerdefinition und eine Cloud Build-Konfiguration, die zum Erstellen des Container-Images verwendet wird. In diesem Schritt erstellen Sie einen Cloud Build-Trigger, der die Anweisungen in der Datei cloudbuild.yaml ausführt, die sich im Ordner labs/cloudbuild-scheduled-jobs/code-oss-java befindet.

gcloud builds triggers create manual \
    --name=custom-image-trigger \
    --repo=$GITHUB_USER/software-delivery-workshop \
    --repo-type=GITHUB \
    --branch=main \
    --build-config=labs/cloudbuild-scheduled-jobs/code-oss-java/cloudbuild.yaml \
    --substitutions=_REGION=$REGION,_AR_REPO_NAME=custom-images,_AR_IMAGE_NAME=code-oss-java,_IMAGE_DIR=labs/cloudbuild-scheduled-jobs/code-oss-java

TRIGGER_ID=$(gcloud builds triggers list \
    --filter=name="custom-image-trigger" --format="value(id)")

In diesem Beispiel wird Folgendes konfiguriert:

  • Mit dem gcloud-CLI-Befehl wird in Cloud Build ein manueller Trigger mit dem Namen custom-image-trigger erstellt, wie durch das Flag name in der zweiten Zeile angegeben.
  • Die nächsten drei Zeilen enthalten Flags, die sich auf das GitHub-Quell-Repository beziehen:
  • Das Flag build-config gibt den Pfad zur Cloud Build-Datei im Git-Repository an.
  • Verwenden Sie das Flag substitutions, um den Job dynamisch zu machen. Für diesen Job übergibt der Befehl die folgenden Variablen:

    • Region, $_REGION
    • Artifact Registry-Repository-Name, $_AR_REPO_NAME
    • Container-Image-Name, $_AR_IMAGE_NAME
    • Speicherort des zu erstellenden Dockerfile, $_IMAGE_DIR

    Sehen Sie sich die Datei cloudbuild.yaml an, um zu sehen, wie diese Variablen im Prozess verwendet werden.

  • Nachdem der Trigger erstellt wurde, wird der eindeutige Name des Triggers abgerufen und zur späteren Verwendung in der Umgebungsvariablen $TRIGGER_ID gespeichert.

Cloud Scheduler konfigurieren

Damit Ihre Images immer auf dem neuesten Stand sind, können Sie mit Cloud Scheduler den Cloud Build-Trigger in einer bestimmten Häufigkeit ausführen. In dieser Anleitung wird der Job täglich ausgeführt. In der Praxis sollten Sie hier eine Häufigkeit festlegen, die den Anforderungen Ihrer Organisation entspricht, damit immer die neuesten Updates enthalten sind.

  1. Weisen Sie dem Standarddienstkonto eine erforderliche Rolle zu, um den Cloud Build-Trigger aufzurufen:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
        --role="roles/cloudbuild.builds.editor"
    
  2. Weisen Sie dem Cloud Build-Dienstkonto eine erforderliche Rolle zu, um Images in Artifact Registry hochzuladen:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
        --role="roles/artifactregistry.admin"
    
  3. Erstellen Sie den Cloud Scheduler-Job mit dem folgenden Befehl:

    gcloud scheduler jobs create http run-build \
        --schedule='0 1 * * *' \
        --uri=https://cloudbuild.googleapis.com/v1/projects/$PROJECT_ID/locations/global/triggers/$TRIGGER_ID:run \
        --location=us-central1 \
        --oauth-service-account-email=$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
        --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform
    
  4. Der Job wird einmal täglich ausgeführt. Wenn Sie die Funktion jedoch sofort testen möchten, führen Sie den Job manuell über Cloud Scheduler aus:

    Zu Cloud Scheduler

    1. Suchen Sie auf der Seite „Cloud Scheduler“ nach dem Eintrag run-build, den Sie gerade erstellt haben.
    2. Klicken Sie in der Spalte „Aktionen“ auf das Dreipunkt-Menü more_vertWeitere Optionen für diese Zeile.
    3. Klicken Sie auf Jobausführung erzwingen, um das System manuell zu testen.
    4. Nachdem der Befehl erfolgreich ausgeführt wurde, wechseln Sie zur Cloud Build-Verlaufsseite, um den Fortschritt zu prüfen:

      Zum Cloud Build-Verlauf

Ergebnisse überprüfen

Da Sie die Container Scanning API im Rahmen des Einrichtungsprozesses aktiviert haben, scannt Artifact Registry die Images automatisch auf Sicherheitslücken.

So prüfen Sie die Sicherheitslücken:

  1. Öffnen Sie die Seite „Artifact Registry-Repositories“:

    Zu Artifact Registry-Repositories

  2. Klicken Sie in der Repository-Liste auf ein Repository.

  3. Klicken Sie auf den Namen eines Images. Die Gesamtzahl der Sicherheitslücken für jeden Image-Digest wird in der Spalte Sicherheitslücken angezeigt.

    Seite „Artifact Registry-Repositories“ mit einem Beispiel-Image-Namen

  4. Wenn Sie die Liste der Sicherheitslücken für ein Image aufrufen möchten, klicken Sie auf den Link in der Spalte Vulnerabilities (Sicherheitslücken). In der Liste der Sicherheitslücken werden der Schweregrad, die Verfügbarkeit einer Fehlerbehebung und der Name des Pakets angezeigt, das die Sicherheitslücke enthält.

    Artifact Registry-Seite „Sicherheitslücken“ mit einer Beispielliste von Sicherheitslücken

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Damit Ihrem Google Cloud -Konto die auf dieser Seite verwendeten Ressourcen nicht in Rechnung gestellt werden, sollten Sie Ressourcen, die Sie nicht mehr benötigen, löschen.

So löschen Sie ein Google Cloud -Projekt über die Google Cloud Console oder die gcloud-Befehlszeile:

Console

  1. Wechseln Sie in der Google Cloud -Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

gcloud

    Google Cloud -Projekt löschen:

    gcloud projects delete PROJECT_ID

Weitere Informationen zum Löschen anderer Ressourcen wie Workstation-Cluster, Workstation-Konfigurationen und Workstations finden Sie unter Ressourcen löschen.

Nächste Schritte