亚马逊AWS官方博客
新功能 – Amazon App Runner：几分钟内就可通过代码创建可扩展、安全的 Web 应用程序
容器已成为我打包 Web 应用程序的默认方式。尽管我喜欢容器提供的速度、生产力和一致性，但有一个方面是我在容器开发工作流程中并不欣赏的：在首次部署容器镜像时经历了漫长的流程。
您可能对如下流程印象深刻：设置负载均衡器、配置域、设置 TLS、创建 CI/CD 管道以及部署到容器服务。容器已成为我打包 Web 应用程序的默认方式。尽管我喜欢容器提供的速度、生产力和一致性，但有一个方面是我在容器开发工作流程中并不欣赏的：在首次部署容器镜像时经历了漫长的流程。
多年来，我调整了工作流程，现在有了一个 Amazon Cloud Development Kit 脚手架项目可供使用，但却花了很长时间才进入这个阶段。尽管这个脚手架项目非常适合大型应用程序，但是当我只想部署和缩放单个容器镜像时，它确实让人感觉要完成大量工作。
在 Amazon Web Services中，我们有许多服务可以对容器化应用程序进行精细控制，但许多客户询问 Amazon Web Services是否可以处理其容器环境的配置和操作。他们只想指向现有的代码或容器仓库，让应用程序在云中运行和扩展，而无需配置和管理基础设施服务。
由于客户要求我们打造更简单的工具，因此我们的工程师一直在努力建立您将会喜欢的新服务。
隆重推出 Amazon App Runner
Amazon App Runner 可让您更轻松地将 Web 应用程序和 API 部署到云中，无论使用何种语言编写而成，并且即使以前缺乏部署和管理容器或基础设施经验的团队亦可轻松应对。该服务内置 Amazon Web Services运营和安全最佳实践，并在收到通知的时候自动扩展或缩减，无需担心冷启动。
从源代码部署
App Runner 可以通过连接到源代码或容器注册表来部署您的应用程序。我将首先展示连接到源代码时该工具的工作原理。我在 GitHub 仓库中有一个 Python Web 应用程序。我将 App Runner 连接到此项目，这样就可以看到该工具如何编译我的代码并将其部署到 Amazon Web Services。
在 App Runner 控制台中，我选择创建 App Runner 服务。
对于仓库类型，我选择源代码仓库，然后按照说明将服务连接到我的 GitHub 账户。对于仓库，我选择包含要部署应用程序的仓库。对于分支，我选择主。
对于部署触发器，我选择自动。这意味着，当 App Runner 发现我的源代码有更改时，它会自动构建更新的版本并将其部署到我的 App Runner 服务
我现在可以配置构建。对于运行时，我选择 Python 3。该服务目前支持两种语言：Python 和 Node.js。如果您需要其他语言，则需要使用容器注册表工作流程（稍后将演示）。我还完成了“构建”命令、“启动” 命令和端口字段，如下所示：
我现在为服务命名，然后选择希望容器使用的 CPU 和内存大小。此处的选择将影响我支付的价格。由于我的应用程序需要的 CPU 或内存量非常少，因此选择 1 个 vCPU 和 2 GB 来降低成本。我还可以在此提供任何环境变量来配置我的应用程序。
控制台可让我为服务自定义多个不同的设置。
我可以配置自动扩展行为。默认情况下，我的服务将拥有容器镜像的一个实例，但是如果该服务收到的并发请求超过 80 个，它将扩展到多个实例。您可以选择指定最大实例数量以控制成本。
我可以展开运行状况检查，并设置 App Runner 向其发送运行状况检查请求的路径。如果我没有设置路径，App Runner 将尝试建立 TCP 连接以验证运行状况。默认情况下，如果 App Runner 连续收到五次运行状况检查失败，它将认为实例运行状况不佳并将其替换。
我可以展开安全性，然后选择要由实例使用的 IAM 角色。这可让容器有权与其他 Amazon Web Services服务进行通信。App Runner 会加密我的应用程序源镜像或源 bundle 的所有存储副本。如果我提供客户管理的密钥 (CMK)，App Runner 会使用它来加密我的源代码。如果我没有提供一个密钥，App Runner 将改为使用 Amazon Web Services管理的密钥。
最后，我检查服务的配置，然后选择创建和部署。
几分钟后，我的应用程序顺利部署，服务提供了一个指向已部署 Web 应用程序的 URL。App Runner 确保对 https 进行了配置，这样我就可以与团队中的人员共享此 URL 来测试应用程序，而不会让他们收到浏览器安全警告。我不需要在容器镜像中实现对 HTTPS 安全流量的处理，App Runner 会完成所有配置。
我现在想要设置一个自定义域。该服务可让我在不离开控制台的情况下进行配置。我打开服务，选择自定义域选项卡，然后选择添加域。
在域名中，我输入要用于我的应用程序的域，然后选择保存。
在我证明对此域的所有权后，该应用程序将在我的自定义 URL 中提供。接下来，我将向您展示 App Runner 如何处理容器镜像。
从容器镜像部署
我创建了一个 .NET Web 应用程序，将其构建为容器镜像，然后将此容器镜像推送到 Amazon ECR Public（我们的公共容器注册表）。
如同第一个演示中所完成的工作，我选择了创建服务。在源代码和部署中，对于仓库类型，我选择容器注册表。对于提供商，我选择 Amazon ECR Public。在容器镜像 URI 中，我输入镜像的 URI。
部署设置现在仅提供手动触发部署的选项。这是因为我选择了 Amazon ECR Public。如果我想在每次更改容器时进行部署，那么对于提供商，需要选择 Amazon ECR。
从此处开始，说明与“从源代码部署” 部分中完全相同。部署后，该服务会提供 URL，我的应用程序在互联网上线。
注意事项
App Runner 将文件系统作为临时存储在容器实例中实现。文件是临时的。例如，当您暂停和恢复 App Runner 服务时，这些文件不会持续存在。更普遍地说，作为应用程序无状态性质的一部分，文件不能保证在处理单个请求之后继续存在。但是，在其生命周期内，储存的文件确实占用 App Runner 服务的部分存储分配量。尽管临时存储文件不能保证在请求中持久存储，但它们有时可能会持续存在。您有机会利用此类文件。例如，在处理请求时，如果将来的请求有所需要，您可以缓存应用程序下载的文件。这可能会加快未来的请求处理速度，但我无法保证速度一定提升。您的代码不应假定在之前请求中下载的文件仍然存在。要获得有保证的缓存，请使用像 Amazon ElastiCache 这样高吞吐量、低延迟的内存数据库。
合作伙伴在行动
我们一直在与 MongoDB、Datadog 和 HashiCorp 等合作伙伴合作以集成 App Runner。以下是他们一直在开展的工作：
MongoDB –“我们很高兴能够将 App Runner 与 MongoDB Atlas 集成，以便开发人员利用我们全球云原生数据库服务的可扩展性和性能开发其 App Runner 应用程序。”
Datadog –“使用 Amazon App Runner，客户现在可以更轻松地从容器镜像或源代码仓库部署和扩展 Web 应用程序。借助我们的全新集成，客户可以监控自己的 App Runner 指标、日志和事件，以更快地解决问题，并为其应用程序确定最佳资源和扩展设置。”
HashiCorp –“将 HashiCorp Terraform 与 Amazon App Runner 集成意味着开发人员可以更快、更轻松地部署生产云应用程序，同时减少要配置和管理的基础设施。”
我们还有来自 Pulumi、Logz.io 和 Sysdig 的激动人心的集成，这可让 App Runner 客户使用其已知和信任的工具与服务。作为 Amazon Web Services 咨询合作伙伴，Trek10 可以帮助客户利用 App Runner 进行云原生架构设计。
可用性和定价
Amazon App Runner 现已在美国东部（弗吉尼亚北部）、美国西部（俄勒冈）、美国东部（俄亥俄州）、亚太地区（东京）、欧洲（爱尔兰）区域推出。您可以将 App Runner 与 Amazon Web Services管理控制台和 Amazon Copilot CLI 结合使用。
使用 App Runner，您可以为应用程序使用的计算和内存资源付费。 App Runner 会自动扩展和缩减活动容器的数量，以满足应用程序的处理要求。您可以对应用程序使用的容器数量设置最大限制，以便成本不超过预算。
只有在 App Runner 运行时，您才需要为其付费，并且可以轻松暂停应用程序和快速恢复执行。这在开发和测试情况下尤其有用，因为您可以在不使用应用程序时将其关闭，从而有效管理成本。有关更多信息，请参阅 App Runner 定价页面。
立即开始使用 Amazon App Runner，快速、安全地大规模运行 Web 应用程序。