本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
基于源代码的 App Runner 服务
您可以使用基于两种根本不同的服务源 AWS App Runner 来创建和管理服务：源代码和源图像。无论源类型如何，App Runner 都会负责启动、运行、扩展和负载平衡您的服务。您可以使用 App Runner 的 CI/CD 功能来跟踪源图像或代码的更改。当 App Runner 发现更改时，它会自动构建（对于源代码）并将新版本部署到您的 App Runner 服务。
本章讨论基于源代码的服务。有关基于源图像的服务的信息，请参阅基于源图像的 App Runner 服务。
源代码是 App Runner 为您构建和部署的应用程序代码。将 App Runner 指向代码存储库中的源目录，然后选择与编程平台版本相对应的合适运行时。App Runner 根据运行时的基本映像和您的应用程序代码构建映像。然后，它会启动一个基于此镜像运行容器的服务。
App Runner 提供了便捷的特定于平台的托管运行时。这些运行时中的每一个都根据你的源代码构建一个容器镜像，并在你的镜像中添加语言运行时依赖关系。您无需提供容器配置和构建说明，例如 Dockerfile。
本章的副主题讨论 App Runner 支持的各种平台，即为不同的编程环境和版本提供托管运行时的托管平台。
主题
源代码存储库提供者
App Runner 通过从源代码存储库中读取源代码来部署您的源代码。App Runner 支持两个源代码存储库提供程序：GitHub
从您的源代码存储库提供商部署
要将源代码从源代码存储库部署到 App Runner 服务，App Runner 需要与该服务建立连接。使用 App Runner 控制台创建服务时，您需要提供连接详细信息和源目录，供 App Runner 部署源代码。
连接
作为服务创建过程的一部分，您需要提供连接详细信息。当你使用 App Runner API 或时 AWS CLI，连接是一种单独的资源。首先，使用 CreateConnectionAPI 操作创建连接。然后，在创建服务期间使用 CreateServiceAPI 操作提供连接的 ARN。
源目录
创建服务时，还会提供源目录。默认情况下，App Runner 使用存储库的根目录作为源目录。源目录是源代码存储库中存储应用程序源代码和配置文件的位置。生成和启动命令也从源目录执行。当您使用 App Runner API 或创建或更新服务时，您需要在CreateService和 UpdateServiceAPI 操作中提供源目录。 AWS CLI 有关更多信息，请参阅下面的源目录部分。
有关创建 App Runner 服务的更多信息，请参阅创建 App Runner 服务。有关 App Runner 连接的更多信息，请参阅管理 App Runner 连接。
源目录
创建 App Runner 服务时，您可以提供源目录以及存储库和分支。将 “源目录” 字段的值设置为存储应用程序源代码和配置文件的存储库目录路径。App Runner 从您提供的源目录路径执行生成和启动命令。
将源目录路径的值输入为从根存储库目录开始的绝对路径。如果未指定值，则默认为存储库顶级目录，也称为存储库根目录。
除了顶级存储库目录之外，您还可以选择提供不同的源目录路径。这支持 monorepo 存储库架构，这意味着多个应用程序的源代码存储在一个存储库中。要通过单个 monorepo 创建和支持多个 App Runner 服务，请在创建每个服务时指定不同的源目录。
注意
如果您为多个 App Runner 服务指定相同的源目录，则这两个服务将分别部署和运行。
如果您选择使用apprunner.yaml配置文件来定义服务参数，请将其放在存储库的源目录文件夹中。
如果 “部署” 触发器选项设置为 “自动”，则您在源目录中提交的更改将触发自动部署。 只有源目录路径中的更改才会触发自动部署。重要的是要了解源目录的位置如何影响自动部署的范围。有关更多信息，请参阅中的自动部署部署方法。
注意
如果您的 App Runner 服务使用 PHP 托管的运行时，并且您想要指定默认根存储库以外的源目录，那么使用正确的 PHP 运行时版本非常重要。有关更多信息，请参阅 使用 PHP 平台。
应用程序运行器托管平台
App Runner 托管平台为各种编程环境提供托管运行时。每个托管运行时都可以根据编程语言或运行时环境的版本轻松构建和运行容器。使用托管运行时时，App Runner 从托管运行时映像开始。此镜像基于 Amazon Linux Docker 镜像
在使用 App Runner 控制台或 CreateServiceAPI 操作创建服务时，可以为 App Runner 服务指定运行时。您也可以将运行时指定为源代码的一部分。在包含在代码存储库中的 A pp Runner 配置文件中使用runtime关键字。托管运行时的命名约定是。 <language-name><major-version>
每次部署或服务更新时，App Runner 都会将服务的运行时更新到最新版本。如果您的应用程序需要托管运行时的特定版本，则可以使用 App Runner 配置文件中的runtime-version关键字进行指定。您可以锁定到任何级别的版本，包括主要版本或次要版本。App Runner 仅对服务的运行时进行较低级别的更新。
托管运行时版本和 App Runner 版本
App Runner 现在为您的应用程序提供了更新的构建流程。它目前正在为在托管运行时 Python 3.11 和 Node.js 18 上运行的服务调用新版本，上次发布于 2023 年 12 月 29 日。修改后的构建过程更快、更高效。它还会创建占用空间较小的最终映像，其中仅包含运行应用程序所需的源代码、构建工件和运行时。
我们将较新的构建过程称为修订后的 App Runner 版本，将原始构建过程称为最初的 App Runner 版本。为了避免对早期版本的运行时平台进行重大更改，App Runner 仅将修订后的版本应用于特定的运行时版本，通常是新发布的主要版本。
我们在apprunner.yaml配置文件中引入了一个新组件，以使修订后的版本向后兼容，适用于非常具体的用例，还可以更灵活地配置应用程序的构建。这是可选pre-run参数。我们将在以下各节中说明何时使用此参数以及有关构建的其他有用信息。
下表说明了 App Runner 版本的哪个版本适用于特定的托管运行时版本。我们将继续更新此文档，让您随时了解我们当前的运行时间。
重要
Python 3.11 — 我们对使用 Python 3.11 托管运行时的服务的构建配置提出了具体建议。有关更多信息，请参阅 Python 平台主题特定运行时版本的标注中的。
有关 App Runner 版本和迁移的更多信息
当您将应用程序迁移到使用修订版本的较新运行时时，可能需要稍微修改构建配置。
为了提供迁移注意事项的背景信息，我们将首先描述原始 App Runner 版本和修订版的高级流程。接下来我们将有一节介绍您的服务的特定属性，这些属性可能需要一些配置更新。
最初的 App Runner 版本
最初的 App Runner 应用程序构建过程利用了该 AWS CodeBuild 服务。初始步骤基于该 CodeBuild 服务精心策划的图像。接下来是 Docker 构建流程，该过程使用适用的 App Runner 托管运行时映像作为基础映像。
一般步骤如下：
-
在 CodeBuild精心策划的图像中运行
pre-build命令。这些
pre-build命令是可选的。它们只能在apprunner.yaml配置文件中指定。 -
使用在 CodeBuild 上一步中的同一张图像上运行
build命令。这些
build命令是必需的。它们可以在 App Runner 控制台、App Runner API 或apprunner.yaml配置文件中指定。 -
运行 Docker 版本，根据您的特定平台和运行时版本的 App Runner 托管运行时映像生成映像。
-
从我们在步骤 2 中生成的图像中复制该
/app目录。目标是基于我们在步骤 3 中生成的 App Runner 托管运行时映像的图像。 -
在生成的 App Runner 托管运行时映像上再次运行
build命令。我们再次运行构建命令，从步骤 4 中复制到的/app目录中的源代码生成构建工件。稍后，App Runner 将部署此映像，以便在容器中运行您的 Web 服务。这些
build命令是必需的。它们可以在 App Runner 控制台、App Runner API 或apprunner.yaml配置文件中指定。 -
运行步骤 2 中 CodeBuild 镜像中的
post-build命令。这些
post-build命令是可选的。它们只能在apprunner.yaml配置文件中指定。
构建完成后，App Runner 会部署步骤 5 中生成的 App Runner 托管运行时映像，以便在容器中运行您的 Web 服务。
修订后的 App Runner 版本
修订后的构建过程比上一节中描述的原始构建过程更快、更高效。它消除了先前版本版本中出现的生成命令的重复。它还会创建占用空间较小的最终映像，其中仅包含运行应用程序所需的源代码、构建工件和运行时。
此构建过程使用 Docker 多阶段构建。一般处理步骤如下：
-
构建阶段 — 启动 docker 构建过程，该过程在 App Runner 构建映像之上执行
pre-build和build命令。-
将应用程序源代码复制到
/app目录中。注意
在 Docker 构建的每个阶段，此
/app目录都被指定为工作目录。 -
运行
pre-build命令。这些
pre-build命令是可选的。它们只能在apprunner.yaml配置文件中指定。 -
运行
build命令。这些
build命令是必需的。它们可以在 App Runner 控制台、App Runner API 或apprunner.yaml配置文件中指定。
-
-
打包阶段 — 生成最终的客户容器镜像，该镜像也基于 App Runner 运行映像。
-
将前一个生成阶段的
/app目录复制到新的运行映像。这包括您的应用程序源代码和前一阶段的构建工件。 -
运行
pre-run命令。如果您需要使用build命令修改/app目录之外的运行时映像，请将相同或必需的命令添加到apprunner.yaml配置文件的这一段。这是为支持修订后的 App Runner 版本而引入的新参数。
这些
pre-run命令是可选的。它们只能在apprunner.yaml配置文件中指定。注意
-
只有修订后的版本支持这些
pre-run命令。如果您的服务使用的是使用原始版本的运行时版本，请不要将它们添加到配置文件中。 -
如果您不需要使用
build命令修改/app目录之外的任何内容，则无需指定pre-run命令。
-
-
-
生成后阶段 — 此阶段从 “构建” 阶段恢复并运行
post-build命令。-
在
/app目录中运行post-build命令。这些
post-build命令是可选的。它们只能在apprunner.yaml配置文件中指定。
-
构建完成后，App Runner 会部署运行映像，以便在容器中运行您的 Web 服务。
注意
配置生成过程apprunner.yaml时，不要被误导到的 “运行” 部分中的env条目。尽管步骤 2 (b) 中引用的pre-run命令参数位于 “运行” 部分，但不要使用 “运行” 部分中的env参数来配置构建。这些pre-run命令仅引用配置文件的 Build 部分中定义的env变量。有关更多信息，请参阅 App Runner 配置文件一章跑步部分中的。
考虑迁移时需要考虑的服务要求
如果您的应用程序环境具有这两个要求中的任何一个，则需要通过添加pre-run命令来修改构建配置。
如果你需要使用
build命令修改/app目录之外的任何内容。-
如果您需要运行两次
build命令来创建所需的环境。这是一个非常不寻常的要求。绝大多数版本都不会这样做。
在/app目录之外进行修改
-
修订后的 App Runner 版本假设您的应用程序在
/app目录之外没有依赖关系。 -
您在
apprunner.yaml文件、App Runner API 或 App Runner 控制台中提供的命令必须在/app目录中生成构件。 -
您可以修改
pre-buildbuild、和post-build命令以确保所有构建工件都在/app目录中。 -
如果您的应用程序需要在编译版本中进一步修改为服务生成的映像，则可以在
/app目录之外使用新pre-run命令apprunner.yaml。有关更多信息，请参阅 使用配置文件设置 App Runner 服务选项。
运行build命令两次
-
最初的 App Runner 版本运行
build命令两次，第一次是在步骤 2 中，然后在步骤 5 中再次运行。修订后的 App Runner 版本纠正了这种冗余性，并且只运行一次build命令。如果您的应用程序不寻常地要求build命令运行两次，则修订后的 App Runner 版本提供了使用pre-run参数再次指定和执行相同命令的选项。这样做会保留相同的双重构建行为。
