Lab: Extensiones del servicio en Media CDN

1. Introducción

Última actualización: 1/5/2024

Las redes de distribución de contenidos (CDN) mejoran el rendimiento del usuario almacenando en caché el contenido al que se accede con frecuencia más cerca de los usuarios finales, finalizando las conexiones más cerca de los clientes, reutilizando conexiones con el origen y mediante la adopción de personalizaciones y protocolos de red modernos.

Media CDN, la red perimetral global de GCP para la transmisión de contenido multimedia, proporciona muchas herramientas integradas o Las capacidades principales están diseñadas para abordar los casos de uso más comunes, pero también es posible que tengas requisitos que este conjunto de funciones principales no aborda.

Las extensiones del servicio para Media CDN, a veces denominadas programación perimetral, te permiten ejecutar tu propio código en el perímetro para personalizar el comportamiento de Media CDN. Esto desbloquea casos de uso adicionales que van desde la normalización de la clave de caché, la autenticación de token personalizado y la revocación de tokens, campos de registro personalizados adicionales, pruebas A/B y páginas de error personalizadas.

Qué compilarás

En este codelab, revisaremos los pasos para implementar un entorno de entrega de CDN habilitado para procesamiento perimetral con Media CDN (CDN) + Extensiones de servicio (programabilidad perimetral) + Cloud Storage (fuente de CDN).

Qué aprenderás

• Cómo configurar Media CDN con un bucket de Cloud Storage configurado como origen
• Cómo crear un complemento de extensión de servicio con autenticación HTTP personalizada y asociarlo con Media CDN
• Cómo validar que el complemento de extensión de servicio funcione según lo esperado
• Cómo administrar un complemento de extensión de servicio, como actualizar, hacer referencia, revertir y borrar una versión específica del complemento (opcional)

Requisitos

• Herramientas de redes básicas y conocimiento de HTTP
• Conocimiento básico de la línea de comandos de Unix/Linux

2. Antes de comenzar

Solicitud de lista de entidades permitidas de Media CDN y Lista de extensiones permitidas para las extensiones del servicio

Precaución: Asegúrate de que tu proyecto esté incluido en la lista de entidades permitidas de Media CDN y las extensiones del servicio de Media CDN. No podrás finalizar este lab si tu proyecto no está incluido en la lista de entidades permitidas.

Antes de comenzar, asegúrate de que tu proyecto se haya agregado a la lista de entidades permitidas de la versión preliminar privada para Media CDN y las extensiones del servicio para Media CDN.

• Para solicitar acceso a Media CDN y a las extensiones del servicio de Media CDN, comunícate con tu equipo de Cuentas de Google para crear una solicitud de acceso en tu nombre para Media CDN y las extensiones del servicio.

Notas: Si formas parte de Google y deseas probar las Extensiones del servicio con Media CDN, comunícate con el PM de Media CDN y Extensiones del servicio para solicitar acceso.

3. Configuración y requisitos

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Puedes realizar todo tu trabajo en este lab usando simplemente un navegador.

Antes de comenzar

Roles de IAM y Acceso

Los permisos de Identity and Access Management (IAM) necesarios para crear recursos de Media CDN y Artifact Registry son los siguientes:

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

En Cloud Shell, asegúrate de que estén configuradas las variables de entorno project_id, project_num, location y repository.

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

Habilita las APIs

Habilitar Media CDN y APIs de extensiones del servicio a través de los siguientes comandos

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 de Cloud Storage

El contenido de Media CDN puede originarse desde ubicaciones como un bucket de Cloud Storage, una ubicación de almacenamiento de terceros o cualquier extremo HTTP(HTTPS) de acceso público.

En este codelab, almacenaremos contenido en un bucket de Cloud Storage.

Notas: Los nombres de los buckets de Cloud Storage deben ser únicos a nivel global. Para asegurarnos de que no haya conflictos, usaremos la variable de entorno $PROJECT_ID como parte del nombre del bucket.

Usaremos el comando gsutil mb para crear el bucket.

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

De manera opcional, puedes crear un bucket de Cloud Storage con la GUI de la siguiente manera:

1. En la consola de Google Cloud, ve a la página de Cloud Storage.
2. Haz clic en el botón CREAR.
3. Ingresa un nombre para el bucket. - es decir, "mediacdn-bucket-$PROJECT_ID".
4. Deja el resto de la configuración con sus valores predeterminados.
5. Haz clic en el botón CREAR.

5. Sube un objeto de prueba al bucket de Cloud Storage

Ahora, subiremos un objeto al bucket de Cloud Storage.

1. Crear un archivo en Cloud Shell y, luego, subirlo al bucket con gsutil

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

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

Notas: Media CDN admite buckets privados como origen. Para permitir que Media CDN acceda al contenido desde un bucket privado de Cloud Storage, debes configurar IAM para otorgar acceso de objectViewer a la cuenta de servicio de Media CDN.

La cuenta de servicio tiene el siguiente formato:

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

2. Otorga acceso a Media CDN al bucket

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

6. Configurar Media CDN

A continuación, crearemos una configuración de Media CDN.

Cada configuración de Media CDN consta de dos recursos principales:

• EdgeCacheService, responsable de la configuración para el cliente (TLS, direccionamiento IP), enrutamiento, configuración de CDN (modos de almacenamiento en caché, TTL, firma) y políticas de seguridad.
• EdgeCacheOrigin, responsable de la configuración por origen para cualquier origen basado en HTTP, como también de las condiciones de reintento cuando el contenido no está disponible o no se puede acceder a él.

Configura un origen de almacenamiento en caché perimetral

Ahora creemos un origen que apunte al bucket de Cloud Storage que acabas de crear.

1. En la consola de Google Cloud, ve a la página Media CDN.
2. Haz clic en la pestaña ORIGENES.
3. Haz clic en CREAR ORIGEN.
4. Ingresa “cloud-storage-origin” como el nombre para el origen de la caché perimetral.
5. En Dirección de origen, haz lo siguiente:
6. elige “Seleccionar un bucket de Google Cloud Storage”.
7. EXPLORAR al bucket de Cloud Storage llamado ‘mediacdn-bucket-$PROJECT_ID’.
8. haz clic en SELECCIONAR.
9. Deja el resto de la configuración con sus valores predeterminados.
10. Haz clic en CREAR ORIGEN.

El recurso EdgeCacheOrigin recién creado aparecerá en la lista de orígenes de tu proyecto en la página Orígenes.

Configura un servicio de almacenamiento en caché perimetral

1. En la consola de Google Cloud, ve a la página Media CDN.
2. Haz clic en la pestaña SERVICIOS.
3. Haz clic en CREAR SERVICIO.
4. Ingresa un nombre único para tu servicio, como "media-cdn" y, luego, haz clic en Siguiente.

5. En la sección Enrutamiento, haz clic en AGREGAR REGLA DE HOST.
6. Ingresa el comodín - “*” en el campo Hosts.

7. Haz clic en AGREGAR REGLA DE RUTA.
8. En Prioridad, especifica “1”.
9. Haz clic en AGREGAR UNA CONDICIÓN DE CONCORDANCIA. En Coincidencia de ruta de acceso, selecciona “Coincidencia de prefijo”. como Tipo de concordancia, especifica “/” en el campo Coincidencia de ruta y, luego, haz clic en Listo.
10. Selecciona Fetch from an Origin en Acción principal y, luego, elige el origen que configuraste en la lista desplegable.

11. Haz clic en CONFIGURACIÓN AVANZADA para ampliar más opciones de configuración.
12. En Acción de enrutamiento, haz clic en AGREGAR UN ELEMENTO. A continuación, sigue estos pasos:
13. En Tipo, selecciona “Política de CDN”.
14. Para el modo de caché, selecciona "Forzar el almacenamiento en caché todo".
15. Deja el resto de las opciones como predeterminadas
16. Haga clic en Listo.
17. Haz clic en Guardar.

18. Haz clic en CREAR SERVICIO.

El recurso EdgeCacheService recién creado aparece en la página Servicios, en la lista de servicios de tu proyecto.

Recupera la dirección IP y las pruebas de MediaCDN

1. En la consola de Google Cloud, ve a la página Media CDN.
2. Ir a Media CDN
3. Haga clic en la pestaña Servicios.
4. Para tu servicio, consulta la columna Direcciones.

Si quieres probar que tu servicio esté configurado correctamente para almacenar contenido en caché, usa la herramienta de línea de comandos curl para enviar solicitudes y verificar las respuestas.

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

El comando debería generar un resultado similar al siguiente:

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

Creaste correctamente una implementación de MediaCDN con Cloud Storage como origen.

7. Configura Artifact Registry para extensiones de servicio

Antes de crear una extensión del servicio, debemos configurar Artifact Registry. Artifact Registry es el administrador de paquetes universal de Google Cloud para administrar artefactos de compilación. Los complementos de extensión de servicio (Proxy-Wasm) se publican en Artifact Registry. Una vez publicados en Artifact Registry, los complementos de Proxy-Wasm se pueden implementar en tu implementación de Media CDN.

Notas: Los nombres de los repositorios de Artifact Registry deben ser únicos a nivel global. Para asegurarnos de que no haya conflictos, usaremos la variable de entorno $PROJECT_ID como parte del nombre del repositorio.

Usaremos el comando gcloud artifacts Repositories create para crear el repositorio.

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

De manera opcional, puedes crear un repositorio con la GUI de la siguiente manera:

1. En la consola de Google Cloud, ve a la página Artifact Registry.
2. Haz clic en el botón + CREAR REPOSITORIO.
3. Ingresa un nombre para el repositorio. es decir, "service-extension-$PROJECT_ID".
4. Formato: Docker, Modo: "Standard"; Tipo de ubicación: "Región" y elige "us-central1 (Iowa)".
5. Haz clic en el botón CREAR.

El recurso de repositorio de Artifact Registry recién creado debería aparecer en la página Repositorios.

Una vez que se haya creado el recurso del repositorio, ejecuta el siguiente comando en Cloud Shell para configurar tu cliente de Docker de Cloud Shell para enviar y extraer paquetes con este repositorio.

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

Resultado:

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

8. Configura extensiones del servicio en Media CDN

Ahora, demostraremos cómo escribir y compilar un complemento de extensión de servicio (Proxy-Wasm) que se puede implementar en Media CDN con el lenguaje de programación Rust.

En este ejemplo, crearemos un complemento de Proxy-Wasm que verifique que cada solicitud HTTP contenga un encabezado de autorización con el valor “secreto”. Si la solicitud no contiene este encabezado, el complemento generará una respuesta HTTP 403 Forbidden.

Un repaso rápido sobre las extensiones del servicio. Existen tres recursos clave: WasmAction, WasmPlugin y WasmPluginVersion.

• Un recurso WasmAction es lo que se adjunta a tu EdgeCacheService de Media CDN. Un WasmAction hace referencia a un recurso WasmPlugin.
• Un recurso WasmPlugin tiene una versión principal que corresponde a la versión WasmPluginVersion activa en ese momento.
• Un WasmPluginVersions hace referencia a una imagen de contenedor de Artifact Registry. A medida que realizas cambios en los complementos proxy-wasm, creas diferentes WasmPluginVersions.

Consulta el siguiente diagrama para comprender mejor la relación entre estos recursos.

Escribe y compila un complemento de extensión de servicio

1. Instala la cadena de herramientas de Rust con las instrucciones que se indican en https://www.rust-lang.org/tools/install.

Precaución: Asegúrate de seguir las instrucciones para instalar la cadena de herramientas de Rust.

Si obtienes el error “-bash: rustup: command not found” cuando ejecutes “rustup”, prueba “fuente “$HOME/.cargo/env” ‘ para volver a cargar el entorno PATH en Cloud Shell.

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

2. Luego, agrega compatibilidad con Wasm a tu cadena de herramientas de Rust ejecutando el siguiente comando:

rustup target add wasm32-wasi

3. Crea un paquete de Rust llamado my-wasm-plugin:

cargo new --lib my-wasm-plugin

Resultado:

Created library `my-wasm-plugin` package

4. Ingresa el directorio my-wasm-plugin. Deberías ver un archivo Cargo.toml y un directorio src.

cd my-wasm-plugin
ls

Resultado:

Cargo.toml  src

5. A continuación, configura tu paquete de Rust con la edición del archivo Cargo.toml. Después de la línea [dependencies] del archivo Cargo.toml, agrega lo siguiente:

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. Después de realizar los cambios, el archivo Cargo.toml debería verse así:

[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. descarga el archivo sample_code. Copia todo el contenido del archivo sample_code en el archivo lib.rs del directorio src en Cloud Shell.

Notas: El archivo lib.rs es el lugar donde se encuentra tu código fuente. El código fuente debe estar escrito en el lenguaje de programación RUST. Para ver más recetas de código de muestra, consulta network-actions-recipes.

En este codelab, nuestro código verifica que cada solicitud HTTP contenga un encabezado de autorización con el valor “secreto” y generará una respuesta HTTP 403 Forbidden si la solicitud no contiene este encabezado.

8. Después de realizar los cambios, el archivo lib.rs debería verse así:

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. Ahora que configuramos el archivo de manifiesto Cargo.toml y escribimos nuestro código Proxy-Wasm en el archivo lib.rs , podemos compilar el complemento Proxy-Wasm.

cargo build --release --target wasm32-wasi

Una vez que la compilación se complete correctamente, verás un mensaje como el que se muestra a continuación:

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

También verifiquemos el directorio target y comprobaremos que se hayan creado los archivos:

ls ./target

Verás el resultado como se muestra a continuación:

CACHEDIR.TAG release wasm32-wasi

Publica un complemento de Proxy-Wasm en Artifact Registry

Ahora, publicaremos nuestro complemento Proxy-Wasm en el repositorio de Artifact Registry que creaste antes para que se pueda implementar en Media CDN.

Primero, empaquetamos los complementos Proxy-Wasm en una imagen de contenedor.

1. Crea un archivo llamado Dockerfile en el mismo directorio my-wasm-plugin, con el siguiente contenido:

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

2. A continuación, compila la imagen del contenedor:

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

Precaución: Si usas Apple Silicon (arquitectura basada en ARM) o cualquier otro procesador que no sea x86, primero debes habilitar la compatibilidad con WASM en Docker (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads) y, luego, ejecutar el siguiente comando en su lugar para compilar la imagen de contenedor.

(Solo para procesadores que no sean x86) A continuación, compila la imagen del contenedor:

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

Salida

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

3. Luego, publica o "envía" tu complemento Proxy-Wasm a Artifact Registry. Etiquetaremos la imagen de contenedor con el atributo “prod” etiqueta.

Notas: Artifact Registry usa una convención de nombres para identificar imágenes y repositorios.

El nombre completo de una imagen de Docker en un repositorio está en el siguiente 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

Ahora, continuamos y enviamos la etiqueta “prod” imagen de contenedor al repositorio.

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

Resultado:

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

Precaución: Asegúrate de haber configurado gcloud como auxiliar de credenciales para el dominio de Artifact Registry asociado con la ubicación del repositorio.

Qué hacer si recibes “permiso denegado” cuando envíes el contenedor a Artifact Registry, vuelve a Configurar Artifact Registry para extensiones del servicio y ejecuta el comando gcloud auth otra vez.

Ahora, verifiquemos que la imagen de contenedor del complemento Proxy-Wasm se envió correctamente a Artifact Registry. Deberías ver un resultado similar al siguiente:

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

Resultado:

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

Asocia un complemento de Proxy-Wasm a tu implementación de Media CDN

Ya estamos listos para asociar el complemento Proxy-Wasm a tu implementación de Media CDN.

Los complementos Proxy-Wasm están asociados con rutas de Media CDN en el recurso EdgeCacheService.

Precaución: Es posible que la creación de recursos de proxy-Wasm tarde un poco en completarse.

Espera hasta ver el mensaje de finalización antes de continuar con los pasos siguientes.

1. Primero, creamos un recurso Wasm-plugin para nuestro complemento Proxy-Wasm.

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

2. A continuación, creamos 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. A continuación, especificamos la versión principal de nuestro complemento Proxy-Wasm.

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

Ahora, verifiquemos que el complemento Proxy-Wasm se asoció correctamente a la imagen del contenedor que reside en el repositorio de Artifact Registry. Deberías ver un resultado similar al siguiente:

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

Resultado:

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. A continuación, crearemos un recurso WasmAction que haga referencia al recurso del complemento de Wasm.

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

También verifiquemos que el recurso WasmAction se asoció correctamente con el complemento Proxy-Wasm. Deberías ver un resultado similar al siguiente:

gcloud alpha service-extensions wasm-actions list

Resultado:

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

5. Ahora, debemos exportar la configuración de EdgeCacheService de Media CDN:

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

6. A continuación, abre el archivo my-service.yaml y agrega una wasmAction a la routeAction para la ruta dada, que hace referencia al recurso WasmPlugin creado anteriormente.

wasmAction: "my-wasm-action-resource"

7. Después de las ediciones, el archivo my-service.yaml debería verse así:

...

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. Luego, guardamos la configuración actualizada con la configuración de Proxy-Wasm en el archivo my-service-with-wasm.yaml.

Precaución: Si encuentras un error de validación de configuración cuando importas el archivo yaml editado a la API de servicios de Edge-Cache, vuelve a verificar el archivo yaml y asegúrate de que la línea wasmAction esté agregada en la sección routeAction. Asegúrate de usar espacios solo para la sangría, ya que YAML no acepta tabulaciones.

9. Por último, importamos la configuración actualizada para el entorno de producción de Media CDN:

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

9. Valida el complemento de proxy de Wasm de extensiones de servicio en Media CDN

Si quieres probar que tu servicio esté configurado correctamente para almacenar contenido en caché, usa la herramienta de línea de comandos curl para enviar solicitudes y verificar las respuestas.

Notas: El cambio puede tardar hasta 10 minutos en propagarse por toda la red de MediaCDN. Mientras tanto, es posible que no veas el error HTTP 403. Sigue intentando hasta que se muestre el error 403.

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

El comando debería generar un resultado similar al siguiente:

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

Ahora, emite la solicitud de nuevo con un encabezado de autorización y su valor de secreto.

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

El comando debería generar un resultado similar al siguiente:

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

10. Cómo administrar los complementos de Proxy-Wasm (opcional)

Actualiza un complemento de Proxy-Wasm

A medida que realices mejoras o agregues nuevas funcionalidades a tus complementos de Proxy-Wasm, tendrás que implementar los complementos actualizados en Media CDN. A continuación, se explican los pasos para implementar una versión actualizada de un complemento.

A modo de ejemplo, puedes actualizar el código del complemento de muestra para evaluar el encabezado de autorización con otro valor de autenticación. Para ello, debes modificar el código de la siguiente manera:

Primero, actualiza el archivo de origen src/lib.rs con el código que se muestra a continuación:

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

A continuación, compila, empaqueta y publica el complemento actualizado:

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 vez que se actualice la imagen de contenedor en Artifact Registry, debemos crear una versión nueva de WasmPluginVersion y, luego, actualizar la versión –main-version de WasmPlugin para que haga referencia a la nueva versión.

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

Ya actualizaste correctamente la versión de la imagen de contenedor que se importará desde Artifact Registry y se envió a tu implementación de Media CDN.

Cómo revertir a una versión anterior

Para revertir a una versión anterior de un complemento, puedes actualizar el recurso del complemento de Wasm para hacer referencia a una versión anterior.

Primero, enumeramos las versiones disponibles:

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

Deberías ver el siguiente resultado:

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

A continuación, actualizamos el recurso del complemento de Wasm para hacer referencia a la versión anterior, “a2a8ce”:

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

Una vez que la operación se complete correctamente, deberías ver este resultado:

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

Dado que Media CDN guarda el resumen de la imagen de tu imagen de Docker cada vez que se crea un nuevo recurso de complemento de Wasm, la reversión usará la versión de tu código que se estaba ejecutando antes del último lanzamiento.

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

Para la versión "a2a8ce", esa es la versión con resumen 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"

Cómo borrar una WasmAction y WasmPlugin

Para borrar un WasmAction, WasmPlugin y las WasmPluginVersions asociadas, sigue estos pasos.

Primero, quita la referencia a WasmAction en la configuración de EdgeCacheService de Media CDN.

Línea de referencia que se quitará:

wasmAction: "my-wasm-action-resource"

Luego, actualizamos la configuración de EdgeCacheService editada.

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

A continuación, actualiza la versión principal de tu WasmPlugin a una cadena vacía "".

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

""

Por último, realiza los siguientes pasos de eliminación en orden.

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. Limpia el entorno del lab

Una vez que hayas completado el codelab, no olvides limpiar los recursos del lab; de lo contrario, seguirán ejecutándose y acumulando costos.

Los siguientes comandos borrarán el servicio EdgeCache de Media CDN, la configuración de EdgeCache Config y el complemento de extensiones del servicio. Realiza los siguientes pasos de eliminación en orden.

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

Cada uno de los comandos anteriores debería solicitarte que confirmes la eliminación del recurso.

12. ¡Felicitaciones!

¡Felicitaciones! Completaste el codelab Extensiones del servicio en Media CDN.

Temas abordados

• Cómo configurar Media CDN con un bucket de Cloud Storage configurado como origen
• Cómo crear un complemento de extensión de servicio con autenticación HTTP personalizada y asociarlo con Media CDN
• Cómo validar que el complemento de extensión de servicio funcione según lo esperado
• Cómo administrar un complemento de extensión de servicio, como actualizar, hacer referencia, revertir y borrar una versión específica del complemento (opcional)

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

• Agrega notificaciones push a una app web
• Crea una AWP con Workbox

Lecturas adicionales

• Carga de service worker de alto rendimiento
• Estrategias de almacenamiento en caché del service worker basadas en tipos de solicitud

Documentos de referencia

• Documentos del manifiesto de apps web
• Propiedades del manifiesto de apps web (MDN)
• Instalación y Agregar a la pantalla principal
• Descripción general de los service workers
• Ciclo de vida del service worker
• Carga de service worker de alto rendimiento
• Guía de soluciones sin conexión