亚马逊AWS官方博客

使用 AWS AppConfig 安全部署应用程序配置设置

几年前我们发现,通过传统代码部署的方式进行配置变更效率太低,我们需要一种内部服务,让我们可以更快地进行配置变更,同时保持与代码变更一致的操作审查严格程度。因此,我们构建了一个工具来满足这一需求。现在,AWS、零售、Kindle 和 Alexa 的大多数团队都在使用此配置部署系统,他们能够在几秒钟内完成动态变更,不再需要数分钟。能够仅部署配置变更(与代码分离)意味着我们不必重新启动使用该配置的应用程序或服务,并且变更会立即生效。在 Amazon 和 AWS 内部,这项服务每天被使用数千次。

客户经常问我们,他们要如何才能像我们一样运营。为此,我们决定将这种内部工具与我们的客户共享。今天,我们宣布推出 AWS AppConfig,将它作为 AWS Systems Manager 的一项功能。借助 AWS AppConfig,客户可以跨托管在 Amazon Elastic Compute Cloud (EC2) 实例、容器上的任何大小的应用程序以及无服务器应用程序和函数,快速部署配置变更,而不影响代码。

您可以使用 API 或控制台创建和更新配置,并且可以在部署之前使用定义的架构模板或 AWS Lambda 函数来验证变更。AWS AppConfig 还包含自动安全控制功能,可监控配置变更的部署,并在出现问题时回滚到先前的配置。配置更新的部署可立即用于您正在运行的应用程序,因为应用程序使用简单的 API 定期轮询和检索最新的可用配置。

使用 AWS AppConfig管理应用程序配置设置
使用 AWS AppConfig 创建和管理应用程序的配置设置是一个简单的过程。首先,我创建一个应用程序,然后为该应用程序定义一个或多个环境配置文件部署策略。环境表示逻辑部署组,例如测试或生产环境,或者它也可以表示应用程序的子组件,例如 Web、移动和后端组件。我可以为每种环境配置 Amazon CloudWatch 警报,这些警报将由 AWS AppConfig 进行监控,一旦部署期间出现警报就会触发回滚。配置文件定义了要部署的配置数据的来源,以及可选的验证程序,以确保您的配置数据正确才进行部署。部署策略定义如何执行部署。

首先,进入 AWS Systems Manager 控制面板,然后从导航面板中选择 AppConfig。单击创建配置数据,将进入一个页面,在其中可以为应用程序指定名称以及添加描述(可选),如果需要,还可以为应用程序添加标签。

创建应用程序后,将进入带有环境配置文件选项卡的页面。首先创建一个环境,将该应用程序用于我的生产环境。选择环境选项卡后,单击创建环境。在显示的页面上,我给该环境命名,然后在监控下,选择在出现 Cloudwatch 警报时启用回滚。然后,提供一个 IAM 角色,让 AWS AppConfig 能够在部署期间监控选定的警报,然后单击添加。有关角色所需权限的详细信息,请参阅此处的内容。

接下来是设置配置文件。返回我的应用程序的详细信息视图,选择配置文件选项卡,然后单击创建配置文件。所需的详细信息包括配置的名称和 AWS AppConfig 用来访问配置的服务角色。我可以选择创建一个新角色,也可以选择使用已有的角色。

单击下一步,然后选择将要部署的配置数据的来源。我可以从 Systems Manager 文档或 Parameter Store 中的参数中进行选择。在本演练中,我将选择这样一个参数:当该参数设置为 true 时,它将为该示例应用程序的用户启用与该功能相关的功能。

接下来,我可以选择向配置文件添加一个或多个验证程序,以便 AWS AppConfig 可以在我尝试更新设置时,验证值是否正确以及会否导致应用程序失败。在这里,我将使用 JSON 架构,因此将使用语法检查。如果我想运行代码来执行验证(即语义检查),则可以配置 Lambda 函数。输入架构后,单击创建配置文件完成该过程。

剩下的一项任务是配置用来控制部署的部署策略。我可以从 AWS AppConfig 控制面板中执行此操作,方法是选择部署策略选项卡,然后单击创建部署策略。在这里,我配置了一个策略,该策略可让 AWS AppConfig 一次性部署到五分之一 (20%) 的托管该应用程序的实例。监控将在部署和等待期间执行,直到部署完成。在部署和等待期间,如果发生任何错误,则将触发与该环境相关的警报,并且将发生回滚。您可以在此处阅读更多有关可以为策略设置的选项的信息。单击创建部署策略即可完成此步骤,并使该策略可供部署期间选择。

在为应用程序配置了环境和配置文件,并制定了部署策略(我可以添加更多)之后,就可以开始部署了。导航到我的配置文件,然后单击开始部署

我选择要部署到的环境、包含要部署的配置变更的参数的版本、部署策略,然后输入描述(可选)。我选择的参数版本为 2。参数的版本 1 的值为 { “featureX”: false }。参数的版本 2 的值为 { “featureX”: true },可在部署后立即为我的用户启用与该功能关联的功能。

单击开始部署将启动验证和部署过程。我知道该参数的版本 2 的值是有效的,因此在验证后部署过程将继续进行。一旦部署可用于某个目标,则该目标将在下一次配置轮询时收到更新的配置,并且将为我的用户安全地启用与 featureX 相关联的新功能!

在本文中,我通过功能切换介绍了一种非常简单的方法。通过这种方法,我能够立即启用可能需要及时部署(如新产品发布或宣布)的功能。AWS AppConfig 可以用于许多其他不同的用例,这里仅提供几个参考示例:

  • A/B 测试:对哪些版本的应用程序可以赚取更多收入进行实验。
  • 用户会员资格:允许高级订阅者访问应用程序的付费内容。

请注意,从 AWS AppConfig 接收部署的目标不需要使用 Systems Manager 代理进行配置,也不需要具有 AWS Identity and Access Management (IAM) 实例配置文件(虽然其他 Systems Manager 功能需要)。这使我可以将 AWS AppConfig 用于托管实例和非托管实例。您可以在用户指南中阅读有关 AWS AppConfig 的更多信息。定价信息可在此处获得。AWS AppConfig 现在向所有商业 AWS 区域的客户提供。

– Steve