1. 概览
本系列 Codelab（自定进度的实操教程）旨在指导 Google App Engine（标准版）开发者完成一系列迁移，从而对应用进行现代化改造。完成此操作后，用户可以通过将其显式容器化以支持 Cloud Run，App Engine 的 Google Cloud 容器托管姊妹服务以及其他容器托管服务，从而使其应用更具可移植性。
本教程介绍了如何使用 Docker 的替代方案 Cloud Buildpack 将 App Engine 应用容器化，以便部署到 Cloud Run 全代管式服务。Cloud Buildpack 能够将您的应用容器化，而无需管理 Dockerfile 文件，甚至不需要任何关于 Docker 的知识。
此 Codelab 面向 Python 2 App Engine 开发者，他们已将应用从原始内置服务迁移到 Python 3，现在正寻求在容器中运行这些应用。此 Codelab 将从已完成的模块 2 或模块 3 Python 3 应用开始。
您将了解如何
- 使用 Cloud Buildpack 将应用容器化
- 将容器映像部署到 Cloud Run
所需条件
- 符合以下条件的 Google Cloud Platform 项目：
- 基本 Python 技能
- 常用 Linux 命令的实践知识
- 具备开发和部署 App Engine 应用的基础知识
- 建议您先完成第 2 单元或第 3 单元 Codelab 中的任意一个（或全部完成），包括将它们移植到 Python 3 中，然后再开始学习此 Codelab（第 5 单元）。
- 一个可正常运行的 Python 3 App Engine 应用，可进行容器化
调查问卷
如何使用此 Codelab？
<ph type="x-smartling-placeholder">2. 背景
PaaS 系统（例如 App Engine 和 Cloud Functions）为您的团队和应用提供了许多便利。例如，这些无服务器平台，可让 SysAdmin/Devops 重点打造解决方案。您的应用可根据需要自动扩缩，使用按用量计费的结算方式有助于缩减至零，并使用多种常见的开发语言。
不过，容器的灵活性也具有吸引力，能够选择任何语言、任何库、任何二进制文件。Google Cloud Run 的宗旨就是为用户提供两全其美的体验、无服务器的便利性以及容器的灵活性。
了解如何使用 Cloud Run 不在本 Codelab 的范围之内，而是在 Cloud Run 文档中介绍。这里的目标是让您知道如何为 Cloud Run（或其他服务）容器化 App Engine 应用。在继续前进之前，您需要了解一些事项，主要是您的用户体验会略有不同，因为您将不再使用应用代码进行部署，因此用户体验会稍低一些。
相反，您需要学习一些有关容器的知识，例如如何构建和部署它们。您还可以决定要在容器映像中放入什么，包括网络服务器，因为您将不再使用 App Engine 的网络服务器。如果您不想遵循此路径，那么将应用保持在 App Engine 上并不是一个坏选择。
在本教程中，您将学习如何容器化应用、移除 App Engine 配置文件、管理网络服务器，包括如何启动应用。
此迁移具有以下步骤：
- 设置/准备工作
- 容器化应用
- 替换配置文件
- 修改应用文件
3. 设置/准备工作
在开始学习本教程的主要部分之前，让我们设置项目、获取代码，然后部署基准应用，以便我们知道我们从工作代码开始。
1.设置项目
如果您完成了模块 2 或模块 3 的 Codelab，我们建议重复使用同一项目（和代码）。或者，您可以创建一个全新的项目或重复使用另一个现有项目。确保该项目具有有效的结算账号，并且已启用 App Engine（应用）。
2. 获取基准示例应用
此 Codelab 的前提条件之一是拥有一个可正常运行的模块 2 或 3 示例应用。如果您还没有 Google 账号，我们建议您先学完任一教程（上文中的链接），然后再继续前往此页面。或者，如果您已经熟悉其内容，则可以先从下面获取其代码文件夹之一。
无论您是使用自己的还是我们的，本教程都从这里开始。此 Codelab 会逐步引导您完成迁移，在您完成迁移后，迁移内容应该与第 5 单元的“FINISH 代码库”文件夹中的内容大体一致。
START 文件（您自己的或我们的）目录应如下所示：
$ ls
README.md main.py templates
app.yaml requirements.txt
3. （重新）部署基准应用
现在需要执行的其余准备工作步骤：
- 重新熟悉
gcloud命令行工具 - 使用
gcloud app deploy重新部署示例应用 - 确认应用在 App Engine 上运行没有任何问题
成功执行完这些步骤后，您就可以对其进行容器化。
4. 将应用容器化
Docker 是当今行业的标准容器化平台。如前所述，使用它的一个挑战是，它需要花费精力来构建一个高效的 Dockerfile，即决定容器映像构建方式的配置文件。另一方面，Buildpack 几乎不需要费力，因为它使用自省来确定应用的依赖项，让 Buildpack 容器尽可能高效地处理你的应用。
如果您希望跳过了解 Docker 这一过程，并且希望将您的 App Engine 应用容器化，使其能够在 Cloud Run 或任何其他容器托管平台上运行，那么您来对地方了。如果您有兴趣了解如何使用 Docker 进行应用容器化，可以在完成本单元后完成第 4 单元 Codelab。它与本示例相同，但使用 Docker 让您更深入地了解如何管理容器映像。
迁移步骤包括替换 App Engine 配置文件以及指定应如何启动应用。下表总结了每种平台类型所需的配置文件。将 App Engine 列与 Buildpack 列（以及可选的 Docker 列）进行比较：
说明 | App Engine | Docker | Buildpack |
常规配置 |
|
| ( |
第三方库 |
|
|
|
第三方配置 |
| （不适用） | （不适用） |
启动 | （不适用）或 |
|
|
忽略文件 |
|
|
|
将您的应用容器化后，就可以将其部署到 Cloud Run。其他 Google Cloud 容器平台选项包括 Compute Engine、GKE 和 Anthos。
常规配置
App Engine 会自动启动您的应用，但 Cloud Run 不会自动启动。Procfile 充当与 app.yaml entrypoint 指令类似的角色。对于我们的示例应用，Procfile 将执行 python main.py 以启动 Flask 开发服务器。如果需要，您还可以使用生产 Web 服务器，例如 gunicorn；如果这样做，请务必将其添加到 requirements.txt。如需详细了解如何使用 Buildpack 从源代码进行部署，请参阅此 Cloud Run 文档页面。
您只需将 app.yaml entrypoint 指令移到 Procfile 中。如果您没有 Flask 开发服务器，请暂时使用，因为这只是一个示例测试应用，以便用户熟悉此迁移。您的应用将是一个您最了解的特定启动命令。在后台，Cloud Run 服务会创建一个看起来/行为更像 app.yaml 的 service.yaml。您可以访问如下所示的链接，查看自动生成的 service.yaml，但该链接适用于您的服务 SVC_NAME 和 REGION：https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view。
第三方库
requirements.txt 文件无需更改；Flask 应与 Datastore 客户端库（Cloud Datastore 或 Cloud NDB）一起存在。如果您希望使用其他兼容 WSGI 的 HTTP 服务器（例如 Gunicorn，编写文档时的最新版本为 20.0.4），请将 gunicorn==20.0.4 添加到 requirements.txt。
第三方配置
Buildpack 不支持 Python 2，所以我们在这里不做讨论。在 Cloud Run 上的容器中运行的 Python 3 应用与 Python 3 App Engine 应用类似，因为第三方库必须在 requirements.txt 中指定。
启动
Python 3 用户可以选择在其 handlers 部分将其 app.yaml 文件转换为具有 entrypoint 而不是 script: auto 指令。如果您在 Python 3 app.yaml 中使用 entrypoint，它将看起来像这样：
runtime: python38
entrypoint: python main.py
entrypoint 指令用于告知 App Engine 如何启动服务器。您几乎可以将其直接移动到 Procfile 中。总结入口点指令在两个平台之间的位置：这直接转化为以下内容：还显示了 Docker 等效项作为参考：
- Buildpack：
Procfile中的行：web: python main.py - Docker：
Dockerfile中的行：ENTRYPOINT ["python", "main.py"]
在测试和预演阶段，你可以轻松地从 Python 运行 Flask 的开发服务器（如上所述），但开发者可以选择用于生产环境的功能更强大的功能，例如使用 gunicorn 的 Cloud Run 快速入门示例。
应用文件
所有模块 2 或模块 3 应用均与 Python 2-3 兼容，这意味着 main.py 的核心组件没有更改；我们只添加了几行启动代码。在 main.py 底部添加一行代码以启动开发服务器，因为 Cloud Run 需要打开端口 8080，以便它可以调用您的应用：
if __name__ == '__main__':
import os
app.run(debug=True, threaded=True, host='0.0.0.0',
port=int(os.environ.get('PORT', 8080)))
5. 构建和部署
将 App Engine 配置替换为 Buildpack 并完成源文件更新后，您便可以在 Cloud Run 上运行该配置了。在此之前，我们先简要讨论服务。
服务与应用
虽然 App Engine 最初是为托管应用而创建的，但它还是一个托管由微服务集合组成的 Web 服务或应用的平台。在 Cloud Run 中，一切都是服务，无论是实际服务还是具有 Web 界面的应用，因此请考虑将其用作服务的部署而不是应用。
除非您的 App Engine 应用由多项服务组成，否则您在部署应用时无需进行任何命名。但在 Cloud Run 中，您需要指定服务名称，而 App Engine 的 appspot.com 网域则提供其项目 ID，例如https://PROJECT_ID.appspot.com，也可以是地区 ID 缩写，例如http://PROJECT_ID.REGION_ID.r.appspot.com。
但是，Cloud Run 服务的域名具有服务名称、区域 ID 缩写和哈希值，而非项目 ID，例如 https://SVC_NAME-HASH-REG_ABBR.a.run.app。最重要的是，开始考虑服务名称！
部署服务
执行以下命令以构建您的容器映像并部署到 Cloud Run。出现提示时，选择您的区域并允许未经身份验证的连接，以方便测试并选择适当的区域，其中 SVC_NAME 是要部署的服务的名称。
$ gcloud run deploy SVC_NAME --source . Please choose a target platform: [1] Cloud Run (fully managed) [2] Cloud Run for Anthos deployed on Google Cloud [3] Cloud Run for Anthos deployed on VMware [4] cancel Please enter your numeric choice: 1 To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`. Please specify a region: [1] asia-east1 [2] asia-east2 [3] asia-northeast1 [4] asia-northeast2 [5] asia-northeast3 [6] asia-south1 [7] asia-southeast1 [8] asia-southeast2 [9] australia-southeast1 [10] europe-north1 [11] europe-west1 [12] europe-west2 [13] europe-west3 [14] europe-west4 [15] europe-west6 [16] northamerica-northeast1 [17] southamerica-east1 [18] us-central1 [19] us-east1 [20] us-east4 [21] us-west1 [22] us-west2 [23] us-west3 [24] us-west4 [25] cancel Please enter your numeric choice: <select your numeric region choice> To make this the default region, run `gcloud config set run/region REGION`. Allow unauthenticated invocations to [SVC_NAME] (y/N)? y Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION] ✓ Building and deploying... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM]. ✓ Creating Revision... ✓ Routing traffic... Done. Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic. Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app
请使用浏览器访问指定的网址，确认部署是否成功！
如 gcloud 命令所示，用户可以设置各种默认设置来减少输出和互动性，如上所示。例如，为了避免所有交互，您可以改用以下单行式部署命令：
$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated
如果您使用此菜单，请务必选择相同的服务名称 SVC_NAME 和所需的 REGION 名称，而不是像上面以交互方式执行的操作那样的编入索引的菜单选项。
6. 摘要/清理
确认应用在 Cloud Run 上和在 App Engine 上一样。如果您跳过本系列，但未执行任何上述 Codelab，则应用本身不会更改；它会记录对主网页 (/) 的所有访问，在您访问过该网站后，将如下所示：
您的代码现在应与 Module 5 repo folder 中的内容一致。恭喜您完成本单元 5 Codelab。
可选：清理
何不准备好清理，以避免在进入下一个迁移 Codelab 时继续计费？由于您目前使用的是其他产品，请务必查看 Cloud Run 价格指南。
可选：停用服务
如果您尚未准备好学习下一个教程，请停用您的服务，以避免产生额外费用。当您准备好继续学习下一个 Codelab 时，可以重新启用它。应用停用期间，不会产生任何流量费用。不过，如果您的 Datastore 用量超出免费配额，您需要另外付费，因此请删除足够多的流量，使其不超过该限额。
另一方面，如果您不打算继续迁移，而是想彻底删除所有内容，则可以删除服务或彻底关停项目。
后续步骤
恭喜，您已将应用容器化，本教程到这里就结束了！接下来，您将在第 4 单元 Codelab（链接如下）中了解如何使用 Docker 执行相同的操作，或完成其他 App Engine 迁移：
- 第 4 单元：迁移到 Cloud Run with Docker
- 使用 Docker 将应用容器化，以便在 Cloud Run 上运行
- 让您可以继续使用 Python 2
- 模块 7：App Engine 推送任务队列（如果您使用 [推送] 任务队列，此为必需参数）
- 向模块 1 应用添加了 App Engine
taskqueue推送任务 - 在第 8 单元中，帮助用户做好迁移到 Cloud Tasks 的准备
- 向模块 1 应用添加了 App Engine
- 模块 3：
- 对从 Cloud NDB 到 Cloud Datastore 的 Datastore 访问进行现代化改造
- 这是用于 Python 3 App Engine 应用和非 App Engine 应用的库
- 模块 6：迁移到 Cloud Firestore
- 迁移到 Cloud Firestore 以使用 Firebase 功能
- 虽然 Cloud Firestore 支持 Python 2，但此 Codelab 仅在 Python 3 中提供。
7. 其他资源
App Engine 迁移模块 Codelab 问题/反馈
如果您在此 Codelab 中发现任何问题，请先搜索您的问题，然后再提交。用于搜索和创建新问题的链接：
迁移时可参考的资源
下表列出了模块 2 和 3（开始）以及模块 5 (FINISH) 对应的代码库文件夹的链接。您还可以从所有 App Engine Codelab 迁移的代码库访问这些库，您可以克隆或下载 ZIP 文件。
Codelab | Python 2 | Python 3 |
（代码） | ||
（代码） | ||
模块 5 | （不适用） |
App Engine 和 Cloud Run 资源
以下是有关此特定迁移的其他资源：