Mit Cloud Workstations können Sie benutzerdefinierte Images für Ihre Workstations erstellen und verwenden. Nachdem ein benutzerdefiniertes Image verwendet wird, ist es sinnvoll, einen Rebuild des benutzerdefinierten Images zu automatisieren, um Korrekturen und Updates aus den Basis-Images zu übernehmen.
In dieser Anleitung erfahren Sie, wie Sie eine automatisierte Pipeline erstellen, um sicherzustellen, dass Sie Sicherheitsupdates und ‑patches in Ihre benutzerdefinierten Workstation-Images einfügen.
Umgebung vorbereiten
Bevor Sie fortfahren, müssen Sie die folgenden Umgebungsvariablen festlegen.
Legen Sie die Projekt-ID für das Cloud-Projekt fest, das Sie verwenden möchten:
PROJECT_ID=$PROJECT_ID
Legen Sie den GitHub-Nutzernamen fest, unter dem Sie Ihr Repository speichern möchten:
GITHUB_USER=$GITHUB_ID
Legen Sie die Variablen
PROJECT_NUMBER
undREGION
fest, die während des Prozesses 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.
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.
Konfigurieren Sie Docker so, dass die
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 die 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 forken
So forken Sie ein Beispiel-Repository mit Containerdefinitionen:
- Klicken Sie auf diesen Link, um einen neuen Fork des
software-delivery-workshop
-Repositorys zu erstellen. - Wenn Sie dazu aufgefordert werden, melden Sie sich bei GitHub an.
- Wählen Sie Ihren GitHub-Nutzernamen als Inhaber aus. Der Repository-Name wird als
software-delivery-workshop
angezeigt. - Klicken Sie auf Fork erstellen und warten Sie einige Sekunden, bis der Vorgang abgeschlossen ist.
Cloud Build mit GitHub verbinden
Verbinden Sie das Repository dann mit Cloud Build. Verwenden Sie dazu die integrierte GitHub-Verbindungsfunktion. 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. Sie können die letzten Schritte überspringen, da Sie das später über die Befehlszeile erledigen 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 zum Erstellen des Container-Images. In diesem Schritt erstellen Sie einen Cloud Build-Trigger, der die Anweisungen in der Datei cloudbuild.yaml
ausführt. Diese Datei befindet sich im Ordner labs/cloudbuild-scheduled-jobs/code-oss-java.
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 ein manueller Trigger mit dem Namencustom-image-trigger
in Cloud Build erstellt, wie durch das Flagname
in der zweiten Zeile angegeben. - Die nächsten drei Zeilen enthalten Flags für das GitHub-Quell-Repository:
- Pfad zum Repository
- Typ des Repositorys
- Git-Zweig für den Build
- 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 gestalten. Für diesen Job werden mit dem Befehl die folgenden Variablen übergeben:- Region,
$_REGION
- Name des Artifact Registry-Repositorys,
$_AR_REPO_NAME
- Container-Image-Name:
$_AR_IMAGE_NAME
- Speicherort des Dockerfiles für den Build,
$_IMAGE_DIR
Sehen Sie sich die Datei cloudbuild.yaml an, um zu sehen, wie diese Variablen im Prozess verwendet werden.
- Region,
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 regelmäßigen Abständen ausführen. In dieser Anleitung wird der Job täglich ausgeführt. In der Praxis sollten Sie diese Option auf eine Häufigkeit festlegen, die den Anforderungen Ihrer Organisation entspricht, damit immer die neuesten Updates berücksichtigt werden.
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"
Weisen Sie dem Cloud Build-Dienstkonto eine erforderliche Rolle zu, um Bilder in Artifact Registry hochzuladen:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \ --role="roles/artifactregistry.admin"
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
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:
- Suchen Sie auf der Seite „Cloud Scheduler“ nach dem Eintrag, den Sie gerade erstellt haben und der run-build heißt.
- Klicken Sie in der Spalte „Aktionen“ in der entsprechenden Zeile auf das Menü more_vertWeitere Optionen.
- Klicken Sie auf Force a job run (Jobausführung erzwingen), um das System manuell zu testen.
Nachdem der Befehl erfolgreich ausgeführt wurde, wechseln Sie zur Seite „Cloud Build-Verlauf“, um den Fortschritt zu prüfen:
Ergebnisse überprüfen
Da Sie die Container Scanning API im Rahmen der Einrichtung aktiviert haben, scannt Artifact Registry die Images automatisch auf Sicherheitslücken.
So prüfen Sie die Sicherheitslücken:
Öffnen Sie die Seite „Artifact Registry-Repositorys“:
Klicken Sie in der Liste der Repositories auf ein Repository.
Klicken Sie auf einen Bildnamen. Alle Sicherheitslücken für die einzelnen Image-Digests werden in der Spalte Sicherheitslücken angezeigt.
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). Die Liste mit den Sicherheitslücken umfasst den Schweregrad, die Verfügbarkeit einer entsprechenden Lösung und den Namen des Pakets, das die Sicherheitslücke enthält.