使用 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