Lab: Diensterweiterungen in Media CDN

1. Einführung

Letzte Aktualisierung: 01.05.2024

Content Delivery Networks (CDNs) verbessern die Leistung für Nutzer, indem sie häufig aufgerufene Inhalte näher an den Endnutzern im Cache speichern, Verbindungen näher an den Clients beenden, Verbindungen zum Ursprung wiederverwenden und moderne Netzwerkprotokolle und Anpassungen nutzen.

Media CDN, das globale Edge-Netzwerk von GCP für das Streamen von Medien, bietet viele integrierte oder „Kern“-Funktionen. Die Kernfunktionen sind für die häufigsten Anwendungsfälle vorgesehen. Möglicherweise haben Sie aber auch Anforderungen, die nicht durch diese Kernfunktionen abgedeckt werden.

Mit Service Extensions für Media CDN, manchmal auch als Edge-Programmierbarkeit bezeichnet, können Sie Ihren eigenen Code am Edge ausführen, um das Verhalten von Media CDN anzupassen. Dadurch werden zusätzliche Anwendungsfälle ermöglicht, z. B. das Normalisieren von Cache-Schlüsseln, die benutzerdefinierte Token-Authentifizierung und der Token-Widerruf, zusätzliche benutzerdefinierte Logfelder, A/B-Tests und benutzerdefinierte Fehlerseiten.

Umfang

In diesem Codelab werden die Schritte zum Bereitstellen einer CDN-Bereitstellungsumgebung mit Edge Compute-Unterstützung mit Media CDN (CDN) + Service Extensions (Edge-Programmierbarkeit) + Cloud Storage (CDN-Quelle) beschrieben.

Lerninhalte

• Media CDN mit einem als Ursprung festgelegten Cloud Storage-Bucket einrichten
• Diensterweiterungs-Plug‑in mit benutzerdefinierter HTTP-Authentifizierung erstellen und mit Media CDN verknüpfen
• So prüfen Sie, ob das Service Extension-Plug-in wie erwartet funktioniert
• (optional) Verwalten eines Service Extension-Plug-ins, z. B. Aktualisieren, Referenzieren, Zurücksetzen und Löschen einer bestimmten Plug-in-Version

Voraussetzungen

• Grundkenntnisse in den Bereichen Netzwerk und HTTP
• Grundkenntnisse zu Unix/Linux-Befehlszeilen

2. Hinweis

Antrag auf Zulassungsliste für Media CDN und Zulassungsliste für Service Extensions

Achtung: Ihr Projekt muss für Media CDN und Service Extensions für Media CDN auf der Zulassungsliste stehen. Wenn Ihr Projekt nicht auf der Zulassungsliste steht, können Sie dieses Lab nicht abschließen.

Bevor Sie beginnen, müssen Sie dafür sorgen, dass Ihr Projekt sowohl für Media CDN als auch für Diensterweiterungen für Media CDN auf die Zulassungsliste für die private Vorschau gesetzt wurde.

• Wenn Sie Zugriff auf Media CDN und Service Extensions für Media CDN anfordern möchten, wenden Sie sich an Ihr Google-Account-Management-Team, damit es in Ihrem Namen eine Zugriffsanfrage für Media CDN und Service Extensions erstellt.

Hinweise:Wenn Sie zu Google gehören und Service Extensions mit Media CDN testen möchten, wenden Sie sich an die Produktmanager für Media CDN und Service Extensions, um Zugriff anzufordern.

3. Einrichtung und Anforderungen

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Für dieses Lab benötigen Sie lediglich einen Browser.

Hinweis

IAM-Rollen und ‑Zugriff

Die zum Erstellen von Media CDN- und Artifact Registry-Ressourcen erforderlichen IAM-Berechtigungen (Identity and Access Management) sind:

• roles/networkservices.edgeCacheAdmin
• roles/networkservices.edgeCacheUser
• roles/networkservices.edgeCacheViewer
• roles/artifactregistry.repoAdmin

Prüfen Sie in Cloud Shell, ob die Umgebungsvariablen project_id, project_num, location und repository eingerichtet sind.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
PROJECT_NUM=[YOUR-PROJECT-NUMBER]
LOCATION=us-central1
REPOSITORY=service-extension-$PROJECT_ID

APIs aktivieren

Aktivieren Sie die Media CDN- und Service Extensions APIs mit den folgenden Befehlen.

gcloud services enable networkservices.googleapis.com
gcloud services enable networkactions.googleapis.com
gcloud services enable edgecache.googleapis.com
gcloud services enable artifactregistry.googleapis.com

4. Cloud Storage-Bucket erstellen

Media CDN-Inhalte können von Speicherorten wie einem Cloud Storage-Bucket, einem Drittanbieterspeicherort oder einem öffentlich zugänglichen HTTP(HTTPS)-Endpunkt stammen.

In diesem Codelab speichern wir Inhalte in einem Cloud Storage-Bucket.

Hinweise:Cloud Storage-Bucket-Namen müssen global eindeutig sein. Um Konflikte zu vermeiden, verwenden wir die Umgebungsvariable $PROJECT_ID als Teil des Bucket-Namens.

Wir verwenden den Befehl gsutil mb, um den Bucket zu erstellen.

gsutil mb gs://mediacdn-bucket-$PROJECT_ID

Optional können Sie einen Cloud Storage-Bucket über die Benutzeroberfläche erstellen:

1. Wechseln Sie in der Google Cloud Console zum Cloud Storage-Browser.
2. Klicken Sie auf die Schaltfläche ERSTELLEN.
3. Geben Sie einen Namen für den Bucket ein. – z.B. „mediacdn-bucket-$PROJECT_ID“.
4. Behalten Sie für alle anderen Einstellungen die Standardwerte bei.
5. Klicken Sie auf die Schaltfläche ERSTELLEN.

5. Testobjekt in den Cloud Storage-Bucket hochladen

Als Nächstes laden wir ein Objekt in den Cloud Storage-Bucket hoch.

1. Erstellen Sie eine Datei in Cloud Shell und laden Sie sie dann mit gsutil in den Bucket hoch.

echo media-cdn-service-extensions-test > file.txt

gsutil cp file.txt gs://mediacdn-bucket-$PROJECT_ID

Hinweise:Media CDN unterstützt private Buckets als Ursprung. Damit Media CDN auf Inhalte aus einem privaten Cloud Storage-Bucket zugreifen kann, müssen Sie IAM so konfigurieren, dass dem Media CDN-Dienstkonto „objectViewer“-Zugriff gewährt wird.

Das Dienstkonto hat die folgenden Rollen:

service-<PROJECT_NUM>@gcp-sa-mediaedgefill.iam.gserviceaccount.com

2. Media CDN-Zugriff auf den Bucket gewähren

gsutil iam ch \
serviceAccount:service-$[e-mail]:objectViewer gs://mediacdn-bucket-$PROJECT_ID

6. Media CDN konfigurieren

Als Nächstes erstellen wir eine Media CDN-Konfiguration.

Jede Media CDN-Konfiguration besteht aus zwei Hauptressourcen:

• EdgeCacheService für die clientseitige Konfiguration (TLS, IP-Adressierung), Routing, CDN-Konfiguration (Cache-Modi, TTLs, Signatur) und Sicherheitsrichtlinien.
• EdgeCacheOrigin: Verantwortlich für die Konfiguration pro Ursprung für jeden HTTP-basierten Ursprung sowie für Wiederholungsbedingungen, wenn Inhalte nicht verfügbar oder erreichbar sind.

Edge-Cache-Ursprung konfigurieren

Erstellen wir nun einen Ursprung, der auf den gerade erstellten Cloud Storage-Bucket verweist.

1. Rufen Sie in der Google Cloud Console die Seite Media CDN auf.
2. Klicken Sie auf den Tab URSPRÜNGE.
3. Klicken Sie auf ORIGIN ERSTELLEN.
4. Geben Sie „cloud-storage-origin“ als Namen für den Edge-Cache-Ursprung ein.
5. Unter „Herkunftsadresse“:
6. Wählen Sie „Google Cloud Storage-Bucket auswählen“ aus.
7. Suchen Sie nach dem Cloud Storage-Bucket mit dem Namen „mediacdn-bucket-$PROJECT_ID“.
8. Klicken Sie auf „AUSWÄHLEN“.
9. Behalten Sie für alle anderen Einstellungen die Standardwerte bei.
10. Klicken Sie auf ORIGIN ERSTELLEN.

Die neu erstellte EdgeCacheOrigin-Ressource wird in der Liste der Ursprünge in Ihrem Projekt auf der Seite „Ursprünge“ angezeigt.

Edge-Cache-Dienst konfigurieren

1. Rufen Sie in der Google Cloud Console die Seite Media CDN auf.
2. Klicken Sie auf den Tab DIENSTE.
3. Klicken Sie auf DIENST ERSTELLEN.
4. Geben Sie einen eindeutigen Namen für den Dienst ein, z.B. „media-cdn“, und klicken Sie dann auf „Weiter“.

5. Klicken Sie im Bereich „Routing“ auf HOSTREGEL HINZUFÜGEN.
6. Geben Sie im Feld „Hosts“ den Platzhalter „*“ ein.

7. Klicken Sie auf ROUTENREGEL HINZUFÜGEN.
8. Geben Sie für „Priorität“ den Wert „1“ an.
9. Klicken Sie auf ÜBEREINSTIMMUNGSBEDINGUNG HINZUFÜGEN, wählen Sie für „Pfadübereinstimmung“ die Option „Präfixübereinstimmung“ als Keyword-Option aus, geben Sie „/“ in das Feld „Pfadübereinstimmung“ ein und klicken Sie dann auf „Fertig“.
10. Wählen Sie unter „Primäre Aktion“ die Option Von einem Ursprung abrufen und dann den von Ihnen konfigurierten Ursprung aus der Drop-down-Liste aus.

11. Klicken Sie auf ERWEITERTE KONFIGURATIONEN, um weitere Konfigurationsoptionen zu maximieren.
12. Klicken Sie unter „Routenaktion“ auf ELEMENT HINZUFÜGEN. Gehen Sie anschließend so vor:
13. Wählen Sie für „Typ“ die Option „CDN-Richtlinie“ aus.
14. Wählen Sie für den Cache-Modus „Cache-all erzwingen“ aus.
15. Behalten Sie in allen anderen Feldern die Standardwerte bei.
16. Klicken Sie auf "Fertig".
17. Klicken Sie auf Speichern.

18. Klicken Sie auf DIENST ERSTELLEN.

Die neu erstellte EdgeCacheService-Ressource wird auf der Seite „Dienste“ in der Liste der Dienste in Ihrem Projekt angezeigt.

MediaCDN-IP-Adresse abrufen und testen

1. Rufen Sie in der Google Cloud Console die Seite Media CDN auf.
2. Zu Media CDN
3. Klicken Sie auf den Tab Services (Dienste).
4. Die Adressen für Ihren Dienst finden Sie in der Spalte Adressen.

Wenn Sie testen möchten, ob Ihr Dienst richtig für das Caching von Inhalten konfiguriert ist, verwenden Sie das Befehlszeilentool „curl“, um Anfragen zu senden und die Antworten zu prüfen.

curl -svo /dev/null "http://MEDIA_CDN_IP_ADDRESS/file.txt"

Die Befehlsausgabe sollte in etwa so aussehen:

< HTTP/2 200 OK
...
media-cdn-service-extensions-test
...

Sie haben jetzt erfolgreich eine MediaCDN-Bereitstellung mit Cloud Storage als Ursprung erstellt.

7. Artifact Registry für Dienst-Extensions konfigurieren

Bevor wir Service Extensions erstellen, müssen wir die Artifact Registry konfigurieren. Artifact Registry ist der universelle Paketmanager von Google Cloud zum Verwalten von Build-Artefakten. Plug-ins für Diensterweiterungen (Proxy-Wasm) werden in Artifact Registry veröffentlicht. Nachdem Proxy-Wasm-Plug-ins in Artifact Registry veröffentlicht wurden, können sie in Ihrer Media CDN-Bereitstellung bereitgestellt werden.

Hinweise:Artifact Registry-Repository-Namen müssen global eindeutig sein. Um Konflikte zu vermeiden, verwenden wir die Umgebungsvariable $PROJECT_ID als Teil des Repository-Namens.

Wir verwenden den Befehl gcloud artifacts repositories create, um das Repository zu erstellen.

gcloud artifacts repositories create service-extension-$PROJECT_ID \
    --repository-format=docker \
    --location=$LOCATION \
    --description="Repo for Service Extension" \
    --async

Optional können Sie ein Repository auch über die Benutzeroberfläche erstellen:

1. Rufen Sie in der Google Cloud Console die Seite Artifact Registry auf.
2. Klicken Sie auf die Schaltfläche + REPOSITORY ERSTELLEN.
3. Geben Sie einen Namen für das Repository ein, z. B. „service-extension-$PROJECT_ID“.
4. Format: „Docker“, Modus: „Standard“, Standorttyp: „Region“, „us-central1 (Iowa)“ auswählen
5. Klicken Sie auf die Schaltfläche ERSTELLEN.

Die neu erstellte Artifact Registry-Repository-Ressource sollte auf der Seite „Repositories“ angezeigt werden.

Nachdem die Repository-Ressource erstellt wurde, führen Sie den folgenden Befehl in Cloud Shell aus, um Ihren Cloud Shell-Docker-Client so zu konfigurieren, dass Pakete über dieses Repository hoch- und heruntergeladen werden.

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

Ausgabe:

...
Adding credentials for: us-central1-docker.pkg.dev
Docker configuration file updated.

8. Service Extensions in Media CDN konfigurieren

Im Folgenden wird gezeigt, wie Sie ein Service Extensions-Plug-in (Proxy-Wasm) schreiben und erstellen, das in Media CDN bereitgestellt werden kann. Dazu verwenden wir die Programmiersprache Rust.

In diesem Beispiel erstellen wir ein Proxy-Wasm-Plug-in, das prüft, ob jede HTTP-Anfrage einen Authorization-Header mit dem Wert „secret“ enthält. Wenn die Anfrage diesen Header nicht enthält, generiert das Plug-in eine HTTP-Antwort mit dem Statuscode 403 Forbidden.

Kurze Auffrischung zu Diensterweiterungen: Es gibt drei wichtige Ressourcen: WasmAction, WasmPlugin und WasmPluginVersion.

• Eine WasmAction-Ressource wird an Ihren Media CDN EdgeCacheService angehängt. Eine WasmAction verweist auf eine WasmPlugin-Ressource.
• Eine WasmPlugin-Ressource hat eine Hauptversion, die der aktuellen aktiven WasmPluginVersion entspricht.
• WasmPluginVersions verweisen auf ein Container-Image aus Artifact Registry. Wenn Sie Änderungen an Ihren Proxy-Wasm-Plug-ins vornehmen, erstellen Sie verschiedene WasmPluginVersions.

Das folgende Diagramm veranschaulicht die Beziehung zwischen diesen Ressourcen.

Plug‑in für Diensterweiterungen schreiben und erstellen

1. Installieren Sie die Rust-Toolchain gemäß der Anleitung unter https://www.rust-lang.org/tools/install.

Achtung: Folgen Sie der Anleitung, um die Rust-Toolchain zu installieren.

Wenn Sie beim Ausführen von „rustup“ den Fehler -bash: rustup: command not found erhalten, versuchen Sie, den PATH-Umgebung in Cloud Shell mit source "$HOME/.cargo/env" neu zu laden.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

2. Fügen Sie als Nächstes Ihrer Rust-Toolchain Wasm-Unterstützung hinzu, indem Sie den folgenden Befehl ausführen:

rustup target add wasm32-wasi

3. Erstellen Sie ein Rust-Paket mit dem Namen my-wasm-plugin:

cargo new --lib my-wasm-plugin

Ausgabe:

Created library `my-wasm-plugin` package

4. Wechseln Sie in das Verzeichnis my-wasm-plugin. Dort sollten Sie eine Datei namens Cargo.toml und ein Verzeichnis namens src sehen.

cd my-wasm-plugin
ls

Ausgabe:

Cargo.toml  src

5. Konfigurieren Sie als Nächstes Ihr Rust-Paket, indem Sie die Datei Cargo.toml bearbeiten. Fügen Sie nach der Zeile [dependencies] in der Datei „Cargo.toml“ Folgendes hinzu:

proxy-wasm = "0.2"
log = "0.4"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true
opt-level = 3
codegen-units = 1
panic = "abort"
strip = "debuginfo"

6. Nach der Bearbeitung sollte die Datei Cargo.toml in etwa so aussehen:

[package]
name = "my-wasm-plugin"
version = "0.1.0"
edition = "2021"

[dependencies]
proxy-wasm = "0.2"
log = "0.4"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true
opt-level = 3
codegen-units = 1
panic = "abort"
strip = "debuginfo"

7. Laden Sie die Datei „sample_code“ herunter. Kopieren Sie den gesamten Inhalt der Datei „sample_code“ in die Datei lib.rs im Verzeichnis src in Cloud Shell.

Hinweise:Der Quellcode befindet sich in der Datei lib.rs. Der Quellcode sollte in der Programmiersprache RUST geschrieben werden. Weitere Codebeispiele finden Sie unter network-actions-recipes.

In diesem Codelab wird in unserem Code geprüft, ob jede HTTP-Anfrage einen Autorisierungsheader mit dem Wert „secret“ enthält. Wenn die Anfrage diesen Header nicht enthält, wird eine HTTP 403-Antwort „Forbidden“ (Verboten) generiert.

8. Nach der Bearbeitung sollte die Datei lib.rs in etwa so aussehen:

use log::info;
use proxy_wasm::traits::*;
use proxy_wasm::types::*;

...

struct DemoPlugin;

impl HttpContext for DemoPlugin {
    fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action {
        if self.get_http_request_header("Authorization") == Some(String::from("secret")) {
            info!("Access granted.");
            Action::Continue
        } else {
            self.send_http_response(403, vec![], Some(b"Access forbidden.\n"));
            Action::Pause
        }
    }
}

impl Context for DemoPlugin {}

9. Nachdem wir die Manifestdatei Cargo.toml konfiguriert und den Proxy-Wasm-Code in die Datei lib.rs geschrieben haben , können wir das Proxy-Wasm-Plug-in erstellen.

cargo build --release --target wasm32-wasi

Wenn der Build erfolgreich abgeschlossen wurde, wird eine Meldung wie die folgende angezeigt:

Finished release [optimized] target(s) in 1.01s

Prüfen wir auch das Verzeichnis target und sehen wir nach, ob die Dateien erstellt wurden:

ls ./target

Die Ausgabe sollte so aussehen:

CACHEDIR.TAG release wasm32-wasi

Proxy-Wasm-Plug-in in Artifact Registry veröffentlichen

Als Nächstes veröffentlichen wir unser Proxy-Wasm-Plug-in im Artifact Registry-Repository, das Sie zuvor erstellt haben, damit es in Media CDN bereitgestellt werden kann.

Zuerst verpacken wir die Proxy-Wasm-Plug-ins in einem Container-Image.

1. Erstellen Sie im selben Verzeichnis my-wasm-plugin eine Datei namens Dockerfile mit folgendem Inhalt:

FROM scratch 
COPY target/wasm32-wasi/release/my_wasm_plugin.wasm plugin.wasm

2. Erstellen Sie als Nächstes das Container-Image:

docker build --no-cache --platform wasm -t my-wasm-plugin .

Achtung: Wenn Sie Apple Silicon (ARM-basierte Architektur) oder andere Nicht-x86-Prozessoren verwenden, müssen Sie zuerst die WASM-Unterstützung in Docker aktivieren (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads) und dann den folgenden Befehl ausführen, um das Container-Image zu erstellen.

(nur Nicht-x86-Prozessoren) Erstellen Sie als Nächstes das Container-Image:

docker build --no-cache --platform wasm --provenance=false -t my-wasm-plugin . 

Ausgabe

[+] Building 0.2s (5/5) FINISHED                                     docker:default
...

3. Als Nächstes veröffentlichen Sie Ihr Proxy-Wasm-Plug-in in Artifact Registry oder übertragen es dorthin. Wir taggen unser Container-Image mit dem Tag „prod“.

Hinweise:Artifact Registry verwendet eine Namenskonvention zum Identifizieren von Repositories und Images.

Der vollständige Name für ein Docker-Image in einem Repository hat folgendes Format:

LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

docker tag my-wasm-plugin $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin:prod

Jetzt übertragen wir das mit dem Tag „prod“ versehene Container-Image per Push an das Repository.

docker push $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin:prod

Ausgabe:

The push refers to repository 
...
8564ddd9910a: Pushed 
prod: digest: sha256:f3ae4e392eb45393bfd9c200cf8c0c261762f7f39dde5c7cd4b9a8951c6f2812 size: 525

Achtung: Achten Sie darauf, dass Sie gcloud als Credential Helper für die mit dem Speicherort des Repositorys verknüpfte Artifact Registry-Domain konfiguriert haben.

Wenn Sie beim Übertragen des Containers in die Artifact Registry den Fehler „permission denied“ (Berechtigung verweigert) erhalten, kehren Sie zu Artifact Registry für Dienst-Extensions konfigurieren zurück und führen Sie den Befehl gcloud auth noch einmal aus.

Prüfen Sie nun, ob das Container-Image des Proxy-Wasm-Plug-ins erfolgreich in Artifact Registry übertragen wurde. Die Ausgabe sollte in etwa so aussehen:

gcloud artifacts docker images list $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin --include-tags

Ausgabe:

Listing items under project 
...
IMAGE                                         DIGEST           TAGS  CREATE_TIME          UPDATE_TIME
<LOCATION>-docker.pkg.dev/.../my-wasm-plugin  sha256:08c12...  prod  2021-11-10T23:31:27  2021-11-10T23:31:27

Proxy-Wasm-Plug‑in mit Ihrer Media CDN-Bereitstellung verknüpfen

Jetzt können wir das Proxy-Wasm-Plug‑in mit Ihrer Media CDN-Bereitstellung verknüpfen.

Proxy-Wasm-Plug‑ins sind in der EdgeCacheService-Ressource mit Media CDN-Routen verknüpft.

Achtung: Das Erstellen jeder Proxy-Wasm-Ressource kann einige Zeit in Anspruch nehmen.

Warten Sie, bis die Meldung angezeigt wird, dass der Vorgang abgeschlossen ist, bevor Sie mit den nächsten Schritten fortfahren.

1. Zuerst erstellen wir eine Wasm-Plugin-Ressource für unser Proxy-Wasm-Plugin.

gcloud alpha service-extensions wasm-plugins create my-wasm-plugin-resource

2. Als Nächstes erstellen wir eine WasmPluginVersion.

gcloud alpha service-extensions wasm-plugin-versions create my-version-1 \
    --wasm-plugin=my-wasm-plugin-resource \
    --image="$LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin:prod"

3. Als Nächstes geben wir die Hauptversion für unser Proxy-Wasm-Plug-in an.

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource \
    --main-version=my-version-1

Prüfen Sie nun, ob das Proxy-Wasm-Plug-in erfolgreich dem Container-Image zugeordnet wurde, das sich im Artifact Registry-Repository befindet. Die Ausgabe sollte in etwa so aussehen:

gcloud alpha service-extensions wasm-plugin-versions list --wasm-plugin=my-wasm-plugin-resource

Ausgabe:

NAME   WASM_IMAGE WASM_IMAGE_DIGEST CONFIG_SIZE  CONFIG_IMAGE CONFIG_IMAGE_DIGEST UPDATE_TIME                                            
c7cfa2 <LOCATION>-docker.pkg.dev/.../my-wasm-plugin@sha256:6d663... ... ... 
...

4. Als Nächstes erstellen wir eine WasmAction-Ressource, die auf unsere Wasm-Plug-in-Ressource verweist.

gcloud alpha service-extensions wasm-actions create my-wasm-action-resource \
    --wasm-plugin=my-wasm-plugin-resource

Prüfen wir auch, ob die WasmAction-Ressource erfolgreich dem Proxy-Wasm-Plug-in zugeordnet wurde. Die Ausgabe sollte in etwa so aussehen:

gcloud alpha service-extensions wasm-actions list

Ausgabe:

NAME                                     WASMPLUGIN                                            
my-wasm-action-resource                  projects/805782461588/locations/global/wasmPlugins/myenvoyfilter-resource
...

5. Als Nächstes müssen wir die Konfiguration unseres Media CDN EdgeCacheService exportieren:

gcloud edge-cache services export media-cdn --destination=my-service.yaml

6. Öffnen Sie dann die Datei my-service.yaml und fügen Sie der routeAction für die angegebene Route eine wasmAction hinzu, die auf die zuvor erstellte WasmPlugin-Ressource verweist.

wasmAction: "my-wasm-action-resource"

7. Nach der Bearbeitung sollte die Datei my-service.yaml in etwa so aussehen:

...

pathMatchers:
  - name: routes
    routeRules:
    - headerAction: {}
      matchRules:
      - prefixMatch: /
      origin: projects/<PROJECT_NUM>/locations/global/edgeCacheOrigins/cloud-storage-origin
      priority: '1'
      routeAction:
        cdnPolicy:
          cacheKeyPolicy: {}
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 3600s
          signedRequestMode: DISABLED
        wasmAction: "my-wasm-action-resource"
...

8. Anschließend speichern wir die aktualisierte Konfiguration mit der Proxy-Wasm-Konfiguration in der Datei my-service-with-wasm.yaml.

Achtung: Wenn beim Importieren der bearbeiteten YAML-Datei in die Edge-Cache-Services API ein Konfigurationsvalidierungsfehler auftritt, prüfen Sie die YAML-Datei noch einmal und achten Sie darauf, dass die Zeile wasmAction im Abschnitt routeAction hinzugefügt wurde. Verwenden Sie für den Einzug nur Leerzeichen. Tabs werden von YAML nicht akzeptiert.

9. Schließlich importieren wir die aktualisierte Konfiguration für die Media CDN-Produktionsumgebung:

$ gcloud alpha edge-cache services import media-cdn --source=my-service-with-wasm.yaml

9. Service Extensions-Proxy-Wasm-Plug-in in Media CDN validieren

Wenn Sie testen möchten, ob Ihr Dienst richtig für das Caching von Inhalten konfiguriert ist, verwenden Sie das Befehlszeilentool „curl“, um Anfragen zu senden und die Antworten zu prüfen.

Hinweise:Es kann bis zu 10 Minuten dauern, bis die Änderung im gesamten MediaCDN-Netzwerk wirksam wird. In der Zwischenzeit wird der HTTP 403-Fehler möglicherweise nicht angezeigt. Versuchen Sie es so lange, bis der Fehler 403 zurückgegeben wird.

curl -svo /dev/null "http://IP_ADDRESS/file.txt"

Die Befehlsausgabe sollte in etwa so aussehen:

< HTTP/2 403 Forbidden
...
Access forbidden.
...

Stellen Sie die Anfrage jetzt noch einmal mit einem Authorization-Header und dem Wert „secret“ aus.

curl -svo /dev/null "http://IP_ADDRESS/file.txt" -H "Authorization: secret"

Die Befehlsausgabe sollte in etwa so aussehen:

< HTTP/2 200 OK
...
media-cdn-service-extensions-test
...

10. Optional: Proxy-Wasm-Plug-ins verwalten

Proxy-Wasm-Plug-in aktualisieren

Wenn Sie Ihre Proxy-Wasm-Plug-ins verbessern oder neue Funktionen hinzufügen, müssen Sie die aktualisierten Plug-ins in Media CDN bereitstellen. Im Folgenden wird beschrieben, wie Sie eine aktualisierte Version eines Plug-ins bereitstellen.

Sie können beispielsweise den Beispiel-Plug-in-Code so aktualisieren, dass der Authorization-Header anhand eines anderen Werts für die Authentifizierung ausgewertet wird.

Aktualisieren Sie zuerst die Quelldatei „src/lib.rs“ mit dem unten gezeigten Code:

use log::{info, warn};
use proxy_wasm::traits::*;
use proxy_wasm::types::*;

...

struct DemoPlugin;

impl HttpContext for DemoPlugin {
    fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action {
        if self.get_http_request_header("Authorization") == Some(String::from("another_secret")) {
            info!("Access granted.");
            Action::Continue
        } else {
            warn!("Access forbidden.");
            self.send_http_response(403, vec![], Some(b"Access forbidden.\n"));
            Action::Pause
        }
    }
}

impl Context for DemoPlugin {}

Erstellen, verpacken und veröffentlichen Sie als Nächstes das aktualisierte Plug-in:

cargo build --release --target wasm32-wasi
docker build --no-cache --platform wasm -t my-wasm-plugin .
docker tag my-wasm-plugin $LOCATION-docker.pkg.dev/$PROJECT_NUM/$REPOSITORY/my-wasm-plugin:prod
docker push $LOCATION-docker.pkg.dev/$PROJECT_NUM/$REPOSITORY>/my-wasm-plugin:prod

Sobald das Container-Image in Artifact Registry aktualisiert wurde, müssen wir eine neue WasmPluginVersion erstellen und dann die –main-Version des WasmPlugin aktualisieren, damit sie auf die neue Version verweist.

gcloud alpha service-extensions wasm-plugin-versions create my-version-2 \
    --wasm-plugin=my-wasm-plugin-resource \
   --image="$LOCATION-docker.pkg.dev/$PROJECT_NUM/$REPOSITORY>/my-wasm-plugin:prod"

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource \
    --main-version=my-version-2

Sie haben die Version des Container-Images, das aus Artifact Registry importiert werden soll, erfolgreich aktualisiert und in Ihrer Media CDN-Bereitstellung live geschaltet.

Rollback zu einer vorherigen Version durchführen

Wenn Sie ein Rollback auf eine frühere Version eines Plug-ins ausführen möchten, können Sie die Wasm-Plug-in-Ressource so aktualisieren, dass sie auf eine frühere Version verweist.

Zuerst listen wir die verfügbaren Versionen auf:

gcloud alpha service-extensions wasm-plugin-versions list --wasm-plugin=my-wasm-plugin-resource

Es sollte folgende Ausgabe angezeigt werden:

NAME   WASM_IMAGE WASM_IMAGE_DIGEST CONFIG_SIZE  CONFIG_IMAGE CONFIG_IMAGE_DIGEST UPDATE_TIME                                            
c7cfa2 <LOCATION>-docker.pkg.dev/.../my-wasm-plugin@sha256:6d663... ... ... 
a2a8ce <LOCATION>-docker.pkg.dev/.../my-wasm-plugin@sha256:08c12... ... ... 

Als Nächstes aktualisieren wir die Wasm-Plugin-Ressource, damit sie auf die vorherige Version „a2a8ce“ verweist:

$ gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource \
    --main-version="a2a8ce"

Wenn der Vorgang erfolgreich ist, sollte die folgende Ausgabe angezeigt werden:

✓ WASM Plugin [my-wasm-plugin-resource] is now serving version "a2a8ce"

Da Media CDN den Image-Digest Ihres Docker-Images jedes Mal speichert, wenn eine neue Wasm-Plugin-Ressource erstellt wird, wird beim Rollback die Version Ihres Codes verwendet, die vor dem letzten Rollout ausgeführt wurde.

gcloud alpha service-extensions wasm-plugins describe my-wasm-plugin-resource \
  --expand-config

Für die Version „a2a8ce“ ist das die Version mit dem Digest „sha256:08c12…“:

name: "my-wasm-plugin-resource"
mainVersion: "a2a8ce"
mainVersionDetails:
  image: "<LOCATION>-docker.pkg.dev/<PROJECT>/<REPOSITORY>/my-wasm-plugin"
  imageDigest: "<LOCATION>-docker.pkg.dev/<PROJECT>/<REPOSITORY>/my-wasm-plugin@sha256:08c121dd7fd1e4d3a116a28300e9fc1fa41b2e9775620ebf3d96cb7119bd9976"

WasmAction und WasmPlugin löschen

So löschen Sie eine WasmAction, ein WasmPlugin und die zugehörigen WasmPluginVersions:

Entfernen Sie zuerst den Verweis auf die WasmAction in der EdgeCacheService-Konfiguration von Media CDN.

Zu entfernende Referenzlinie:

wasmAction: "my-wasm-action-resource"

Anschließend aktualisieren wir die bearbeitete EdgeCacheService-Konfiguration.

gcloud alpha edge-cache services import prod-media-service --source=my-service.yaml

Aktualisieren Sie als Nächstes die Hauptversion Ihres WasmPlugin auf einen leeren String „“.

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource --main-version=

""

Führen Sie zum Schluss die folgenden Löschvorgänge in der angegebenen Reihenfolge aus.

gcloud alpha service-extensions wasm-actions delete my-wasm-action-resource

gcloud alpha service-extensions wasm-plugin-versions delete my-version \ --wasm-plugin=my-wasm-plugin-resource

gcloud alpha service-extensions wasm-plugins delete my-wasm-plugin-resource

11. Lab-Umgebung bereinigen

Vergessen Sie nicht, die Lab-Ressourcen zu bereinigen, nachdem Sie das CodeLab abgeschlossen haben. Andernfalls werden sie weiter ausgeführt und es fallen Kosten an.

Mit den folgenden Befehlen werden der Media CDN EdgeCache-Dienst, die EdgeCache-Konfiguration und das Service Extensions-Plug-in gelöscht. Führen Sie die folgenden Schritte zum Löschen in der angegebenen Reihenfolge aus.

gcloud edge-cache services delete media-cdn

gcloud edge-cache origins delete cloud-storage-origin

gcloud alpha service-extensions wasm-actions delete my-wasm-action-resource

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource --main-version=""

gcloud alpha service-extensions wasm-plugin-versions delete my-version-1 --wasm-plugin=my-wasm-plugin-resource

gcloud alpha service-extensions wasm-plugins delete my-wasm-plugin-resource

gcloud artifacts repositories delete service-extension-$PROJECT_ID --location=$LOCATION

Bei jedem der oben genannten Befehle sollten Sie aufgefordert werden, das Löschen der Ressource zu bestätigen.

12. Glückwunsch!

Sie haben das Codelab zu Service Extensions in Media CDN abgeschlossen.

Behandelte Themen

• Media CDN mit einem als Ursprung festgelegten Cloud Storage-Bucket einrichten
• Diensterweiterungs-Plug‑in mit benutzerdefinierter HTTP-Authentifizierung erstellen und mit Media CDN verknüpfen
• So prüfen Sie, ob das Service Extension-Plug-in wie erwartet funktioniert
• (optional) Verwalten eines Service Extension-Plug-ins, z. B. Aktualisieren, Referenzieren, Zurücksetzen und Löschen einer bestimmten Plug-in-Version

Nächste Schritte

Hier finden Sie einige Codelabs:

• Einer Web-App Push-Benachrichtigungen hinzufügen
• PWA mit Workbox erstellen

Weitere Informationen

• Leistungsstarkes Laden von Service Workern
• Service Worker-Caching-Strategien basierend auf Anfragetypen

Referenzdokumente

• Dokumentation zum Web-App-Manifest
• Web-App-Manifest-Eigenschaften (MDN)
• Installieren und zum Startbildschirm hinzufügen
• Service Worker – Übersicht
• Service Worker-Lebenszyklus
• Leistungsstarkes Laden von Service Workern
• Offline-Kochbuch