Lab: Diensterweiterungen in Media CDN

1. Einführung

Zuletzt aktualisiert:01.05.2024

Content Delivery Networks (CDNs) verbessern die Nutzerleistung, indem häufig aufgerufene Inhalte näher an den Endnutzern im Cache gespeichert werden, Verbindungen näher an den Clients beendet werden, Verbindungen zum Ursprung wiederverwendet und moderne Netzwerkprotokolle und -anpassungen verwendet werden.

Media CDN, das globale Edge-Netzwerk der GCP für das Streaming von Medien, bietet viele integrierte Die Kernfunktionen sind für die häufigsten Anwendungsfälle vorgesehen.Möglicherweise haben Sie aber auch Anforderungen, die von diesem Satz von Kernfunktionen nicht erfüllt werden.

Mit Diensterweiterungen für Media CDN, die manchmal auch als Edge-Programmierbarkeit bezeichnet werden, können Sie Ihren eigenen Code auf Edge-Geräten ausführen, um das Verhalten von Media CDN anzupassen. Dadurch werden zusätzliche Anwendungsfälle wie die Normalisierung des Cache-Schlüssels, die benutzerdefinierte Tokenauthentifizierung und der Widerruf von Tokens, zusätzliche benutzerdefinierte Logfelder, A/B-Tests und eine benutzerdefinierte Fehlerseite möglich.

Inhalt

In diesem Code-Lab führen wir Sie durch die Schritte zum Bereitstellen einer CDN-Bereitstellungsumgebung mit Edge Compute-Unterstützung mit Media CDN (CDN) + Diensterweiterungen (Edge Programmability) + Cloud Storage (CDN-Quelle).

Aufgaben in diesem Lab

• Media CDN mit einem Cloud Storage-Bucket einrichten, der als Ursprung festgelegt ist
• Diensterweiterungs-Plug-in mit benutzerdefinierter HTTP-Authentifizierung erstellen und mit Media CDN verknüpfen
• So prüfen Sie, ob das Diensterweiterungs-Plug-in wie erwartet funktioniert
• Optional: Diensterweiterungs-Plug-in verwalten, z. B. Aktualisieren, Verweisen, Rollback und Löschen einer bestimmten Plug-in-Version

Voraussetzungen

• Grundkenntnisse in Netzwerken und HTTP-Kenntnissen
• Grundkenntnisse zu Unix/Linux-Befehlszeilen

2. Hinweis

Anfrage für Media CDN-Zulassungsliste und Zulassungsliste für Diensterweiterungen

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

Bevor Sie beginnen, müssen Sie prüfen, ob Ihr Projekt der Zulassungsliste für private Vorschauen sowohl für Media CDN als auch für Diensterweiterungen für Media CDN hinzugefügt wurde.

• Wenn Sie Zugriff auf Media CDN und Diensterweiterungen für Media CDN anfordern möchten, wenden Sie sich bitte an Ihr Account-Management-Team bei Google, um in Ihrem Namen eine Zugriffsanfrage für Media CDN und Diensterweiterungen zu erstellen.

Hinweise:Wenn Sie Teil von Google sind und Diensterweiterungen mit Media CDN testen möchten, wenden Sie sich an die PMs für Media CDN und Diensterweiterungen, um Zugriff anzufordern.

3. Einrichtung und Anforderungen

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, 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 dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud, wodurch die Netzwerkleistung und Authentifizierung erheblich verbessert werden. Sie können alle Aufgaben in diesem Lab ganz einfach in einem Browser erledigen.

Hinweis

IAM-Rollen und Zugriff

Zum Erstellen von Media CDN- und Artifact Registry-Ressourcen sind die folgenden IAM-Berechtigungen (Identity and Access Management) erforderlich:

• 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

Media CDN und aktivieren Service Extensions APIs mithilfe der folgenden Befehle

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 aus Quellen wie einem Cloud Storage-Bucket, einem Drittanbieter-Speicherort oder einem öffentlich zugänglichen HTTP(HTTPS)-Endpunkt stammen.

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

Hinweise: Namen von Cloud Storage-Buckets müssen global eindeutig sein. Um sicherzustellen, dass es keine Konflikte gibt, 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. Klicke auf ERSTELLEN.
3. Geben Sie einen Namen für den Bucket ein. – z.B. "mediacdn-bucket-$PROJECT_ID".
4. Behalten Sie in allen anderen Standardeinstellungen die Standardeinstellungen bei.
5. Klicke auf ERSTELLEN.

5. Testobjekt in den Cloud Storage-Bucket hochladen

Nun laden wir ein Objekt in den Cloud Storage-Bucket hoch.

1. Datei in Cloud Shell erstellen und dann mit gsutil in den Bucket hochladen

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

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

Hinweis: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 „objectViewer“-Zugriff auf das Media CDN-Dienstkonto 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: zuständig für clientseitige Konfiguration (TLS, IP-Adressierung), Routing, CDN-Konfiguration (Cache-Modi, TTLs, Signierung) und Sicherheitsrichtlinien.
• EdgeCacheOrigin: zuständig für die ursprungsspezifische Konfiguration für jeden HTTP-basierten Ursprung sowie für Wiederholungsbedingungen, wenn Inhalte nicht verfügbar oder nicht erreichbar sind.

Edge-Cache-Ursprung konfigurieren

Erstellen Sie nun einen Ursprung, der auf den Cloud Storage-Bucket verweist, den Sie gerade erstellt haben.

1. Rufen Sie in der Google Cloud Console die Seite Media CDN auf.
2. Klicken Sie auf den Tab ORIGINS.
3. Klicken Sie auf Ursprung erstellen.
4. Geben Sie „cloud-storage-origin“ ein. als Name für den Edge-Cache-Ursprung.
5. Unter „Startadresse“:
6. wählen Sie „Google Cloud Storage-Bucket auswählen“ aus.
7. Durchsuchen Sie den Cloud Storage-Bucket mit dem Namen „mediacdn-bucket-$PROJECT_ID“.
8. klicken Sie auf AUSWÄHLEN.
9. Behalten Sie in allen anderen Standardeinstellungen die Standardeinstellungen bei.
10. Klicken Sie auf Ursprung erstellen.

Die neu erstellte EdgeCacheOrigin-Ressource wird in Ihrem Projekt auf der Seite „Ursprünge“ in der Liste der 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 Ihren Dienst ein, z. B. „media-cdn“. – und dann auf „Weiter“.

5. Klicken Sie im Abschnitt „Routing“ auf HOSTREGEL HINZUFÜGEN.
6. Platzhalter eingeben – „*“ in das Feld "Hosts" ein.

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

11. Klicken Sie auf ERWEITERTE KONFIGURATIONEN, um weitere Konfigurationsoptionen zu erweitern.
12. Klicken Sie in der Routingaktion auf ITEM HINZUFÜGEN. Gehen Sie anschließend so vor:
13. Wählen Sie als Typ „CDN-Richtlinie“ aus.
14. Wählen Sie für den Cache-Modus die Option „Alle im Cache speichern“ aus.
15. Behalten Sie für alle anderen Standardeinstellungen 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. Informationen zu Ihrem Dienst finden Sie in der Spalte Adressen.

Um zu testen, ob Ihr Dienst richtig für das Speichern von Inhalten im Cache konfiguriert ist, verwenden Sie das curl-Befehlszeilentool, um Anfragen zu senden und die Antworten zu prüfen.

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

Die Ausgabe des Befehls sollte in etwa so aussehen:

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

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

7. Artifact Registry für Diensterweiterungen konfigurieren

Bevor Sie eine Diensterweiterung erstellen, müssen Sie Artifact Registry konfigurieren. Artifact Registry ist der universelle Paketmanager von Google Cloud zum Verwalten von Build-Artefakten. Proxy-Wasm-Plug-ins für Diensterweiterungen werden in Artifact Registry veröffentlicht. Nach der Veröffentlichung in Artifact Registry können Proxy-Wasm-Plug-ins in Ihrer Media CDN-Bereitstellung bereitgestellt werden.

Hinweise:Artifact Registry-Repository-Namen müssen global eindeutig sein. Um sicherzustellen, dass es keine Konflikte gibt, verwenden wir die Umgebungsvariable $PROJECT_ID als Teil des Repository-Namens.

Wir verwenden den Befehl gcloudartifact 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 über die GUI wie folgt 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. Beispiel: „service-extension-$PROJECT_ID“.
4. Format: „Docker“. Modus: „Standard“, Standorttyp – „Region“ und wählen Sie „us-central1 (Iowa)“ aus.
5. Klicke auf 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 übertragen und abgerufen werden.

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

Ausgabe:

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

8. Diensterweiterungen in Media CDN konfigurieren

Jetzt zeigen wir Ihnen, wie ein Diensterweiterungs-Plug-in (Proxy-Wasm) geschrieben und erstellt wird, das mithilfe der Programmiersprache Rust in Media CDN bereitgestellt werden kann.

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

Eine 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 aktuell aktiven WasmPluginVersion entspricht.
• WasmPluginVersions-Elemente verweisen auf ein Container-Image aus Artifact Registry. Wenn Sie Änderungen an Ihren Proxy-Wasm-Plug-ins vornehmen, werden verschiedene WasmPluginVersions erstellt.

Das Diagramm unten veranschaulicht die Beziehung zwischen diesen Ressourcen.

Diensterweiterungs-Plug-in 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 zum Installieren der Rust-Toolchain.

Wenn Sie die Meldung -bash: rustup: Command not found erhalten wenn „rustup“ ausgeführt wird, versuchen Sie es mit source „$HOME/.cargo/env“. ", um die PATH-Umgebung in Cloud Shell neu zu laden.

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

2. Fügen Sie als Nächstes Ihrer Rust-Toolchain die 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. Geben Sie das Verzeichnis my-wasm-plugin ein. Es sollten die Datei Cargo.toml und das Verzeichnis src zu sehen sein.

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 in der Datei „Cargo.toml“ nach der Zeile [dependencies] 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 ungefähr 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 vollständigen Inhalt der Datei „sample_code“ in Cloud Shell in die Datei lib.rs im Verzeichnis src.

Hinweis:Der Quellcode befindet sich in der Datei lib.rs. Der Quellcode sollte in der Programmiersprache RUST geschrieben sein. Weitere Rezepte mit Beispielcode finden Sie unter network-actions-recipes.

In diesem Codelab prüft unser Code, ob jede HTTP-Anfrage einen Autorisierungsheader mit dem Wert „secret“ enthält, und generiert eine „HTTP 403 Forbidden“-Antwort, wenn die Anfrage diesen Header nicht enthält.

8. Nach der Bearbeitung sollte die Datei lib.rs ungefähr 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 Sie die Manifestdatei Cargo.toml konfiguriert und den Proxy-Wasm-Code in die Datei lib.rs geschrieben haben , können Sie das Proxy-Wasm-Plug-in erstellen.

cargo build --release --target wasm32-wasi

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

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

Prüfen Sie auch das Verzeichnis target und prüfen Sie, ob die Dateien erstellt wurden:

ls ./target

Sie sehen die Ausgabe wie folgt:

CACHEDIR.TAG release wasm32-wasi

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

Jetzt 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 mit dem Namen Dockerfile und 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 einen anderen Nicht-x86-Prozessor verwenden, müssen Sie zuerst die WASM-Unterstützung in Docker (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads) aktivieren und dann stattdessen 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 Proxy-Wasm-Plug-in an Artifact Registry zu senden. Wir versehen unser Container-Image mit dem Tag „prod“, Tag.

Hinweise: Artifact Registry verwendet eine Namenskonvention, um Repositories und Images zu identifizieren.

Der vollständige Name für ein Docker-Image in einem Repository hat das folgende 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 getaggte "prod"-Tag Container-Image in das Repository übertragen.

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: Sie müssen gcloud als Credential Helper für die Artifact Registry-Domain konfiguriert haben, die mit dem Speicherort des Repositorys verknüpft ist.

Wenn Ihnen eine Berechtigung verweigert wird Fehler beim Übertragen des Containers an Artifact Registry angezeigt wird, kehren Sie zu Artifact Registry für Diensterweiterungen konfigurieren zurück und führen Sie den Befehl gcloud auth noch einmal aus.

Überprüfen Sie nun, ob das Container-Image des Proxy-Wasm-Plug-ins erfolgreich an 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 Sie das Proxy-Wasm-Plug-in mit Ihrer Media CDN-Bereitstellung verknüpfen.

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

Achtung: Die Erstellung einer Proxy-Wasm-Ressource kann einige Zeit dauern.

Warten Sie, bis Sie die Abschlussmeldung sehen, bevor Sie mit den nachfolgenden Schritten fortfahren.

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

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 mit dem Container-Image im Artifact Registry-Repository verknüpft wurde. 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 die Ressource des Wasm-Plug-ins verweist.

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

Prüfen Sie auch, ob die WasmAction-Ressource erfolgreich mit dem Proxy-Wasm-Plug-in verknüpft 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. Jetzt 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 ungefähr 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 Fehler bei der Konfigurationsvalidierung 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 das Einrücken nur Leerzeichen. Tabulatoren werden von YAML nicht akzeptiert.

9. Zum Schluss 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. Proxy-Wasm-Plug-in für Diensterweiterungen in Media CDN validieren

Um zu testen, ob Ihr Dienst richtig für das Speichern von Inhalten im Cache konfiguriert ist, verwenden Sie das curl-Befehlszeilentool, um Anfragen zu senden und die Antworten zu prüfen.

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

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

Die Ausgabe des Befehls sollte in etwa so aussehen:

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

Geben Sie die Anfrage jetzt noch einmal mit einem Autorisierungsheader und dem Secret-Wert aus.

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

Die Ausgabe des Befehls 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 Ihre aktualisierten Plug-ins in Media CDN bereitstellen. Im Folgenden werden die Schritte zum Bereitstellen einer aktualisierten Version eines Plug-ins beschrieben.

Sie können beispielsweise den Beispiel-Plug-in-Code aktualisieren, um den Autorisierungs-Header mit einem anderen Wert zur Authentifizierung zu vergleichen, indem Sie den Code wie folgt ändern.

Aktualisieren Sie zuerst die Quelldatei src/lib.rs mit dem folgenden 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 Sie eine neue WasmPluginVersion erstellen und dann die -Hauptversion des WasmPlugin aktualisieren, um auf die neue Version zu verweisen.

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 nun die Version des Container-Images, das aus Artifact Registry importiert und live in Ihre Media CDN-Bereitstellung übertragen werden soll, aktualisiert.

Rollback auf eine vorherige Version durchführen

Wenn Sie zu einer früheren Version eines Plug-ins zurückkehren möchten, können Sie die Ressource des Wasm-Plug-ins aktualisieren, um auf eine frühere Version zu verweisen.

Zuerst listen wir die verfügbaren Versionen auf:

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

Sie sollten die Ausgabe sehen:

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 Ressource des Wasm-Plug-ins, um auf die vorherige Version „a2a8ce“ zu verweisen:

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

Wenn der Vorgang erfolgreich war, sollten Sie folgende Ausgabe sehen:

✓ 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-Plug-in-Ressource erstellt wird, wird für das Rollback die Version Ihres Codes verwendet, die vor dem letzten Roll-out ausgeführt wurde.

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

Für Version „a2a8ce“ ist dies 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

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

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

Referenzlinie, die entfernt werden soll:

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

Als Nächstes aktualisieren Sie die Hauptversion Ihres WasmPlugin in einen leeren String "".

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

""

Führen Sie zum Schluss die folgenden Löschschritte der Reihe nach 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 nach Abschluss des Codelabs nicht, die Lab-Ressourcen zu bereinigen. Andernfalls werden sie weiterhin ausgeführt und es fallen Kosten an.

Mit den folgenden Befehlen werden der Media CDN EdgeCache-Dienst, die EdgeCache Config und das Service Extensions Plugin gelöscht. Führen Sie die folgenden Löschschritte der Reihe nach durch.

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!

Herzlichen Glückwunsch! Sie haben das Codelab zu Diensterweiterungen auf Media CDN abgeschlossen.

Behandelte Themen

• Media CDN mit einem Cloud Storage-Bucket einrichten, der als Ursprung festgelegt ist
• Diensterweiterungs-Plug-in mit benutzerdefinierter HTTP-Authentifizierung erstellen und mit Media CDN verknüpfen
• So prüfen Sie, ob das Diensterweiterungs-Plug-in wie erwartet funktioniert
• Optional: Diensterweiterungs-Plug-in verwalten, z. B. Aktualisieren, Verweisen, Rollback und Löschen einer bestimmten Plug-in-Version

Was liegt als Nächstes an?

Sehen Sie sich einige dieser Codelabs an...

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

Weitere Informationen

• Laden von Service Workern mit hoher Leistung
• Caching-Strategien für Service Worker basierend auf Anfragetypen

Referenzdokumente

• Web-App-Manifest-Dokumente
• Web App Manifest-Properties (MDN)
• Installieren und Zum Startbildschirm hinzufügen
• Service Worker – Übersicht
• Service Worker-Lebenszyklus
• Laden von Service Workern mit hoher Leistung
• Offline-Rezepte