Lab: Service Extensions su Media CDN

1. Introduzione

Ultimo aggiornamento: 2024-05-01

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

Media CDN, la rete perimetrale globale di Google Cloud per lo streaming di contenuti multimediali, offre numerosi sistemi di Le funzionalità di base sono pensate per soddisfare i casi d'uso più comuni, ma potrebbero anche avere requisiti che non vengono presi in considerazione da questo set di funzionalità principali.

Service Extensions per Media CDN, a volte nota anche come programmabilità perimetrale, ti consente di eseguire il tuo codice a livello perimetrale per personalizzare il comportamento di Media CDN. Questo sblocca casi d'uso aggiuntivi che vanno dalla normalizzazione della chiave cache, all'autenticazione e alla revoca del token del token, ai campi di log aggiuntivi personalizzati, ai test A/B e alla pagina di errore personalizzata.

Cosa creerai

In questo codelab, esamineremo i passaggi per eseguire il deployment di un ambiente di distribuzione CDN abilitato per Edge Compute con Media CDN (CDN) + Service Extensions (Edge Programmability) + Cloud Storage (origine di CDN).

Cosa imparerai a fare

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

Che cosa ti serve

• Networking di base e conoscenza di HTTP
• Conoscenza di base della riga di comando Unix/Linux

2. Prima di iniziare

Richiesta per la lista consentita di Media CDN e Lista consentita di Service Extensions

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

Prima di iniziare, devi assicurarti che il progetto sia stato aggiunto alla lista consentita di anteprime private 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 dell'Account Google per creare una richiesta di accesso per tuo conto a 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

Anche se Google Cloud può essere utilizzato da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

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

Dovrebbe richiedere solo qualche istante per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere una schermata simile al seguente:

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

Prima di iniziare

Ruoli IAM e Accesso

Di seguito sono riportate le autorizzazioni IAM (Identity and Access Management) necessarie per creare risorse Media CDN e Artifact Registry:

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

All'interno di 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

Attiva Media CDN e le API di Service Extensions tramite i comandi seguenti

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 posizioni come un bucket Cloud Storage, un percorso 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 evitare 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

Facoltativamente, 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. Non modificare 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 in modo da concedere l'accesso objectViewer all'account di servizio Media CDN.

L'account di servizio ha il seguente formato:

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

2. Concedi a Media CDN l'accesso al bucket

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

6. Configura Media CDN

Quindi creeremo una configurazione Media CDN.

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

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

Configura un'origine della cache perimetrale

Ora creiamo un'origine che punti 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 cache perimetrale.
5. In Indirizzo di origine:
6. scegli "Seleziona un bucket Google Cloud Storage".
7. SFOGLIA nel bucket Cloud Storage denominato "mediacdn-bucket-$PROJECT_ID".
8. fai clic su SELEZIONA.
9. Non modificare le altre impostazioni predefinite.
10. Fai clic su CREA ORIGINE.

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

Configura un servizio di cache perimetrale

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" e fai clic su Avanti.

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

7. Fai clic su AGGIUNGI REGOLA PERCORSO.
8. Per Priorità, specifica "1".
9. Fai clic su AGGIUNGI UNA CONDIZIONE DI CORRISPONDENZA e per Corrispondenza percorso, seleziona "Corrispondenza prefisso". come tipo di corrispondenza, specifica "/" nel campo Corrispondenza percorso e 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 estendere altre opzioni di configurazione.
12. In Azione route, fai clic su AGGIUNGI UN ELEMENTO. Poi segui questi passaggi:
13. Per Tipo, seleziona "Criterio CDN".
14. Per la modalità cache, seleziona "Forza memorizzazione nella cache di tutto".
15. Lascia 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 progetto.

Recupera l'indirizzo IP MediaCDN ed esegui il test

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, vedi la colonna Indirizzi.

Per verificare che il servizio sia configurato correttamente per memorizzare i contenuti nella cache, utilizza lo strumento a riga di comando curl per inviare le 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 una Service Extensions, dobbiamo configurare Artifact Registry. Artifact Registry è il gestore di pacchetti universale di Google Cloud per la gestione degli artefatti delle build. I plug-in di Service Extension (Proxy-Wasm) vengono pubblicati in Artifact Registry. Una volta pubblicati in Artifact Registry, puoi eseguire il deployment dei plug-in Proxy-Wasm 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 artefatti 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" e scegli "us-central1 (Iowa)"
5. Fai clic sul pulsante CREA.

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

Una volta creata la risorsa repository, esegui questo comando in Cloud Shell per configurare il client Docker di Cloud Shell ed 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 dimostreremo come scrivere e creare un plug-in di estensione di servizio (Proxy-Wasm) di cui è possibile eseguire il deployment su 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 di autorizzazione con il valore "secret". Se la richiesta non contiene questa intestazione, il plug-in genererà una risposta HTTP 403 Forbidden.

Un rapido ripasso sulle estensioni di servizio. Esistono tre risorse chiave: WasmAction, Wasmplugin e WasmpluginVersion.

• Una risorsa WasmAction è ciò che viene collegato a Media CDN EdgeCacheService. Un WasmAction fa riferimento a una risorsa Wasmplugin.
• Una risorsa Wasmplugin ha una versione main-version che corrisponde all'attuale versione attiva del plug-in.
• Un elemento WasmpluginVersions fa riferimento a un'immagine container di Artifact Registry. Man mano che apporti modifiche ai plug-in proxy-wasm, crei diversi WasmpluginVersion.

Fai riferimento al diagramma di seguito per comprendere meglio la relazione tra queste risorse.

Scrivere e creare un plug-in di estensione di servizio

1. Installa la toolchain di Rust seguendo le istruzioni all'indirizzo https://www.rust-lang.org/tools/install.

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

Se ricevi l'errore "-bash: rustup: command not found" errore durante l'esecuzione di "rustup", prova con "fonte "$HOME/.cargo/env" " per ricaricare l'ambiente PATH in Cloud Shell.

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

2. Successivamente, aggiungi il supporto Wasm alla tua 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, 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 apparire più o meno nel seguente modo:

[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 di 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 formule di codice di esempio, consulta network-actions-recipes.

In questo codelab, il nostro codice verifica che ogni richiesta HTTP contenga un'intestazione di autorizzazione con il valore "secret" e genererà una risposta HTTP 403 Forbidden, se la richiesta non contiene questa intestazione.

8. Dopo le modifiche, il file lib.rs dovrebbe apparire più o meno nel seguente modo:

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 nostro plug-in Proxy-Wasm.

cargo build --release --target wasm32-wasi

Una volta completata la build, verrà visualizzato il seguente messaggio:

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

Verifica anche la directory target e controlla che i file siano stati creati:

ls ./target

Verrà visualizzato l'output come mostrato di seguito:

CACHEDIR.TAG release wasm32-wasi

Pubblicare un plug-in Proxy-Wasm in Artifact Registry

Ora pubblicheremo il nostro plug-in Proxy-Wasm nel repository Artifact Registry che hai creato in precedenza per poterne eseguire il deployment su Media CDN.

Per prima cosa pacchettiamo 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. A questo punto, crea l'immagine container:

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

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

(solo processori non x86) A questo punto, 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. Quindi, pubblica o esegui il push il plug-in Proxy-Wasm in Artifact Registry. Segnaleremo l'immagine container con il tag "prod" del tag.

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

Il nome completo di un'immagine Docker in un repository è nel formato seguente:

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 del tag "prod" l'immagine container 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 per le credenziali per il dominio Artifact Registry associato alla posizione del repository.

Se ricevi un messaggio "Autorizzazione negata" quando esegui il push del container ad Artifact Registry, torna a Configura Artifact Registry for Service Extensions ed esegui di nuovo il comando gcloud auth.

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

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: il completamento di ogni creazione di risorsa Proxy-Wasm potrebbe richiedere del tempo.

Attendi finché non viene visualizzato il messaggio di completamento prima di procedere con i passaggi successivi.

1. Per prima cosa, 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 una 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. Poi specifichiamo la versione principale del nostro 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 risiede in Artifact Registry Repository. Dovresti vedere un output simile:

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. In seguito creiamo una risorsa WasmAction che fa riferimento alla risorsa del plug-in Wasm.

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

Verifica inoltre che la risorsa WasmAction sia stata associata correttamente al plug-in Proxy-Wasm. Dovresti vedere 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 di Media CDN EdgeCacheService:

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

6. Quindi, apri il file my-service.yaml e aggiungi un elemento wasmAction al campo 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 a questo:

...

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. Quindi, 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 dei servizi di memorizzazione in una cache perimetrale, verifica il file YAML e assicurati che la riga wasmAction sia aggiunta all'interno della sezione routeAction. Assicurati di utilizzare solo gli spazi per il rientro, poiché le schede non sono accettate da YAML.

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

$ 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 i contenuti nella cache, utilizza lo strumento a riga di comando curl per inviare le richieste e controllare le risposte.

Note:la propagazione della modifica nell'intera rete MediaCDN potrebbe richiedere fino a 10 minuti. Nel frattempo, potresti non essere in grado di 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 nuovamente la richiesta con un'intestazione Autorizzazione e il relativo valore 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

Aggiornare 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 sono riportati i passaggi per il deployment di una versione aggiornata di un plug-in.

Ad esempio, potresti aggiornare il codice del plug-in campione per valutare l'intestazione Authorization a fronte di un altro valore per l'autenticazione, modificando il codice come riportato di seguito.

Innanzitutto, aggiorna il file sorgente src/lib.rs con il codice seguente:

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

Quindi, 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 un nuovo WasmpluginVersion e quindi aggiornare la versione -main-di Wasmplugin per fare 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 la versione dell'immagine container per l'importazione da Artifact Registry e il push live al deployment 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.

Per prima cosa, 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 per fare riferimento alla versione precedente, "a2a8ce":

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

Una volta completata l'operazione, dovrebbe essere visualizzato questo output:

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

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

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

Per la versione "a2a8ce", questa è 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 una WasmAction e WasmPlugin

Per eliminare un WasmAction, un Wasmplugin e i WasmpluginVersion associati, procedi nel seguente modo.

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

Riga di riferimento da rimuovere:

wasmAction: "my-wasm-action-resource"

Quindi aggiorniamo la configurazione EdgeCacheService modificata.

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

Quindi, aggiorna la versione principale del tuo Wasmplugin con una stringa vuota "".

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

""

Infine, esegui i seguenti passaggi di eliminazione nell'ordine indicato.

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. Pulisci l'ambiente del lab

Dopo aver completato il CodeLab, non dimenticare di pulire le risorse del lab, altrimenti rimarranno in esecuzione e ad accumulare costi.

I seguenti comandi eliminano il servizio EdgeCache di Media CDN, la configurazione di EdgeCache e il plug-in per le estensioni di servizio. Esegui i seguenti passaggi di eliminazione 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 di Service Extension con autenticazione HTTP personalizzata e associarlo a Media CDN
• Come verificare che il plug-in di estensione di servizio funzioni come previsto
• (Facoltativo) Come gestire un plug-in di estensione di servizio, ad esempio aggiornare, fare riferimento, eseguire il rollback ed eliminare una versione specifica di un plug-in

Passaggi successivi

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

• Aggiungere notifiche push a un'app web
• Crea una PWA usando Workbox

Per approfondire

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

Documenti di riferimento

• Documentazione del file manifest dell'app web
• Proprietà del file manifest dell'app web (MDN)
• Installa e Aggiungi a schermata Home
• Panoramica del service worker
• Ciclo di vita dei service worker
• Caricamento del service worker ad alte prestazioni
• Libro di ricette offline