Lab: Extensiones del servicio en Media CDN

1. Introducción

Última actualización: 2024-05-01

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 las conexiones al origen y adoptando protocolos y personalizaciones de redes modernos.

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

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

Qué compilarás

En este codelab, analizaremos los pasos para implementar un entorno de entrega de CDN habilitado para Edge Compute con Media CDN (CDN) + Service Extensions (programabilidad perimetral) + Cloud Storage (fuente de la CDN).

Qué aprenderás

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

Requisitos

• Conocimientos básicos de redes y 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 entidades permitidas de extensiones de servicio

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

Antes de comenzar, deberás asegurarte de que tu proyecto se haya agregado a la lista de entidades permitidas de la versión preliminar privada tanto para Media CDN como para las extensiones de servicio de Media CDN.

• Para solicitar acceso a Media CDN y a Service Extensions para Media CDN, comunícate con tu equipo de Cuentas de Google para que cree una solicitud de acceso en tu nombre para Media CDN y Service Extensions.

Notas: Si formas parte de Google y deseas probar las Service Extensions con Media CDN, comunícate con los administradores de productos de Media CDN y Service Extensions 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 y acceso de IAM

Los permisos de Identity and Access Management (IAM) necesarios para crear recursos de CDN de Media 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

Habilita las APIs de Media CDN y Service Extensions con 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 en 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 los parámetros de 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. Crea un archivo en Cloud Shell y, luego, súbelo al bucket con gsutil.

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

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

Notas: La CDN de medios admite buckets privados como origen. Para permitir que Media CDN acceda al contenido de 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 de Media CDN al bucket

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

6. Configura 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 orientada al cliente (TLS, direccionamiento IP), el enrutamiento, la configuración de CDN (modos de almacenamiento en caché, TTL, firma) y las políticas de seguridad.
• EdgeCacheOrigin, responsable de la configuración por origen para cualquier origen basado en HTTP, así como de las condiciones de reintento cuando el contenido no está disponible o no se puede acceder a él.

Configura un origen del 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 ORIGINS.
3. Haz clic en CREATE ORIGIN.
4. Ingresa "cloud-storage-origin" como el nombre del origen de la caché perimetral.
5. En Dirección de origen, haz lo siguiente:
6. Elige "Seleccionar un bucket de Google Cloud Storage".
7. NAVEGA al bucket de Cloud Storage llamado "mediacdn-bucket-$PROJECT_ID".
8. Haz clic en SELECCIONAR.
9. Deja el resto de los parámetros de configuración con sus valores predeterminados.
10. Haz clic en CREATE ORIGIN.

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 Edge Cache

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, por ejemplo, "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 ENRUTAMIENTO.
8. En Prioridad, especifica "1".
9. Haz clic en AGREGAR UNA CONDICIÓN DE CONCORDANCIA, para Concordancia de ruta, selecciona "Concordancia de prefijo" como Tipo de concordancia, especifica "/" en el campo Concordancia de ruta y, luego, haz clic en Listo.
10. Selecciona Fetch from an Origin en Acción principal y, luego, selecciona el origen que configuraste en la lista desplegable.

11. Haz clic en CONFIGURACIONES AVANZADAS para expandir más opciones de configuración.
12. En Acción de ruta, haz clic en AGREGAR UN ELEMENTO. A continuación, sigue estos pasos:
13. En Tipo, selecciona "Política de CDN".
14. En Modo de caché, selecciona "Forzar caché de todo".
15. Deja el resto de las opciones con la configuración predeterminada.
16. Haz clic en Listo.
17. Haz clic en Guardar.

18. Haz clic en CREAR SERVICIO.

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

Recupera la dirección IP de MediaCDN y realiza pruebas

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

Para 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 producir un resultado similar al siguiente:

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

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

7. Configura Artifact Registry para las extensiones de servicio

Antes de crear extensiones de 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 Service Extension (Proxy-Wasm) se publican en Artifact Registry. Una vez que se publican 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, p. ej., “service-extension-$PROJECT_ID”.
4. Formato: “Docker”, Modo: “Estándar”, Tipo de ubicación: “Región” y elige “us-central1 (Iowa)”.
5. Haz clic en el botón CREAR.

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

Una vez que se haya creado el recurso Repository, ejecuta el siguiente comando en Cloud Shell para configurar tu cliente de Docker de Cloud Shell de modo que envíe y extraiga 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 Service Extensions en Media CDN

Ahora, demostraremos cómo escribir y compilar un complemento de Service Extension (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 breve repaso sobre las extensiones de 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 de WasmPlugin.
• Un recurso de WasmPlugin tiene una versión principal que corresponde a la versión activa actual de WasmPluginVersion.
• Un WasmPluginVersions hace referencia a una imagen de contenedor de Artifact Registry. A medida que realices cambios en tus complementos de proxy-wasm, crearás diferentes versiones de WasmPlugin.

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

Escribe y compila un complemento de Service Extension

1. Instala la cadena de herramientas de Rust. Para ello, sigue las instrucciones que se encuentran en https://www.rust-lang.org/tools/install.

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

Si recibes el error "-bash: rustup: command not found" cuando ejecutas "rustup", prueba con "source "$HOME/.cargo/env" para volver a cargar la variable de entorno PATH en Cloud Shell.

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

2. A continuación, ejecuta el siguiente comando para agregar compatibilidad con Wasm a tu cadena de herramientas de Rust:

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 al directorio my-wasm-plugin y 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 editando el archivo Cargo.toml. Después de la línea [dependencies] en el 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 tus ediciones, el archivo Cargo.toml debería verse aproximadamente de la siguiente manera:

[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 reside tu código fuente. El código fuente debe escribirse en el lenguaje de programación RUST. Para obtener más ejemplos de recetas de código, 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 Prohibido si la solicitud no contiene este encabezado.

8. Después de tus ediciones, el archivo lib.rs debería verse aproximadamente de la siguiente manera:

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 de Proxy-Wasm en el archivo lib.rs , podemos compilar nuestro complemento de 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 verificaremos el directorio target y comprobaremos que se hayan creado los archivos:

ls ./target

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

CACHEDIR.TAG release wasm32-wasi

Publica un complemento de Proxy-Wasm en Artifact Registry

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

Primero, empaquetamos los complementos de 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 para compilar la imagen del contenedor.

(Solo para procesadores que no son 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. A continuación, publica o "envía" tu complemento de Proxy-Wasm a Artifact Registry. Etiquetaremos nuestra imagen de contenedor con la etiqueta "prod".

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

El nombre completo de una imagen de Docker en un repositorio tiene 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, enviaremos la imagen de contenedor etiquetada como "prod" 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 el auxiliar de credenciales para el dominio de Artifact Registry asociado a la ubicación del repositorio.

Si recibes un error de "permiso denegado" cuando envías el contenedor a Artifact Registry, vuelve a Configurar Artifact Registry para las extensiones de servicio y vuelve a ejecutar el comando gcloud auth.

Ahora, verifiquemos que la imagen de contenedor del complemento de Proxy-Wasm se haya enviado 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 con tu implementación de Media CDN

Ahora ya puedes asociar el complemento Proxy-Wasm a tu implementación de Media CDN.

Los complementos de Proxy-Wasm se asocian con rutas de Media CDN en el recurso EdgeCacheService.

Precaución: La creación de cada recurso de Proxy-Wasm puede tardar un tiempo en completarse.

Espera hasta que veas el mensaje de finalización antes de continuar con los pasos posteriores.

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

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

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

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

Ahora, verifiquemos que el complemento de Proxy-Wasm se haya asociado correctamente a la imagen de 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 a nuestro recurso de complemento de Wasm.

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

También verificaremos que el recurso WasmAction se haya asociado correctamente al 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 nuestro Media CDN EdgeCacheService:

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

6. Luego, abre el archivo my-service.yaml y agrega un wasmAction al routeAction para la ruta determinada, que hace referencia al recurso WasmPlugin creado anteriormente.

wasmAction: "my-wasm-action-resource"

7. Después de tus ediciones, el archivo my-service.yaml debería verse aproximadamente 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 la configuración cuando importes el archivo YAML editado a la API de servicios de caché perimetral, vuelve a verificar el archivo YAML y asegúrate de que la línea wasmAction se haya agregado dentro de la sección routeAction. Asegúrate de usar solo espacios 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 Service Extensions Proxy-Wasm en Media CDN

Para 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 puedas ver el error HTTP 403. Sigue intentando hasta que aparezca el error 403.

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

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

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

Ahora, vuelve a enviar la solicitud 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 producir un resultado similar al siguiente:

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

10. Opcional: Administra complementos de Proxy-Wasm

Cómo actualizar un complemento de Proxy-Wasm

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

Por ejemplo, puedes actualizar el código de muestra del complemento para evaluar el encabezado de autorización en función de otro valor para la autenticación. Para ello, modifica el código de la siguiente manera.

Primero, actualiza el archivo fuente 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 nueva WasmPluginVersion y, luego, actualizar la versión principal 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

Ahora, actualizaste correctamente la versión de la imagen del contenedor que se importará desde Artifact Registry y se enviará en vivo a tu implementación de CDN de medios.

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 que haga 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 realice 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 recurso nuevo de complemento de Wasm, la reversión usará la versión de tu código que se ejecutaba antes de la última versión.

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

Para la versión "a2a8ce", es la versión con el 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 un WasmAction y un WasmPlugin

Para borrar un WasmAction, un WasmPlugin y los WasmPluginVersions asociados, 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 editada de EdgeCacheService.

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 para borrar el rol 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

Después de completar 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 y el complemento de extensiones de servicio. Sigue los pasos que se indican a continuación para borrar el historial.

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 pedirte que confirmes el borrado del recurso.

12. ¡Felicitaciones!

¡Felicitaciones! Completaste el codelab de Service Extensions en Media CDN.

Temas abordados

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

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

• Cómo agregar notificaciones push a una app web
• Compila una AWP con Workbox

Lecturas adicionales

• Carga de Service Worker de alto rendimiento
• Estrategias de almacenamiento en caché de Service Worker basadas en tipos de solicitudes

Documentos de referencia

• Documentación del manifiesto de la app web
• Propiedades del manifiesto de la app web (MDN)
• Instalar y agregar a la pantalla principal
• Descripción general de Service Worker
• Ciclo de vida del Service Worker
• Carga de Service Worker de alto rendimiento
• Offline Cookbook