Dieser Artikel beschreibt die neue Cloud-Run-Funktion, mit der sich Cloud Storage Buckets als Container-Volume einbinden lassen.
Einführung
Wer Serverless-Dienste wie Cloud Run für eine statische Website nutzen möchte, will in der Regel auch auf Dateien in einem Bucket zugreifen. Eine neue Funktion der Google Cloud Platform macht das jetzt einfacher denn je. Falls Sie Cloud Run noch nicht kennen: Es ist ein Managed Service zum Ausführen containerisierter workloads auf der skalierbaren Infrastruktur von Google. In diesem Artikel betrachten wir das Beispiel einer statischen Website – die Einsatzmöglichkeiten dieser Funktion sind jedoch nahezu unbegrenzt.
Problemstellung
Bis vor Kurzem ließ sich Object Storage in Cloud Run nur über Drittanbieter-Tools oder Cloud-Client-Bibliotheken innerhalb der Anwendung ansprechen. Das funktionierte zwar, brachte aber häufig zusätzlichen Aufwand bei Skalierung und Verwaltung im Bereitstellungsprozess mit sich.
Mit der kürzlich eingeführten Möglichkeit, Cloud Storage in Cloud Run zu mounten, lassen sich Cloud Storage Buckets nun direkt als Volumes in Cloud-Run-Containern einbinden – ganz ohne zusätzliche Bibliotheken.
Nachdem wir die Verbesserungen und ihre Vorteile beleuchtet haben, kommen wir zu unserem Anwendungsfall: dem Hosten einer statischen Website mit Cloud Run und Cloud Storage Volume Mounts.
Lösung
Legen Sie zunächst ein Projekt für die Anwendung und den Storage Bucket an. Setzen Sie in Ihrem bevorzugten Kommandozeilen-Tool ein paar praktische Umgebungsvariablen und konfigurieren Sie gcloud.
export GCP_PROJECT=my-cloud-run-static-site
export REGION=us-east4
gcloud projects create $GCP_PROJECT
gcloud config set project $GCP_PROJECT
Aktivieren Sie anschließend die APIs für Cloud Run, Cloud Build und Artifact Registry, um diese Services nutzen zu können.
gcloud services enable run.googleapis.com \
cloudbuild.googleapis.com \
artifactregistry.googleapis.com
Jetzt holen wir den Code für unsere statische Website.
git clone https://github.com/waymanls/my-cloud-run-static-site.git
Ein Blick in die Datei index.html zeigt, dass wir unsere Bilder unter dem Pfad /images ablegen. Diesen Pfad brauchen wir später im Tutorial noch einmal. Zunächst legen wir den Cloud Storage Bucket für unsere statischen Assets an und laden das JPEG-Bild hoch.
gcloud storage buckets create gs://$GCP_PROJECT-bucket --location=$REGION
gcloud storage cp beach.jpeg gs://$GCP_PROJECT-bucket/beach.jpeg
Als Nächstes erstellen wir unser Artifact-Registry-Repository.
gcloud artifacts repositories create $GCP_PROJECT-repo \
--repository-format=docker \
--location=$GCP_REGION
Mit dem Artifact-Registry-Repo im Rücken bauen und pushen wir nun das Container-Image über Cloud Build.
gcloud builds submit --tag $REGION-docker.pkg.dev/$GCP_PROJECT/$GCP_PROJECT-repo/$GCP_PROJECT-svc
Sobald das Container-Image in unserem Repository liegt, erstellen wir damit eine Cloud-Run-Anwendung der zweiten Generation.
gcloud run deploy $GCP_PROJECT-svc --image $REGION-docker.pkg.dev/$GCP_PROJECT/$GCP_PROJECT-repo/$GCP_PROJECT-svc \
--execution-environment=gen2 --allow-unauthenticated
Jetzt fehlt nur noch der letzte Baustein unseres Beispiels: das Einbinden des Cloud Storage Buckets als Container-Volume. Dazu "aktualisieren" wir unseren Cloud-Run-Service. Die Konfigurationswerte übergeben wir hier per Switch im gcloud-Befehl, alternativ ist auch eine YAML-Service-Datei möglich. Wie Sie im folgenden Befehl sehen, verwenden wir den zuvor in der index.html festgelegten Pfad "images" als Basispfad und Namen für unser Container-Volume.
gcloud run services update $GCP_PROJECT-svc \
--execution-environment=gen2 \
--add-volume=name=images,type=cloud-storage,bucket=$GCP_PROJECT-bucket \
--add-volume-mount=volume=images,mount-path=/usr/share/nginx/html/images
Nach diesen Schritten haben Sie eine Cloud-Run-Anwendung, die einen Cloud Storage Bucket erfolgreich als Volume in Ihren Cloud-Run-Service einbindet und auf ein Objekt aus diesem Volume zugreift.

Aufräumen
Zum Abschluss empfiehlt es sich, das Projekt mit folgendem Befehl wieder zu löschen.
gcloud projects delete $GCP_PROJECT
Der Vorteil dieses Ansatzes: Sie binden Ihre Serverless-workloads in Cloud Run nativ und direkt an statische Assets in Object-Storage-Backends an – ohne den bisher nötigen Umweg über Cloud-Client-Bibliotheken oder Drittanbieter-Services.