Laboratório: Extensões de serviço no Media CDN

1. Introdução

Última atualização:01/05/2024

As redes de fornecimento de conteúdo (CDNs) melhoram a performance do usuário armazenando em cache o conteúdo acessado com frequência mais perto dos usuários finais, encerrando as conexões mais perto dos clientes, reutilizando as conexões com a origem e adotando protocolos e personalizações de rede modernos.

O Media CDN, a rede de borda global do GCP para streaming de mídia, oferece muitos recursos integrados ou "principais". Eles são destinados a atender aos casos de uso mais comuns, mas você também pode ter requisitos que não são atendidos por esse conjunto de atributos principais.

As extensões de serviço para Media CDN, às vezes também chamadas de programabilidade de borda, permitem executar seu próprio código na borda para personalizar o comportamento do Media CDN. Isso desbloqueia outros casos de uso, como normalização de chave de cache, autenticação e revogação de token personalizado, campos de registro personalizados adicionais, teste A/B e página de erro personalizada.

O que você vai criar

Neste codelab, vamos mostrar as etapas para implantar um ambiente de entrega de CDN habilitado para computação de borda com Media CDN (CDN) + Service Extensions (programabilidade de borda) + Cloud Storage (fonte da CDN).

O que você vai aprender

• Como configurar a Media CDN com um bucket do Cloud Storage definido como origem
• Como criar um plug-in de extensão de serviço com autenticação HTTP personalizada e associá-lo ao Media CDN
• Como validar se o plug-in Service Extension está funcionando conforme o esperado
• (opcional) Como gerenciar um plug-in de extensão de serviço, como atualizar, referenciar, reverter e excluir uma versão específica do plug-in

O que é necessário

• Conhecimento básico de redes e HTTP
• Conhecimento básico de linha de comando do Unix/Linux

2. Antes de começar

Solicitação de lista de permissões da Media CDN e lista de permissões do Service Extensions

Atenção: verifique se o projeto está na lista de permissões do Media CDN e do Service Extensions para Media CDN. Não será possível concluir este laboratório se o projeto não estiver na lista de permissões.

Antes de começar, verifique se o projeto foi adicionado à lista de permissões da prévia particular do Media CDN e do Service Extensions para Media CDN.

• Para solicitar acesso ao Media CDN e às Service Extensions para Media CDN, entre em contato com a equipe da sua Conta do Google para criar uma solicitação de acesso em seu nome para o Media CDN e as Service Extensions.

Observações:se você faz parte do Google e quer testar as Service Extensions com a Media CDN, entre em contato com os PMs da Media CDN e das Service Extensions para solicitar acesso.

3. Configuração e requisitos

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.

Antes de começar

Funções e acesso do IAM

As permissões do Identity and Access Management (IAM) necessárias para criar recursos da Media CDN e do Artifact Registry são as seguintes:

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

No Cloud Shell, verifique se as variáveis de ambiente project_id, project_num, location e repository estão configuradas.

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

Ativar APIs

Ative as APIs Media CDN e Service Extensions com os comandos abaixo

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. Crie um bucket do Cloud Storage

O conteúdo da Media CDN pode ser originado de locais como um bucket do Cloud Storage, um local de armazenamento de terceiros ou qualquer endpoint HTTP(HTTPS) acessível publicamente.

Neste codelab, vamos armazenar conteúdo em um bucket do Cloud Storage.

Observações:os nomes dos buckets do Cloud Storage precisam ser exclusivos globalmente. Para garantir que não haja conflitos, vamos usar a variável de ambiente $PROJECT_ID como parte do nome do bucket.

Vamos usar o comando gsutil mb para criar o bucket.

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

Também é possível criar um bucket do Cloud Storage usando a GUI da seguinte maneira:

1. No Console do Google Cloud, acesse a página Cloud Storage.
2. Clique no botão CRIAR.
3. Digite um nome para o bucket. - ou seja, "mediacdn-bucket-$PROJECT_ID".
4. Deixe as outras configurações como padrão.
5. Clique no botão CRIAR.

5. Fazer upload de um objeto de teste para o bucket do Cloud Storage

Agora vamos fazer upload de um objeto para o bucket do Cloud Storage.

1. Crie um arquivo no Cloud Shell e faça upload dele para o bucket usando gsutil.

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

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

Observações:a Media CDN é compatível com buckets particulares como origem. Para permitir que a Media CDN acesse conteúdo de um bucket privado do Cloud Storage, configure o IAM para conceder acesso de objectViewer à conta de serviço da Media CDN.

A conta de serviço tem o seguinte formato:

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

2. Conceder acesso da CDN de mídia ao bucket

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

6. Configurar o Media CDN

Em seguida, vamos criar uma configuração da Media CDN.

Cada configuração do Media CDN consiste em dois recursos principais:

• EdgeCacheService, responsável pela configuração voltada ao cliente (TLS, endereçamento IP), roteamento, configuração de CDN (modos de cache, TTLs, assinatura) e políticas de segurança.
• EdgeCacheOrigin, responsável pela configuração por origem de qualquer origem baseada em HTTP, bem como pelas condições de nova tentativa quando o conteúdo não está disponível ou acessível.

Configurar uma origem do armazenamento em cache de borda

Agora vamos criar uma origem que aponta para o bucket do Cloud Storage que você acabou de criar.

1. No console do Google Cloud, acesse a página Media CDN.
2. Clique na guia ORIGENS.
3. Clique em CRIAR ORIGEM.
4. Insira "cloud-storage-origin" como o nome da origem do armazenamento em cache de borda.
5. Em "Endereço de origem":
6. escolha 'Selecionar um bucket do Cloud Storage'.
7. NAVEGUE até o bucket do Cloud Storage chamado "mediacdn-bucket-$PROJECT_ID".
8. clique em SELECIONAR.
9. Deixe as outras configurações como padrão.
10. Clique em CRIAR ORIGEM.

O recurso EdgeCacheOrigin recém-criado aparece na lista de origens do projeto na página "Origens".

Configurar um serviço de cache próximo dos usuários finais

1. No console do Google Cloud, acesse a página Media CDN.
2. Clique na guia SERVIÇOS.
3. Clique em CRIAR SERVIÇO.
4. Insira um nome exclusivo para o serviço, por exemplo, "media-cdn", e clique em "Próxima".

5. Na seção "Roteamento", clique em ADICIONAR REGRA DE HOST.
6. Insira o caractere curinga "*" no campo "Hosts".

7. Clique em ADICIONAR REGRA DE ROTA.
8. Em "Prioridade", especifique "1".
9. Clique em ADICIONAR UMA CONDIÇÃO DE CORRESPONDÊNCIA. Em "Correspondência de caminho", selecione "Correspondência de prefixo" como "Tipo de correspondência", especifique "/" no campo "Correspondência de caminho" e clique em "Concluído".
10. Selecione Buscar em uma origem em "Ação principal" e escolha a origem que você configurou na lista suspensa.

11. Clique em CONFIGURAÇÕES AVANÇADAS para abrir mais opções de configuração.
12. Em "Ação de rota", clique em ADICIONAR UM ITEM. Em seguida, faça o seguinte:
13. Em "Tipo", selecione "Política de CDN".
14. Em "Modo de cache", selecione "Forçar cache de tudo".
15. Deixe o restante como padrão.
16. Clique em "Concluído".
17. Clique em Salvar.

18. Clique em CRIAR SERVIÇO.

O recurso EdgeCacheService recém-criado aparece na página "Serviços" na lista de serviços do seu projeto.

Recuperar o endereço IP do MediaCDN e fazer testes

1. No console do Google Cloud, acesse a página Media CDN.
2. Acessar a Media CDN
3. Clique na guia Serviços.
4. Para seu serviço, consulte a coluna Endereços.

Para testar se o serviço está configurado corretamente para armazenar conteúdo em cache, use a ferramenta de linha de comando curl para emitir solicitações e verificar as respostas.

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

O comando vai produzir uma saída semelhante a esta:

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

Agora você criou uma implantação do MediaCDN com o Cloud Storage como origem.

7. Configurar o Artifact Registry para Service Extensions

Antes de criar Service Extensions, precisamos configurar o Artifact Registry. O Artifact Registry é o gerenciador de pacotes universal do Google Cloud para gerenciar artefatos de build. Os plug-ins de extensão de serviço (Proxy-Wasm) são publicados no Artifact Registry. Depois de publicados no Artifact Registry, os plug-ins Proxy-Wasm podem ser implantados na sua implantação da Media CDN.

Observações:os nomes dos repositórios do Artifact Registry precisam ser exclusivos em nível global. Para garantir que não haja conflitos, vamos usar a variável de ambiente $PROJECT_ID como parte do nome do repositório.

Vamos usar o comando gcloud artifacts repositories create para criar o repositório.

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

Se quiser, crie um repositório usando a GUI da seguinte maneira:

1. No console do Google Cloud, acesse a página do Artifact Registry.
2. Clique no botão + CRIAR REPOSITÓRIO.
3. Insira um nome para o repositório, por exemplo, "service-extension-$PROJECT_ID".
4. Formato: "Docker", Modo: "Padrão", Tipo de local: "Região" e escolha "us-central1 (Iowa)".
5. Clique no botão CRIAR.

O recurso do repositório do Artifact Registry recém-criado vai aparecer na página "Repositórios".

Depois que o recurso "Repository" for criado, execute o comando a seguir no Cloud Shell para configurar o cliente Docker do Cloud Shell para enviar por push e efetuar pull de pacotes usando esse repositório.

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

Saída:

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

8. Configurar Service Extensions no Media CDN

Agora, vamos demonstrar como escrever e criar um plug-in de extensão de serviço (Proxy-Wasm) que pode ser implantado no Media CDN usando a linguagem de programação Rust.

Neste exemplo, vamos criar um plug-in Proxy-Wasm que verifica se cada solicitação HTTP contém um cabeçalho de autorização com o valor "secret". Se a solicitação não contiver esse cabeçalho, o plug-in vai gerar uma resposta HTTP 403 Forbidden.

Uma rápida atualização sobre extensões de serviço: há três recursos principais: WasmAction, WasmPlugin e WasmPluginVersion.

• Um recurso WasmAction é o que é anexado ao seu Media CDN EdgeCacheService. Uma WasmAction faz referência a um recurso WasmPlugin.
• Um recurso WasmPlugin tem uma versão principal que corresponde ao WasmPluginVersion ativo atual.
• Um WasmPluginVersions faz referência a uma imagem de contêiner do Artifact Registry. Ao fazer mudanças nos seus plug-ins proxy-wasm, você cria diferentes WasmPluginVersions.

Consulte o diagrama abaixo para entender melhor a relação entre esses recursos.

Escrever e criar um plug-in de extensão de serviço

1. Instale o conjunto de ferramentas Rust seguindo as instruções em https://www.rust-lang.org/tools/install.

Atenção: siga as instruções da solicitação para instalar a cadeia de ferramentas do Rust.

Se você receber um erro "-bash: rustup: command not found" ao executar "rustup", tente source "$HOME/.cargo/env" para recarregar o ambiente PATH no Cloud Shell.

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

2. Em seguida, adicione o suporte a Wasm à sua cadeia de ferramentas do Rust executando o seguinte comando:

rustup target add wasm32-wasi

3. Crie um pacote do Rust chamado my-wasm-plugin:

cargo new --lib my-wasm-plugin

Saída:

Created library `my-wasm-plugin` package

4. Entre no diretório my-wasm-plugin. Você vai encontrar um arquivo Cargo.toml e um diretório src.

cd my-wasm-plugin
ls

Saída:

Cargo.toml  src

5. Em seguida, configure o pacote Rust editando o arquivo Cargo.toml. Depois da linha [dependencies] no arquivo Cargo.toml, adicione o seguinte:

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. Depois das edições, o arquivo Cargo.toml vai ficar mais ou menos assim:

[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. Faça o download do arquivo sample_code. Copie todo o conteúdo do arquivo sample_code para o arquivo lib.rs no diretório src do Cloud Shell.

Observações:o arquivo lib.rs é onde o código-fonte reside. O código-fonte precisa ser escrito na linguagem de programação RUST. Para mais exemplos de código, consulte network-actions-recipes.

Neste codelab, nosso código verifica se cada solicitação HTTP contém um cabeçalho de autorização com o valor "secret" e gera uma resposta HTTP 403 Forbidden se a solicitação não contiver esse cabeçalho.

8. Depois das edições, o arquivo lib.rs vai ficar mais ou menos assim:

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. Agora que configuramos o arquivo de manifesto Cargo.toml e escrevemos nosso código Proxy-Wasm no arquivo lib.rs , podemos criar nosso plug-in Proxy-Wasm.

cargo build --release --target wasm32-wasi

Quando a build for concluída, você vai receber uma mensagem como esta:

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

Vamos também verificar o diretório target e conferir se os arquivos foram criados:

ls ./target

A saída vai aparecer assim:

CACHEDIR.TAG release wasm32-wasi

Publicar um plug-in do Proxy-Wasm no Artifact Registry

Agora, vamos publicar nosso plug-in Proxy-Wasm no repositório do Artifact Registry que você criou antes para que ele possa ser implantado na Media CDN.

Primeiro, empacotamos os plug-ins do Proxy-Wasm em uma imagem de contêiner.

1. Crie um arquivo chamado Dockerfile no mesmo diretório my-wasm-plugin, com o seguinte conteúdo:

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

2. Em seguida, crie a imagem do contêiner:

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

Atenção: se você estiver usando o Apple Silicon (arquitetura baseada em ARM) ou qualquer outro processador que não seja x86, primeiro ative o suporte a WASM no Docker (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads) e execute o seguinte comando para criar a imagem do contêiner.

(somente processadores não x86) Em seguida, crie a imagem do contêiner:

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

Saída

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

3. Em seguida, publique ou "envie" o plug-in Proxy-Wasm para o Artifact Registry. Vamos marcar a imagem do contêiner com a tag "prod".

Observações:o Artifact Registry usa uma convenção de nomenclatura para identificar repositórios e imagens.

O nome completo de uma imagem do Docker em um repositório está no seguinte 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

Agora, vamos enviar a imagem do contêiner "prod" com tag para o repositório.

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

Saída:

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

Atenção: confira se você configurou o gcloud como auxiliar de credenciais para o domínio do Artifact Registry associado ao local do repositório.

Se você receber um erro de 'permissão negada' ao enviar o contêiner para o Artifact Registry, volte para Configurar o Artifact Registry para Service Extensions e execute o comando gcloud auth novamente.

Agora vamos verificar se a imagem do contêiner do plug-in Proxy-Wasm foi enviada ao Artifact Registry. Você vai ver uma saída semelhante a esta:

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

Saída:

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

Associar um plug-in do Proxy-Wasm à implantação do Media CDN

Agora estamos prontos para associar o plug-in Proxy-Wasm à sua implantação do Media CDN.

Os plug-ins do Proxy-Wasm estão associados a rotas do Media CDN no recurso EdgeCacheService.

Atenção: cada criação de recurso do Proxy-Wasm pode levar algum tempo para ser concluída.

Aguarde até que a mensagem de conclusão apareça antes de seguir para as próximas etapas.

1. Primeiro, criamos um recurso Wasm-plugin para nosso plug-in Proxy-Wasm.

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

2. Em seguida, criamos um 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. Em seguida, especificamos a versão principal do nosso plug-in Proxy-Wasm.

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

Agora, vamos verificar se o plug-in Proxy-Wasm foi associado corretamente à imagem do contêiner no repositório do Artifact Registry. Você vai ver uma saída semelhante a esta:

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

Saída:

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. Em seguida, criamos um recurso WasmAction que faz referência ao recurso do plug-in Wasm.

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

Vamos verificar também se o recurso WasmAction foi associado ao plug-in Proxy-Wasm. Você vai ver uma saída semelhante a esta:

gcloud alpha service-extensions wasm-actions list

Saída:

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

5. Agora, precisamos exportar a configuração do nosso Media CDN EdgeCacheService:

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

6. Em seguida, abra o arquivo my-service.yaml e adicione um wasmAction ao routeAction da rota especificada, que faz referência ao recurso WasmPlugin criado anteriormente.

wasmAction: "my-wasm-action-resource"

7. Depois das edições, o arquivo my-service.yaml vai ficar assim:

...

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. Em seguida, salvamos a configuração atualizada com a configuração do Proxy-Wasm no arquivo my-service-with-wasm.yaml.

Atenção: se você encontrar um erro de validação de configuração ao importar o arquivo YAML editado para a API de serviços de cache de borda, verifique novamente o arquivo YAML e confira se a linha wasmAction foi adicionada à seção routeAction. Use apenas espaços para recuo. O YAML não aceita tabulações.

9. Por fim, importamos a configuração atualizada para o ambiente de produção do Media CDN:

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

9. Validar o plug-in Proxy-Wasm do Service Extensions no Media CDN

Para testar se o serviço está configurado corretamente para armazenar conteúdo em cache, use a ferramenta de linha de comando curl para emitir solicitações e verificar as respostas.

Observações:pode levar até 10 minutos para que a mudança seja propagada por toda a rede do MediaCDN. Enquanto isso, talvez você não consiga ver o erro HTTP 403. Continue tentando até que o erro 403 seja retornado.

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

O comando vai produzir uma saída semelhante a esta:

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

Agora, emita a solicitação novamente com um cabeçalho de autorização e o valor secreto dele.

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

O comando vai produzir uma saída semelhante a esta:

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

10. Opcional: gerenciar plug-ins do Proxy-Wasm

Como atualizar um plug-in do Proxy-Wasm

À medida que você faz melhorias ou adiciona novas funcionalidades aos plug-ins do Proxy-Wasm, é necessário implantar os plug-ins atualizados no Media CDN. A seguir, vamos mostrar as etapas para implantar uma versão atualizada de um plug-in.

Por exemplo, é possível atualizar o código de plug-in de amostra para avaliar o cabeçalho de autorização em relação a outro valor para autenticação, modificando o código da seguinte maneira.

Primeiro, atualize o arquivo de origem src/lib.rs com o código mostrado abaixo:

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

Em seguida, crie, empacote e publique o plug-in atualizado:

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

Depois que a imagem do contêiner for atualizada no Artifact Registry, crie uma nova WasmPluginVersion e atualize a –main-version do WasmPlugin para referenciar a nova versão.

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

Agora, você atualizou a versão da imagem do contêiner a ser importada do Artifact Registry e enviada para sua implantação da Media CDN.

Como reverter para uma versão anterior

Para reverter para uma versão anterior de um plug-in, atualize o recurso do plug-in Wasm para referenciar uma versão anterior.

Primeiro, listamos as versões disponíveis:

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

Você vai ver a saída:

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

Em seguida, atualizamos o recurso do plug-in Wasm para fazer referência à versão anterior, "a2a8ce":

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

Quando a operação for concluída, você vai ver esta saída:

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

Como a Media CDN salva o resumo da imagem Docker sempre que um novo recurso de plug-in Wasm é criado, a reversão usa a versão do seu código que estava em execução antes do último lançamento.

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

Para a versão "a2a8ce", que é a versão com o resumo 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"

Excluir um WasmAction e um WasmPlugin

Para excluir um WasmAction, WasmPlugin e as WasmPluginVersions associadas, siga estas etapas.

Primeiro, remova a referência ao WasmAction na configuração do Media CDN EdgeCacheService.

Linha de referência a ser removida:

wasmAction: "my-wasm-action-resource"

Em seguida, atualizamos a configuração editada do EdgeCacheService.

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

Em seguida, atualize a versão principal do WasmPlugin para uma string vazia "".

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

""

Por fim, siga as etapas de exclusão abaixo em ordem.

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. Liberar espaço no ambiente do laboratório

Depois de concluir o codelab, não se esqueça de liberar os recursos do laboratório. Caso contrário, eles vão continuar sendo executados e gerando custos.

Os comandos a seguir vão excluir o serviço EdgeCache da Media CDN, a configuração do EdgeCache e o plug-in Service Extensions. Siga as etapas de exclusão abaixo na ordem.

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 um dos comandos acima vai pedir que você confirme a exclusão do recurso.

12. Parabéns!

Parabéns, você concluiu o codelab "Service Extensions no Media CDN".

O que vimos

• Como configurar a Media CDN com um bucket do Cloud Storage definido como origem
• Como criar um plug-in de extensão de serviço com autenticação HTTP personalizada e associá-lo ao Media CDN
• Como validar se o plug-in Service Extension está funcionando conforme o esperado
• (opcional) Como gerenciar um plug-in de extensão de serviço, como atualizar, referenciar, reverter e excluir uma versão específica do plug-in

Qual é a próxima etapa?

Confira alguns destes codelabs:

• Adicionar notificações push a um app da Web
• Criar um PWA usando o Workbox

Leia mais

• Carregamento de service worker de alto desempenho
• Estratégias de cache do service worker com base em tipos de solicitação

Documentos de referência

• Documentos do manifesto do app da Web
• Propriedades do manifesto do app da Web (MDN)
• Instalar e adicionar à tela inicial
• Visão geral do service worker
• Ciclo de vida do service worker
• Carregamento de service worker de alto desempenho
• Manual para uso off-line