85 个版本 (39 个稳定版本)

1.40.0 2024 年 8 月 16 日
1.37.0 2024 年 7 月 22 日
1.19.0 2024 年 3 月 26 日
1.9.0 2023 年 12 月 21 日
0.0.0 2021 年 5 月 7 日

#2#deployment

Download history 132/week @ 2024-04-26 424/week @ 2024-05-03 185/week @ 2024-05-10 212/week @ 2024-05-17 252/week @ 2024-05-24 157/week @ 2024-05-31 291/week @ 2024-06-07 525/week @ 2024-06-14 225/week @ 2024-06-21 273/week @ 2024-06-28 508/week @ 2024-07-05 191/week @ 2024-07-12 269/week @ 2024-07-19 242/week @ 2024-07-26 176/week @ 2024-08-02 326/week @ 2024-08-09

每月 1,015 次下载
aws-mocks 中使用

Apache-2.0

3MB
48K SLoC

aws-sdk-appconfig

AppConfig 功能标志和动态配置可以帮助软件开发人员在不进行完整代码部署的情况下快速安全地调整生产环境中的应用程序行为。AppConfig 加快了软件发布频率,提高了应用程序的弹性,并帮助您更快地解决突发问题。使用功能标志,您可以逐渐向用户发布新功能,并在将新功能完全部署给所有用户之前测量这些更改的影响。使用操作标志和动态配置,您可以更新阻止列表、允许列表、节流限制、日志详细程度,并在生产环境中快速响应问题。

尽管应用程序配置内容可能因应用程序而异,但 AppConfig 支持以下用例,涵盖了广泛的客户需求

  • 功能标志和切换 - 在受控环境中安全地发布新功能给您的客户。如果您遇到问题,可以立即回滚更改。
  • 应用程序调整 - 在生产环境中测试用户对更改的影响的同时,谨慎地引入应用程序更改。
  • 允许列表或阻止列表 - 无需部署新代码即可控制对高级功能的访问或立即阻止特定用户。
  • 集中式配置存储 - 将您的配置数据组织并保持一致性,跨所有工作负载。您可以使用 AppConfig 将存储在 AppConfig 主机配置存储、Secrets Manager、Systems Manager、Parameter Store 或 Amazon S3 中的配置数据部署到 AppConfig。

AppConfig 的工作原理

本节提供了关于 AppConfig 的工作原理以及如何开始的概述。

1. 识别您想要在云端管理的代码中的配置值

在开始创建AppConfig实体之前,我们建议您识别出您希望在AppConfig中动态管理的代码中的配置数据。好的例子包括功能标志或开关、允许和阻止列表、日志详细程度、服务限制和节流规则等。如果您的配置数据已经存在于云中,您可以利用AppConfig的验证、部署和扩展功能来进一步简化配置数据管理。

2. 创建应用程序命名空间

要创建命名空间,您需要创建一个名为应用程序的AppConfig实体。应用程序只是一个组织结构,类似于文件夹。

3. 创建环境

对于每个AppConfig应用程序,您定义一个或多个环境。环境是目标(如Beta或生产环境中的应用程序、Lambda函数或容器)的逻辑分组。您还可以为应用程序的子组件(如Web、移动和后端)定义环境。您还可以为每个环境配置Amazon CloudWatch警报。系统在配置部署期间监控警报。如果触发警报,系统将回滚配置。

4. 创建配置配置文件

配置配置文件包括,但不限于,一个URI,它使AppConfig能够找到其存储位置中的配置数据和一个配置文件类型。AppConfig支持两种配置配置文件类型:功能标志和自由格式配置。功能标志配置配置文件将数据存储在AppConfig托管配置存储中,URI只是托管。对于自由格式配置配置文件,您可以将数据存储在AppConfig托管配置存储中或任何与AppConfig集成的Amazon Web Services服务中,如《AppConfig用户指南》中所述的创建自由格式配置配置文件。配置配置文件还可以包括可选的验证器,以确保您的配置数据在语法和语义上正确。当您开始部署时,AppConfig将使用您创建配置配置文件时指定的验证器进行检查。如果检测到任何错误,则部署将回滚到以前的配置数据。

5. 部署配置数据

当您创建新的部署时,您需要指定以下内容:- 应用程序ID

  • 配置配置文件ID
  • 配置版本
  • 您想要部署配置数据的环境ID
  • 定义您希望更改生效速度的部署策略ID
  1. 当您调用StartDeployment API操作时,AppConfig执行以下任务:1. 通过配置配置文件中的位置URI从底层数据存储检索配置数据。
  2. 使用您创建配置配置文件时指定的验证器验证配置数据在语法和语义上是否正确。

将数据的副本缓存起来,以便它可以被您的应用程序检索。这个缓存的副本被称为“已部署数据”。

您可以将AppConfig代理配置为本地主机,并让代理轮询AppConfig以获取配置更新。代理调用StartConfigurationSessionGetLatestConfiguration API操作,并在本地缓存配置数据。要检索数据,您的应用程序需要向localhost服务器发送HTTP请求。AppConfig代理支持多种用例,具体请参阅《AppConfig用户指南》中的简化检索方法。如果AppConfig代理不支持您的用例,您可以通过直接调用StartConfigurationSessionGetLatestConfiguration API操作来配置您的应用程序轮询AppConfig以获取配置更新。

本参考旨在与AppConfig用户指南一起使用。

入门

GitHub(https://github.com/awslabs/aws-sdk-rust/tree/main/examples)上的示例文件夹提供了许多服务和操作示例。

每个AWS服务都有一个SDK提供。您必须在Rust项目中添加Tokio作为依赖项来执行异步代码。要将aws-sdk-appconfig添加到您的项目,请在您的Cargo.toml文件中添加以下内容

[dependencies]
aws-config = { version = "1.1.7", features = ["behavior-version-latest"] }
aws-sdk-appconfig = "1.40.0"
tokio = { version = "1", features = ["full"] }

然后在代码中,可以使用以下方式创建客户端

use aws_sdk_appconfig as appconfig;

#[::tokio::main]
async fn main() -> Result<(), appconfig::Error> {
    let config = aws_config::load_from_env().await;
    let client = aws_sdk_appconfig::Client::new(&config);

    // ... make some calls with the client

    Ok(())
}

有关可以进行的调用以及每个调用的输入和输出信息,请参阅客户端文档

使用SDK

在SDK发布之前,我们将向开发者指南添加有关使用SDK的信息。您可以通过打开一个issue并描述您要做什么来建议指南的附加部分。

获取帮助

许可证

本项目采用Apache-2.0许可证。

依赖项

~8–20MB
~281K SLoC