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 o desempenho do usuário armazenando em cache o conteúdo acessado com frequência mais perto dos usuários finais, encerrando conexões mais próximas aos clientes, reutilizando conexões à origem e pela adoção de personalizações e protocolos de rede modernos.

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

As extensões de serviço do Media CDN, às vezes chamadas de programação de borda, permitem que você execute seu próprio código na borda para personalizar o comportamento do Media CDN. Isso desbloqueia casos de uso adicionais, como a normalização de chaves de cache, autenticação de token personalizada e revogação de tokens, campos de registro personalizados adicionais, testes A/B e página de erro personalizada.

O que você vai criar

Neste codelab, vamos analisar as etapas para implantar um ambiente de entrega de CDN ativado para o Edge Compute com Media CDN (CDN) + Extensões de serviço (programabilidade no Edge) + Cloud Storage (origem de CDN).

O que você vai aprender

• Como configurar o 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 da extensão de serviço está funcionando como 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

• Rede básica e conhecimento de HTTP
• Conhecimento básico de linha de comando do Unix/Linux

2. Antes de começar

Solicitação de lista de permissões do Media CDN e Lista de permissões de extensões de serviço

Cuidado: confira se o projeto está na lista de permissões do Media CDN e das extensões de serviço do Media CDN. Você não vai conseguir concluir este laboratório se o projeto não estiver na lista de permissões.

Antes de começar, confira se o projeto foi adicionado à lista de permissões da visualização particular do Media CDN e das extensões de serviço do Media CDN.

• Para solicitar acesso ao Media CDN e às extensões de serviço do Media CDN, entre em contato com a Equipe de Contas do Google para criar uma solicitação de acesso em seu nome ao Media CDN e às extensões de serviço.

Observações: se você faz parte do Google e quer testar as extensões de serviço com o Media CDN, entre em contato com os gerentes de projeto do Media CDN e das extensões de serviço 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

Papéis do IAM e Acesso

As permissões do Identity and Access Management (IAM) necessárias para criar recursos do 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

Ativar CDN de mídia e APIs de extensões de serviço usando 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 do Media CDN pode se originar de locais como um bucket do Cloud Storage, um local de armazenamento de terceiros ou qualquer endpoint HTTP(HTTPS) público acessível.

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, usaremos a variável de ambiente $PROJECT_ID como parte do nome do bucket.

Usaremos 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 forma:

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. faça upload de um objeto de teste no bucket do Cloud Storage

Agora faremos upload de um objeto no bucket do Cloud Storage.

1. Criar um arquivo no Cloud Shell e fazer upload dele no bucket usando a gsutil

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

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

Observações:o Media CDN oferece suporte a buckets particulares como origem. Para permitir que o Media CDN acesse o conteúdo de um bucket particular do Cloud Storage, configure o IAM para conceder acesso de objectViewer à conta de serviço do Media CDN.

A conta de serviço tem o seguinte formato:

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

2. Conceder ao Media CDN acesso 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 do Media CDN.

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

• EdgeCacheService, responsável pela configuração do 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 para qualquer origem baseada em HTTP, bem como condições de repetição quando o conteúdo não estiver disponível ou acessível.

Configurar uma origem de armazenamento em cache próximo dos usuários finais

Agora vamos criar uma origem que aponte 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. Digite "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 Google Cloud Storage".
7. Procure 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 seu projeto na página "Origens".

Configurar um serviço de armazenamento em cache de borda

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 seu serviço, como "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 depois clique em "Concluído".
10. Selecione Buscar de uma origem em "Ação principal" e escolha a origem que você configurou na lista suspensa.

11. Clique em CONFIGURAÇÕES AVANÇADAS para ampliar as opções.
12. Na ação "Rota", clique em ADICIONAR UM ITEM. Em seguida, faça o seguinte:
13. Em Tipo, selecione "Política de CDN".
14. Para o modo Cache, selecione "Forçar todo cache".
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" da lista de serviços do projeto.

Recuperar o endereço IP MediaCDN e testar

1. No console do Google Cloud, acesse a página Media CDN.
2. Acessar o 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 produz uma saída semelhante a esta:

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

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

7. Configurar o Artifact Registry para extensões de serviço

Antes de criar uma extensão de serviço, precisamos configurar o Artifact Registry. O Artifact Registry é o gerenciador universal de pacotes 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 implantação do Media CDN.

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

Usaremos 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

Também é possível criar um repositório usando a GUI da seguinte forma:

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. ou seja, "service-extension-$PROJECT_ID".
4. No formato Docker, Modo: "Padrão", "Tipo de local": "Região" e escolha "us-central1 (Iowa)".
5. Clique no botão CRIAR.

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

Depois que o recurso do repositório for criado, execute o seguinte comando no Cloud Shell para configurar seu cliente Docker do Cloud Shell para enviar e extrair 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 extensões de serviço 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 (link em inglês).

Neste exemplo, criaremos 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 gerará uma resposta HTTP 403 Forbidden.

Um resumo rápido sobre as extensões de serviço: há três recursos principais: WasmAction, WasmPlugin e WasmPluginVersion.

• Um recurso WasmAction é o que é anexado ao EdgeCacheService para o Media CDN. Um WasmAction faz referência a um recurso do 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 plug-ins proxy-Wasm, você cria diferentes WasmPluginVersions.

Confira 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 do Rust seguindo as instruções em https://www.rust-lang.org/tools/install.

Cuidado: siga as instruções do prompt para instalar o conjunto de ferramentas do Rust.

Se você receber a mensagem "-bash: rustup: command not found" erro 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 ao Wasm ao conjunto de ferramentas do Rust executando o seguinte comando:

rustup target add wasm32-wasi

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

cargo new --lib my-wasm-plugin

Saída:

Created library `my-wasm-plugin` package

4. Digite o diretório my-wasm-plugin. Você verá 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. Após as edições, o arquivo Cargo.toml ficará 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 o conteúdo completo do arquivo sample_code para o arquivo lib.rs no diretório src do Cloud Shell.

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

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

8. Após as edições, o arquivo lib.rs ficará 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 criamos nosso código Proxy-Wasm no arquivo lib.rs , podemos criar nosso plug-in Proxy-Wasm.

cargo build --release --target wasm32-wasi

Depois que o build for concluído, você verá uma mensagem semelhante a esta:

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

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

ls ./target

O resultado será exibido abaixo:

CACHEDIR.TAG release wasm32-wasi

Publicar um plug-in Proxy-Wasm no Artifact Registry

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

Primeiro, empacotamos os plug-ins 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 .

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

(Somente processadores que não sã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. Depois, publique ou envie por push seu plug-in Proxy-Wasm para o Artifact Registry. Vamos marcar a imagem de contêiner com a tag "prod" tag.

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

O nome completo de uma imagem 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 tag "prod" imagem de contêiner ao 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

Cuidado: verifique se você configurou a gcloud como auxiliar de credenciais para o domínio do Artifact Registry associado ao local do repositório.

Se você estiver recebendo "permissão negada" erro ao enviar o contêiner para o Artifact Registry, volte para Configurar o Artifact Registry para extensões de serviço 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ê verá uma resposta 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 Proxy-Wasm à implantação do Media CDN

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

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

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

Aguarde até ver a mensagem de conclusão antes de prosseguir para as próximas etapas.

1. Primeiro, criamos um recurso Wasm-plugin para o 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 à imagem do contêiner no repositório do Artifact Registry. Você vai ver uma resposta 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

Verifique também se o recurso WasmAction foi associado ao plug-in Proxy-Wasm. Você verá uma resposta 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 Media CDN EdgeCacheService:

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

6. Depois, abra o arquivo my-service.yaml e adicione uma wasmAction à 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 ficará mais ou menos 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 Proxy-Wasm no arquivo my-service-with-wasm.yaml.

Cuidado: se você encontrar erros de validação da configuração ao importar o arquivo yaml editado para a API de serviços de armazenamento em cache próximo dos usuários finais, verifique o arquivo yaml e confira se a linha wasmAction foi adicionada à seção routeAction. Use apenas espaços para recuo. As tabulações não são aceitas pelo YAML.

9. Por fim, importamos a configuração atualizada do 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 de extensões de serviço 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 alteração seja propagada em toda a rede MediaCDN. Enquanto isso, talvez você não veja o erro HTTP 403. Continue tentando até que o erro 403 seja retornado.

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

O comando produz 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 do secret

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

O comando produz uma saída semelhante a esta:

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

10. Opcional: gerenciar plug-ins Proxy-Wasm

Como atualizar um plug-in Proxy-Wasm

À medida que você fizer melhorias ou adicionar novas funcionalidades aos plug-ins Proxy-Wasm, precisará implantar os plug-ins atualizados no Media CDN. Veja abaixo as etapas para implantar uma versão atualizada de um plug-in.

Como exemplo, você pode atualizar o código do plug-in de amostra para avaliar o cabeçalho "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, precisamos criar um novo WasmPluginVersion e atualizar a versão -main-plug-in para fazer referência à 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

Você atualizou a versão da imagem do contêiner que será importada do Artifact Registry e ativada na implantação do Media CDN.

Como reverter para uma versão anterior

Para reverter para uma versão anterior de um plug-in, você pode atualizar o recurso do plug-in Wasm para fazer referência a 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 resposta:

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ê verá esta saída:

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

Como o Media CDN salva o resumo da imagem do Docker sempre que um novo recurso de plug-in Wasm é criado, a reversão usa a versão do código 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", essa é a versão com 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"

Como excluir um WasmAction e WasmPlugin

Para excluir um WasmAction, um WasmPlugin e os WasmPluginVersions associados, siga estas etapas.

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

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, execute 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. Limpar o ambiente do laboratório

Após concluir o CodeLab, não se esqueça de limpar os recursos do laboratório, caso contrário, eles continuarão em execução e acumulando custos.

Os comandos a seguir vão excluir o serviço EdgeCache do Media CDN, a configuração do EdgeCache e o plug-in de extensões de serviço. Siga as etapas de exclusão abaixo em 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

Todos os comandos acima precisam confirmar a exclusão do recurso.

12. Parabéns!

Parabéns, você concluiu o codelab "Extensões de serviço no Media CDN".

O que vimos

• Como configurar o 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 da extensão de serviço está funcionando como 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:

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

Leia mais

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

Documentos de referência

• Documentação do manifesto de app da Web
• Propriedades do manifesto do app da Web (MDN, na sigla em inglês)
• Instalar e Adicionar à tela inicial
• Visão geral do service worker
• Ciclo de vida do service worker
• Carregamento de alto desempenho do service worker
• Manual off-line