服务
关于
CloudProse博客
监控,运营和开发运营

我的Linux实例使用AWS SSM始终是最新的

使用AWS Systems Manager管理Linux EC2实例的更新。
 安迪·沃宗(Andy Warzon)Trek10
阿图尔·科瓦尔斯基(Artur Kowalski) | 2019年8月23日

2019年8月23日,星期五

我们生活在一个需要记住实例上的操作系统或基础软件包的世界中,因为安全至关重要。

在我们的ENV中,有很多实例。有时很容易出错,或者我们忘记更新其中一个实例。

借助AWS SSM,我们可以安排EC2实例的自动更新。

AWS Systems Manager代理(SSM代理)是可以在Amazon EC2实例,本地服务器或虚拟机(VM)上安装和配置的Amazon软件。 SSM代理使Systems Manager可以更新,管理和配置这些资源。代理处理来自AWS Cloud中Systems Manager服务的请求,然后按照请求中的指定运行它们。然后,SSM代理通过使用Amazon Message Delivery Service(服务前缀:ec2messages)将状态和执行信息发送回Systems Manager服务。

对于本文,我将创建一个小的ENV。为了更好地使用SSM,我们需要向EC2实例添加正确的标签,并在这些实例上安装SSM代理。

我们的更新计划:

  • 在更新实例之前,将自动创建AMI Image作为备份解决方案。
  • 临时实例将在世界标准时间周六06:00修补
  • 在实例上仅安装重要更新和重要更新

设定

在暂存ENV中,将有两个使用Ubuntu 14.04 OS的EC2实例(称为stage web01和舞台 web02)。

标签

如果我们的环境很大,标签会很有帮助。对于我们的文章,我们将3个标签附加到实例:

  • env:分期
  • os:ubuntu14
  • 补丁组:ubuntu_staging

从这些标记中,我们知道实例来自使用OS ubuntu 14的环境登台,并且该实例是补丁组ubuntu_staging的一部分。稍后这很重要。

SSM代理

SSM代理默认安装在以下AMI上:

  • 2016年11月或之后发布的Windows Server 2003-2012 R2 急性心肌梗死
  • Windows Server 2016和2019
  • 亚马逊Linux
  • 亚马逊Linux 2
  • Ubuntu服务器16.04
  • Ubuntu服务器18.04

我们的实例使用的是Ubuntu 14.04,默认情况下未安装SSM代理。我们需要手动安装SSM代理。 您可以阅读有关安装SSM代理的AWS文档.

IAM角色

默认情况下,AWS Systems Manager无权对您的实例执行操作。您必须使用AWS Identity and Access Management(IAM)实例配置文件授予访问权限。实例配置文件是一个在启动时将IAM角色信息传递到Amazon Elastic Compute Cloud(Amazon EC2)实例的容器。您可以通过将一个或多个IAM策略附加到新角色或已创建的角色上来定义Systems Manager的实例配置文件,这些IAM策略定义了必要的权限。

对于本文的后续操作,您将需要两个IAM角色。

The first IAM Role will be called role-for-ssm. This role will be attached to our two instances.

转到AWS控制台-> IAM ->角色,然后点击“创建角色”按钮

创建一个称为Role-for-ssm的角色,并附加名为以下内​​容的AWS管理器策略:AmazonEC2RoleforSSM

欲了解更多信息,请阅读 //docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html

请记住,将IAM角色角色附加到我们的两个实例中。

转到AWS控制台->EC2,选择所需实例,然后点击操作-> Instance Settings ->附加/替换IAM角色

The second IAM Role will be called ssm_automation_service_role.

在创建此角色之前,请 阅读这篇文章 并做任务1,2,3

阅读本文并完成任务后,IAM角色ssm 自动化 service_role应该具有一个称为“ AmazonSSMAutomationRole”的附加策略和一个内联策略。

使用SSM

检查您的环境,我们需要确保SSM代理正在实例上运行:

出于测试目的,整个环境在一个AZ中以eu-central-1启动。

(当然,对于高可用性需求,请始终尝试在不同的可用区中启动多个实例)

每个实例都为SSM添加了IAM角色,并安装了SSM代理。

请转到AWS Systems Manager中的托管实例,以检查我们是否正确添加了称为角色角色的IAM角色以及SSM代理是否正常工作。

我们应该在那里看到整个ENV。

创建维护窗口

现在,我们需要为登台实例创建一个维护窗口:

请转到AWS控制台-> Systems Manager ->维护窗口,然后选择创建维护窗口。

<pre><code>名称:Ubuntu_Staging描述:使用Ubuntu OS登台实例的维护窗口检查允许未注册的目标检查Cron计划生成器选择每个星期六的06:00持续时间:1小时停止启动任务:0小时计划时区:Etc / UTC</code></pre>

创建补丁基准

修补程序基准定义了允许在实例上安装的修补程序。您可以一一指定批准或拒绝的补丁。您还可以创建自动批准规则,以指定应自动批准某些类型的更新(例如,关键更新)。被拒绝的列表会覆盖规则和已批准的列表。

更多 有关补丁基准的信息.

要创建新的补丁程序基准,请转到AWS控制台-> Systems Manager ->补丁程序管理器,然后单击橙色按钮:创建补丁程序基准。

<pre><code>名称:ubuntu-patch-baseline说明:ubuntu实例的补丁程序基线作为操作系统,请选择Ubuntu默认补丁程序基线:请勿更改-保留未标记。</code></pre>

现在我们需要创建一些规则:

Rule1

<pre><code>产品:All部门:AllPriority:必需合规报告:严重</code></pre>

Rule2

<pre><code>产品:全部部门:无优先级:重要合规报告:关键</code></pre>

现在单击创建补丁程序基准,如果一切正常,我们应该看到:

使用自定义补丁基准分配补丁组标记

现在,这一步非常重要,我们需要为我们的自定义补丁基线分配补丁组标签。

请转到AWS控制台-> Systems Manager -> Patch Manager

找到我们针对Ubuntu的补丁程序基准,请按名称使用搜索: ubuntu-patch-baseline

选择我们的补丁程序基准,然后点击操作-> Modify patch groups

在补丁组中,添加我们的标签: staging_ubuntu

现在单击关闭。

In Patch groups, we should see our Patch group, staging_ubuntu, registered with ubuntu-patch-baseline.

请记住:如果我们未为补丁程序组指定补丁程序基准,则AWS将为所需的操作系统使用默认的补丁程序基准。

在维护窗口中注册目标

我们希望SSM仅更新带有我们标签的实例 Patch Group:staging_ubuntu

请转到AWS Systems Manager-> Maintenance windows

Search Maintenance window by name, ubuntu_staging, and click on the Window ID of the ubuntu_staging.

我们应该看到:

现在我们需要创建维护窗口目标。

单击“目标”选项卡并注册目标。

<pre><code>目标名称:staging-targets描述:仅用于登台实例的窗口目标在Targets选择中,请选择:实例标签并输入:标签键:补丁组标签值:staging_ubuntu</code></pre>

最后,点击注册目标

我们应该看到这样的东西:

现在,我们已经在维护窗口中注册了实例。

因此,如果我们添加具有正确标签和IAM角色的新实例,则新实例将自动添加到此维护窗口。

在维护窗口中创建任务

现在,我们需要在“维护”窗口中添加任务以暂存ENV。

请转到AWS Systems Manager->维护窗口。

Search the Maintenance window by name: ubuntu_staging, and click on Window ID of the ubuntu_staging.

现在单击任务。

我们需要做的第一件事是在开始修补之前注册用于创建AMI映像的自动任务。这将是我们的备份计划。如果在修补后出现问题,我们可以还原更改,从备份AMI启动新实例。

为此,请:

单击注册任务,然后选择注册自动化任务。

<pre><code>名称:Create_AMI_image描述:此任务将在修补之前创建实例的AMI映像。</code></pre>

在自动化文档中,请选择AWS-CreateImage在文档版本中,选择运行时的最新版本。在“任务优先级”中,键入:0

Task priority 0 - it’s the highest priority, it will be executed as the first task In Targets, we need to select staging-targets registered targets groups

速率控制:

在这里,我们可以设置一次可以运行多少个实例。

如果我们有一个非常大的环境,我们可以使用一个百分比,但是在我们的情况下,我们将一次设置一个实例。

在错误阈值中,我们设置应该停止该任务的时间的值。因此,如果出现错误,该任务将被停止。

我建议使用1。

现在,选择一个自定义服务角色,该角色将使Maintenance Windows可以代表您与其他AWS资源进行交互。

在我们的情况下,将是角色: ssm_automation_service_role

完成配置自动化以创建AMI映像的最后一步是设置输入参数。

请输入以下参数:

<pre><code>InstanceId {{TARGET_ID}}否重新启动false</code></pre>

然后选择橙色按钮“编辑自动化任务”

由于这些参数,SSM开始工作时,它将首先停止实例并创建AMI映像作为备份解决方案。

现在我们需要创建第二个修补任务

转到维护窗口->任务,然后选择注册任务。然后选择注册运行命令任务。

类型:名称:PatchingTask

In the Command document, select AWS-RunPatchBaseline and enter 5 as the Task Priority

因此,在这种情况下,第一个任务是 创建 急性心肌梗死 图片 因为它的优先级为0,第二个将是 修补任务 因为它的优先级较低(5)

与之前一样,在Targets中,我们需要选择称为 staging-targets

速率控制,我们还需要设置1个目标(此任务将在目标组中的每个实例上执行-一个接一个地执行),并在出现1个错误后停止

现在我们需要为此任务选择一个服务角色。

和以前一样,我们需要使用一个角色: ssm_automation_service_role

在此示例中,我们不会更改“输出”选项(将被禁用),也不需要启用SNS通知。

在参数中,选择操作->安装。所有其他选项将保持默认。

现在单击Edit Run命令任务,我们已经完成了SSM的配置。

测试SSM

出于测试目的,我已更改了UTC每个星期五上午11:45的“维护”窗口。

更改“维护”窗口后,请记住启用“维护”窗口。

如果启用“维护”窗口,则应该看到类似以下内容:

我们应该看到下一次执行时间: 格林尼治标准时间2019年7月12日星期五上午11:45:00

11:45之后,转到“维护”窗口,然后单击“历史记录”,我们应该看到类似以下内容:

我们的窗口执行ID为“进行中”-非常好!选择我们的窗口执行ID,然后单击查看详细信息。

我们看到SSM现在承担创建AMI映像的任务。

修补任务正在进行时,它看起来应该相似。

最后,我们应该看到如下所示:

恭喜! 我们已经成功配置了SSM以创建AMI映像作为备份,然后更新了我们的实例。

作者
 安迪·沃宗(Andy Warzon)Trek10
阿图尔·科瓦尔斯基(Artur Kowalski)