实践：媒体 CDN 上的 Service Extensions

1. 简介

上次更新日期：2024 年 5 月 1 日

内容分发网络 (CDN) 通过以下方式提高用户性能：将经常访问的内容缓存到更靠近最终用户的位置、在更靠近客户端的位置终止连接、重复使用与源站的连接，以及采用现代网络协议和自定义设置。

媒体 CDN 是 GCP 用于流式传输媒体内容的全球边缘网络，可提供许多内置或“核心”功能。核心功能旨在满足最常见的用例，但您可能还有一些要求无法通过此核心功能集来满足。

Media CDN 的 Service Extensions（有时也称为边缘可编程性）可让您在边缘运行自己的代码，以自定义 Media CDN 的行为。这可解锁更多使用情形，包括规范化缓存键、自定义令牌身份验证和令牌撤消、其他自定义日志字段、A/B 测试和自定义错误页面。

构建内容

在此实验中，我们将逐步介绍如何部署启用边缘计算的 CDN 交付环境，该环境包含 Media CDN (CDN) + Service Extensions（边缘可编程性）+ Cloud Storage（CDN 的来源）。

学习内容

• 如何设置 Media CDN 并将 Cloud Storage 存储分区设置为源站
• 如何创建具有自定义 HTTP 身份验证的 Service Extensions 插件并将其与 Media CDN 相关联
• 如何验证服务扩展插件是否按预期运行
• （可选）如何管理服务扩展插件，例如更新、引用、回滚和删除特定插件版本

所需条件

• 网络组建和管理以及 HTTP 基础知识
• Unix/Linux 命令行基础知识

2. 准备工作

申请加入 Media CDN 许可名单和 Service Extensions 许可名单

注意：请确保您的项目已列入媒体 CDN 和媒体 CDN 的 Service Extensions 的许可名单。如果您的项目未列入许可名单，您将无法完成本实验。

开始之前，您需要确保您的项目已添加到媒体 CDN 和媒体 CDN 的 Service Extensions 的非公开预览版许可名单中。

• 如需同时请求对 Media CDN 和 Media CDN 的 Service Extensions 的访问权限，请联系您的 Google 客户支持团队，让他们代表您为 Media CDN 和 Service Extensions 创建访问权限请求

注意：如果您是 Google 员工，并且想使用 Media CDN 测试 Service Extensions，请与 Media CDN 和 Service Extensions 的产品经理联系，申请访问权限。

3. 设置和要求

启动 Cloud Shell

虽然可以通过笔记本电脑对 Google Cloud 进行远程操作，但在此 Codelab 中，您将使用 Google Cloud Shell，这是一个在云端运行的命令行环境。

在 GCP 控制台中，点击右上角工具栏上的 Cloud Shell 图标：

预配和连接到环境应该只需要片刻时间。完成后，您应该会看到如下内容：

这个虚拟机已加载了您需要的所有开发工具。它提供了一个持久的 5GB 主目录，并且在 Google Cloud 中运行，大大增强了网络性能和身份验证功能。只需一个浏览器，即可完成本实验中的所有工作。

准备工作

IAM 角色和访问权限

创建 Media CDN 和 Artifact Registry 资源所需的 Identity and Access Management (IAM) 权限如下：

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

在 Cloud Shell 中，确保已设置 project_id、project_num、location 和 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

启用 API

通过以下命令启用 Media CDN 和 Service Extensions API

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. 创建 Cloud Storage 存储分区

Media CDN 内容可来自 Cloud Storage 存储分区、第三方存储位置或任何可公开访问的 HTTP(HTTPS) 端点等位置。

在此 Codelab 中，我们将内容存储在 Cloud Storage 存储分区中。

注意：Cloud Storage 存储分区名称必须是全局唯一的。为确保没有冲突，我们将使用 $PROJECT_ID 环境变量作为存储分区名称的一部分。

我们将使用 gsutil mb 命令创建存储分区

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

您也可以使用 GUI 创建 Cloud Storage 存储分区，如下所示：

1. 在 Google Cloud 控制台中，转到 Cloud Storage 页面。
2. 点击创建按钮。
3. 输入存储分区的名称。即“mediacdn-bucket-$PROJECT_ID”。
4. 将其余设置保留为默认值。
5. 点击创建按钮。

5. 将测试对象上传到 Cloud Storage 存储分区

现在，我们将对象上传到 Cloud Storage 存储分区中。

1. 在 Cloud Shell 中创建一个文件，然后使用 gsutil 将其上传到存储分区中

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

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

注意：Media CDN 支持将私密存储分区作为源站。如需允许 Media CDN 访问私有 Cloud Storage 存储分区中的内容，您需要配置 IAM 以向 Media CDN 服务账号授予 objectViewer 访问权限。

该服务账号具有以下格式：

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

2. 向媒体 CDN 授予对存储分区的访问权限

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

6. 配置媒体 CDN

接下来，我们将创建媒体 CDN 配置。

每项 Media CDN 配置都包含两个主要资源：

• EdgeCacheService，负责面向客户端的配置（TLS、IP 地址）、路由、CDN 配置（缓存模式、TTL、签名）和安全政策。
• EdgeCacheOrigin，负责为任何基于 HTTP 的源提供源级配置，以及在内容不可用或无法访问时的重试条件。

配置边缘缓存来源

现在，我们来创建一个指向您刚刚创建的 Cloud Storage 存储分区的来源。

1. 在 Google Cloud 控制台中，前往 Media CDN 页面。
2. 点击来源标签页。
3. 点击创建来源。
4. 输入“cloud-storage-origin”作为边缘缓存来源的名称。
5. 在“来源地址”下：
6. 选择“选择 Google Cloud Storage 存储分区”。
7. 浏览到名为“mediacdn-bucket-$PROJECT_ID”的 Cloud Storage 存储分区。
8. 点击“选择”。
9. 将其余设置保留为默认值。
10. 点击创建来源。

新创建的 EdgeCacheOrigin 资源会显示在“来源”页面上您项目的来源列表中。

配置边缘缓存服务

1. 在 Google Cloud 控制台中，前往 Media CDN 页面。
2. 点击服务标签页。
3. 点击创建服务。
4. 为您的服务输入一个唯一名称（例如“media-cdn”），然后点击“下一步”。

5. 在“路由”部分，点击添加主机规则。
6. 在“主机”字段中输入通配符“*”。

7. 点击添加路由规则。
8. 对于“优先级”，请指定“1”。
9. 点击添加匹配条件，对于“路径匹配”，选择“前缀匹配”作为匹配类型，在“路径匹配”字段中指定“/”，然后点击“完成”。
10. 在“主要操作”下选择从来源提取，然后从下拉列表中选择您配置的来源。

11. 点击高级配置以展开更多配置选项。
12. 在“路由操作”中，点击 ADD AN ITEM。之后，执行以下操作：
13. 对于“类型”，选择“CDN 政策”。
14. 对于“缓存模式”，选择“强制缓存所有内容”。
15. 将其余设置保留为默认值
16. 点击“完成”。
17. 点击保存。

18. 点击创建服务。

新创建的 EdgeCacheService 资源会显示在“服务”页面上，位于项目中的服务列表中。

检索 MediaCDN IP 地址并进行测试

1. 在 Google Cloud 控制台中，前往 Media CDN 页面。
2. 前往媒体 CDN
3. 点击 Services（服务）标签。
4. 对于您的服务，请参阅地址列。

如需测试您的服务是否已正确配置为缓存内容，请使用 curl 命令行工具发出请求并检查响应。

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

该命令应生成类似于以下内容的输出：

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

现在，您已成功创建以 Cloud Storage 为来源的 MediaCDN 部署。

7. 为 Service Extensions 配置 Artifact Registry

在创建 Service Extensions 之前，我们需要配置 Artifact Registry。Artifact Registry 是 Google Cloud 的通用软件包管理器，用于管理构建制品。Service Extension (Proxy-Wasm) 插件已发布到 Artifact Registry。发布到 Artifact Registry 后，Proxy-Wasm 插件即可部署到您的 Media CDN 部署中。

注意：Artifact Registry 代码库名称必须是全局唯一的。为确保没有冲突，我们将使用 $PROJECT_ID 环境变量作为代码库名称的一部分。

我们将使用 gcloud artifacts repositories create 命令创建代码库

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

您也可以使用 GUI 创建代码库，如下所示：

1. 在 Google Cloud 控制台中，转到 Artifact Registry 页面。
2. 点击 + 创建仓库按钮。
3. 输入代码库的名称，例如“service-extension-$PROJECT_ID”。
4. 格式 -“Docker”，模式 -“标准”，位置类型 -“区域”，然后选择“us-central1（爱荷华）”
5. 点击创建按钮。

新创建的 Artifact Registry 仓库资源应显示在“仓库”页面上。

创建代码库资源后，在 Cloud Shell 中运行以下命令，以配置 Cloud Shell Docker 客户端，从而使用此代码库推送和拉取软件包。

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

输出：

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

8. 在 Media CDN 上配置 Service Extensions

现在，我们将演示如何使用 Rust 编程语言编写和构建可部署到媒体 CDN 的服务扩展程序 (Proxy-Wasm) 插件。

在此示例中，我们将创建一个 Proxy-Wasm 插件，用于验证每个 HTTP 请求是否包含值为“secret”的 Authorization 标头。如果请求不包含此标头，插件将生成 HTTP 403 Forbidden 响应。

简要回顾一下服务扩展功能 - 有三种关键资源：WasmAction、WasmPlugin 和 WasmPluginVersion。

• WasmAction 资源会附加到您的 Media CDN EdgeCacheService。WasmAction 引用 WasmPlugin 资源。
• WasmPlugin 资源具有与当前有效 WasmPluginVersion 对应的主版本。
• WasmPluginVersions 会引用 Artifact Registry 中的容器映像。在您更改 proxy-wasm 插件时，系统会创建不同的 WasmPluginVersion。

请参考下图，以便更好地了解这些资源之间的关系。

编写和构建服务扩展程序插件

1. 按照 https://www.rust-lang.org/tools/install 中的说明安装 Rust 工具链。

注意：请务必按照提示说明安装 Rust 工具链。

如果您在运行“rustup”时收到“-bash: rustup: command not found”错误，请尝试运行“source "$HOME/.cargo/env”以重新加载 Cloud Shell 中的 PATH 环境变量。

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

2. 接下来，运行以下命令，向 Rust 工具链添加 Wasm 支持：

rustup target add wasm32-wasi

3. 创建名为 my-wasm-plugin 的 Rust 软件包：

cargo new --lib my-wasm-plugin

输出：

Created library `my-wasm-plugin` package

4. 进入 my-wasm-plugin 目录，您应该会看到一个 Cargo.toml 文件和一个 src 目录。

cd my-wasm-plugin
ls

输出：

Cargo.toml  src

5. 接下来，通过修改 Cargo.toml 文件来配置 Rust 软件包。在 Cargo.toml 文件中的 [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"

6. 修改后，Cargo.toml 文件应大致如下所示：

[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. 下载 sample_code 文件。将 sample_code 文件的全部内容复制到 Cloud Shell 中 src 目录下的 lib.rs 文件中。

注意：lib.rs 文件是源代码所在的位置。源代码应使用 RUST 编程语言编写。如需查看更多示例代码，请参阅 network-actions-recipes。

在此 Codelab 中，我们的代码会验证每个 HTTP 请求是否包含值为“secret”的 Authorization 标头，如果请求不包含此标头，则会生成 HTTP 403 Forbidden 响应。

8. 修改后，lib.rs 文件应大致如下所示：

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. 现在，我们已配置 Cargo.toml 清单文件并在 lib.rs 文件中编写了 Proxy-Wasm 代码，接下来可以构建 Proxy-Wasm 插件了。

cargo build --release --target wasm32-wasi

构建成功完成后，您会看到如下所示的消息：

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

我们还要验证 target 目录并检查文件是否已创建：

ls ./target

您将看到如下所示的输出：

CACHEDIR.TAG release wasm32-wasi

将 Proxy-Wasm 插件发布到 Artifact Registry

现在，我们将把 Proxy-Wasm 插件发布到您之前创建的 Artifact Registry 代码库，以便将其部署到 Media CDN。

我们首先将 Proxy-Wasm 插件打包到容器映像中。

1. 在同一目录 my-wasm-plugin 中创建一个名为 Dockerfile 的文件，其中包含以下内容：

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

2. 接下来，构建容器映像：

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

注意：如果您使用的是 Apple Silicon（基于 ARM 的架构）或任何其他非 x86 处理器，则需要先在 Docker 上启用 WASM 支持 (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads)，然后运行以下命令来构建容器映像。

（仅限非 x86 处理器）接下来，构建容器映像：

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

输出

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

3. 接下来，将 Proxy-Wasm 插件发布或“推送”到 Artifact Registry。我们将使用“prod”标记标记容器映像。

注意：Artifact Registry 使用命名惯例来识别代码库和映像。

代码库中 Docker 映像的全名采用以下格式：

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

现在，我们继续将带有“prod”标记的容器映像推送到代码库。

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

输出：

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

注意：请确保您已将 gcloud 配置为与代码库位置相关联的 Artifact Registry 网域的凭据帮助程序。

如果您在将容器推送到 Artifact Registry 时收到“permission denied”（权限遭拒）错误，请返回为 Service Extensions 配置 Artifact Registry，然后再次运行 gcloud auth 命令。

现在，我们来验证 Proxy-Wasm 插件的容器映像是否已成功推送到 Artifact Registry，您应该会看到类似的输出：

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

输出：

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

将 Proxy-Wasm 插件与媒体 CDN 部署相关联

现在，我们已准备好将 Proxy-Wasm 插件与您的媒体 CDN 部署相关联。

Proxy-Wasm 插件与 EdgeCacheService 资源中的媒体 CDN 路由相关联。

注意：每个 Proxy-Wasm 资源创建过程可能需要一些时间才能完成。

请等待系统显示完成消息，然后再继续执行后续步骤。

1. 首先，我们为 Proxy-Wasm 插件创建一个 Wasm 插件资源。

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

2. 接下来，我们创建一个 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. 接下来，我们为 Proxy-Wasm 插件指定主版本。

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

现在，我们来验证 Proxy-Wasm 插件是否已成功关联到 Artifact Registry 代码库中的容器映像，您应该会看到类似的输出：

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

输出：

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. 接下来，我们创建一个引用 Wasm 插件资源的 WasmAction 资源。

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

我们还要验证 WasmAction 资源是否已成功关联到 Proxy-Wasm 插件，您应该会看到类似如下的输出：

gcloud alpha service-extensions wasm-actions list

输出：

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

5. 现在，我们需要导出 Media CDN EdgeCacheService 的配置：

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

6. 然后，打开 my-service.yaml 文件，并为给定路由的 routeAction 添加 wasmAction，该 wasmAction 会引用之前创建的 WasmPlugin 资源。

wasmAction: "my-wasm-action-resource"

7. 修改后，my-service.yaml 文件应大致如下所示：

...

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. 然后，我们将更新后的配置（包含 Proxy-Wasm 配置）保存到 my-service-with-wasm.yaml 文件中。

注意：如果将修改后的 YAML 文件导入到 Edge-Cache 服务 API 时遇到配置验证错误，请仔细检查该 YAML 文件，并确保 wasmAction 行已添加到 routeAction 部分中。请确保您仅使用空格进行缩进，YAML 不接受制表符。

9. 最后，我们导入生产环境 Media CDN 的更新配置：

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

9. 验证 Media CDN 上的 Service Extensions Proxy-Wasm 插件

如需测试您的服务是否已正确配置为缓存内容，请使用 curl 命令行工具发出请求并检查响应。

注意：更改最长可能需要 10 分钟才能在整个 MediaCDN 网络中生效。在此期间，您可能无法看到 HTTP 403 错误。请继续尝试，直到返回 403 错误。

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

该命令应生成类似于以下内容的输出：

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

现在，再次发出请求，并添加 Authorization 标头，其值为 secret

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

该命令应生成类似于以下内容的输出：

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

10. 可选：管理 Proxy-Wasm 插件

更新 Proxy-Wasm 插件

在改进 Proxy-Wasm 插件或向其中添加新功能时，您需要将更新后的插件部署到媒体 CDN。下面，我们将介绍部署插件更新版本的步骤。

例如，您可以修改代码，如下所示，更新示例插件代码，以根据另一个值评估 Authorization 标头进行身份验证。

首先，使用以下代码更新 src/lib.rs 源文件：

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

接下来，构建、打包并发布更新后的插件：

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

在 Artifact Registry 中更新容器映像后，我们需要创建新的 WasmPluginVersion，然后更新 WasmPlugin 的 –main-version 以引用新版本。

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

现在，您已成功更新要从 Artifact Registry 导入的容器映像版本，并将其实时推送到 Media CDN 部署。

回滚到先前的版本

如需回滚到插件的先前版本，您可以更新 Wasm 插件资源以引用先前版本。

首先，我们列出可用的版本：

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

您应该会看到以下输出：

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

接下来，我们更新 Wasm 插件资源以引用之前的版本“a2a8ce”：

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

操作成功后，您应该会看到以下输出：

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

由于 Media CDN 会在每次创建新的 Wasm 插件资源时保存 Docker 映像的映像摘要，因此回滚将使用上次发布之前运行的代码版本。

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

对于版本“a2a8ce”（即摘要为 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"

删除 WasmAction 和 WasmPlugin

如需删除 WasmAction、WasmPlugin 及关联的 WasmPluginVersion，请按照以下步骤操作。

首先，移除 Media CDN EdgeCacheService 配置中对 WasmAction 的引用。

要移除的参考线：

wasmAction: "my-wasm-action-resource"

然后，我们更新修改后的 EdgeCacheService 配置。

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

接下来，将 WasmPlugin 的 main-version 更新为空字符串 ""。

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

""

最后，按顺序执行以下删除步骤。

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. 清理实验环境

完成本 Codelab 后，请务必清理实验资源，否则这些资源会继续运行并产生费用。

以下命令将删除 Media CDN EdgeCache 服务、EdgeCache 配置和 Service Extensions 插件。请按顺序执行以下删除步骤。

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

上述每个命令都应要求您确认是否要删除资源。

12. 恭喜！

恭喜，您已完成 Media CDN 上的 Service Extensions Codelab！

所学内容

• 如何设置 Media CDN 并将 Cloud Storage 存储分区设置为源站
• 如何创建具有自定义 HTTP 身份验证的 Service Extensions 插件并将其与 Media CDN 相关联
• 如何验证服务扩展插件是否按预期运行
• （可选）如何管理服务扩展插件，例如更新、引用、回滚和删除特定插件版本

后续操作

查看下列 Codelab…

• 向 Web 应用添加推送通知
• 使用 Workbox 构建 PWA

深入阅读

• 高性能 Service Worker 加载
• 基于请求类型的 Service Worker 缓存策略

参考文档

• Web 应用清单文档
• Web 应用清单属性 (MDN)
• 安装并添加到主屏幕
• Service Worker 概览
• Service Worker 生命周期
• 高性能 Service Worker 加载
• 离线实战宝典