亚马逊AWS官方博客
AWS Systems Manager 变更管理器的简介
您一直在倾听客户的反馈,因此在持续迭代、创新和改进应用程序和基础设施。您不断修改云中的 IT 系统。让我们面对现实,在作业系统中改变某些项目可能会造成损坏,或带来有时不可预测的副作用;这与您做了多少次测试无关。另一方面,不做改变意味着停滞,紧接着就会落伍,然后就是死亡。
这就是为什么各种规模和类型的组织都接受控制变更的文化。一些组织采用变更管理流程,例如 ITIL v4 中定义的流程。有些组织采用开发运维的持续部署或其他方法。无论如何,为了支持变更管理流程,拥有工具非常重要。
今天,我们将推出 AWS Systems Manager 变更管理器,这是适用于 AWS Systems Manager 的新变更管理功能。它简化了运营工程师跟踪、批准和实施对其应用程序配置和基础设施操作变更的方式。
使用变更管理器有两个主要优势。首先,它可以提高对应用程序配置和基础设施所做更改的安全性,从而降低服务中断的风险。它通过跟踪仅实施批准的更改,使运营变更更加安全。其次,它与其他 AWS 服务(例如 AWS Organizations 和 AWS Single Sign-On)紧密集成,或与 Systems Manager 变更日历和 Amazon CloudWatch 警报集成。
变更管理器提供了问责制,以统一方式报告和审计整个组织所做的变更、更改意图以及谁批准和实施这些变更。
变更管理器跨 AWS 区域和多个 AWS 账户工作。它与组织和AWS SSO 密切合作,从中心点管理变更,并以受控的方式在您的全球基础设施中进行部署。
术语
您可以在单个 AWS 账户上使用 AWS Systems Manager 变更管理器,但大多数情况下,您将在多账户配置中使用它。
管理多个 AWS 账户变更的方式取决于这些账户的关联方式。变更管理器使用 AWS Organizations 中定义的账户之间的关系。使用变更管理器时,有三种类型的帐户:
- 管理账户 — 也称为“主账户”或“根账户”。 管理账户是 AWS Organizations 层次结构中的根账户。根据这个事实,这是管理账户。
- 代理管理员帐户 — 代理管理员帐户是一个已被授权管理组织中其他帐户的帐户。在变更管理器上下文中,这是从中发起变更请求的帐户。您通常需要登录此帐户才能管理模板和变更请求。使用代理管理员帐户可以限制与根账户建立的连接。它还允许您通过使用变更所需的特定权限子集来强制执行最低权限策略。
- 成员帐户 — 成员帐户不是管理帐户或代理管理员帐户,但仍包含在组织中的帐户。在我的变更管理器心理模型中,这些帐户将是保存部署变更的资源的帐户。代理管理员帐户将发起变更请求,该请求将影响成员账户中的资源。不建议系统管理员直接登录这些帐户。
让我们通过简短的演示来看看如何使用 AWS Systems Manager 变更管理器。
一次性配置
在这种情况下,我将向您展示如何将 变更管理器用于与组织关联的多个 AWS 账户。如果您对一次性配置不感兴趣,请跳转至下面的创建变更请求部分。
在使用变更管理器之前,需要执行四个一次性配置操作:一个操作在根帐户中执行,另外三个在代理管理员帐户中执行。在根帐户中,我使用 Quick Setup(快速设置)来定义我的代理管理员帐户,然后初始配置帐户的权限。在代理管理员帐户中,您可以定义用户身份来源,定义哪些用户有权批准变更模板,然后定义变更请求模板。
首先,我确保自己有一个组织,并且我的 AWS 账户按组织单位 (OU) 进行组织。在这个简单示例中,我有三个账户:根账户、管理 OU 中的代理管理员帐户和托管 OU 中的成员帐户。准备好后,我使用根账户上的 Quick Setup(快速设置)来配置我的帐户。有多条路径通向 Quick Setup(快速设置);对于此演示,我使用 Quick Setup(快速设置)控制台顶部的蓝色横幅,然后单击 Setup Change Manager(设置变更管理器)。
如果我尚未定义代理管理员帐户,请在 Quick Setup(快速设置)页面上输入该 ID。然后,我选择授予代理管理员帐户代表我执行变更的权限边界。这是变更管理器获得的进行变更的最大权限。在几分钟内创建变更请求时,我将进一步限制此权限集。在此示例中,我授予了变更管理器调用任何 ec2
API 的权限。这实际上授权变更管理器只运行与 EC2 实例相关的变更。
在屏幕下方,我选择作为变更目标的帐户集。我在整个组织或自定义之间进行选择,以选择一个或多个 OU。
不久后,快速安装程序完成了我的 AWS 账户权限的配置,我可以转到一次性设置的第二部分。
接下来,我切换到我的代理管理员帐户。变更管理器询问我如何管理组织中的用户:使用 AWS Identity and Access Management (IAM) 或 AWS Single Sign-On? 这定义了当我选择批准者时,变更管理器在何处提取用户身份。这是一次性配置选项。这可以随时在变更管理器 Settings(设置)页面中进行更改。
然后,在同一页面上,我定义了 Amazon Simple Notification Service (SNS) 主题来接收有关模板评论的通知。在创建或修改模板时,该通道都会收到通知,以便模板批准者审阅和批准模板。我还定义了有权批准变更模板的 IAM(或 SSO)用户(在一分钟内详细了解这些模板)。
或者,您可以使用现有的 AWS Systems Manager 变更日历来定义未授权变更的时段,例如营销活动或节假日销售。
最后,我定义一个变更模板。每个变更请求都是从模板创建的。模板基于这些变更请求定义所有变更请求的通用参数,例如变更请求审批者、要执行的操作或发送进度通知的 SNS 主题。在使用模板之前,您可以强制对模板进行审查和批准。创建多个模板来处理不同类型的更改是非常合理的。例如,您可以创建一个用于标准变更的模板,再创建一个用于覆盖变更日历的紧急变更的模板。或者,您可以为不同类型的自动化运行手册(文档)创建不同的模板。
为了帮助您开始使用,我们为您创建了一个模板:“Hello World”模板。您可以将它用作创建变更请求和测试批准流程的起点。
我可以随时创建自己的模板。假设我的系统管理员团队经常重新启动 EC2 实例。我创建了一个模板,允许他们创建更改请求以重启一个或多个实例。我使用代理管理员帐户,导航到变更管理器管理控制台,然后单击 Create template(创建模板)。
简而言之,模板定义了授权操作的列表、发送通知的位置以及谁可以批准变更请求。操作是 AWS Systems Manager Runbook。紧急变更模板允许变更请求绕过我之前写过的变更日历。在 Runbook Options(Runbook 选项)下,我选择一个或多个允许运行的 Runbook。对于此示例,我选择 AWS EC2RestartInstance
Runbook。
我使用控制台来创建模板,但模板在内部被定义为 YAML。我可以使用 Editor(编辑器)选项卡或在使用 AWS 命令行界面 (CLI) 或 API 时编辑 YAML。这意味着我可以像基础设施的其余部分一样对它们进行版本控制(作为代码)。
就在下面,我使用 markdown 格式的文本来记录我的模板。我使用此部分来记录模板的定义特征,并向申请者提供任何必要的说明,例如退出程序。
我向下滚动该页面,然后单击 Add Approver(添加审批者)定义审批者。审批者可以是个人用户或组。审批者列表可以在模板级别或在变更请求本身中定义。我还选择创建 SNS 主题,以便在创建需要审批者批准的请求时通知审批者。
在 Monitoring(监控)部分中,我选择一个警报,该警报在激活时会停止基于此模板的任何更改,然后启动回滚。
在 Notifications(通知)部分,我选择或创建另一个 SNS 主题,以便在此模板的状态变更时通知我。
完成后,我会保存模板并提交以供审查。
模板必须经过审查和批准才能使用。为了批准模板,我将控制台作为我之前定义的 template_approver
用户进行连接。作为 template_approver
用户,我在 Overview(概述)选项卡上看到待批准。或者,我导航到 Templates(模板)选项卡,选择要查看的模板。完成审查后,单击 Approve(批准)。
Voila,现在我们准备基于此模板创建变更请求。请记住,上述所有步骤都是一次性配置,可以随时修改。修改现有模板后,变更将再次经过审核和批准流程。
创建变更请求
要在与组织关联的任何账户上创建变更请求,我从代理管理员账户打开 AWS Systems Manager 变更管理器控制台,然后单击 Create request(创建请求)。
选择要使用的模板,然后单击 Next(下一步)。
我输入此变更请求的名称。在授权所有批准后立即启动变更,或者指定一个可选的计划时间。当模板允许时,我会选择此变更的审批者。在此示例中,审批者由模板定义,无法更改。我单击 Next(下一步),
在下一个屏幕上,有多个重要的配置选项,与变更的实际执行有关:
- 目标位置 — 允许我定义要在哪个目标 AWS 账户和 AWS 区域上运行此变更。
- 部署目标 — 允许我定义哪些资源是此变更的目标。一个 EC2 实例? 或者由其标签、资源组、实例 ID 列表或所有 EC2 实例标识的多个实例。
- Runbook 参数 — 允许我定义要传递给我的 runbook 的参数(如有)。
- 执行角色 — 允许我定义我授予 System Manager 的权限集,以便使用此变更进行部署。权限集必须将服务
changemanagement.ssm.amazonaws.com
作为信任策略的 Principal。选择角色允许我授予变更管理器运行时与我拥有的权限集不同的权限集。
以下是允许变更管理器停止 EC2 实例的示例(您可以将其范围限定为特定 AWS 账户、特定区域或特定实例):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*",
},
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
}
相关的信任政策:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "changemanagement.ssm.aws.internal"
},
"Action": "sts:AssumeRole"
}
]
}
准备好后,我单击 Next(下一步)。在最后一页上,我查看数据输入,然后单击 Submit for approval(提交以获得批准)。
在此阶段,审批者会根据模板中配置的 SNS 主题收到通知。要继续此演示,退出控制台,然后以我创建的 cr_approver
用户身份重新登录,该用户有权查看和批准变更请求。
作为 cr_approver
用户,我导航到控制台,查看变更请求,然后单击 Approve(批准)。
变更请求状态将切换为已计划,最终变为绿色的 Success(成功)。我可以随时单击变更请求以获取状态并收集错误(如有)。
我单击变更请求以查看详细信息。特别是,Timeline(时间线)选项卡显示了此 CR 的历史记录。
可用性和定价
AWS Systems Manager 变更管理器目前在除中国大陆外的所有商业 AWS 区域均可使用。定价基于两个维度:您提交的变更请求数和所发出的 API 调用总数。您提交的变更请求数将是主要的成本因素。我们将对每个变更请求收取 0.29 USD 的费用。查看定价页面了解更多详情。
从第一个变更请求开始,您可以免费评估变更管理器 30 天。