Lab: Service Extensions su Media CDN

1. Introduzione

Ultimo aggiornamento: 01/05/2024

Le Content Delivery Network (CDN) migliorano le prestazioni degli utenti memorizzando nella cache i contenuti a cui si accede di frequente più vicino agli utenti finali, terminando le connessioni più vicino ai client, riutilizzando le connessioni all'origine e adottando protocolli e personalizzazioni di rete moderni.

Media CDN, la rete edge globale di GCP per lo streaming di contenuti multimediali, offre molte funzionalità integrate o "di base". Le funzionalità di base sono pensate per soddisfare i casi d'uso più comuni, ma potresti avere anche requisiti non soddisfatti da questo insieme di funzionalità di base.

Service Extensions per Media CDN, a volte chiamato anche programmabilità perimetrale, consente di eseguire il proprio codice a livello perimetrale per personalizzare il comportamento di Media CDN. In questo modo si sbloccano ulteriori casi d'uso, che vanno dalla normalizzazione della chiave della cache all'autenticazione e alla revoca dei token personalizzati, a campi di log personalizzati aggiuntivi, ai test A/B e a una pagina di errore personalizzata.

Cosa creerai

In questo lab di programmazione, esamineremo i passaggi per eseguire il deployment di un ambiente di distribuzione CDN abilitato per Edge Compute con Media CDN (CDN) + Service Extensions (programmabilità perimetrale) + Cloud Storage (origine della CDN).

Cosa imparerai a fare

• Come configurare Media CDN con un bucket Cloud Storage impostato come origine
• Come creare un plug-in Service Extensions con autenticazione HTTP personalizzata e associarlo a Media CDN
• Come verificare che il plug-in Service Extension funzioni come previsto
• (facoltativo) Come gestire un plug-in di Service Extensions, ad esempio aggiornare, fare riferimento, eseguire il rollback ed eliminare una versione specifica del plug-in

Che cosa ti serve

• Conoscenza di base del networking e di HTTP
• Conoscenza di base della riga di comando Unix/Linux

2. Prima di iniziare

Richiesta di inclusione nella lista consentita di Media CDN e Service Extensions

Attenzione: assicurati che il tuo progetto sia incluso nella lista consentita per Media CDN e Service Extensions per Media CDN. Non potrai completare questo lab se il tuo progetto non è incluso nella lista consentita.

Prima di iniziare, devi assicurarti che il tuo progetto sia stato aggiunto alla lista consentita dell'anteprima privata sia per Media CDN che per Service Extensions per Media CDN.

• Per richiedere l'accesso sia a Media CDN che a Service Extensions per Media CDN, contatta il team dedicato al tuo account Google per creare una richiesta di accesso per tuo conto per Media CDN e Service Extensions

Note: se fai parte di Google e vuoi testare Service Extensions con Media CDN, contatta i PM di Media CDN e Service Extensions per richiedere l'accesso.

3. Configurazione e requisiti

Avvia Cloud Shell

Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

Nella console GCP, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:

Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere un risultato simile a questo:

Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Tutto il lavoro di questo lab può essere svolto semplicemente con un browser.

Prima di iniziare

IAM Roles & Access

Le autorizzazioni Identity and Access Management (IAM) richieste per creare risorse Media CDN e Artifact Registry sono le seguenti:

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

In Cloud Shell, assicurati che le variabili di ambiente project_id, project_num, location e repository siano configurate.

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

Abilita le API

Abilita le API Media CDN e Service Extensions tramite i comandi riportati di seguito

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. Crea un bucket Cloud Storage

I contenuti di Media CDN possono provenire da località come un bucket Cloud Storage, una posizione di archiviazione di terze parti o qualsiasi endpoint HTTP(HTTPS) accessibile pubblicamente.

In questo codelab, archivieremo i contenuti in un bucket Cloud Storage.

Note: i nomi dei bucket Cloud Storage devono essere univoci a livello globale. Per assicurarci che non ci siano conflitti, utilizzeremo la variabile di ambiente $PROJECT_ID come parte del nome del bucket.

Utilizzeremo il comando gsutil mb per creare il bucket

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

Se vuoi, puoi creare un bucket Cloud Storage utilizzando la GUI come segue:

1. Nella console Google Cloud, vai alla pagina Cloud Storage.
2. Fai clic sul pulsante CREA.
3. Inserisci un nome per il bucket. - ad esempio "mediacdn-bucket-$PROJECT_ID".
4. Lascia invariate le altre impostazioni predefinite.
5. Fai clic sul pulsante CREA.

5. Carica un oggetto di test nel bucket Cloud Storage

Ora caricheremo un oggetto nel bucket Cloud Storage.

1. Crea un file in Cloud Shell e caricalo nel bucket utilizzando gsutil.

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

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

Note:Media CDN supporta i bucket privati come origine. Per consentire a Media CDN di accedere ai contenuti da un bucket Cloud Storage privato, devi configurare IAM per concedere l'accesso objectViewer all'account di servizio Media CDN.

Il service account ha il seguente formato:

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

2. Concedere l'accesso a Media CDN al bucket

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

6. Configura Media CDN

A questo punto, creeremo una configurazione Media CDN.

Ogni configurazione di Media CDN è costituita da due risorse principali:

• EdgeCacheService, responsabile della configurazione rivolta ai client (TLS, indirizzamento IP), del routing, della configurazione CDN (modalità cache, TTL, firma) e delle norme di sicurezza.
• EdgeCacheOrigin, responsabile della configurazione per origine per qualsiasi origine basata su HTTP, nonché delle condizioni di ripetizione dei tentativi quando i contenuti non sono disponibili o raggiungibili.

Configura un'origine della edge cache

Ora creiamo un'origine che punta al bucket Cloud Storage che hai appena creato.

1. Nella console Google Cloud, vai alla pagina Media CDN.
2. Fai clic sulla scheda ORIGINI.
3. Fai clic su CREA ORIGINE.
4. Inserisci "cloud-storage-origin" come nome dell'origine della edge cache.
5. In Indirizzo mittente:
6. scegli "Seleziona un bucket Cloud Storage".
7. SFOGLIA fino al bucket Cloud Storage denominato "mediacdn-bucket-$PROJECT_ID".
8. fai clic su SELEZIONA.
9. Lascia invariate le altre impostazioni predefinite.
10. Fai clic su CREA ORIGINE.

La risorsa EdgeCacheOrigin appena creata viene visualizzata nell'elenco delle origini del progetto nella pagina Origini.

Configura un servizio Edge Cache

1. Nella console Google Cloud, vai alla pagina Media CDN.
2. Fai clic sulla scheda SERVIZI.
3. Fai clic su CREA SERVIZIO.
4. Inserisci un nome univoco per il tuo servizio, ad esempio "media-cdn", poi fai clic su Avanti.

5. Nella sezione Routing, fai clic su AGGIUNGI REGOLA HOST.
6. Inserisci il carattere jolly "*" nel campo Host.

7. Fai clic su AGGIUNGI REGOLA DI ROUTING.
8. In Priorità, specifica "1".
9. Fai clic su AGGIUNGI UNA CONDIZIONE DI CORRISPONDENZA, per Corrispondenza del percorso seleziona "Corrispondenza prefisso" come Tipo di corrispondenza, specifica "/" nel campo Corrispondenza del percorso, quindi fai clic su Fine.
10. Seleziona Recupera da un'origine in Azione principale, quindi seleziona l'origine che hai configurato nell'elenco a discesa.

11. Fai clic su CONFIGURAZIONI AVANZATE per espandere altre opzioni di configurazione.
12. In Azione del percorso, fai clic su AGGIUNGI UN ELEMENTO. Quindi:
13. Per Tipo, seleziona "Criterio CDN".
14. Per la modalità Cache, seleziona "Forza cache di tutto".
15. Mantieni tutte le altre impostazioni predefinite.
16. Fai clic su Fine.
17. Fai clic su Salva.

18. Fai clic su CREA SERVIZIO.

La risorsa EdgeCacheService appena creata viene visualizzata nella pagina Servizi nell'elenco dei servizi del tuo progetto.

Recuperare l'indirizzo IP di MediaCDN e testarlo

1. Nella console Google Cloud, vai alla pagina Media CDN.
2. Vai a Media CDN
3. Fai clic sulla scheda Servizi.
4. Per il tuo servizio, consulta la colonna Indirizzi.

Per verificare che il servizio sia configurato correttamente per memorizzare nella cache i contenuti, utilizza lo strumento a riga di comando curl per inviare richieste e controllare le risposte.

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

Il comando dovrebbe produrre un output simile al seguente:

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

Ora hai creato correttamente un deployment MediaCDN con Cloud Storage come origine.

7. Configura Artifact Registry per Service Extensions

Prima di creare Service Extensions, dobbiamo configurare Artifact Registry. Artifact Registry è il gestore di pacchetti universale di Google Cloud per la gestione degli artefatti di build. I plug-in di estensione di servizio (Proxy-Wasm) vengono pubblicati in Artifact Registry. Una volta pubblicati in Artifact Registry, i plug-in Proxy-Wasm possono essere implementati nel deployment di Media CDN.

Note: i nomi dei repository Artifact Registry devono essere univoci a livello globale. Per evitare conflitti, utilizzeremo la variabile di ambiente $PROJECT_ID come parte del nome del repository.

Utilizzeremo il comando gcloud artifacts repositories create per creare il repository

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

Facoltativamente, puoi creare un repository utilizzando la GUI come segue:

1. Nella console Google Cloud, vai alla pagina Artifact Registry.
2. Fai clic sul pulsante + CREA REPOSITORY.
3. Inserisci un nome per il repository, ad esempio "service-extension-$PROJECT_ID".
4. Formato: "Docker", modalità: "Standard", tipo di località: "Regione", seleziona "us-central1 (Iowa)".
5. Fai clic sul pulsante CREA.

La risorsa del repository Artifact Registry appena creata dovrebbe essere visualizzata nella pagina Repository.

Una volta creata la risorsa Repository, esegui il comando seguente in Cloud Shell per configurare il client Docker di Cloud Shell in modo da eseguire il push e il pull dei pacchetti utilizzando questo repository.

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

Output:

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

8. Configura Service Extensions su Media CDN

Ora mostreremo come scrivere e creare un plug-in di Service Extensions (Proxy-Wasm) che può essere implementato in Media CDN utilizzando il linguaggio di programmazione Rust.

In questo esempio, creeremo un plug-in Proxy-Wasm che verifica che ogni richiesta HTTP contenga un'intestazione Authorization con il valore "secret". Se la richiesta non contiene questa intestazione, il plug-in genererà una risposta HTTP 403 Forbidden.

Un breve riepilogo delle estensioni di servizio: esistono tre risorse chiave: WasmAction, WasmPlugin e WasmPluginVersion.

• Una risorsa WasmAction è ciò che viene collegato a EdgeCacheService di Media CDN. Un WasmAction fa riferimento a una risorsa WasmPlugin.
• Una risorsa WasmPlugin ha una versione principale che corrisponde alla WasmPluginVersion attiva corrente.
• Un WasmPluginVersions fa riferimento a un'immagine container di Artifact Registry. Man mano che apporti modifiche ai plug-in proxy-wasm, crei versioni diverse di WasmPlugin.

Consulta il diagramma seguente per comprendere meglio la relazione tra queste risorse.

Scrivere e creare un plug-in di Service Extensions

1. Installa la toolchain Rust seguendo le istruzioni riportate in https://www.rust-lang.org/tools/install.

Attenzione: assicurati di seguire le istruzioni del prompt per installare la toolchain Rust.

Se ricevi l'errore "-bash: rustup: command not found" quando esegui "rustup", prova "source "$HOME/.cargo/env" per ricaricare la variabile di ambiente PATH in Cloud Shell.

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

2. Successivamente, aggiungi il supporto Wasm alla toolchain Rust eseguendo questo comando:

rustup target add wasm32-wasi

3. Crea un pacchetto Rust denominato my-wasm-plugin:

cargo new --lib my-wasm-plugin

Output:

Created library `my-wasm-plugin` package

4. Inserisci la directory my-wasm-plugin e dovresti vedere un file Cargo.toml e una directory src.

cd my-wasm-plugin
ls

Output:

Cargo.toml  src

5. A questo punto, configura il pacchetto Rust modificando il file Cargo.toml. Dopo la riga [dependencies] nel file Cargo.toml, aggiungi quanto segue:

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. Dopo le modifiche, il file Cargo.toml dovrebbe avere un aspetto simile al seguente:

[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. scarica il file sample_code. Copia l'intero contenuto del file sample_code nel file lib.rs nella directory src in Cloud Shell.

Note:il file lib.rs è la posizione in cui si trova il codice sorgente. Il codice sorgente deve essere scritto nel linguaggio di programmazione RUST. Per altre ricette di codice campione, consulta network-actions-recipes.

In questo Codelab, il nostro codice verifica che ogni richiesta HTTP contenga un'intestazione Authorization con il valore "secret" e genera una risposta HTTP 403 Forbidden se la richiesta non contiene questa intestazione.

8. Dopo le modifiche, il file lib.rs dovrebbe avere un aspetto simile al seguente:

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. Ora che abbiamo configurato il file manifest Cargo.toml e scritto il codice Proxy-Wasm nel file lib.rs , possiamo creare il plug-in Proxy-Wasm.

cargo build --release --target wasm32-wasi

Una volta completata correttamente la build, verrà visualizzato un messaggio come mostrato di seguito:

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

Verifichiamo anche la directory target e controlliamo che i file siano stati creati:

ls ./target

Vedrai l'output mostrato di seguito:

CACHEDIR.TAG release wasm32-wasi

Pubblica un plug-in Proxy-Wasm in Artifact Registry

Ora pubblicheremo il plug-in Proxy-Wasm nel repository Artifact Registry che hai creato in precedenza, in modo che possa essere implementato in Media CDN.

Per prima cosa, pacchettizziamo i plug-in Proxy-Wasm in un'immagine container.

1. Crea un file denominato Dockerfile nella stessa directory my-wasm-plugin, con il seguente contenuto:

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

2. Poi crea l'immagine container:

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

Attenzione: se utilizzi Apple Silicon (architettura basata su ARM) o qualsiasi altro processore non x86, devi prima attivare il supporto WASM su Docker (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads), quindi esegui il seguente comando per creare l'immagine container.

(solo processori non x86) Dopodiché, crea l'immagine container:

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

Output

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

3. Successivamente, pubblica o "trasferisci" il plug-in Proxy-Wasm ad Artifact Registry. Taggheremo la nostra immagine container con il tag "prod".

Note:Artifact Registry utilizza una convenzione di denominazione per identificare i repository e le immagini.

Il nome completo di un'immagine Docker in un repository ha il seguente formato:

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

Ora procediamo con il push dell'immagine container "prod" taggata nel repository.

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

Output:

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

Attenzione: assicurati di aver configurato gcloud come assistente alle credenziali per il dominio Artifact Registry associato alla posizione del repository.

Se ricevi l'errore "Autorizzazione negata" quando esegui il push del container in Artifact Registry, torna alla sezione Configurare Artifact Registry per Service Extensions ed esegui di nuovo il comando gcloud auth.

Ora verifichiamo che il push dell'immagine container del plug-in Proxy-Wasm sia stato eseguito correttamente in Artifact Registry. Dovresti visualizzare un output simile al seguente:

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

Output:

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

Associa un plug-in Proxy-Wasm al deployment di Media CDN

Ora siamo pronti per associare il plug-in Proxy-Wasm al deployment di Media CDN.

I plug-in Proxy-Wasm sono associati alle route Media CDN nella risorsa EdgeCacheService.

Attenzione: la creazione di ogni risorsa Proxy-Wasm potrebbe richiedere un po' di tempo.

Attendi di visualizzare il messaggio di completamento prima di procedere con i passaggi successivi.

1. Innanzitutto, creiamo una risorsa Wasm-plugin per il nostro plug-in Proxy-Wasm.

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

2. A questo punto, creiamo un 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. Successivamente, specifichiamo la versione principale del plug-in Proxy-Wasm.

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

Ora verifichiamo che il plug-in Proxy-Wasm sia stato associato correttamente all'immagine container che si trova nel repository Artifact Registry. Dovresti vedere un output simile a questo:

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

Output:

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. Successivamente, creiamo una risorsa WasmAction che fa riferimento alla nostra risorsa plug-in Wasm.

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

Verifichiamo anche che la risorsa WasmAction sia stata associata correttamente al plug-in Proxy-Wasm. Dovresti visualizzare un output simile:

gcloud alpha service-extensions wasm-actions list

Output:

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

5. Ora dobbiamo esportare la configurazione del nostro servizio EdgeCacheService di Media CDN:

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

6. Poi, apri il file my-service.yaml e aggiungi un wasmAction a routeAction per la route specificata, che fa riferimento alla risorsa WasmPlugin creata in precedenza.

wasmAction: "my-wasm-action-resource"

7. Dopo le modifiche, il file my-service.yaml dovrebbe avere un aspetto simile al seguente:

...

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. Poi salviamo la configurazione aggiornata con la configurazione Proxy-Wasm nel file my-service-with-wasm.yaml.

Attenzione: se si verifica un errore di convalida della configurazione durante l'importazione del file YAML modificato nell'API edge-cache services, controlla di nuovo il file YAML e assicurati che la riga wasmAction sia aggiunta all'interno della sezione routeAction. Assicurati di utilizzare solo spazi per il rientro, le tabulazioni non sono accettate da YAML.

9. Infine, importiamo la configurazione aggiornata per l'ambiente di produzione Media CDN:

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

9. Convalida il plug-in Proxy-Wasm di Service Extensions su Media CDN

Per verificare che il servizio sia configurato correttamente per memorizzare nella cache i contenuti, utilizza lo strumento a riga di comando curl per inviare richieste e controllare le risposte.

Note:la propagazione della modifica sull'intera rete MediaCDN potrebbe richiedere fino a 10 minuti. Nel frattempo, potresti non riuscire a visualizzare l'errore HTTP 403. Continua a provare finché non viene restituito l'errore 403.

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

Il comando dovrebbe produrre un output simile al seguente:

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

Ora, invia di nuovo la richiesta con un'intestazione Authorization e il relativo valore di secret

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

Il comando dovrebbe produrre un output simile al seguente:

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

10. (Facoltativo) Gestione dei plug-in Proxy-Wasm

Aggiornamento di un plug-in Proxy-Wasm

Man mano che apporti miglioramenti o aggiungi nuove funzionalità ai plug-in Proxy-Wasm, dovrai eseguire il deployment dei plug-in aggiornati su Media CDN. Di seguito, vengono illustrati i passaggi per il deployment di una versione aggiornata di un plug-in.

Ad esempio, puoi aggiornare il codice del plug-in di esempio per valutare l'intestazione Authorization rispetto a un altro valore per l'autenticazione, modificando il codice come segue.

Per prima cosa, aggiorna il file sorgente src/lib.rs con il codice mostrato di seguito:

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 {}

Poi, crea, pacchettizza e pubblica il plug-in aggiornato:

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

Una volta aggiornata l'immagine container in Artifact Registry, dobbiamo creare una nuova WasmPluginVersion e poi aggiornare la versione principale di WasmPlugin in modo che faccia riferimento alla nuova versione.

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

Ora hai aggiornato correttamente la versione dell'immagine container da importare da Artifact Registry e hai eseguito il push nell'implementazione di Media CDN.

Eseguire il rollback a una versione precedente

Per eseguire il rollback a una versione precedente di un plug-in, puoi aggiornare la risorsa del plug-in Wasm in modo che faccia riferimento a una versione precedente.

Innanzitutto, elenchiamo le versioni disponibili:

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

Dovresti vedere l'output:

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... ... ... 

Successivamente, aggiorniamo la risorsa del plug-in Wasm in modo che faccia riferimento alla versione precedente, "a2a8ce":

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

Una volta completata l'operazione, dovresti visualizzare questo output:

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

Poiché Media CDN salva il digest dell'immagine Docker ogni volta che viene creata una nuova risorsa Wasm-plugin, il rollback utilizzerà la versione del codice in esecuzione prima dell'ultimo rollout.

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

Per la versione "a2a8ce", ovvero la versione con 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"

Eliminazione di un'azione Wasm e di un plug-in Wasm

Per eliminare un WasmAction, un WasmPlugin e le relative WasmPluginVersions, segui questi passaggi.

Innanzitutto, rimuovi il riferimento a WasmAction nella configurazione di Media CDN EdgeCacheService.

Linea di riferimento da rimuovere:

wasmAction: "my-wasm-action-resource"

Quindi, aggiorniamo la configurazione di EdgeCacheService modificata.

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

Poi, aggiorna la versione principale del tuo WasmPlugin a una stringa vuota "".

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

""

Infine, esegui i passaggi di eliminazione riportati di seguito in ordine.

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. Liberare spazio nell'ambiente del lab

Dopo aver completato il codelab, non dimenticare di liberare spazio dalle risorse del lab, altrimenti continueranno a essere eseguite e ad accumulare costi.

I seguenti comandi elimineranno il servizio EdgeCache di Media CDN, la configurazione EdgeCache e il plug-in Service Extensions. Esegui i passaggi di eliminazione riportati di seguito nell'ordine indicato.

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

Ciascuno dei comandi precedenti dovrebbe chiederti di confermare l'eliminazione della risorsa.

12. Complimenti!

Congratulazioni, hai completato il codelab Service Extensions su Media CDN.

Argomenti trattati

• Come configurare Media CDN con un bucket Cloud Storage impostato come origine
• Come creare un plug-in Service Extensions con autenticazione HTTP personalizzata e associarlo a Media CDN
• Come verificare che il plug-in Service Extension funzioni come previsto
• (facoltativo) Come gestire un plug-in di Service Extensions, ad esempio aggiornare, fare riferimento, eseguire il rollback ed eliminare una versione specifica del plug-in

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab...

• Aggiungere notifiche push a un'app web
• Creare una PWA utilizzando Workbox

Further reading

• Caricamento di service worker ad alte prestazioni
• Strategie di memorizzazione nella cache dei service worker in base ai tipi di richieste

Documentazione di riferimento

• Documenti sul file manifest dell'app web
• Proprietà del manifest dell'app web (MDN)
• Installa e aggiungi alla schermata Home
• Panoramica dei service worker
• Ciclo di vita del service worker
• Caricamento di service worker ad alte prestazioni
• Offline Cookbook