原文:
annas-archive.org/md5/b44a68a3321a441a0fdffa7dcbaf1892译者:飞龙
第十四章:监控和日志记录您的环境和工作负载
在本节中,您将了解 AWS 中可用的本地监控选项,以及如何通过不同的可访问日志接收来自您的环境和应用程序的反馈。
本书的这一部分包括以下章节:
-
第十四章,CloudWatch 和 X-Ray 在 DevOps 中的作用
-
第十五章,CloudWatch 指标和 Amazon EventBridge
-
第十六章,生成的各种日志(VPC 流日志、负载均衡器日志、CloudTrail 日志)
-
第十七章,高级和企业级日志记录场景
第十五章:CloudWatch 和 X-Ray 在 DevOps 中的作用
一旦你的应用程序在云中运行,你就需要一个方法来监控它,以确保它保持健康并有效地运行。CloudWatch 可以汇总你的服务和应用程序的日志,但将其与X-Ray结合使用,可以追踪应用程序的性能,找出进一步提升性能的地方。
在本章中,我们将涵盖以下主要内容:
-
CloudWatch 概述
-
使用 CloudWatch 汇总你的日志
-
CloudWatch 告警
-
为应用程序追踪添加 X-Ray
CloudWatch 概述
监控有许多重要原因,从运营角度到商业角度都很重要。首先,它让你不仅可以看到环境中运行的内容,还能了解这些资源的性能。其次,从运营角度来看,当你尝试实时解决问题时,监控非常关键。从商业角度来看,监控让你知道一些关键事项,比如你的部署是否已成功完成,客户是否没有看到任何负面影响。
在今天这个信息可以迅速通过互联网,尤其是社交媒体渠道传播的时代,任何影响客户体验的事情都可能并且通常会迅速传播。这会影响你的品牌和商业利润。通过 CloudWatch 监控你的资源可以让你走在前面,采取主动而非被动的应对方式:
图 14.1 – 监控如何持续演变
你今天监控系统和资源的方式可能与 5 到 10 年前监控方式有所不同。诸如基础设施变化和瀑布式部署哲学等因素决定了需要监控的内容。
过去,你可能需要配置一台服务器,并且这台服务器会运行长达十年才会被淘汰。然而,随着云服务的发展,如自动扩展,根据需求不断增加和移除实例,所监控的指标不仅要与系统健康相关,还要与客户体验的性能相关:
图 14.2 – AWS CloudWatch 的功能
亚马逊 CloudWatch 是一项 AWS 原生服务,帮助你监控服务和资源。它是 AWS 提供的管理工具的一部分。CloudWatch 的主要功能是帮助你跟踪和监控资源和应用程序的性能。在监控过程中,CloudWatch 服务可以通过 SNS 服务通知人员,或通过事件触发自动化响应这些告警。CloudWatch 还可以用于收集和监控日志文件。CloudWatch 包括三个主要组件:指标、告警和事件。
了解和使用 CloudWatch 统一代理
AWS 提供了一个统一的 CloudWatch 代理,可以帮助你处理多种事情,无论是对本地服务器还是 EC2 实例。让我们回顾几个使用 CloudWatch 统一代理的常见场景。
以不同用户身份运行
在 Linux 服务器上运行 CloudWatch 代理时,CloudWatch 代理默认作为 root 用户运行。如果你的公司不允许代理和程序以 root 用户身份运行,那么你可以为 CloudWatch 代理创建一个自定义用户,并在配置文件中告诉代理 run_as_user。
拥有多个 CloudWatch 代理配置文件
基于经批准的Amazon 机器映像(AMI)构建的组织,必须用于任何开发或生产构建,可以将 CloudWatch 配置文件预先配置到实例中。这个配置文件将允许跨所有实例收集标准配置。开发团队可以添加另一个配置文件,CloudWatch 代理可以在启动时读取并处理,其中包括任何特定的应用程序指标或日志。
一个例子是,如果应用团队正在运行一个 NGINX 服务器来为其 Web 应用提供前端,或者他们可能使用 NGINX 的代理功能来重定向流量。他们的自定义配置文件可以指定查找 NGINX 的 4XX 和 5XX 错误,同时也可以配置消费这些日志并将其发送回 CloudWatch Logs。
将指标和日志发送到与实例运行所在账户不同的账户
CloudWatch 代理具有灵活性,可以通过在配置中指定 role_arn 将指标、日志或两者发送到另一个 AWS 账户进行监控。
向 CloudWatch 代理收集的指标添加自定义维度
CloudWatch 会创建它收集的指标的汇总。这些汇总可能并不总是最适合你和你的团队,因此,可以通过使用 append_dimensions 字段自定义分组方式。
我们刚刚看到,无论是在 AWS EC2 实例还是本地服务器上使用的统一 CloudWatch 代理,都可以在多种场景下收集日志和指标。现在,让我们通过在 EC2 实例上安装 CloudWatch 代理的过程。
在 EC2 实例上安装 CloudWatch 代理
了解 CloudWatch 统一代理的最佳方法是通过在 EC2 实例上安装代理的过程。以下教程将带你完成搭建 EC2 实例的步骤,然后安装和配置代理。最后,我们将向 EC2 实例发送一些流量,以便查看生成的指标和日志。
注意
在下一章中,我们将更深入地探讨 CloudWatch 指标。第十五章,CloudWatch 指标和 Amazon EventBridge,将讨论通用指标和自定义指标。
到目前为止,我们在示例中一直使用 Amazon Linux 作为任何 EC2 实例的操作系统。Amazon Linux 是一个优秀的操作系统,并且预安装了许多在 AWS 云计算环境中使用的软件包。这正是我们在本示例中使用不同操作系统——Ubuntu——的原因。Ubuntu 操作系统默认并不会安装一些软件包,例如 CloudWatch 统一代理。这使得我们可以在这个 EC2 实例上通过安装过程来进行操作,但如果你在数据中心有一个 EC2 实例,过程是一样的,只不过你需要使用密钥对对实例进行身份验证,而且这个密钥对会定期轮换。而 EC2 实例可以扮演角色,因此不需要将访问密钥和秘密密钥存储在实例上,实际上,扮演角色是一种更安全的做法。让我们开始吧:
-
首先,让我们为实例创建 IAM 角色;我们需要确保实例具有 CloudWatch 和 AWS Systems Manager 的权限。要创建角色,我们需要在本地保存一个初始的
JSON策略文件,然后附加所需的两个托管策略。将JSON策略复制到名为STS.json的文件中:{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Service": "ec2.amazonaws.com"}, "Action": "sts:AssumeRole" } } -
保存好初始策略后,我们现在可以创建角色并附加这两个托管策略:
aws iam create-role --role-name CW-EC2 --assume-role-policy-document file://STS.json aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore --role-name CW-EC2 aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy --role-name CW-EC2 -
由于我们将通过 CLI 启动我们的实例,因此需要创建一个实例配置文件。一旦实例配置文件创建完成,我们就可以将新的角色附加到
instance profile:aws iam create-instance-profile --instance-profile-name CW_SSM aws iam add-role-to-instance-profile --role-name CW-EC2 --instance-profile-name CW_SSM -
然后,我们需要查询
SSM参数存储中的 AMI,我们希望使用该 AMI 来启动我们的镜像:AMI='aws ssm get-parameters --names \ /aws/service/canonical/ubuntu/server/16.04/stable/current/amd64/hvm/ebs-gp2/ami-id \ --query 'Parameters[0].[Value]' --output text --region us-east-2'如果你想查看返回的 AMI 值,可以使用以下命令:
echo $AMI -
我们稍后需要进入我们的实例,但与其创建密钥对,不如添加以下脚本,该脚本将安装 SSM 代理和统一的 CloudWatch 代理,适用于 Debian 操作系统。我们将创建此脚本并将其保存为名为
agents.sh的文件,这样我们就可以在稍后通过user-data参数启动 EC2 实例时使用它。安装 SSM 代理和
theunifiedCloudWatchagent的脚本如下:Chapter-14 folder of this book's GitHub repository under the same name – agents.sh. -
一旦我们将
AMI值存储到变量中,就可以使用以下命令启动我们的镜像:user-data script, which we just created, as well as a Name tag for our instance. This name will help us identify our instance when we try to find it later. -
当我们的实例正在启动并运行我们提供给它的启动脚本时,我们可以登录到 AWS 控制台,并直接使用以下网址访问 SSM 会话管理器:
console.aws.amazon.com/systems-manager/session-manager。登录后,在右上角检查确保您所在的区域正确。我们指定我们的实例启动在俄亥俄州区域(us-east-2),如果列出了其他区域,请切换到您创建实例的区域。作为替代,您也可以通过EC2屏幕选择实例,然后从操作下拉菜单中选择连接。在连接到实例屏幕中,选择会话管理器,然后点击橙色的连接按钮。连接到实例时,应该会弹出一个包含您会话的新窗口。 -
现在我们已经成功地通过 SSM 连接到实例,而不需要使用密钥,我们可以配置代理。我们已经使用
user-data脚本中的一些命令安装了 CloudWatch 代理。为了将一些日志流传输到 CloudWatch Logs,我们需要告诉代理具体要推送哪些日志。我们需要以sudo用户身份运行配置脚本,脚本位于/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard。为了简化命令,我们将通过sudo su命令切换到 root 用户:sudo su /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard -
运行 CloudWatch 代理配置管理器时,您将被提示回答一些问题,但设置应该不会超过 5 分钟。这里显示的问题是那些没有选择默认值的:
-
您想要选择哪个默认的指标配置?标准(2)日志文件路径:
/var/log/amazon/ssm/amazon-ssm-agent.log。 -
您是否想指定任何其他日志文件进行监控?不(2)。
-
您是否希望将配置存储在 SSM 参数存储中?不(2)。
-
-
配置向导完成后,由于我们使用的是 Ubuntu 操作系统,我们将把新生成的
config文件复制到代理预期的位置,并将文件所有权授予cwagent用户:cp /opt/aws/amazon-cloudwatch-agent/bin/config.json /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json chown cwagent /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -
现在我们的 CloudWatch 代理文件已经配置完成,我们需要重新启动代理以使更改生效。我们可以通过以下命令实现这一点:
& symbol at the end of the command will put the script in the background so that you can do other things, and the script will still be running. -
我们生成日志的首要方式之一是点击橙色的
CloudWatch服务。服务名称出现后,点击CloudWatch将带您进入该服务。 -
一旦进入
amazon-ssm-agent.log,点击该日志组的名称,将带您进入日志流。 -
日志组中应该只有一个日志流。该日志流的名称将是您 AWS EC2 实例的标识符。点击这个日志流,以便我们查看日志:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_14.3_B17405.jpg
图 14.3 – 我们 CloudWatch 日志组中的单个日志流
-
如果您已经退出了您的
Sessionworkerclosed。任何在 CloudWatch 代理运行期间退出会话管理器的情况,都应该出现在日志列表中。您可以点击日志左侧的小三角形来展开内容,查看完整的日志条目。注意
我们将继续使用此实例进行本章的进一步练习。如果您打算稍后继续操作,我建议您将此实例置于休眠状态,这样您就不会因此而产生费用。这样,等到您准备好再次操作时,就无需重新配置一切。
现在,我们已经将统一的 CloudWatch 代理添加到非 Amazon 实例上,接下来我们将看一下 CloudWatch Logs 的一些其他功能。如果您打算在短时间内完成下一次使用 CloudWatch 警报的练习,我建议您要么保持此实例运行,要么仅仅停止实例,这样您可以访问 CloudWatch 代理汇总并推送的指标,供警报使用。
使用 CloudWatch 聚合日志
亚马逊的 CloudWatch 服务不仅是一个强大的监控工具,还允许您将操作系统、应用程序、自定义日志文件甚至 CloudTrail 日志等多种类型的日志路由到 CloudWatch Logs 的可靠存储中。
CloudWatch Logs 允许您将来自相同来源(日志流)的日志进行分组,然后使用筛选模式在这些组中进行搜索。筛选模式类似于 CloudWatch 版的正则表达式,允许您在日志流和日志组的不同字段中进行搜索。
使用订阅,您可以将特定日志流中的所有日志或仅符合特定筛选模式的日志推送出去。您可以将订阅数据推送到 Amazon Kinesis 流进行实时数据处理,或推送到 Lambda 函数进行事件驱动处理。您甚至可以使用 Lambda 函数将通过日志推送到一个或多个 CloudWatch 日志组的日志,直接推送到托管的 Elasticsearch 服务,以便通过 Kibana 界面进行更轻松的搜索和图形趋势分析。
在简要了解 CloudWatch Logs 之后,接下来让我们深入了解一下我们刚才提到的一些术语,以及它们在 CloudWatch Logs 中是如何协同工作的。
CloudWatch Logs 术语
当我们深入探讨 CloudWatch Logs 时,有一些术语是我们需要熟悉的,尤其是在接下来的练习和专业考试的上下文中:
筛选模式:限制哪些日志会被转发到 AWS 目标资源的过滤表达式。
日志事件:在 CloudWatch Logs 中记录的某项活动的记录被称为日志事件。事件消息必须是 UTF-8 格式。
日志流 和 日志组:共享相同来源的一组日志流在 CloudWatch Logs 控制台中被归为日志组。一个日志组中可以包含任意数量的日志流。
指标过滤器:通过使用指标过滤器,你可以从接收到的事件中提取数据。然后,你可以将这些数据转换为 CloudWatch 指标上的数据点。指标过滤器被分配给日志组。特定日志组中的所有日志流都会分配这些特定的指标过滤器。
保留设置:你的日志文件在 CloudWatch Logs 中的保留时间由保留设置决定。默认情况下,日志会被永久保存,不会过期。如果你不需要保存日志超过指定时间,这可能会导致额外的费用。你可以为每个日志组选择 1 天至 10 年之间的保留期限,一旦达到该保留期限,日志将自动删除:
图 14.4 – 从资源到 CloudWatch Logs 的日志流动
使用我们刚刚学到的术语,在前面的图示中,我们可以看到从 AWS 资源生成的日志如何成为日志流。一个或多个日志流会被合并形成一个日志组。日志流然后根据保留设置被保留或删除。
接下来,我们将学习如何使用 CloudWatch Logs 的一个功能 —— Insights,来分析 CloudWatch Logs 服务所捕获的数据。
CloudWatch 警报
除了将日志发送到存储并进行搜索,监控系统的另一个方面是当出现问题时接收警报。这些警报可以是简单的通知,让你知道某个服务或服务器没有响应。也可以是主动警报,提醒你所运行应用的平台的 CPU 或内存即将耗尽,需要在更大问题发生之前进行扩展。
你可以使用 CloudWatch 服务来监控单一指标或多个条件以创建警报。当基础资源的指标满足某个标准时,可以触发这些警报。在 CloudWatch 中,你可以创建两种类型的警报:指标警报和复合警报。
指标警报 监控 CloudWatch 的特定指标。它有一个监控阈值,该阈值在初次创建时设置,同时还有一个可以突破阈值的周期数,超过该周期数后会进入警报状态。一旦触发该警报状态,就可以配置相应的操作。可用的操作包括向 SNS 主题发送通知、执行 EC2 操作、执行 AutoScaling 操作,或在 Systems Manager 中创建 OpsItem 或事件。
复合警报 使用你创建的多个警报状态,以便在警报触发时创建特定条件。
一旦告警触发,你可以让告警执行各种操作,如下所示:
-
停止、终止或重启一个 EC2 实例。
-
让自动伸缩组进行扩容或缩容。
-
向 AWS SNS 主题发送通知消息。
图 14.5 – CloudWatch 告警示例
在准备 DevOps 专业考试时,有一些关于 CloudWatch 告警的事实你应该知道。虽然专业考试不会直接考察这些事实,但它们可以融入到更大的场景中:
-
告警名称只能由 ASCII 字符组成。
-
每个区域、每个账户最多可以创建 5,000 个告警。
-
你可以将告警添加到 CloudWatch 仪表板中。
-
你可以通过使用
SetAlarmState设置来测试告警(无论是启用还是禁用告警)。 -
CloudWatch 服务保存告警历史记录 2 周。
接下来,我们将创建一个 CloudWatch 告警并创建一些事件来触发告警。为了接收告警通知,我们还需要创建一个 SNS 主题。然而,如果你已经有一个 SNS 主题并希望使用该现有主题,可以跳过这一步。只要确保如果跳过这一步,你已经订阅了该主题。
创建一个 CloudWatch 告警
你应该已经有一个 EC2 实例,它正在生成从我们上一个练习中建立的指标。我们将使用这个实例的指标来监控告警,并通过施加负载使告警被触发。
为了接收告警通知,我们需要一个 SNS 主题,供我们订阅电子邮件地址:
-
打开终端并输入以下命令来创建
topic:topic was created successfully, then it should return something like this:{
“TopicArn”: “arn:aws:sns:us-east-2:470066103307:cwatch”
}
-
现在我们有了
topic,我们需要使用subscribe并填写我们的电子邮件地址:JSON statement telling you that the subscription is pending:{
“SubscriptionArn”: “待确认”
}
-
现在,我们需要进入我们的电子邮件账户,找到 SNS 服务刚刚发送的电子邮件。然后,我们必须点击上面写有确认订阅的链接。
-
创建了 SNS 主题后,我们可以返回 AWS 管理控制台,导航到
CW_Agent并记下实例 ID。一旦记下了这个信息,去导航栏左上方的服务下拉菜单中选择 CloudWatch 服务。打开 CloudWatch 服务的新标签页,我们稍后需要回到这个实例来测试我们的告警。 -
一旦进入 CloudWatch 服务,从左侧菜单中找到告警菜单设置。点击该菜单项以展开并查看子菜单项。展开后,点击所有告警,这样你就能进入告警页面。
-
在告警页面,点击标有创建告警的橙色按钮来创建新的告警。这将弹出创建告警的提示。
-
点击选择指标按钮。这将弹出一个对话框,您可以选择指标。找到自定义命名空间,然后点击CWAgent。进入CWAgent命名空间后,选择标记为ImageId, InstanceId, InstanceType的分组,并点击该链接。
-
找到名为
mem_used_percent的指标。然而,在点击选择框之前,请确保InstanceId与您之前找到的实例 ID 匹配。如果一切匹配,则选中该指标左侧的复选框,以便在警报中使用此指标。当您选择此指标或任何其他指标时,顶部将显示一个图形,显示您所选指标的记录值。点击页面底部的橙色选择指标按钮继续:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_14.6_B17405.jpg图 14.6 - 在创建 CloudWatch 警报时选择要监控的单一指标
-
向下滚动至
20。更改这些值后,点击橙色的下一步按钮。 -
现在,在通知屏幕上,使用以下选择。填充完所有部分后,向下滚动到页面底部并点击橙色的下一步按钮:
a. 警报状态触发器:在警报中。
b. 选择 SNS 主题:选择一个现有的 SNS 主题。
c. 发送通知到:选择您刚刚创建的 cwatch 通知主题。
-
接下来,在
chapter14处作为警报名称。点击橙色的下一步按钮。 -
最后,在预览并创建页面,向下滚动到页面底部,逐一检查页面上的各项值。如果一切看起来正常,请点击页面底部的橙色创建警报按钮。
-
现在我们已经创建了警报,接下来需要对其进行测试。我们可以通过使用 CLI 更改
SetAlarmState来进行测试。然而,我们将通过对 EC2 实例本身进行压力测试来测试警报。找到之前打开的包含实例 ID 的标签。选择该实例旁边的复选框,然后在 AWS 管理控制台的实例屏幕顶部,找到标有操作的下拉菜单。点击操作菜单以显示子菜单项。选择连接。 -
在连接屏幕上,使用会话管理器连接到实例。进入会话管理器标签页后,点击底部的橙色连接按钮,开始我们在 EC2 实例中的会话。
-
现在我们已经进入实例,接下来需要安装一个包来帮助我们对实例进行压力测试并触发警报。运行以下命令安装该包:
sudo apt-get install -y stress -
一旦安装了
stress包,我们可以使用以下选项来运行它,进行压力测试实例的内存:stress –vm 2 –vm-bytes 126M -
当实例的内存使用百分比超过 20%并持续 5 分钟后,您应该会收到一封电子邮件通知,通知将发送到您在 SNS 主题中订阅的电子邮件地址。
现在,我们已经看到 CloudWatch 服务如何收集和聚合日志,并通过发送警报帮助我们进行监控工作,接下来我们将介绍我们监控和调试工具包中的另一个工具:AWS X-Ray。
使用 X-Ray 添加应用程序跟踪
X-Ray 是用于监控现代 Web 应用程序的服务。现代应用程序本质上是面向服务的应用程序。这些应用程序可以是无服务器架构应用程序或运行在容器中的应用程序。在这些现代应用程序中,应用本身被拆分成多个部分。虽然这带来了许多优势,包括水平扩展的便捷性和充分利用云原生服务,但也会带来一些挑战。了解错误最终对您的服务(或业务)产生的影响变得更加复杂。
跟踪功能使您能够通过以下方式在现代应用程序中连接各个环节:
-
发现多个服务。
-
获取有关单个操作的洞察。
-
查看段内隔离的问题。
-
对特定问题进行根本原因分析。
图 14.7 – X-Ray 跟踪如何将各个部分拆分成段
跟踪功能使您能够快速查看并轻松检查特定 API 调用或特定用户发生了什么。
一个跟踪是一个全面的视图,它从客户的角度封装了从客户创建交易的端到端事务。
到此为止,X-Ray 会将跟踪分解成多个段。段是来自单个服务器的片段。
现在我们已经理解了跟踪,这是 X-Ray 中的一个主要概念,让我们来看一下 X-Ray 服务本身是如何工作的。
然后,跟踪被分解成不同的段。一个段提供了资源的名称、请求的具体信息以及正在执行的工作。段也可以显示在该段中发生的问题,如错误、故障和异常。
X-Ray 服务是如何工作的?
您首先将 X-Ray SDK 集成到您的应用程序中。可以针对不同的语言(如 Python、Java 和 Node.js)进行定制。接下来,一个实例上的守护进程开始收集数据。然后,守护进程将这些数据发送到 X-Ray 后端。在 X-Ray 后端,跟踪数据被记录。不同服务可能会在不同时间点提供数据,但 X-Ray 服务可以通过使用跟踪 ID将所有这些信息拼接在一起。一旦收集到跟踪数据,X-Ray 服务会创建一个名为服务地图的汇总视图。最后,X-Ray 提供了一套分析功能,允许您深入挖掘并回答三个重要问题。
另一个需要注意的事项是,X-Ray 服务是云无关的。这意味着你编写的代码不必仅在 AWS 云中运行。代码可以在其他地方运行,以利用 X-Ray 服务的跟踪功能,例如在开发者的笔记本电脑上或企业数据中心中。前提是运行环境能够连接回 AWS X-Ray 服务,并具有一组凭证以使其能够运行。
X-Ray 帮助你解答三个问题
X-Ray 服务帮助开发者解答三个特定问题:
-
我的应用程序运行得怎么样?
-
为什么我的应用程序表现成这样?
-
谁受到了这些问题的影响?
X-Ray 界面的图形化展示,表现为服务图,使你和你的开发团队能够看到应用程序用户在哪些地方消耗了资源。它还会给出不同资源的响应时间,让你看到是否某个特定资源是延迟或问题的根源。
现在我们了解了 X-Ray 如何帮助我们开发和排查在 AWS 云上运行的应用程序,让我们来看一下 X-Ray 服务如何与无服务器服务集成。
X-Ray 和无服务器服务
在与无服务器服务,特别是 Lambda 一起使用 X-Ray 时,X-Ray 服务提供了一些 CloudWatch 监控无法提供的独特优势。X-Ray 让你获取 AWS Lambda 冷启动的时间信息。
当 Lambda 服务首次收到请求执行一个函数时,它需要准备执行环境。这意味着它需要从存储代码的 S3 桶中获取代码,并分配运行时环境,包括内存和 CPU。经过最后的初始化步骤后,Lambda 就可以执行处理程序。
在 Lambda 函数上实施 X-Ray
在第十二章中,我们讲解了 AWS Lambda。这是 AWS 提供的函数即服务(Function-as-a-Service)。我们可以将自己构建的函数启用 X-Ray 服务,以查看来自 AWS X-Ray 的跟踪和段信息:
注意
如果你还没有完成第十二章中的创建 Lambda 函数练习,或者如果你已经从账户中删除了该函数,请返回并重新执行/重新部署该练习。我们将使用这个函数来继续进行 AWS X-Ray 练习。
-
登录到AWS 管理控制台并导航到Lambda服务。
-
一旦进入
my_word_count_python。点击该函数的名称以进入此函数。如果你没有创建此函数,或者在执行练习后删除了它,你有两个选项。你可以返回并重新创建此函数,或者你可以尝试按照你在帐户中创建的其他函数的步骤来实施 X-Ray 跟踪服务。 -
现在你已经进入Lambda服务,向下滚动页面,直到找到水平菜单栏,然后点击名为配置的菜单项:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_14.8_B17405.jpg
图 14.8 – Lambda 水平菜单中的配置高亮显示
-
选择配置菜单项会在屏幕左侧弹出一个垂直菜单。找到名为监控和操作工具的选项并点击它。这会将监控和操作视图显示出来。在该视图的右上角,选择编辑。
-
在编辑监控工具页面,找到标有AWS X-Ray的部分。点击滑块按钮,为这个 Lambda 函数启用 X-Ray 跟踪。然后,在页面底部点击保存:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_14.9_B17405.jpg
图 14.9 – 将 AWS X-Ray 添加到我们的 Lambda 函数中
-
点击保存将带你回到配置标题下的监控和操作工具页面。你应该会看到活动跟踪现在已经启用。启用跟踪后,让我们运行一个测试,看看 X-Ray 是如何工作的。从水平导航栏中,点击名为测试的菜单项。
-
如果需要创建另一个测试事件,你可以使用默认数据并将其保存为
XRtest。如果你仍然保留了上一个练习中的 Lambda 函数,那么你应该已经创建了名为Test1的测试事件。创建好测试事件后,点击测试事件部分右上角的橙色测试按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_14.10_B17405.jpg图 14.10 – 测试事件部分右侧的橙色测试按钮
-
一旦测试事件运行完毕,我们可以点击水平菜单中的监控菜单项,进入监控页面。默认情况下,该页面会显示指标部分。然而,我们将点击名为跟踪的项,以便查看生成的 X-Ray 跟踪信息。
-
在跟踪屏幕上,我们现在可以看到一个服务地图,它与函数的跟踪 ID 一起生成,相关的跟踪信息如下表所示:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_14.11_B17405.jpg
图 14.11 – 生成的 X-Ray 服务地图
-
返回到测试部分,点击测试事件两到三次。当 Lambda 调用完成后,你可以返回到监控标签并再次查看追踪表格:
图 14.12 – 同一 Lambda 函数的追踪表格
如果你连续多次点击了测试事件,那么在表格中的响应时间列,你应该会看到一些函数的响应时间明显快于其他函数。这是因为这些函数不需要冷启动。
我们刚刚完成了一个练习,它将之前运行的 Lambda 函数与 X-Ray 追踪结合,帮助我们获取更多信息。我们可以看到调用的路径,从客户开始,以及函数首次响应所需时间的变化。
接下来,让我们总结一下本章关于 AWS CloudWatch 和 X-Ray 的内容。
总结
在本章中,我们探讨了在不同环境和应用程序中进行监控的重要性,尤其是 CloudWatch 服务。
在下一章中,我们将继续深入研究 CloudWatch 服务,重点关注该服务的监控和指标功能。我们还将学习如何使用 AWS EventHub 自动化响应 CloudWatch 服务。
复习问题
回答以下问题以测试你对本章的理解:
-
你被一家公司聘请,帮助 DevOps 团队。该团队目前需要帮助进行监控。公司希望使用所有原生的 AWS 服务,而不是第三方服务。目前有一个生产环境中的 RDS PostgreSQL 数据库需要密切监控,因为它是客户订单的主要数据存储。可以使用哪些服务来实时监控和告警,如果 IOPs 指标超过正常水平,并允许 DevOps 团队增加更多 IOPs?(选择两个)
a. Amazon CloudWatch
b. Amazon CloudTrail
c. Amazon Simple Notification Service
d. Amazon Route 53
-
你为一家公司开发了一个现代应用程序,该应用程序使用 AWS Lambda 函数,在有人将文件放入 S3 存储桶时被调用。公司希望更好地了解该应用程序,并要求你将 AWS X-Ray 集成到 Lambda 函数中,以便他们能看到追踪信息。为了确保所有未加 instrument 的服务调用你的 Lambda 函数时也能进行追踪,你应该如何操作?
a. 在 AWS Lambda 函数配置下,启用开始追踪。
b. 在 AWS Lambda 函数配置下,启用活动追踪。
c. 当 Lambda 函数由未加 instrument 的服务调用时,不支持追踪。
d. 当 Lambda 函数由未加 instrument 的服务调用时,不需要额外配置就能记录追踪。
-
你被安排加入一个使用主要基于无服务器架构的团队,该架构由 Lambda 函数组成。他们希望能够在软件开发生命周期(SDLC)的测试阶段分析这些函数的调用。以下哪两种工具可以帮助他们实现这一目标?
a. Amazon CloudTrail
b. Amazon CloudWatch
c. Amazon Inspector
d. Amazon X-Ray
审查答案
-
a, c
-
b
-
b, d
第十六章:CloudWatch 指标与 Amazon EventBridge
指标是 AWS CloudWatch 的核心内容之一。它们记录服务的性能,并可根据提供的数据触发警报和操作。虽然有大量现成的指标可用,但也可以创建自定义指标。这进一步扩展了 CloudWatch 的功能。
利用 Amazon EventBridge 捕获的指标,当它们达到某些阈值时,便是一项强大的能力。作为一名 DevOps 工程师,这是一个非常有力的工具,可以帮助你自动化系统,使其具备自愈能力,并能够根据客户生成的容量需求不断扩展和收缩。这些自动响应可以由本地 AWS 服务或第三方系统触发。这在日常监控和创建某些事件发生时的例程中尤其有用。
本章将涵盖以下主要内容:
-
更详细地了解 CloudWatch 指标
-
AWS 服务的 CloudWatch 基本指标
-
使用 CloudWatch 指标创建仪表板
-
Amazon EventBridge 概述
更详细地了解 CloudWatch 指标
在上一章中,我们了解了 CloudWatch 服务,并检查了它提供的一些功能。我们甚至在创建警报时讨论了指标的主题。
在应用程序和监控中,指标即数据。很多时候,这些是不断流动的大量数据。这些数据不仅从技术角度使用,也从业务角度使用,用来查看公司如何表现。
指标是 CloudWatch 的基础。当记录时,指标代表一组按时间排序的数据点,这些数据点随后会发布到 CloudWatch 服务中。
指标存在于单一区域。这意味着,如果你有一个多区域环境,那么不同资源的指标将被收集并存储在资源创建和运行的同一地区。尽管你不能删除指标,但它们会在 15 个月后自动过期。
命名空间是 CloudWatch 指标的容器。你将找到指标的命名空间与许多服务的 AWS 服务名称相同:
图 15.1 – CloudWatch 控制台中的命名空间
PutMetricData 命令与 CloudWatch 代理。
指标数据会在特定时间段内聚合成统计数据。这些聚合通过命名空间、指标名称、维度和度量数据点相关联。你可以通过五种方式来衡量统计数据:平均值、最小值、最大值、总和或样本数。当选择样本数时,CloudWatch 会计算数据点的数量。
CloudWatch 的一个优点是,即使资源没有运行,您仍然可以访问指标。您甚至可以访问已终止的资源的指标,例如已终止的 EC2 实例、已删除的 Elastic Load Balancers、Fargate 容器和已删除的 EBS 卷。
在 CloudWatch 中查看您的指标
您可以通过登录 AWS 管理控制台,进入CloudWatch服务,并从左侧菜单中选择Metrics来查看您的指标图表:
图 15.2 – CloudWatch 指标图表示例
在InstanceID、functionName、Invocations、Namespace等字段中,其中一个不起作用的是通过Amazon 资源名称(ARN)进行搜索。
使用 CloudWatch 指标流进行流式处理指标
正如我们之前所说,CloudWatch会保存您的指标数据 15 个月,然后删除这些数据。如果您希望将这些数据推送到像 S3 存储桶或数据湖这样的长期存储中,或者通过Amazon Kinesis Data Firehose推送数据,可以通过指标流实现。您还可以选择将您的指标数据通过指标流推送到第三方提供商。
CloudWatch 指标中的数据可以以 JSON 或 OpenTelemetry 格式推送到指标流。
现在我们已经了解了 CloudWatch 指标流是什么,接下来让我们看看为什么我们会使用指标流。
为什么要通过指标流将您的指标推送到第三方?
过去,专注于监控和仪表盘等服务的合作伙伴依赖于通过 CloudWatch 服务的 API 调用,将数据从您的账户导入他们的服务。随着账户的增长,这可能会增加您的额外费用。GetMetricData API 调用每 1,000 次请求收费 0.01 美元。指标流通过每 1,000 次请求仅收费 0.003 美元,大大降低了此成本。
现在我们已经了解了如何使用指标流存储或共享我们的指标,接下来让我们看看 CloudWatch 指标中有哪些不同类型的指标。
AWS 服务中的 CloudWatch 基本指标
CloudWatch 会自动免费监控一组基础指标,每 5 分钟更新一次。大多数 AWS 服务会自动将指标免费发送到 CloudWatch 指标中。这些包括 EC2、S3、EBS、Kinesis、Lambda 等基础服务。
EC2 服务的基本监控
当实例创建时,七个指标会以每 5 分钟一次的频率推送到 CloudWatch。你可以将这个频率更改为 1 分钟一次,额外收费。CloudWatch 还提供二进制状态检查,作为其免费套餐的一部分。使用此检查是查看实例是否正在运行的重要手段,但它并不是检查应用程序是否正常运行的好方法。状态检查可以作为早期预警,帮助识别如 AMI 问题、实例意外(或故意)终止,甚至可用区或区域故障等情况。
除了状态检查外,EC2 指标还分为三类标准类别:
-
CPU
-
磁盘 I/O
-
网络
CPU 指标包含 CPU 使用情况的指标数据。这是你可以用来触发 AutoScaling 事件的主要指标之一,帮助你判断实例是否开始接近其计算能力的上限。对于突发性能实例,例如 EC2 T 系列实例,你还会获得关于 CPUCreditUsage 和 CPUCreditBalance 的指标数据。
记住
对于突发性能 EC2 类型实例,你每小时会获得一定数量的 CPU 积分,这些积分可以累计,直到需要时使用。当实例处理需要比基准更多 CPU 的任务时,实例将使用其 CPU 积分余额。
几乎所有来自 AWS 的服务都与 CloudWatch 指标集成。当你构建和部署应用程序时,请考虑一些需要监控的最关键指标,以确保应用程序和环境的基本健康。这些可以包括以下内容:
-
EC2 实例的
CPUUtilization -
Lambda 函数的错误数量
-
Lambda 函数的持续时间
-
RDS 实例的
DatabaseConnections -
RDS 实例的
DiskQueueDepth -
S3 桶的
NumberOfObjects -
Elastic Load Balancer 的
ActiveConnectionCount -
Elastic Load Balancer 的
HealthyHostCount -
Elastic Load Balancer 的
TargetResponseTime
现在我们已经查看了 CloudWatch 为我们提供的一些主要指标以及常见服务,接下来让我们看看如何在 CloudWatch 中使用自定义指标。
在 CloudWatch 中使用自定义指标
AWS CloudWatch 服务不仅允许你查看和监控来自资源本身的指标数据,如 CPU、内存和网络使用情况。它还允许你创建自定义指标,这些指标可以与应用程序中的错误数量相关联,或直接与业务测量的关键绩效指标挂钩。
CloudWatch 中的高分辨率指标
在监控你的自定义指标时,有时 1 分钟的间隔不足以提供足够的详细信息。通过 put-metric-data API,无论是通过 CLI 还是从 SDKs,你都可以以每秒 1 次的间隔发布自定义指标。
如果你的应用程序可能会出现短时的高峰,而这些高峰的行为无法通过 CloudWatch 指标的默认 1 分钟间隔来捕获,那么启用高分辨率指标可以为你提供这种可见性。如果你需要实时监控,那么高分辨率指标同样可以满足这一需求。
在查看了我们可以使用的高分辨率指标后,让我们看看如何创建那些在我们自己场景中更加有用的自定义指标。
在 CloudWatch 中创建自定义指标
CloudWatch 指标允许你为对你重要的项创建指标和命名空间。你可以通过使用 AWS 为特定语言提供的 SDK,或使用 AWS CLI 和 put-metric-data 命令,将其集成到你的脚本中。
你可以为日志文件中的 ERRORS 实例等内容定义指标,或者跟踪像电商应用程序结账时购物车中商品数量等项目。
当你创建并发布自定义指标时,可以将其定义为标准分辨率,这样它将以 1 分钟为间隔进行度量,或者你也可以将其定义为高分辨率指标,这样它将以 1 秒为间隔进行度量。
现在,让我们使用 Lambda 函数来创建一些自定义指标。
发布自定义指标
自定义指标可以通过多个服务发布,包括 AWS Lambda、Elastic Beanstalk、Amazon EC2,甚至是像 ECS、EKS 或 Fargate 这样的容器服务。
对于我们的动手示例,我们将使用 Lambda 函数来创建自定义指标,然后将其发送到 AWS CloudWatch 服务。我们的示例场景包含一些示例代码,其中我们尝试跟踪某个特定营销活动的注册情况。通过这种方式,营销部门和高层管理团队几乎可以实时地知道这个特定营销活动的投入资金有多有效。我们将这些指标推送到名为 custom_metric 的 CloudWatch 指标中。
我们将在示例中使用的 Lambda 代码位于本书的 GitHub 仓库中,位于 Chapter-15 文件夹下,文件名为 cw_events.py。我们还包括了一个简化版的函数,它不包含 CloudWatch 事件的部分:
cw_events.py:
import boto3
import random
# Resources
cw = boto3.client('cloudwatch')
# The Lambda handler
def lambda_handler(event, context):
put_metric = custom_metric()
return put_metric
###################################
# Create CW Custom Metric
###################################
def custom_metric():
create_metric = cw.put_metric_data(
Namespace='custom_metric',
MetricData = [
{
'MetricName': 'Signups',
'Dimensions': [
{
'Name': 'EMAIL_CAMPAIGN',
'Value': 'cableTV_spot2'
},
],
'Unit': 'None',
'Value': random.randint(1,100)
},
],
)
return create_metric
创建自定义指标并将其发送到 AWS CloudWatch 服务的步骤如下:
-
登录到 Amazon Management Console 并导航到 Lambda 服务。
-
一旦进入 Lambda 服务,点击橙色的 Create function 按钮。
-
一旦你进入
Author from scratch,在custom_metric下 -
Python 3.8 -
权限:创建一个具有基本 Lambda 权限的新角色:
图 15.3 – 创建 Lambda 函数的基本信息
-
填写完所有这些选项后,按下橙色的 Create function 按钮。
-
一旦函数创建完成,进入
chapter-15目录中的lambda_function.py文件,替换lambda_function标签页中的内容。替换代码后,点击代码窗口顶部的部署按钮。这样可以确保未部署更改消息消失,并替换为绿色的已部署更改消息:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.4_B17405.jpg图 15.4 – 显示已部署更改的 Lambda 函数
-
现在我们已经创建了函数,可以开始创建测试事件,这样我们既可以测试函数,又可以在 CloudWatch 指标中看到自定义指标。点击橙色的测试按钮来配置测试事件。无需特殊的测试数据,只需将事件名称设置为测试,然后点击对话框底部的橙色创建按钮。
-
在测试函数之前,我们需要再给函数添加一个权限——
PutMetricData的权限。在Lambda垂直菜单中,点击配置。进入配置设置后,点击左侧菜单中的权限菜单项。这将显示执行角色在主窗口中。点击执行角色标题右侧的编辑按钮。 -
这将带你到基本设置页面。页面底部,在现有角色的名称下方,应该有一个蓝色链接,允许你查看 custom_metric_role在IAM 控制台中的信息。点击此链接后,将会为 IAM 服务打开一个新标签页。
-
当你在
服务中的角色上时:选择 | CloudWatch -
操作:筛选 | PutMetricData:
图 15.5 – 从 IAM 向我们的 Lambda 角色添加内联策略
-
添加额外权限后,点击页面底部的蓝色审核策略按钮。
-
将策略命名为
PutMetricData,然后点击页面底部的蓝色创建策略按钮。 -
现在我们已经修改了 IAM 角色,使其具备了
PutMetricData权限,返回到包含 Lambda 函数的标签页。你应该仍然在基本设置页面上。点击屏幕底部的橙色保存按钮,这将带你回到主 Lambda 屏幕的配置菜单。点击水平菜单顶部的代码标签页。现在,按下橙色的测试按钮,将测试事件发送到我们的 Lambda 函数。 -
在顶部搜索栏中,转到
CloudWatch并右键点击它,以在新标签页中打开。 -
在自定义命名空间的左侧菜单中的
custom_metric:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.6_B17405.jpg图 15.6 – 我们在自定义命名空间中的自定义指标
-
点击 custom_metric 命名空间。此时,我们将看到我们的二级命名空间,即 EMAIL_CAMPAIGN。点击该值将跳转到指标数据页面。勾选 cableTV_spot2 旁边的框,查看图表上绘制的数据。由于我们在函数中使用了随机值,因此该数字会有所变化。
有了这些,我们已经创建了一个 Lambda 函数,它将创建并发布一个自定义指标到 CloudWatch 指标中。接下来,我们将看看如何将这个自定义指标与其他指标一起,纳入到 CloudWatch 仪表板中,为我们自己、我们的团队以及其他人提供快速查看环境状态的功能。
使用 CloudWatch 指标创建仪表板
在 CloudWatch 中查看单个指标可以提供许多有价值的细节。然而,有时,通过快速浏览一个单一的视图,将最相关的指标一并展示出来,会更加有用。CloudWatch 仪表板允许我们快速而轻松地创建这些视图——不仅展示我们账户中 Amazon 资源创建的指标,还包括自定义指标,以及文本和超链接,以便在紧急情况或其他有用的文档中参考运行手册。
CloudWatch 服务甚至为许多最常用的 AWS 服务(如 DynamoDB、EC2、Lambda、S3、EBS 等)提供了自动仪表板。这些预配置的仪表板都是互动式的,可以基于自定义的日期范围查看。
你甚至可以将你创建的仪表板与那些没有直接访问你 AWS 账户的人员共享。这可以通过几种方式实现。第一种方式是将仪表板投射到大屏幕上,这样一个用户团队,或者任何进入显示仪表板屏幕或投影的房间的人,都能查看仪表板上展示的指标和图表。
第二种方法是内建的功能,允许使用用户名和密码与指定的电子邮件地址共享仪表板。
分享仪表板访问权限的第二种方式对于当你试图为某个项目的相关方提供实时指标时非常有用。这个用户可能不太懂技术,但他需要正确的业务信息来帮助做出决策。在本章之前讨论的自定义指标,可以让业务相关方在不请求生成特定报告的情况下,随时查看特定的关键绩效指标(KPI)。
当你在 CloudWatch 仪表板中创建一个仪表板时,它将全球可用。这是因为仪表板不是区域特定的。
有了这些,我们已经了解了仪表板如何让我们作为 DevOps 工程师、开发团队,甚至是项目的相关方,快速查看我们的环境或项目的状态。接下来,让我们通过实际操作来创建一个仪表板。
创建一个基础仪表板来监控我们的资源
让我们使用之前创建的一些指标,并将它们集成到自定义仪表板中:
-
打开Amazon 管理控制台并进入CloudWatch服务。如果你失去会话,可能需要重新登录。同时,确保你在俄亥俄地区(或你用来创建资源的其他地区):
console.aws.amazon.com/cloudwatch/。 -
进入 CloudWatch 服务后,找到并点击左侧菜单顶部的仪表板菜单项。
-
这将带你进入自定义仪表板屏幕。我们将通过点击橙色的创建仪表板按钮开始创建仪表板的过程:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.7_B17405.jpg
图 15.7 – 创建仪表板按钮
-
按下
Chapter15。然后按橙色的创建仪表板按钮来关闭对话框并开始构建仪表板。 -
应该会弹出一个新的对话框,要求我们向仪表板添加小部件。我们将从
Explorer小部件开始:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.8_B17405.jpg图 15.8 – 向 CloudWatch 仪表板添加小部件
-
通过点击数字小部件来开始你的仪表板。滚动到自定义命名空间并点击custom_metric命名空间。将周期从5分钟更改为1天,以便仪表板能保持数据。点击EMAIL_CAMPAIGN次级命名空间并勾选cableTV_spot2框。一旦选中该值,点击对话框底部的橙色框,标记为创建小部件:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.9_B17405.jpg
图 15.9 – 为数字小部件添加值
-
一旦我们的数字小部件被添加,点击橙色的添加小部件按钮,将另一个小部件添加到仪表板中。
-
选择
custom_metric搜索词,以便我们可以找到上一个练习中创建的 Lambda 函数的指标。滚动通过自定义命名空间,找到AWS 命名空间。你可以点击Lambda | 按资源或Lambda | 按函数,因为它们应该都包含相同的指标。找到调用次数指标并勾选函数名左侧的复选框。一旦勾选,点击橙色框,然后点击橙色的创建小部件按钮。 -
我们通过点击
custom_metric lambda函数来向仪表板添加另一个小部件。它应该被命名为/aws/lambda/custom_metric。使用复选框选择该日志组。一旦选择了日志组,点击橙色的添加到仪表板按钮。 -
你将回到仪表板页面,现在应该包含三个小部件。点击仪表板顶部的蓝色保存仪表板按钮。现在你有了一个可以查看和分享的工作仪表板:
图 15.10 – 我们创建的 Chapter15 仪表板
现在我们已经学习了如何将我们的度量指标整合到仪表板中,以便我们可以快速轻松地监控系统,并查看我们需要一眼看到的任何自定义度量指标,接下来我们来看一下如何使用 CloudWatch 通过Amazon EventBridge服务启动事件驱动架构。
Amazon EventBridge 概述
Amazon EventBridge是一个无服务器事件驱动总线,它使得从各种来源获取和处理数据变得容易。这些来源包括 AWS 服务、您的应用程序和第三方 SaaS 提供商。它消除了在服务之间编写点对点集成的复杂性。EventBridge 是 AWS 的托管服务,这意味着您不需要担心随着需求的波动而需要更多或更少的服务,EventBridge 服务会为您处理这些。
图 15.11 – 从事件到目标的 AWS EventBridge 流程
事件源几乎可以是任何 AWS 服务、自定义应用程序或 SaaS 应用程序。
对于 SaaS 应用程序,有一个特别支持的合作伙伴应用程序,称为事件源。此事件源为第三方 SaaS 提供商和您的 AWS 账户之间提供逻辑连接,无需预配任何跨账户 IAM 角色或凭证。
事件总线是EventBridge 服务的核心。默认事件总线用于处理 AWS 服务事件。事件总线可以为您的应用程序自定义创建。
一旦你设置了事件总线,你就可以创建规则。通过使用规则,你可以匹配事件总线检查过的事件元数据或有效负载中的值。规则随后决定哪些事件应该被路由到哪个目标:
图 15.12 – 一个示例事件及其触发的规则
一旦触发了规则,你可以将一个或多个目标与该规则关联。目标是各种 AWS 服务,如 Lambda 函数、Step Functions、Kinesis Streams 以及 ECS 或 Fargate 集群。
注意
CloudWatch Events 服务现在被称为 Amazon EventBridge。如果您之前使用过 CloudWatch 事件,那么该功能仍然可以通过 EventBridge 中的默认事件总线使用。
现在我们已经了解了 Amazon EventBridge 服务,接下来让我们看一下 EventBridge 服务上自动施加的一些限制。
EventBridge 服务限制
当你开始使用 EventBridge 构建事件驱动服务时,最好记住最初对 EventBridge 服务施加的服务限制。这可以帮助你在同时向事件总线发送过多事件的情况下,也能帮助你在构建应用程序时,因为你知道在一个地区默认允许多少个事件总线和规则:
表格 15.1 – AWS EventBridge 服务限制
注意
所有这些限制都是软限制。这意味着它们可以通过向 AWS 提交服务请求来提高。
现在我们已经了解了工作时的服务限制,让我们来看看如何使用 AWS EventBridge 构建事件驱动架构。
使用 EventBridge 构建事件驱动架构
现代云应用程序基于解耦服务。
事件驱动架构有三个关键组件:事件生产者、事件消费者和事件路由器。生产者是产生事件并将其发送到路由器的服务或触发器。路由器或事件总线会过滤特定的事件,并将特定的事件发送到事件消费者。
事件驱动架构的多重好处
当你使用解耦架构时,意味着每个组件执行特定的任务,你将获得多个好处:
图 15.13 – 一个服务使用 EventBridge 和自定义规则推送到多个目标
使用 EventBridge 捕获 AWS 服务事件
我们可以使用 EventBridge 服务通过规则和默认事件总线自动触发事件。让我们从捕获每当 EC2 实例状态变化时并将其发送到日志文件开始,这样我们就可以查看该事件:
-
登录到AWS 管理控制台,并导航到CloudWatch服务。从左侧菜单中找到并展开事件菜单。在事件子菜单中,点击规则链接。
-
一旦规则屏幕出现在主窗口中,点击蓝色的创建规则按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.14_B17405.jpg
图 15.14 – EventBridge 规则页面,带有创建规则按钮
-
现在我们应该处于名为步骤 1:创建规则的界面。在事件源标题下,确保选择了事件模式旁边的单选按钮,这样我们就可以开始构建我们的模式了。
-
对于我们的事件模式,使用
EC2 服务。然后,在事件类型选择下拉菜单中,选择EC2 实例状态变化通知。 -
我们不想要来自 EC2 的所有事件;我们只想知道何时实例启动或终止。选择 特定状态,然后选择 已终止 和 待处理 状态作为规则的状态。你需要使用下拉菜单两次来填充这两个选择项。保留 任何实例 旁边的单选框:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.15_B17405.jpg
图 15.15 – EventBridge 规则的事件模式已填充
-
接下来,我们可以继续处理 步骤 1 的右侧,在那里你可以找到 Targets(目标)标题。点击 添加目标 按钮。
-
在第一个目标下,找到
EC2_STATE:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_15.16_B17405.jpg图 15.16 – 创建自定义日志组作为我们的 EventBridge 目标
-
向下滚动到页面底部,点击蓝色按钮 配置详细信息。
-
对于规则的名称,使用
chapt15-ec2。你可以插入描述。如果你填好了名称和描述,点击蓝色的 创建规则 按钮。 -
我们的规则应该出现在
ec2实例上并触发规则。不要关闭浏览器窗口——我们稍后还要返回查看 CloudWatch 日志组。 -
打开终端窗口,使用
create-instance命令快速启动一个实例(如果你完成了 第十四章 的练习,CloudWatch 和 X-Ray 在 DevOps 中的角色,这些命令应该对你来说有些熟悉):# Capturing the AMI to a variable InstanceId so that you can quickly reference it when terminating your instance in the next step. -
大约 2 到 5 分钟后,我们将终止实例以创建另一个事件供规则使用:
aws ec2 terminate-instances \ --instance-ids {YOUR INSTANCE ID} \ --region us-east-2 -
现在,我们应该再等一两分钟,让实例完全终止。当它开始终止时,回到之前打开 Amazon 管理控制台 的浏览器。
-
在 Amazon 管理控制台 中,我们应该已经进入 CloudWatch 服务,因此我们只需要在 日志 下的 日志组 子菜单中找到它并点击。
-
现在,你应该能够找到我们快速创建的自定义日志组,名为
EC2_STATE。如果你所在区域有太多日志组,可以简单地搜索EC2_STATE,它应该会出现。点击日志组的名称,我们可以查看 EventBridge 为我们生成的内容。 -
现在,你应该在日志组中看到两条日志条目。一条对应于待处理事件,另一条对应于终止事件。
通过这一节,我们已经学习了如何利用在 AWS 账户中发生的事件以及 AWS EventBridge 服务来构建事件驱动架构。尽管我们在实践练习中只使用了一个简单的示例,但这可以扩展到执行诸如发送 SNS 通知并同时记录日志条目,甚至在这是一个关键基础设施的情况下创建新资源等操作。现在,让我们回顾一下本章中学到的所有内容。
总结
在本章中,我们深入探讨了 AWS CloudWatch 服务。我们关注了指标以及构成一个指标的内容。我们了解了 AWS 提供的不同类型的指标,从 Free Tier 的基本指标开始,然后是详细指标,最后学习了如何创建自定义指标。我们还学会了如何使用这些指标在 CloudWatch 中创建自定义仪表板,并发现这些仪表板不仅可以与拥有 IAM 访问权限的团队成员共享,还可以与我们 AWS 账户外的其他人共享。
我们还研究了 EventBridge,这是取代了 CloudWatch Events 的服务。我们学习了如何使用事件总线来处理 AWS 服务、定制应用事件,甚至是 SaaS 提供商,从而推动事件驱动架构的发展。
在下一章中,我们将研究来自不同 Amazon 服务的各种类型的日志。这包括 VPC 流日志、Elastic Load Balancer 日志、CloudTrail 日志,以及这些日志如何帮助我们排查应用程序或安全事件中的问题。
问题
-
你被一家企业聘用,帮助在 AWS 上开发一个电子商务应用程序。公司利益相关者希望了解通过该应用程序下单的订单数,并且希望以秒级粒度获取这一信息。为了获取这个信息,你需要使用 AWS CLI 创建一个自定义的 CloudWatch 指标。你知道默认情况下,自定义指标的粒度是 1 分钟。你如何让应用程序以子分钟间隔发送自定义指标?
a. 使用 AWS CLI
put-metric-data命令发布数据,并将StorageResolution选项设置为1秒,以将指标指定为高分辨率指标。b. 更新 CloudWatch 代理配置文件,然后添加
line high-resolution: true。c. 转到 Amazon 管理控制台中的 CloudWatch 服务的图表,并将分辨率设置为 1 秒的间隔。
d. 向 AWS CLI
put-metric-data命令添加flag –dimensions=1,以指定一个高分辨率指标。 -
你目前在一家中型电子商务公司工作,该公司使用 AWS Lambda 和 DynamoDB 构建了一个无服务器购物车系统。公司的一位高管要求你创建并分享一个仪表板,展示每个购物车的购买数量和每个购物车的弃购数量。董事会成员目前没有 IAM 账户。你如何以尽可能简单且成本效益高的方式向董事会成员提供实时数据访问权限?
a. 使用 Amazon Cognito 的社交登录。让 Cognito 承担一个具有访问特定仪表板权限的角色,以便董事会成员可以访问。
b. 为每个董事会成员创建 IAM 用户。创建一个 IAM 组,该组有权限访问 CloudWatch 仪表板,但设有条件,只显示他们需要查看的特定仪表板的 ARN。
c. 收集董事会成员的电子邮件。通过电子邮件访问功能,使用用户名和密码共享对 CloudWatch 仪表板的访问权限。
d. 收集董事会成员的电子邮件。为 CloudWatch 仪表板集成 SAML。允许董事会成员使用单点登录访问特定的仪表板。
审查答案
-
a
-
c
第十七章:生成的各种日志(VPC 流日志、负载均衡器日志、CloudTrail 日志)
日志是一条信息流,来自不同的源。来自负载均衡器的日志可以成为宝贵的数据源或故障排除的资源。了解如何启用这些资源对于设置或运行您的环境至关重要。在 AWS 环境中执行的任何操作,无论是通过 AWS 管理控制台、CLI 还是 SDK,都会通过底层 API 调用记录到 CloudTrail 中。作为一名 DevOps 工程师,了解是谁以及什么在对环境进行更改并能够检索这些数据,尤其是在请求时,是非常重要的。
在本章中,我们将讨论以下主要内容:
-
AWS CloudTrail 的强大功能
-
启用弹性负载均衡器日志
-
使用 VPC 流日志
-
清理资源
之前讨论的日志
到目前为止,我们主要讨论的是从应用程序本身生成的日志。还包括一些在之前使用 CloudWatch Logs 时 AWS 提供的日志,它们是这些日志的包装器;然而,这些大部分仍然是应用程序和 AWS 服务日志。
当我们想要了解用户如何与我们的环境进行交互时,无论是网络环境还是他们如何在我们的帐户内添加和删除资源时,我们将无法在应用程序日志中找到这些信息。相反,我们必须查看 AWS 中的其他日志。
了解哪些日志适用于哪个目的,还可以帮助我们保护环境的其他服务,例如GuardDuty。
注意
我们将在第二十二章中讨论 GuardDuty,了解的其他政策和标准服务。
现在我们已经看到了我们走过的路和未来的方向,让我们从第一组日志——CloudTrail 日志开始。
AWS CloudTrail 的强大功能
CloudTrail 可通过 AWS 账户或多个账户(使用 AWS 组织)启用治理、合规性、风险审计和操作审计功能。
在 AWS 中,每个操作都是通过 API 调用执行的。无论您是使用 AWS 管理控制台、Amazon CLI 还是任何可用的 SDK,都是如此。这些操作都通过 API 调用来执行,然后这些 API 操作如果已启用 CloudTrail 服务,则会被记录下来:
图 16.1 – 通过 CloudTrail 服务将操作流动到日志的过程
这些内容包括记录启动和停止 EC2 实例的调用、上传和删除 S3 对象、从 VPC 添加或删除安全组、在 DynamoDB 表中添加或删除索引等。 当您的帐户内发生活动时,CloudTrail 会捕捉并记录该活动作为 CloudTrail 事件。此 CloudTrail 事件包含以下详细信息:
-
执行请求的人
-
请求发出的日期和时间
-
请求的源 IP
-
请求是如何发出的
-
正在执行的操作
-
执行操作的区域
-
请求的响应
还需要注意的是,CloudTrail 日志不会实时推送到存储的 S3 存储桶中。相反,CloudTrail 服务每 5 分钟发布一次更新的日志文件,包含它收集到的一批事件。
在确保 CloudTrail 日志本身安全方面,默认情况下,服务会使用 S3 服务器端加密(SSE)对文件进行加密,并将其存储在 Amazon S3 中。你还可以选择使用 KMS 服务创建加密密钥,并使用该密钥对 CloudTrail 日志进行加密。
CloudTrail 服务提供了几个好处。第一个是它记录了用户和资源的活动。通过这些记录,你可以识别是谁在什么时间对 AWS 账户中的资源执行了什么操作。其次,由于事件日志会自动存储和记录,合规性报告变得更加易于管理。第三,你能够通过将 CloudTrail 事件发送到 CloudWatch Logs 来监控、警报和响应正在发生的事件。第四个也是我们在这里提到的最后一个好处是,通过使用类似 SQL 的语法,你可以利用 CloudWatch 服务搜索日志。这使你能够对 CloudTrail 产生的大量数据执行强大的查询。
现在我们了解了 CloudTrail 服务,我们将在我们的账户中设置 CloudTrail。
设置 CloudTrail
我们将设置 CloudTrail,然后再查看 CloudTrail 记录的日志。我们这样做是为了确保在执行本章其他练习时,CloudTrail 服务已经开启并记录了我们的操作。这还将确保在稍后进行 CloudTrail 练习时,我们有一个完整的记录集可以进行搜索。
亚马逊已经更新了默认创建 CloudTrail 路径的方式,使得所有区域在初始化时都被包含在内。在本节中,我们将创建一个特定于我们正在工作的区域的路径。这仍然是可能的,但仅在使用 AWS CLI 的情况下:
-
打开终端以便访问 AWS CLI。首先,我们需要创建一个 S3 存储桶,以便捕获并存储 CloudTrail 日志。使用以下示例命令,记住每个 S3 存储桶名称都是唯一的,你需要创建自己的 S3 存储桶:
aws s3 mb s3://devopsproandbeyond-trail --region us-east-2 -
为了让 CloudTrail 服务能够将日志放入 S3 桶,我们需要为我们的桶附加一个桶策略。将以下桶策略复制并粘贴到本地文件中(在你执行终端命令的地方),命名为
cloudtrail_s3.json。查找两处出现BucketName的地方,你需要将它们替换为你在上一步创建的桶的名称。该文件的副本可以从本书 GitHub 仓库的Chapter-16文件夹下载:{ "Version": "2012-10-17", "Statement": [ { "Sid": "AWSCloudTrailAclCheck20150319", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::BucketName" }, { "Sid": "AWSCloudTrailWrite20150319", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::BucketName/*", "Condition": {"StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}} } ] } -
创建策略文件后,你可以使用以下命令将其附加到你的桶上。确保更改桶名称,以便策略附加到你的桶:
aws s3api put-bucket-policy \ --bucket devopsproandbeyond-trail \ --policy file://cloudtrail_s3.json -
在附加了我们的 S3 桶后,我们可以创建单区域跟踪。使用以下命令创建你的跟踪,记得将命令中的 S3 桶名称替换为你在步骤 1中创建的桶名称。请注意,我们将跟踪命名为
sixteen。我们将在本章后面引用这个跟踪名称:aws cloudtrail create-trail \ --name sixteen \ --s3-bucket-name devopsproandbeyond-trail \ --region us-east-2
如果跟踪创建成功,你应该会看到返回的 JSON,类似以下内容:
{
"Name": "sixteen",
"S3BucketName": "devopsproandbeyond-trail",
"IncludeGlobalServiceEvents": true,
"IsMultiRegionTrail": false,
"TrailARN": "arn:aws:cloudtrail:us-east-2:470066103307:trail/sixteen",
"LogFileValidationEnabled": false,
"IsOrganizationTrail": false
}
-
现在是时候开始跟踪了。仅仅因为我们创建了跟踪并不意味着它会自动开始记录事件。使用以下命令启动跟踪,以便捕获该区域的所有 API 调用:
aws cloudtrail start-logging --name sixteen --region us-east-2 -
接下来,为了将日志流式传输到 CloudWatch 日志(以便我们以后可以搜索它们),我们需要登录到 AWS 管理控制台并快速编辑我们的跟踪。登录控制台后,导航到 CloudTrail 服务。当你进入 CloudTrail 仪表板时,你应该看到我们创建的名为sixteen的跟踪。点击该跟踪名称:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_16.2_B17405.jpg
图 16.2 – 仪表板上的第十六个 CloudTrail 跟踪
-
当你进入第十六个 CloudTrail 时,你应该会看到一个名为CloudTrail 日志的部分。点击该部分右侧标记为编辑的按钮。
-
在
CloudTrailRole-sixteen上。然后,点击屏幕底部的橙色保存更改按钮。
现在,我们已经设置了 CloudTrail 服务来记录我们将来执行的 API 操作,接下来我们来看看弹性负载均衡器日志。
启用弹性负载均衡器日志
弹性负载均衡服务允许你捕获更多关于你环境的数据。这有助于故障排除,尤其是在延迟方面。弹性负载均衡器访问日志还能让你查看用户或服务从源地址到目标服务的路径。有时,这些信息不会出现在应用日志中,因为捕获到的源地址是弹性负载均衡器的地址。弹性负载均衡器访问日志包括以下信息:
-
客户端的 IP 地址
-
请求路径
-
请求接收的时间和日期
-
服务器响应(以数字格式显示)
我们在深入研究 Elastic Beanstalk 和 OpsWorks 等服务时,已经了解了负载均衡如何帮助在两个实例和服务之间分配负载。此时,我们还应该明白,弹性负载均衡可以用来附加多个实例,甚至是自动扩展组中的实例:
图 16.3 – 从弹性负载均衡器到 S3 存储桶的访问日志流
一旦你启用了弹性负载均衡器的访问日志记录,日志记录本身不会产生额外费用。然而,将日志存储在 S3 中会产生存储费用\。
设置弹性负载均衡器并启用日志记录
在本章的第一个实践示例中,我们将使用两个相互引用的 CloudFormation 模板来搭建一个 VPC;第二个模板将搭建一个弹性负载均衡器,并通过两个 EC2 实例提供一个简单的网站。子模板还将创建一个 S3 存储桶,用于捕获我们的访问日志。完成测试环境搭建后,我们需要进入 AWS 管理控制台并启用弹性负载均衡器的日志记录。启用日志记录后,我们可以尝试多次访问该网站。这样做应该会在我们的 S3 存储桶中留下记录,我们可以访问并分析这些记录。本练习中引用的模板位于本书 GitHub 仓库的 Chapter-16 目录下。在开始之前,请下载所有模板。我们开始吧:
-
登录到AWS 管理控制台,并导航到CloudFormation服务。
-
一旦进入CloudFormation页面,如果跳转到主 CloudFormation 服务页面,请点击橙色的创建堆栈按钮。否则,如果跳转到当前堆栈的列表页面,请点击主窗口右上角的创建堆栈按钮,并选择**使用新资源(标准)**选项:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_16.4_B17405.jpg
图 16.4 – 在 CloudFormation 中从堆栈列表页面的创建堆栈按钮
-
无论你是如何到达这里的,我们现在应该能够上传
vpc.yaml模板。然后,在对话框中点击打开按钮。一旦文件上传完成,你可以点击橙色的下一步按钮。 -
这将带你进入
Chapter16-VPC,这是为你的堆栈命名时需要使用的名称。这个名称很重要,因为这个堆栈将创建一些资源,后续堆栈将引用这些资源,并通过堆栈的名称进行引用。一旦输入了名称,点击页面底部的橙色下一步按钮。 -
在配置堆栈选项页面,向下滚动到底部并点击橙色的下一步按钮。
-
此时,我们将在
Chapter16-VPC堆栈中。向下滚动到页面底部,在Capabilities部分下的框中填写,确认此模板将创建一个 IAM 角色。完成后,点击橙色的Create stack按钮,以便初始化并创建我们的初始堆栈。 -
点击 CloudFormation 服务中的
Chapter16-VPC堆栈页面。堆栈创建完成后,进入Outputs部分。此时,你应该能看到 VPC 堆栈创建的六个输出,包括 VPCid、两个私有子网和两个公共子网:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_16.5_B17405.jpg图 16.5 – 初始堆栈创建的输出
-
创建好我们的 VPC 模板并显示输出后,我们可以继续下一个模板。下一个模板将设置负载均衡器,并配置两个运行 Apache Web 服务器的 EC2 实例。每个服务器都运行一个静态网页,但如果你看到的是不同的页面,就能知道自己是被定向到实例一还是实例二。
-
由于我们已经在CloudFormation页面的Outputs部分,我们可以直接前往右上角,点击白色的Create stack按钮。当下拉列表出现时,选择**With new resources (standard)**选项。
-
现在,返回
cross-stack-website.yaml模板上传它。上传模板后,点击页面底部的橙色Next按钮。 -
现在你应该处于
Chapter16-Elastic Load Balancer页面。在Stack name框中输入此值。 -
你还会看到一个参数框。这个框应该已经填上了
Chapter16-VPC。如果你之前的堆栈命名为Chapter16-VPC,你无需更改此值。如果你给堆栈取了其他名字,则需要在此输入该名称,因为这是驱动我们之前看到的所有输出的值。填写完值后,点击页面底部的橙色Next按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_16.6_B17405.jpg图 16.6 – 指定堆栈详情页面中的堆栈名称和参数字段
-
此时,你将被带到Configure stack options页面。此页面无需配置任何内容,因此我们将向下滚动到页面底部,点击橙色的Next按钮。
-
最后,我们将进入Review stack页面。简要查看你为堆栈选择的选项。如果没有错误,点击页面底部的橙色Create stack按钮。
-
由于我们的堆栈正在创建两个 EC2 实例并安装软件和网页,同时还在创建经典负载均衡器,注册这些实例到该负载均衡器,并执行初步健康检查,因此需要几分钟的时间来完成创建。
-
一旦堆栈完成,点击输出菜单项,就像我们在前一个堆栈中所做的那样。这时,您会在这里找到一个密钥的 URL 和 Elastic Load Balancer 的公共 URL 值。右键点击该 URL 并在新标签页中打开。
-
现在,点击同一水平菜单中的资源菜单项,您在其中找到了输出。点击 Elastic Load Balancer 的物理 ID链接,您将直接进入 Elastic Load Balancer 的详细信息页面:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_16.7_B17405.jpg
图 16.7 – 在 CloudFormation 中显示的 Elastic Load Balancer 资源列表
-
现在,向下滚动屏幕的下半部分,直到找到属性标题。在此标题下,您将找到访问日志部分。此处应该有一个值,当前设置为禁用。点击灰色的配置访问日志按钮。
-
当对话框出现时,您需要填写以下值:
-
勾选启用访问日志框。
-
将日志推送间隔更改为5 分钟。
-
为存储 Elastic Load Balancer 访问日志选择一个新的S3 桶名称。
-
勾选框以创建 S3 桶:
-
图 16.8 – 配置访问日志
填写完所有值后,点击蓝色的保存按钮。
-
现在,开启日志功能后,是时候回到之前打开的浏览器标签页,其中包含 Elastic Load Balancer 的 URL。多次刷新页面;如果两个服务器都已成功启动并通过 Elastic Load Balancer 的健康检查,您应该会看到服务器一和服务器二的混合显示在屏幕上。
-
一旦生成了一些流量,我们可以开始导航到为 Elastic Load Balancer 访问日志存储创建的 S3 桶。但是,请记住,日志每 5 分钟才会推送一次,因此您可能需要耐心等待日志的出现。
-
这时,是时候转到 S3 服务并找到您为存储 Elastic Load Balancer 访问日志而创建的桶的名称了。点击桶的名称。您应该会看到一个名为
AWSLogs的文件夹,然后是一个以帐户号码命名的子文件夹。在该帐户文件夹中,应该有名为elasticloadbalancing的进一步子文件夹,然后是按地区、年份、月份和日期命名的子文件夹。最后,您将看到日志文件。点击其中一个日志文件,下载并用 Textpad 或记事本打开它。
通过这个,我们已经了解了如何启用日志并查看来自我们的弹性负载均衡器的流量模式。然而,不要急着关闭这组 CloudFormation 模板。我们将在接下来的部分中使用这里创建的 VPC,来检查 VPC 流日志。但首先,让我们看一下弹性负载均衡器日志的用例。
弹性负载均衡器日志的用例
你可能会想,为什么你会对启用弹性负载均衡器日志感兴趣,而你可以从应用程序的日志文件中获取类似客户端地址的信息?让我们详细查看几个用例:
-
理解请求的延迟——响应请求需要多长时间。
-
监控访问请求——请求来自哪里,去往哪里。
-
衡量客户端与资源之间操作的效率——是否存在可以轻松检测到的瓶颈?
现在我们理解了何时使用弹性负载均衡器日志,让我们看看 VPC 流日志。
使用 VPC 流日志
流日志帮助您捕获有关虚拟私有云(VPC)网络接口进出 IP 流量的信息。一旦捕获到这些数据,它可以被写入 S3 存储桶或推送到 CloudWatch 日志组。
一旦创建了流日志组并开始记录日志,日志不会立即出现。日志可能需要最多 5 分钟才会出现在 S3 存储桶或日志组中:
图 16.9 – VPC 流日志在不同来源之间传输
可以为网络接口创建流日志。这些包括 VPC 本身的网络接口,甚至是其他包含网络接口的服务,如下所示:
-
弹性负载均衡器
-
亚马逊 RDS 数据库
-
亚马逊 ElastiCache 缓存
-
亚马逊 Redshift 数据库
-
亚马逊 WorkSpaces
-
传输网关
-
NAT 网关
现在我们了解了 VPC 流日志是什么以及它们可以附加到哪些内容,让我们先看看它们的限制,然后再设置之前创建的 VPC 上的流日志。
关于 VPC 流日志的限制
虽然 VPC 流日志允许您捕获大多数来自或前往VPC中不同网络接口的流量,但也有一些情况是无法捕获的。我们来快速了解这些情况。在这种情况下,如果在 DevOps 专业考试中或现实生活中出现其中一个场景,我们就知道流日志并不是最佳解决方案。例如,当 VPC 之间的对等连接未在同一帐户内进行对等时,无法为对等的 VPC 启用流日志。另一个需要注意的是,流日志并不会捕获所有的 IP 流量。有一些特定的流量是丢失的,特别是不会被流日志文件捕获的:
-
任何来自实例的流量,试图连接到亚马逊 DNS 服务器。
-
从 Windows 实例发送的用于 Amazon Windows 许可证注册的任何流量。
-
所有与
169.254.169.254之间的流量,用于元数据相关信息 -
所有与
169.254.169.123之间的流量,用于 Amazon Time Sync 服务 -
所有的 DHCP 流量
-
任何发送到 VPC 路由器并通过保留 IP 地址传输的流量
-
所有位于终端节点网络接口与网络负载均衡器接口之间的流量
启用 VPC 流日志
如我们之前在动手练习中提到的,我们将使用本次动手练习中创建的相同VPC来捕获 VPC 流日志。
创建流日志时,你需要指定以下项目:
-
你希望拥有的 AWS 资源
-
如果你希望捕获接受的流量、拒绝的流量或流日志中的所有流量
-
你希望数据发布到的地方(S3 桶或 CloudWatch 日志)
让我们开始吧:
-
从CloudWatch服务开始。在左侧菜单中找到日志,点击日志组。
-
在右上角,点击橙色的创建日志组按钮。
-
创建一个名为
FlowLogs的日志组。你可以更改保留设置,允许日志在 7 天后(1 周)过期。更新完这些设置后,滚动到页面底部并点击橙色的创建按钮。 -
返回到
Chapter16-VPC。点击这个堆栈名称查看该堆栈的详细信息。 -
然后,从堆栈的顶部水平菜单中点击资源菜单项。当资源表格出现时,向下滚动,直到找到 VPC 的条目(它可能靠近底部,因为它是我们最先创建的资源之一)。点击 VPC 的蓝色物理 ID链接,进入 VPC 界面。(在点击之前记下物理 ID 的最后 4 个字母数字字符;记住 VPC 的最后 4 个字母数字字符)。
-
一旦你进入你的 VPC页面,勾选VPC 名称右侧的框。勾选后,点击屏幕右上角的白色操作按钮。完成后,一个下拉菜单会出现。选择创建流日志菜单项。
-
此时,你将被带到
All -
1 分钟 -
发送到 CloudWatch 日志 -
FlowLogs -
VpcFlowLogRole -
填写完所有这些设置后,点击橙色的创建流日志按钮。
-
现在,回到你的 Elastic Load Balancer URL 并向已经加载在 EC2 实例上的网站发送一些流量。这样会生成 VPC 流日志。一旦生成了一些流量,回到名为
FlowLogs的 CloudWatch 日志组,查看它生成的记录。
我们刚刚学习了如何创建自定义的 CloudWatch 日志组并开启 VPC 流日志,以便捕获 VPC 中的流量。接下来,我们将看看在哪些使用场景下开启 VPC 流日志是有意义的。
VPC 流日志的使用场景
由于有如此多类型的日志可用,让我们来看一些使用 VPC 流日志的明确用例。
使用 VPC 流日志来监控远程登录
远程登录到你云基础设施上的实例应仅通过授权人员以及可信地址进行。你可以使用 VPC 流日志查看哪些用户和 IP 地址正在通过 远程桌面协议 (RDP) 或 安全外壳协议 (SSH) 等协议获取访问权限或尝试获取访问权限。
注意
你可以使用 虚拟网络连接 (VNC) 客户端连接到 AWS Mac 实例;然而,这种连接是不安全的。为了确保连接的安全性,你可以通过 SSH 隧道将连接封装起来,具体方法可以参考这里:aws.amazon.com/premiumsupport/knowledge-center/ec2-mac-instance-gui-access/。
使用 VPC 流日志检测威胁
如果你选择使用 VPC 流日志捕获所有事件,包括入口和出口,那么你可以检测到对环境的威胁,例如网络上的端口扫描、网络扫描、有人试图寻找弱点或进入点,或者数据被推送到未经授权的来源。
如果你发现你的系统受到某个事件的影响,那么你可以使用 VPC 流日志追踪攻击者通过网络的路径。
诊断和故障排除网络问题
在分层安全的情况下,有时你会遇到尝试弄清楚为什么无法访问某个实例或服务的情况,这可能会很麻烦。
了解你的网络流量
你可以使用 VPC 流日志来分析你的网络和 AWS 账户的用户行为,并生成可能发生的不安全行为的报告。这可能包括使用未保护的端口,或者允许来自全球的访问,而不是将访问限制在特定的 IP 地址上,并将全球访问限制为内容分发服务器(如 CloudFront)。
现在我们已经了解了 VPC 流日志的各种使用案例,我们将把注意力转向我们最初查看的日志——CloudTrail 日志。
回到我们的 CloudTrail 日志
现在,我们已经通过本章中执行的练习和多个 API 调用创建了一些资源,我们可以回到 CloudTrail 日志中,看看它们是如何被事件填充的。
搜索 CloudTrail 日志
由于我们目前已经执行了足够的操作来生成 CloudTrail 日志,现在我们将开始搜索日志,查看我们捕获到了什么内容:
-
返回到 CloudWatch 服务。从左侧菜单中找到 Logs,但这次点击名为 Log Insights 的子菜单。
-
从选择日志组的下拉菜单中,选择 CloudTrail 日志组。
-
将以下查询放入查询框中,然后按下橙色的 Run query 按钮:
filter eventSource="ec2.amazonaws.com" | stats count(*) as eventCount by eventName, awsRegion | sort eventCount desc -
你应该会看到类似以下的图形:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_16.10_B17405.jpg
图 16.10 – CloudWatch Logs 洞察可视化图表
-
如果你愿意,可以尝试查看 CloudTrail 日志中你能发现的其他信息。
有了这些,我们已经学习了如何使用 CloudWatch Log Insights 查询 CloudTrail 日志。现在,在总结本章之前,让我们清理一下之前创建的资源。
清理资源
在本章中,我们创建了很多资源,如果不清理并保持运行,可能会导致你收到比预期更高的 AWS 账单。完成本章后,务必删除用于创建实例和 Elastic Load Balancer 的 CloudFormation 模板。
总结
在本章中,我们查看了三种不同的日志来源,这些日志可以为你的 AWS 账户提供信息,这些日志不是 CloudTrail 或应用程序日志。首先,我们学习了如何设置 CloudTrail 跟踪记录账户内发生的所有 API 调用。接下来,我们查看了 Elastic Load Balancer 访问日志,了解它们如何记录进入 Elastic Load Balancer 的 IP 地址、时间和响应。最后,我们查看了 VPC Flow Logs 如何捕获来自各种网络接口的网络流量。
在下一章中,我们将总结日志记录的讨论,介绍企业如何补充捕获日志的 AWS 服务。然后,我们将了解日志存储和高级搜索是如何处理的。
复习问题
-
你作为 DevOps 工程师在一家已经实施了多个 CI/CD 流水线的公司工作。一个流水线用于推送应用程序代码及其功能,另一个流水线用于更新账户的基础设施和安全设置。在应用程序的最后一轮安全组更新之后,公司某个远程办公室的所有用户无法再访问自动扩展组中的实例。这些用户仍然可以通过 Elastic Load Balancer 从 Web 协议访问应用程序。这些用户包含多个 IAM 用户组的成员,包括开发人员、权限用户,甚至是管理员。你可以去哪里寻找信息,试图找出问题发生的原因?
a. 收集被拒绝访问的 IAM 用户名。使用这些用户名搜索 CloudWatch 中的 IAM 日志组。
b. 确保已启用 VPC Flow Logs。搜索 VPC Flow Logs 中远程办公室的内部和外部 IP 地址。
c. 收集被拒绝访问的 IAM 用户名。转到 CloudTrail 服务,搜索用户名以查找拒绝访问的记录。
d. 启用应用程序的 Elastic Load Balancer 日志记录。检查 Elastic Load Balancer 日志,查看远程办公室的内部和外部 IP 地址。
-
你被引入到一家即将进行重要生产发布的公司,作为这次发布的一部分,他们正在实施一个新的治理模型,要求监控 AWS 账户上的所有活动。你如何快速有效地帮助公司实现这一目标?
a. 设置 Amazon Inspector 服务,持续检查账户上发生的所有活动。
b. 为所有 VPC 开启 VPC 流日志,确保捕获进出流量。
c. 设置 AWS CloudTrail 服务,监控并记录所有区域的活动。
d. 创建一个指定的 CloudWatch Logs 日志组,以便可以专门过滤创建或终止事件到该日志组。
审核答案
-
b
-
c
第十八章:高级和企业级日志记录场景
当我们准备结束关于日志部分的讨论时,我们将讨论如何实现企业级的日志系统。虽然 CloudWatch 可以搜索日志并呈现一些可视化内容,但我们将探索 AWS 提供的其他本地解决方案,这些解决方案更适合捕获、处理、存储并可视化不断流入的大量日志。
在本章中,我们将覆盖以下主要主题:
-
使用 QuickSight 可视化数据
-
将日志流式传输到 Amazon Elasticsearch
-
使用 Amazon Kinesis 处理日志
使用 QuickSight 可视化数据
尽管有多个第三方可视化工具可用于分析数据并创建日志的图形表示,但 Amazon 为其客户创建了一项本地服务,QuickSight。QuickSight 是为云端规模的 商业智能(BI)服务而开发的,易于使用,且能够从多个来源导入数据。
Amazon QuickSight 使用专有的 SPICE 引擎来计算和提供数据。SPICE 代表 超高速并行内存计算引擎。这项技术旨在实现企业级的极速性能。SPICE 引擎通过自动复制数据来实现这一点,允许成千上万的用户在极快的速度下对这些基础数据进行查询和分析。
Amazon QuickSight 的另一个关键特点是,你可以与 IAM 组织成员共享创建的仪表盘。它还可以通过电子邮件与没有 IAM 或联合账户的 AWS 组织成员共享访问权限。QuickSight 还提供适用于 iPhone 和 Android 的应用程序,方便访问:
图 17.1 – 日志流向 Athena 和 AWS QuickSight 创建可视化
在前一张图中,我们展示了 AWS 用户如何从他们所采取的行动中创建事件。
当你在 AWS 账户中设置 QuickSight 时,你会创建一个命名空间,这是一个逻辑容器,用于组织你的团队、客户以及其他你将邀请到 QuickSight 可视化中的人员。你可以创建多个命名空间,并且可以将用户查看的数据与该命名空间隔离。命名空间也可以跨多个区域。设置好命名空间后,从此不需要进一步的管理操作。
了解了 QuickSight 服务在为我们 Amazon 账户中的用户以及我们组织中的其他人创建可视化时带来的价值后,让我们来看一下 Athena 服务如何基于这些能力进行扩展,利用我们已经存储在 S3 存储桶中的文件。
使用 Amazon Athena 查询数据
AWS 创建了一项服务,允许你查询存储在 S3 存储桶中的数据。该服务是无服务器的,因此无需配置服务器,而且该服务仅对你运行的查询收费。
Presto 查询引擎支持 Amazon Athena。这是一个开源的 SQL 引擎,允许用户以低延迟查询大规模数据集。Presto 引擎还完全支持连接、数组和窗口函数。
Amazon Athena 的主要特点如下:
-
由于它是无服务器的,因此无需管理任何管理或基础设施。
-
它使用标准 SQL 来查询底层数据。
-
它具有极快的性能,无需调优。
-
它支持跨多个数据源进行联合查询。
-
它是安全的,允许你利用 IAM 和 S3 存储桶策略来控制数据访问。
-
它与 S3 作为数据源时具有高可用性。
现在我们已经了解了如何使用 Amazon QuickSight 结合 Amazon Athena 创建更强大的可视化,让我们看看一些 Amazon QuickSight 的应用场景。
Amazon QuickSight 的应用场景
下一节将探讨一些使用 Amazon QuickSight 与其他 AWS 服务结合的应用场景,以创建企业级系统,构建仪表盘和分析系统,用于监控日志和分析。
使用 QuickSight 可视化日志和使用分析,借助 Athena 和 Glue 的支持
亚马逊构建了一个交互式查询服务,允许你使用标准 SQL 语句查询数据,名为 Athena。除了使用标准 SQL 并且无需学习新的特殊语言之外,Athena 的另一个优点是它是无服务器的。这意味着无需配置服务器,且仅对你在系统上运行的查询和扫描的数据收费。
将机器学习洞察集成到你的仪表盘中的能力
Amazon QuickSight 扩展了仅仅以仪表盘格式展示数据的常规功能,通过添加自然语言功能和机器学习洞察,帮助你更全面地理解数据。这些功能帮助用户发现底层数据中隐藏的模式和趋势,而无需专业的技术专长或机器学习技能。
将用户仪表盘连接到你的数据仓库或数据湖
如果你的数据存储在数据仓库中,例如使用Amazon Redshift服务,那么你可以在 Amazon QuickSight 中创建连接,连接到你的 Redshift 集群。此 Redshift 集群会成为自动发现的数据集,并通过 SSL 自动保护 Redshift 集群和 QuickSight 之间的连接,无需额外配置。然后,你可以选择想要在 QuickSight 可视化中使用的表,或者创建自定义 SQL 语句将数据导入 SPICE 引擎中,以分析和可视化数据。
如果你将数据存储在数据湖中,尤其是使用 AWS 的 Lake Formation,那么数据就存储在 Amazon S3 存储桶中。接着,你可以使用 AWS Glue 来爬取数据并创建数据目录。一旦数据目录创建完成,你就可以使用 Amazon Athena 查询数据并创建表和数据库。这些表和数据库充当 S3 存储桶中数据架构的容器。Amazon QuickSight 然后可以连接到 Athena 数据库,创建数据的可视化,甚至进行进一步的 SQL 查询:
图 17.2 – 将 Amazon QuickSight 连接到 AWS 中的数据湖
现在我们已经讲解了一些企业在使用 Amazon QuickSight 时可能遇到的应用场景,接下来让我们通过一个动手练习来加深对该服务概念的理解。这样一来,如果在 DevOps 专业认证考试中遇到关于可视化的问题,我们就能有一个坚实的基础,知道何时选择 Amazon QuickSight 而非 CloudWatch 仪表板。
使用 Amazon QuickSight 创建仪表板
当你在 Amazon QuickSight 中创建数据仪表板时,你实际上是在发布一组交互式图表和图形,供用户探索。该仪表板使用的底层数据不仅展示了洞察,还为用户提供了进一步探索的工具,以防他们有此需求。
让我们一起走过在 Amazon QuickSight 中创建仪表板的过程。为了将数据导入临时数据库以便在 QuickSight 中连接,我们将需要借助 Amazon Athena 服务:
-
登录到 Amazon 管理控制台,在顶部搜索框中搜索
QuickSight。进入 QuickSight 页面后,验证你的 AWS 账户编号,然后按下蓝色按钮 注册 QuickSight。确保将默认的 企业版 更改为 标准版:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.3_B17405.jpg图 17.3 – 来自搜索菜单的 QuickSight 图标
你也可以使用以下 URL:
aws.amazon.com/quicksight/pricing/。点击页面中间的 标准版 链接。进入 标准版 页面后,向下滚动到页面底部,点击大号黄色按钮 开始你的免费试用。你现在应该在标有 创建你的 QuickSight 账户 的页面上。保留第一个选项 使用 IAM 联邦身份 & QuickSight 管理用户 作为 身份验证方法。接下来,对于 QuickSight 区域,将区域更改为 美国东部(俄亥俄州):
图 17.4 – 设置身份验证方法和区域以创建 QuickSight 账户
-
对于您的 QuickSight 账户名称,您需要选择一个独特的名称,并且可以记住。您还需要输入一个电子邮件地址。
-
现在,我们可以指定在当前设置中哪些数据将可供 QuickSight 使用。勾选以下项目旁边的框:
a. 启用在您的 Amazon Redshift、Amazon RDS 和 AWS IAM 服务中自动发现数据和用户。
b. 亚马逊 Redshift
c. 亚马逊 RDS
d. IAM
e. 亚马逊 Athena。
f. 亚马逊 S3(选择显示的桶 – chapter16-elb-logs):
图 17.5 – 选择用于 QuickSight 的 S3 桶
我们已经从之前的实践练习中添加了一个桶,该桶应该包含可供 Amazon QuickSight 查询的数据。
-
您现在将看到一个屏幕,上面有一个跳动的图形,AWS 正在为您创建 QuickSight 账户。账户创建完成后,您将看到一个蓝色按钮,上面写着 进入 Amazon QuickSight。点击此按钮继续。
-
点击按钮后,它将开始为您创建一些示例,并显示一个弹窗,欢迎您使用 QuickSight。点击弹窗中的蓝色 下一步 按钮来关闭它们,或点击右上角的 X。
-
我们需要从 S3 桶中的数据创建一个数据集。找到左侧垂直菜单中的数据集图标并点击它。进入数据集页面后,点击右上角的深蓝色 新建数据集 按钮。
-
如果您还没有选择
Chapter-17文件夹中的MOCK_DATA.csv文件,请选择它并将其上传至 QuickSight。点击 确认文件上传设置 弹窗中的蓝色 下一步 按钮。上传完成后,点击蓝色 可视化 按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.6_B17405.jpg图 17.6 – 确认数据已正确上传至 QuickSight
-
一旦数据加载完成,您将进入 Amazon QuickSight 的 可视化 部分。现在是时候从我们刚刚导入的数据中创建一个可视化了。我们需要首先选择一些字段来显示在图表上。
-
选择 填充地图 类型的图形,它位于右侧可视化类型列表的最后一个值。然后,在选择该可视化类型后,将
state_province值拖动到zip_postal_code值的 颜色 字段中。点击其他一些可视化类型,看看 QuickSight 如何改变数据的展示方式:
图 17.7 – Amazon QuickSight 中的填充地图可视化类型
重要提示
Amazon QuickSight 标准版的价格为每月 12 美元(按月支付)。发布时,有一个为期 30 天的免费试用期,适用于作者;但是,如果您已经使用过该服务,在通过本教程时将会被收费。
现在我们已经看到了如何使用 QuickSight 服务创建交互式仪表板和可视化,接下来我们来看看用于在企业级管理日志的下一个服务——Amazon Elasticsearch 服务。
使用托管 Elasticsearch 搜索和分组日志
许多人将 Elasticsearch 与 ELK 联系在一起;然而,它们之间存在差异。ELK 代表 Elasticsearch、Logstash 和 Kibana。在这种配置中,Elasticsearch 作为存储,Logstash 作为日志解析器,Kibana 作为系统的可视化前端,用户通过它与系统交互:
图 17.8 – ELK 堆栈与 Amazon 托管 Elasticsearch 服务的比较
使用 Amazon 的托管 Elasticsearch 服务时,默认情况下没有安装 Logstash;但是,还有其他选项可以将您生成的日志导入到 Elasticsearch 集群中。
托管 Elasticsearch 的使用场景
AWS 的托管 Elasticsearch 产品有多个使用场景。接下来我们来看看这些场景。
存储和搜索应用监控日志
您可以将存放在 AWS CloudWatch Logs 中的日志流式传输到 Amazon 托管 Elasticsearch 服务。一旦日志进入 Elasticsearch 集群,它们可以通过基于 Lucene 的 Elasticsearch 搜索引擎进行搜索。
安全信息和事件管理(SIEM)
将来自网络中多个事件和应用程序的日志存储在一个集中系统中,可以帮助您使用 Amazon 托管 Elasticsearch 服务的能力,几乎实时地检测和报警安全事件。
企业级搜索引擎
尽管 ELK 堆栈最常与收集和显示日志相关联,但 Elasticsearch 是一个强大的搜索引擎,基于 Lucene 库构建,允许进行近实时的搜索。您可以使用 RESTful API 连接到 Elasticsearch,将结果返回到应用程序,或者将新数据发送到搜索引擎存储。
监控您的基础设施
当您收集来自不同基础设施组件的日志时,无论它们位于云端还是本地,都可以使用 AWS 的托管 Elasticsearch 将它们集中收集到一个解决方案中。这有助于您从各个角度快速研究出现的问题,从而帮助减少您的 平均修复时间 (MTTR)。
请注意,Amazon 的 Elasticsearch 服务正在更名为 Amazon OpenSearch。
现在我们已经了解了 Elasticsearch 服务的使用场景,让我们通过一个实际操作的例子,看看如何将 CloudWatch 日志导入到 Elasticsearch 集群中。
将 CloudWatch Logs 中的日志流式传输到 Elasticsearch 服务
在使用托管 Elasticsearch 服务的实操练习中,我们将部署一个简单的 Lambda 函数来生成一些日志。然后,我们将启动一个单节点的 Elasticsearch 集群来接收这些日志。利用 Lambda 函数生成的日志,这些日志将进入 CloudWatch Logs 日志组。接着,我们会将该日志组订阅到刚刚创建的 Elasticsearch 集群。CloudFormation 脚本还包括一个 AWS 事件规则,每五分钟触发一次 Lambda 函数,以便定期将日志发送到我们的 CloudWatch 日志组。最后,我们将进入 Kibana 可视化界面,查看我们的日志。让我们开始吧:
-
我们首先需要从 GitHub 仓库中的
Chapter-17文件夹下载名为lambda_stack.yml的 CloudFormation 模板。 -
首先,登录到 AWS 管理控制台。在控制台内,导航至CloudFormation服务,以便我们可以快速启动 Lambda 函数。通过点击主服务页面中的橙色创建堆栈按钮,或者如果你已经在堆栈页面并且有之前创建的堆栈,点击右上角的白色创建堆栈按钮来创建带有新资源的堆栈。
-
下载自 GitHub 仓库
Chapter-17文件夹中的lambda_stack.yml文件后上传。上传文件后,点击屏幕底部的橙色下一步按钮。 -
现在,在文本框中的堆栈名称字段内输入
Logging-Lambda作为此 CloudFormation 堆栈的名称。输入后,点击屏幕底部的橙色下一步按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.9_B17405.jpg](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.9_B17405.jpg)
图 17.9 – 输入 CloudFormation 堆栈名称
-
在配置堆栈选项页面上无需操作。向下滚动到页面底部,点击橙色的下一步按钮。
-
在审核页面上,向下滚动到页面底部,勾选复选框,确认此模板需要创建一个 IAM 角色。完成后,可以点击橙色的创建堆栈按钮。
-
创建资源的过程应该需要 1 到 5 分钟;完成后,我们可以点击
LambdaLogGenerator。这将是我们实际的 Lambda 函数。点击此名称旁边的蓝色链接,它位于物理 ID列下。这将直接打开一个新窗口,显示我们的 Lambda 函数:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.10_B17405.jpg](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.10_B17405.jpg)
图 17.10 – 创建的 Lambda 函数的逻辑 ID 和物理 ID
-
我们需要等待至少 5 分钟以便 Lambda 函数被调用,因此在此期间我们将创建 Elasticsearch 集群,以便在日志准备好时能够进行流式传输。在 AWS 管理控制台的顶部搜索框中,搜索
Elasticsearch。当你看到Elasticsearch 服务图标时,右键点击图标,在新标签页中打开该服务。 -
当你进入Amazon Elasticsearch 服务页面时,点击标记为创建新域的蓝色按钮。
-
对于部署类型,选择开发与测试,因为我们只需要一个可用区。在版本部分,选择最新版本。在撰写时,最新版本是 7.10。选择完毕后,点击屏幕底部的蓝色下一步按钮。
-
现在我们应该在
chapter-17域名设置页面。第二个设置将在T3.medium.elasticsearch实例下,因为我们只是进行短期测试,且不需要存储大量数据。做完这些更改后,滚动到页面底部并点击蓝色的下一步按钮。 -
在
devops中 -
Chapter17*
d. 在访问策略下,选择以下内容:
保持其他设置不变,然后点击页面底部的蓝色下一步按钮。点击标签页面上的蓝色下一步按钮,最后滚动到审查页面的底部,点击蓝色的确认按钮。
-
Elasticsearch 集群启动需要几分钟,这段时间我们可以回到 Lambda 函数的页面。返回我们浏览器窗口中的另一个标签页,在那里我们之前已经打开了 Lambda 函数。
-
一旦进入
Logging-Lambda-LambdaLogGenerator函数,点击横向菜单中的监控项。这不仅会让我们看到 Lambda 函数被调用的日志行,还会有一个白色按钮,位于横向菜单旁边,现标记为在 CloudWatch 中查看日志。点击该按钮将直接带你进入日志页面:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_17.11_B17405.jpg图 17.11 - 直接位于横向菜单下方的在 CloudWatch 中查看日志按钮
-
现在我们应该在 Lambda 函数的 CloudWatch 日志组中。日志流标题上方会有一个横向菜单。点击菜单项订阅过滤器。
-
一旦从下拉列表中选择我们刚刚创建的
chapter-17标题。选择Logging-Lambda并选择为日志 Lambda 函数创建的角色。选择log-test。最后,滚动到页面底部并点击橙色的开始流式传输按钮。 -
一旦点击开始流式传输按钮,一个 Lambda 函数将被创建。现在,我们的日志应该开始流入 Elasticsearch 集群中。
-
现在回到我们创建 Elasticsearch 集群的标签页,并点击
chapter-17作为链接域。点击devops)并输入在配置 Elasticsearch 集群时创建的密码。 -
我们现在在 Elasticsearch 集群的 Kibana 界面中。点击显示的文字 Explore on my own。当弹出 Select your tenant 对话框时,只需点击蓝色的 Confirm 按钮。
现在我们已经看过如何捕获日志并将其存储在托管的 Elasticsearch 集群中,接下来我们将探讨如何将 Amazon Kinesis 服务与 Elasticsearch 结合使用。
了解 Amazon Kinesis 服务
AWS 中有一个专门为实时处理流数据而创建的服务。这个服务就是 Amazon Kinesis。随着世界上越来越多的物品产生数据,越来越多的应用程序希望消费这些数据,必须有能够快速消费并对数据进行一些预处理的服务。Kinesis 服务还提供了一些冗余,以防主应用程序出现故障,通过其分片存储记录。默认情况下,记录可以在写入后 24 小时内访问。此设置也可以在配置中扩展,最多保存数据 7 天。发送到 Kinesis 的数据最大为 1 MB。
需要了解的 Amazon Kinesis 关键功能如下:
-
它允许实时摄取、处理和流式传输数据。
-
它是一个完全托管的服务,因此无需管理基础设施。
-
它与其他多个 AWS 服务集成,如 Amazon Redshift。
了解到该服务具备这些内建的优势,它自首次推出以来也经历了演变,以满足使用者的需求。尽管它在处理大量传入数据(如来自多个来源的日志)时非常有用,但这只是它众多用途中的一种。
Kinesis 服务来自 AWS,提供四个独立的功能:
-
Kinesis 视频流 – 该功能允许您轻松、安全地处理传入的视频数据,并支持分析、机器学习或其他处理。
-
Kinesis 数据流 – 该功能允许您将数据从应用程序流式传输到托管的 Kinesis 服务。
-
Kinesis 数据火 hose – 该功能为用户提供了一种简单的方法,将数据流捕获、转换并加载到 AWS 数据存储中,如 S3、ElasticSearch 和 Redshift。
-
Kinesis 数据分析 – 该功能允许用户使用 SQL 或 Apache Flink 轻松地实时处理数据流。
在某些场景中,您可能会同时使用多个功能。
测试小贴士
虽然在参加数据分析 – 专业认证考试时,你需要对 Amazon Kinesis 服务有更深入的了解,但在 DevOps 专业考试中,也有一些场景会考察你是否知道何时使用 Kinesis 服务是正确的解决方案(或错误的解决方案)。
现在我们对 Amazon Kinesis 服务有了基本的了解,让我们看看在企业场景中使用 Amazon Kinesis 服务来处理日志的合适时机。
使用 Amazon Kinesis 处理日志
Kinesis Firehose 允许我们添加一个自动调用 Amazon Lambda 函数的功能,该函数可以在将记录插入 Elasticsearch 集群之前对其进行转换。这与 ELK 堆栈中的 Logstash 实例处理传入日志并在发送到 Elasticsearch 实例之前进行转换的方式非常相似:
图 17.12 – Kinesis Firehose 同时将日志插入 S3 和 Elasticsearch 服务
图中有一个 S3 存储桶的原因之一是,Kinesis Firehose 可以在指定时间内重试任何失败的记录,以便在交付失败时重新发送到 Elasticsearch 服务。
什么因素可能导致失败?嗯,一个常见的原因是 Elasticsearch 集群的空间不足。如果你持续流式传输日志,但没有正确的方式来淘汰旧数据,或者没有向集群添加足够的节点,那么在某个时刻,集群将没有足够的空间,无法再接受任何新数据,或者在我们的案例中,无法接收新的日志。与其丢失这些信息或手动尝试将其插入集群,不如让 Kinesis 将错误的记录排入 S3 存储桶,然后在稍后重新尝试发送数据。
现在我们了解了如何使用 Amazon Kinesis 来增强日志记录设置,让我们来看看正确标记和分类日志的重要性。
使用标签和元数据正确分类日志
在对云资源和后续日志进行分类以便摄取时,标签可以帮助分类资源的来源,特别是在将所有日志推送到大型企业日志解决方案的情况下。
作为一个经验丰富的 DevOps 工程师,在 AWS 中创建资源时,你应该为从 CI/CD 管道中出来的资源添加多个标签,以便有效管理这些资源:
图 17.13 – 用于企业系统中的标签类别和键的示例
当我们在前面的示例中讨论使用 Lambda 函数和 Kinesis 处理时,我们可以查看元数据中包含的标签。
清理资源
在本章的实践过程中,我们在 AWS 账户中创建了许多资源。如果没有及时删除,像托管的 ElasticSearch 集群这样的资源可能会导致账单超出预期。每隔 5 分钟触发一次的 Lambda 函数可能会消耗您的免费套餐配额,因为每月大约有 43,800 分钟,因此此函数将被调用 8,760 次。只需删除不再使用的资源,并删除任何不再使用的 CloudFormation 堆栈,以确保您的 AWS 账单尽可能保持在最低水平。
此外,请记得取消您的 QuickSight 订阅,无论是免费试用还是单月订阅,以免因 QuickSight 服务而产生持续收费。
总结
本章中,我们讨论了如何实施企业级日志记录系统。我们还了解了 AWS 提供的其他本地解决方案,这些方案更适合捕获、处理、存储和可视化大量不断流入的日志数据。
在下一章中,我们将开始探讨如何确保我们的工作负载具有高度可用性,从 Auto Scaling 组及其生命周期开始。
复习问题
-
您的公司要求您创建一个可视化仪表盘,以图形化的方式展示日志,并且管理团队可以访问。管理团队不会通过 IAM 用户登录 AWS 账户,也没有 AWS 管理控制台访问权限。他们还希望从 AWS Redshift 数据库和通过 AWS Batch 过程创建并存储在 S3 桶中的 CSV 文件中进行数据增强。如何为管理团队创建一个易于访问、安全且动态的仪表盘?
a. 使用所有数据源创建一个 CloudWatch 仪表盘。收集管理团队的电子邮件地址,并发送仪表盘访问链接。
b. 通过 CloudWatch Logs 将所有数据流式传输到托管的 ElasticSearch 集群。创建一个 Kibana 仪表盘,展示所需的可视化内容。将 Kibana 仪表盘的链接与执行团队共享。
c. 使用 Kinesis Firehose 将 Redshift 中的数据流式传输到托管的 ElasticSearch 集群。创建一个 Kibana 仪表盘,展示所需的可视化内容。将 Kibana 仪表盘的链接与执行团队共享。
d. 使用 Amazon Athena 创建一个包含所有需要用于 QuickSight 仪表盘日志的临时表。将 CSV 文件导入 QuickSight 以进行可视化。将 Redshift 数据库作为数据源从 QuickSight 导入。收集管理团队的电子邮件地址,并发送仪表盘访问链接。
-
您最近加入了一家公司,该公司在 S3 存储桶中存储了多种不同的日志文件。这些日志来自各种来源,包括使用 S3 同步从本地服务器推送,应用程序负载均衡器日志,VPC 流日志等。公司希望您快速分析这些日志,并查明每个类别的日志有多老。您如何能够快速且经济有效地执行此任务?
a. 将包含日志的 S3 存储桶设置为 Amazon QuickSight 中的数据源。使用 SPICE 引擎分析日志。创建两个快速可视化,一个显示日志的年龄,另一个显示日志的类型。
b. 使用 S3 库存功能搜索 S3 存储桶中的文件。将报告导入 Excel,然后按年龄和日志类型对文件进行排序。
c. 创建一个 AWS Glue 作业目录,列出所有 S3 存储桶中的项目。使用 Amazon Athena 查询日志类型。创建一个查询来对日志类型进行分组。按日期降序排序,以便在每个组中首先显示最旧的日志。
d. 将所有日志导入托管的 Elasticsearch 集群。使用 Kibana 界面,运行一个关于日志类型的查询,然后按年龄对日志进行分组以获取日志数量的统计信息。
查看答案
-
D
-
B
第四部分:启用高可用工作负载、容错能力,并实施标准和政策
在任何环境中都会发生故障,但凭借 AWS 云的区域和全球能力,创建高度可用和容错的工作负载的障碍已经被消除。再加上按计划和实时强制执行标准和政策,你的 CI/CD 旅程将变得更加顺畅。
本书的这一部分包括以下章节:
-
第十八章,自动伸缩和生命周期钩子
-
第十九章,保护数据在传输和静止状态下的安全
-
第二十章,通过系统管理角色和 AWS Config 强制执行标准和合规性
-
第二十一章,使用 Amazon Inspector 检查你的环境
-
第二十二章,其他需要了解的政策和标准服务
第十九章:自动扩展与生命周期钩子
自动化的一个关键特性是利用自动扩展。虽然许多人仅在其基本功能上使用这个Amazon Web Services(AWS)服务,但受过教育的开发运维(DevOps)专业人员理解并利用自动扩展提供的一些更高级的功能。了解这些组件不仅有助于你通过认证考试,还能让你更有效地管理你的 AWS 环境。
在本章中,我们将介绍以下主要内容:
-
理解 AWS 自动扩展
-
使用自动扩展部署弹性计算云(EC2)实例
-
自动扩展生命周期
-
使用自动扩展生命周期钩子
理解 AWS 自动扩展
自动扩展是Amazon EC2 服务的一个子集,围绕自动配置和管理 EC2 实例展开,无需任何人工干预。自动扩展服务可用于在一个或多个可用区(AZs)内,始终保持固定数量的服务器。该服务还为你提供了弹性,可以在不需要持续监控系统的情况下,按需自动扩展,以应对客户或应用程序带来的需求激增。
它通过利用一个互补服务——Amazon CloudWatch 来实现这一点。CloudWatch 监控如中央处理单元(CPU)使用率等度量指标,并确保如果使用率超过 80%,即实例的可用 CPU 有 80% 被特定时间段(例如 5 分钟)占用,则会触发扩展事件。这有助于减轻该实例的负载,并且在新实例上线后,CPU 使用率应会降回 80% 以下。
自动扩展服务会定期对其自动扩展组(ASG)中的实例进行健康检查。健康检查之间的时间可以配置,但默认设置是 300 秒(5 分钟)。你还可以配置实例在被标记为不健康之前允许失败多少次健康检查。类似地,实例必须失败的健康检查次数与它必须通过的健康检查次数相同,才能将其作为健康实例添加到 ASG 中。
自动扩展在基础设施事件规划中也发挥着关键作用。如果你知道客户流量即将增加,例如市场部门购买了一个流行电视节目上的电视广告,或者有一场特别促销即将发生,那么你可以简单地增加 ASG 的期望容量和最大容量,以确保客户不仅有良好的体验,而且服务器也不会过载。
现在我们已经对自动扩展服务有了基本了解,接下来让我们看一下构成该服务的关键组成部分。
理解垂直和水平扩展的区别
在本章中,我们将讨论如何通过水平扩展来根据工作负载的需求调整实例的数量。这通常是一种更具成本效益的扩展方式,因为你可以根据工作负载的基准测试,知道你的工作负载实际需要多少内存和 CPU。这带来了许多好处,包括工作负载的可用性更高,因为有多个实例或容器同时运行应用程序。这避免了被垂直扩展的实例(或容器)成为单点故障(SPoF)。你也不受硬件限制。垂直扩展到一定程度时,你会遇到资源限制。尽管 AWS 中有一些实例拥有巨大的随机存取内存(RAM)和大量的 CPU,但这并不是正确构建和部署应用程序的方式。
水平扩展和垂直扩展的过程在下图中展示:
图 18.1 – 水平扩展与垂直扩展
现在我们已经了解了水平扩展和垂直扩展的区别,接下来让我们来看一下 AWS 自动扩展的关键组成部分。
自动扩展的关键组成部分
自动扩展的主要组成部分之一是 ASG(自动扩展组)。这个 ASG 是你的应用程序或服务的实例的逻辑组合。你需要为 ASG 设置三个主要变量:最小实例数、最大实例数和期望实例数。最小实例数告诉 ASG 在任何时刻,所有指定可用区(AZ)中可以运行的最少实例数。最大实例数告诉 ASG 在该区域内可以分配的最大实例数。这些最大值必须在服务限制范围内。最后,期望容量是指在没有计划动作或由扩展策略驱动的扩展事件的情况下,任何给定时刻运行的实例数量。
你可以在下图中看到 ASG 的示意图:
图 18.2 – ASG 可视化
自动扩展的另一个关键组成部分是启动模板。启动模板决定了 ASG 中的实例将以哪些属性启动。这些属性是通过启动模板提供的。在编写启动模板时,你可以确定例如实例大小、镜像标识符(ID)、虚拟私有云(VPC)ID 等项目。
如果你曾经使用过 ASG,那么你可能熟悉启动配置。启动配置与启动模板非常相似,但在某些方面,启动模板替代了启动配置。首先,启动配置是不可变的。每当你想要更改启动配置时,你需要克隆启动配置、进行更改,然后将其附加到 ASG 上。这与启动模板不同,启动模板支持版本控制。启动模板还支持最新的 EC2 功能,例如使用无限制的 T2 实例和弹性块存储(EBS)标签。
ASG 与弹性负载均衡(ELB)完全集成。无论你使用的是哪一种类型的 ELB,ASG 都能无缝集成。这意味着,如果一个 ASG 与负载均衡器关联,当实例被配置时,它会自动注册到负载均衡器中。相反,当实例被取消配置或终止时,负载均衡器会从实例中清空流量,并在终止实例之前将其从负载均衡器中注销。
注意
如果你有旧的启动配置,但希望利用最新的 EC2 技术,AWS 提供了一个文档页面,介绍如何将启动配置转换为启动模板。你可以在这里找到:docs.aws.amazon.com/autoscaling/ec2/userguide/copy-launch-config.html。
我们将要讨论的最后一个关键组件是扩展计划。扩展计划可以设置为使用预测扩展或动态扩展。如果你将扩展计划设置为使用预测扩展,ASG 将使用机器学习(ML)来分析工作负载的负载情况,特别是针对一周中的特定时间和天数,并生成预定的扩展操作,以确保你的应用程序具备满足这些需求的能力,具体如以下图示所示:
图 18.3 – 预测扩展如何在 Auto Scaling 中调度资源
动态扩展策略是你在使用动态扩展和扩展计划时配置的组件。
需要注意的是,即使你的扩展计算表明你应该超出你设置的最大实例数,这个最大值是一个硬性限制,扩展策略不会超越它。如果在扩展时达到最大实例数的上限,你可以提高最大实例数,或者你可能需要创建一个新的启动配置版本,以适应可能更好地处理应用程序流量的不同类型或系列的实例。
有一句老话形容自动扩展,叫做像火箭一样扩展,像羽毛一样缩减。这是因为从时间角度来看,扩展实例是昂贵的。如果你在扩展事件中启动一到三台实例,它们应该同时上线。引入三台实例将让你获得更多的容量,而不是一次扩展单个实例。如果这部分容量没有必要,那么你可以一次缩减一个实例,保持支出在合理范围内,通过自动扩展控制成本。
在规划 ASG 时,你需要考虑以下因素:
-
启动并配置将成为 ASG 一部分的服务器需要多长时间?
-
在监控工作负载性能时,哪些指标最适用?
-
你希望 ASG 跨多个可用区(AZ)部署吗?如果是的话,需要多少个?
-
自动扩展在你的应用程序中应该扮演什么角色?
在掌握了自动扩展的关键组件后,让我们来看看 AWS 自动扩展的主要使用案例。
了解不同类型的自动扩展
Amazon 的 EC2 自动扩展提供了多种选项,帮助你根据业务需求和预算目标扩展实例。
如果你想完全控制如何扩展实例,那么可以使用手动扩展。通过手动扩展,你可以根据工作负载的需求设置最小值、最大值和所需容量,ASG(自动伸缩组)会相应调整。
有时,流量到达工作负载的情况是相当可预测的。比如,客户在正常工作时间更为活跃,或者你可能有一些内部使用的业务工作负载,而这些工作负载的使用者都位于一个或两个特定的时区。这些情况下使用计划性扩展非常合适。使用计划性扩展时,ASG 会根据你设定的时间和日期自动进行扩展和缩减。
如果你希望在应用程序的服务需求高涨时,ASG 能够自动扩展,并在需求减少时缩回,这就是动态扩展的应用场景。动态扩展允许你选择一个对应用程序重要的特定指标,并设置一个百分比,一旦达到该百分比,与该指标关联的 CloudWatch 警报将被触发,从而启动一个或多个实例,将其添加到 ASG 中。同样,如果你之前响应特定指标扩展了容量,而该指标已经降到一个被低利用的水平,则扩展策略将检查应该开始终止的实例。根据你的配置,可能是最旧的实例、最新的实例,或者是最接近下一个计费周期的实例。
动态扩展还允许你使用步进扩展。这些步进调整可以根据指标警报触发的类型有所不同,这意味着如果流量突然激增,并且你的最大容量允许的情况下,你可以一次性扩展到多个实例。
将动态扩展的属性进一步扩展,就是预测性扩展。预测性扩展分析你的流量趋势,然后根据这些趋势增加或减少 ASG 中的 EC2 实例数量。预测性扩展是一个不错的选择,当你无法准确决定哪个指标最适合你的应用需求,或者你有需要较长时间初始化的应用时。对于那些看似周期性波动的工作负载,比如批量处理,预测性扩展也能发挥作用。预测性扩展分析可以分析这些工作负载,并决定何时引入更多容量。
我们刚刚看了不同的方式,ASG 可以如何被设置和调整,以应对工作负载流量的涌入。现在,让我们看看自动扩展的主要用例。
AWS 自动扩展的四个主要用例
自动扩展为客户解决了四个流行的用例,具体如下:
-
它自动化了服务器的配置。
-
它减少了分页的频率。
-
它使得使用竞价实例变得更加容易。
-
它允许你上下扩展云基础设施并节省成本。
现在我们已经了解了使用自动扩展的一些主要用例,接下来让我们通过创建自己的启动模板,来看看如何将 ASG 付诸实践。
使用自动扩展部署 EC2 实例
了解一个服务的最佳方式就是动手操作,看看它的表现,自动扩展服务也不例外。在这个动手练习中,我们将为我们的 ASG 创建一个启动模板。然后我们将创建一个 ASG。按照以下步骤进行:
-
使用你的管理员用户账户登录到Amazon 管理控制台。登录后,导航至 EC2 服务。在 EC2 服务中,找到并点击左侧菜单中的启动模板子菜单项,该项位于实例菜单标题下。
-
当你进入 EC2 的启动模板主屏幕时,点击主窗口中的橙色创建启动模板按钮。
-
我们现在应该处于标有
chapter18的屏幕上 -
版本 1 -
自动扩展指导—勾选框,如下图所示:
图 18.4 – 启动模板的第一部分已完成
-
接下来,向下滚动页面,查看下一个选择标准框。我们将使用以下值填写剩余的字段:
-
t2.micro。 -
密钥对(登录)—不要在启动模板中包含此项。
-
网络设置—VPC。
-
转到网络设置 | 安全组,并选择你的默认安全组。
-
-
一旦你填写了所有的值,我们可以点击橙色的创建启动模板按钮。此时你应该会看到成功创建了一个启动模板。
-
使用页面中间的链接,在从模板创建自动扩展组标题下,进入自动扩展部分,在此我们可以创建新的 ASG,如下图所示:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_18.5_B17405.jpg
图 18.5 – 创建自动扩展组部分,当你完成启动模板时
-
你现在应该位于
eighteen。 -
在下一个框中,从下拉列表中选择
chapter18)。点击屏幕底部的橙色下一步按钮。 -
在配置设置屏幕上,保持所有默认选项,包括默认 VPC。我们在此练习中不使用任何现货实例或额外的 VPC。在网络框中,依次选择默认 VPC 中的三个子网,直到所有三个子网出现在选择下拉框下方。添加完所有子网后,点击页面底部的橙色下一步按钮,如下图所示:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_18.6_B17405.jpg
图 18.6 – 将默认 VPC 中的三个子网添加到 ASG
-
现在,将
300秒调整为30秒。做出此更改后,点击橙色下一步按钮。 -
在
1、1和3处。 -
向下滚动到
18 ASG 策略 -
平均网络输入(字节) -
5000
以下截图展示了这个过程:
图 18.7 – 我们的 ASG 的带度量的扩展策略
-
填写完伸缩策略的值后,向下滚动到页面底部,点击标有跳过审查的白色按钮。
-
在审查页面,向下滚动到页面底部,点击橙色的创建自动伸缩组按钮,来创建我们的 ASG。
-
一旦点击按钮,你应该会被带到EC2 | 自动伸缩组页面,在那里你会看到你的组的状态最初为更新容量,因为第一个实例正在上线。
-
如果你想查看你的实例扩展,那么你可以按照以下步骤操作。在
eighteen中。 -
在横向菜单栏中,点击
eighteenASG 策略。选中后,使用操作下拉菜单,选择编辑:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_18.8_B17405.jpg图 18.8 – 单个 ASG 的横向菜单栏,突出显示自动伸缩
-
在
5000到100之间。一旦你更改了这个值,点击橙色的更新按钮。 -
返回主自动伸缩组页面并刷新,看到实例上线以满足即将到来的流量的需求。
现在我们已经了解了如何在实际环境中创建启动配置和 ASG,让我们继续深入理解自动伸缩生命周期,以及它如何不同于仅仅启动一个 EC2 实例。
自动伸缩生命周期
当你将EC2 实例放入 ASG 时,它会遵循一个普通 EC2 实例(你通过命令行或 AWS 管理控制台启动的实例)不遵循的特定路径。该实例首先由 ASG 启动。如果这是一个扩展事件的一部分,那么该实例有机会通过生命周期钩子执行特殊命令。生命周期钩子允许你在启动或终止作为 ASG 一部分的实例时添加自定义操作。一旦实例变为健康状态,它将处于服务中状态,并成为 ASG 的一部分。如果该实例未通过设定的健康检查次数,它可能会进入终止状态。如果当前运行的实例数不足以支持流量或指标数据,则可能会发生缩减事件。再次强调,就像扩展事件一样,这个缩减事件也允许我们使用生命周期钩子。
自动伸缩生命周期过程如下面的图示所示:
图 18.9 – 自动伸缩生命周期过程
现在我们已经理解了 ASG 的生命周期,让我们更深入地研究生命周期钩子以及何时最适合使用它们。
使用自动伸缩生命周期钩子
如我们刚才所见,Auto Scaling 生命周期中有两个状态,在实例进入这些状态时允许进行额外操作。这两个状态分别是Terminating:Wait状态,你可以让实例暂停最多 30 分钟,之后再进入Terminating:Proceed状态,最后进入Terminated状态。
生命周期钩子的使用场景
你可能想了解一些生命周期钩子的使用场景。让我们快速看一下几个例子。
第一个例子是使用启动状态来调用 Lambda 函数。一旦我们的实例通过待处理状态并进入Pending:Wait状态,我们就可以利用这个事件为我们的应用程序调用一个特定的 Lambda 函数。一个好的应用场景是,如果我们有 Windows 实例并且需要在每个实例启动时将其加入到特定的Active Directory(AD)域和名称服务器中。当实例进入初始生命周期钩子时,它可以运行一个脚本来获取其域名系统(DNS)名称并加入该域。
当我们开始终止一个实例的过程时,情况也是一样的。在终止实例时,有些情况下我们希望在允许实例进入终止状态之前,确保捕获到来自该一组应用程序的所有数据。
作为提醒,在生命周期钩子中使用复杂脚本可能会导致我们请求新实例上线并加入我们的 ASG 或终止之间的额外时间延迟,从而使我们在需要时能够获得更多的弹性。处于等待状态的实例仍然会占用与 ASG 的最大容量计算相当的实例容量。
清理资源
和我们其他的练习一样,建议你在完成本章后终止所有正在运行的实例并清理 ASG,以免在 AWS 账户中产生不必要的费用。
总结
在本章中,我们介绍了 Auto Scaling 以及它如何自动管理来自内部和外部客户的需求。我们了解了使用不同的扩展策略配置 ASG 的不同方式,甚至通过动手实践部署了一个 ASG。最后,我们探讨了 Auto Scaling 生命周期以及生命周期钩子如何帮助执行比简单扩展更复杂的任务。
在下一章,我们将开始几章的内容,重点讨论如何保护你的环境和管道,首先将讨论保护传输中和静态数据的安全。这将特别涵盖密钥管理服务(KMS)以及使用Amazon 证书管理器(ACM)来管理服务器端证书。
复习问题
-
你被引入了一家公司,该公司正在使用 ELB 和自动扩展运行一个业务关键型的工作负载。这个工作负载是一个二层应用程序,包括应用层和数据库层。目前,两个层都已经在
us-east-1区域的两个可用区(AZ)中部署。数据库需要以同步方式从应用程序进行复制。首席技术官(CTO)告诉你,即使单个可用区不可用,且自动扩展无法在剩余的可用区中启动新的实例,应用程序也必须保持完全可用。你该如何通过 AWS 特定的服务和架构来实现这一目标?-
在 ELB 中设置配置,以在三个可用区中进行部署,并将自动扩展设置为在峰值时每个区域处理 33%的负载。
-
在 ELB 中设置配置,以在三个可用区中进行部署,并将自动扩展设置为在峰值时每个区域处理 50%的负载。
-
在 ELB 中设置配置,以使用 Round Robin 算法在两个区域中进行部署,并将自动扩展设置为在峰值时每个区域处理 50%的负载。
-
在 ELB 中设置配置,以使用 Round Robin 算法在两个区域中进行部署,并将自动扩展设置为在峰值时每个区域处理 100%的负载。
-
-
你为一个在 EC2 实例上运行的应用程序创建了一个 DevOps 管道。客户通过附加到 ASG 的应用程序负载均衡器与此应用程序进行交互。自从发布了最新版本的应用程序和启动模板后,应用程序似乎在每天的每个小时都在多次扩展和收缩。你和你的团队应该采取哪些措施,以稳定 ASG,保持弹性,并优化成本?(选择两个答案)
-
修改应用程序的 ASG,使其使用计划扩展操作。
-
修改应用程序的 ASG 终止策略,使其优先终止最旧的实例。
-
修改应用程序的 ASG 冷却时间,使其变得更长。
-
修改与应用程序 ASG 组关联的 CloudWatch 警报,使其与缩减策略关联的警报周期更长。
-
-
你所在的公司有一个应用程序,包含通过 ASG 启动的 EC2 实例。你注意到当需求增加时,EC2 实例并未自动扩展。你应该如何检查并解决这个问题?
-
检查以确保 ASG 将实例分布到多个区域。
-
检查以确保 ASG 将实例分布到多个可用区。
-
检查以确保正在使用 ELB 健康检查。
-
检查以确保正在衡量正确的指标来触发扩展事件。
-
审查答案
-
b
-
c, d
-
d
第二十章:保护飞行中的数据和静态数据
当你和你的开发人员开始连接到你的系统时,安全性并非总是放在首位。尤其是当你认为加密密钥和证书握手可能会引起延迟时。无论如何,在今天的环境中,无论是传输中的数据还是静态数据,采用加密措施都是必须的。
有多种方法可以将加密技术融入你的环境。这可以从如何确保你与 AWS 之间传输的数据安全开始,然后是确保存储在亚马逊云上的数据安全,再到确保你为客户提供访问的数据的安全。
在本章中,我们将涵盖以下主要主题:
-
了解 KMS 密钥
-
向存储添加加密
-
向数据存储添加加密
-
使用 AWS 证书管理器保护传输中的数据
-
向 Amazon CloudFront 添加证书
数据加密简介
现在,推动加密数据的原因有很多。这个需求可能源于你的公司所在行业需要遵守的法规。也可能是公司内部的合规性治理规定要求数据必须加密。最终,也有可能是通过增加额外的保护层来采取主动的安全立场。无论推动加密的原因是什么,最终的目标都是为客户提供更安全的平台,并更好地保护数据:
图 19.1 – AWS 加密栈
最终,你和你组织的加密目标应该是通过最小化对数据的未经授权的物理和逻辑访问来简化。
在查看数据和加密时,有三个类别需要注意:
-
传输中的数据
-
静态数据
-
使用中的数据
如果按照亚马逊的建议进行操作,那么你应该在环境中尽可能多地进行加密。这包括在存储时对静态数据进行加密,并且在客户端和服务器之间传输数据时对传输中的数据进行加密。
在 AWS 中加密静态数据的选项
在本章中,我们将重点讨论来自 AWS 的两个服务:密钥管理服务和证书管理器。亚马逊生态系统中还有其他一些在数据加密过程中起作用的服务,我们希望简要提及它们,以防它们出现在测试中。
第一个是亚马逊虚拟私有云的一部分,第二个是AWS 虚拟私有网络(AWS VPN)。通过使用 AWS 的站点到站点 VPN 连接将你的数据中心与 VPC 连接,可以通过 IPSec 协议安全地传输数据。IPSec 协议组用于加密互联网传输。
您可以通过设置一个客户网关开始,这通常包括一个路由器,然后在 VPC 上创建 VPN 网关。VPN 的吞吐量限制为 1.25 千兆比特每秒。
现在我们了解了如何在 AWS 账户中加密静态数据的选项,让我们专注于使用 AWS 密钥管理服务(KMS)来保护我们静态数据。
理解 KMS 密钥
KMS 是 Amazon 提供的托管服务,使得生成和管理客户管理密钥(CMK)变得简单。CMK 是用于加密和控制存储在 AWS 上的数据访问的密钥。KMS 与许多其他服务(尤其是 IAM 服务)无缝集成,允许您控制谁有权访问这些密钥。
AWS 为 KMS 密钥创建密钥材料。作为客户,您不能提取、导出、查看或管理此密钥材料。您可以删除密钥,但不能删除密钥材料本身:
图 19.2 – AWS KMS 中的主密钥和数据密钥
在 KMS 中需要理解的一个关键概念是信封加密。当 AWS 加密您的数据时,您的数据是安全的,但您的密钥也需要保护。AWS 通过使用数据密钥加密数据,然后再用另一个密钥加密数据密钥来实现这一点。最顶层的明文密钥称为主密钥。
使用信封加密过程带来许多好处:
-
它保护数据密钥 – 这样,您可以将加密的数据密钥与加密的数据一起存储。
-
您可以使用多个密钥加密相同的数据 – KMS 允许您仅重新加密保护原始数据的数据密钥,而不是重新加密所有原始数据。
-
您可以结合多种算法的优点 – 对称密钥算法通常比公钥算法要小。但是,公钥算法允许继承的角色分离。使用信封加密可以让您同时使用这两种策略。
使用 AWS 托管的 CMK 密钥进行存储加密
每个提供加密的 AWS 服务都有自己的 AWS 托管 KMS 密钥。
AWS 托管的 CMK 和用户创建的 CMK 之间的一个关键区别是轮换计划。使用 AWS 托管密钥时,需要进行密钥轮换,并且每 1,095 天或每 3 年进行一次。
这两种不同类型的密钥的相似之处在于,AWS 托管密钥和 CMK 仅用于您的 AWS 账户。
使用 KMS 与 S3 保护静态存储的对象
KMS 与 S3 对象存储无缝集成。S3 拥有自己的服务托管密钥,允许您几乎不费任何力气地加密存储桶中的对象。还有以下安全控制可帮助将 KMS 与 S3 结合使用:
-
Amazon S3 具有自动加密所有新上传到存储桶中的对象的能力。这是通过 属性 部分中的一个存储桶设置来完成的,标记为 默认加密。一旦启用此设置,任何新上传到存储桶中的对象都会自动使用 Amazon 管理的 S3 密钥(默认情况下)或指定的客户管理的 S3 密钥进行加密。
-
如果你需要追溯性地加密 S3 存储桶中的项目,可以使用 S3 批处理功能。Amazon S3 具有在存储桶中的对象上执行批处理操作的能力。如果你的内部指导方针发生变化,或者审计发现某个用户(无论是内部用户还是外部用户)已经向存储桶中添加了未加密的项目,你可以使用 S3 批量操作来纠正这种情况。
-
如果你想检查某个 S3 存储桶中的项目是否已加密,可以运行 S3 清单报告。
现在我们已经了解了 KMS 如何与 Amazon S3 顺畅配合,特别是在使用 Amazon 管理密钥的情况下,我们将查看如何创建和管理自己的密钥,以及客户管理密钥和 Amazon 管理密钥之间的重要区别。
在 KMS 中创建和管理客户管理密钥
可能会有一些情况,某些用户或团队需要访问数据,而其他人则不应有权限访问。这是集成 CMK 与 IAM 策略来控制谁可以访问密钥的理想用例之一。
正如我们在本练习中所看到的,关键管理员和关键用户之间有职责分离。关键管理员是控制密钥访问的用户,包括旋转和删除密钥的能力。还有关键用户,这些是每天使用密钥的用户和服务角色。这些是你在创建和管理帐户中的密钥时必须理解的重要概念。可能有一些个人和团体需要管理密钥的能力,但不需要访问受密钥保护的数据。
在以下练习中,我们将使用 KMS 创建自己的客户管理密钥。在完成创建密钥之前,我们还将指定关键管理员和关键用户:
-
登录到 AWS 管理控制台并从顶部搜索菜单栏搜索
Key Management Service:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.3_B17405.jpg图 19.3 – 搜索菜单中的密钥管理服务图标
-
一旦进入 KMS,我们现在可以点击橙色的 创建密钥 按钮。
-
现在在 配置密钥 页面,选择 对称 密钥类型,然后点击页面底部的橙色 下一步 按钮。
-
这应该会将我们带到
chapter19作为 KMS 密钥别名。我们可以将example key作为 描述。向下滚动到页面底部,点击橙色的 下一步 按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.4_B17405.jpg图 19.4 – 添加 KMS 密钥别名和描述
-
现在是选择密钥管理员的时候了。这是一个重要步骤,决定了谁可以控制密钥的访问权限以及谁可以删除密钥,但不包括可以使用密钥的人员和组。由于你很可能已经使用我们在开始时创建的
devops用户登录,因此选择该用户,如果你有其他管理员帐户并希望它能够访问密钥,请勾选该名字旁的框。一旦选择了管理员的名字,点击屏幕底部的橙色下一步按钮。 -
现在我们应该在
devops用户下,让我们把之前创建的开发者用户mariel也添加到授权用户列表中。选定后,点击屏幕底部的橙色下一步按钮。 -
在审查页面,向下滚动并点击橙色的完成按钮来创建密钥。
现在我们已经完成了创建 CMK 的过程,让我们看看如何使用这个密钥通过加密来确保我们的数据安全。
使用我们的自定义 KMS 密钥为数据存储添加加密
现在让我们来看看如何使用我们刚刚创建的 CMK 来加密我们之前创建的 S3 存储桶中的对象。在示例中,我们将使用在第四章中创建的存储桶,Amazon S3 Blob 存储:
-
登录到 AWS 管理控制台,进入
devopspro-beyond。找到它后,点击存储桶的名称以进入。 -
进入存储桶后,点击顶部水平菜单中的属性选项卡:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.5_B17405.jpg
图 19.5 – S3 水平菜单中的属性菜单项
-
现在显示的是 S3 存储桶的属性项目,向下滚动,直到找到默认加密标题。点击默认加密框右上角的白色编辑按钮以进入设置界面。
-
现在你应该在标记为编辑默认加密的页面上。在服务器端加密标签下,点击启用旁边的单选按钮。选择后,下面将出现一组新的选择项,供你选择加密密钥类型。选择**AWS 密钥管理服务密钥(SSE-KMS)**选项旁的单选按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.6_B17405.jpg
图 19.6 – 在 S3 存储桶上启用 KMS 密钥
-
一旦进入我们在前面的实操中创建的
chapter19。选择后,向下滚动到页面底部,点击橙色的保存更改按钮。 -
在设置好存储桶的对象加密后,点击横向菜单中的对象菜单项,返回到主存储桶页面。点击橙色的上传按钮,在上传页面上,点击白色的添加文件按钮。选择任意一个文件上传到你的存储桶。一旦文件排队准备上传,点击橙色的上传按钮。
-
当你的文件完全上传到 S3 存储桶时,你可以点击橙色的关闭按钮。这将把你带回到 S3 存储桶的对象页面。点击对象的名称,然后向下滚动到服务器端加密设置,查看你的对象是否已经使用 KMS 密钥进行了加密。
重要提示
如果你已经不再使用 KMS 密钥,你可能想要回去并安排删除它。KMS 密钥不会立即删除,至少需要七天才能删除。加密对象的密钥一旦被删除,将无法访问。
通过了解如何使用 KMS 保护静态数据,我们接下来将学习如何使用 AWS 证书管理器保护传输中的数据。
使用 AWS 证书管理器保护传输中的数据
当你的外部网站呈现传输层安全性(TLS)证书并使用安全的 HTTP 协议(HTTPS/443)时,客户会知道你正在以加密方式保护他们发送到你系统的数据:
图 19.7 – 从浏览器到客户端的 SSL/TLS 工作原理
当你或你的客户请求一个使用 SSL/TLS 证书保护的 HTTPS 网站时,以下步骤会发生:
-
服务器尝试通过安全的
443端口连接到网站。然后该网站服务器会进行身份验证。 -
服务器接着会发送其 SSL 证书的副本。
-
客户端会检查证书,看看它是否来自受信任的机构。如果信任该证书,它将向服务器发送确认消息。
-
服务器随后会发出一个数字签名的确认,开始 SSL 会话。
-
数据随后在客户端和服务器之间安全共享。
AWS 证书管理器(ACM)是一个可以帮助你快速且轻松地在 AWS 服务上创建、管理和部署 TLS 证书的服务器。ACM 也支持公共证书。ACM 处理私钥基础设施(PKI)中最难和最复杂的部分,包括创建证书、证书续期和颁发证书等任务。
ACM 可以快速且轻松地为外部面向的 AWS 资源(如以下内容)提供 TLS 证书:
-
弹性负载均衡
-
AWS Elastic Beanstalk
-
Amazon EC2 实例
-
Amazon API Gateway
-
Amazon CloudFront
ACM 创建的任何证书有效期为 13 个月(395 天)。但是,您不能下载您创建的 ACM 证书的私钥。一旦证书颁发,您就无法添加或删除该证书中的域名。如果需要新域名,您可以创建通配符证书(*.domain.com),或者需要创建新的证书。
当我们在以下段落中提到域名时,我们指的是已在注册商处注册并托管在 DNS 服务器或服务(如 Route 53)上的域名。许多情况下,这可以被认为是域名。当首次为某个域名申请 Amazon 证书时,ACM 必须验证您是否拥有或控制该域名。可以通过两种方式进行验证。第一种是通过电子邮件验证。ACM 会向 WHOIS 数据库中列出的三个电子邮件地址发送验证邮件,您需要在 72 小时内通过该邮件进行验证。第二种验证方式是通过 DNS 验证。ACM 为您的域名创建两个 CNAME 记录,并要求您将这些记录添加到您的 DNS 数据库中进行验证。一旦验证记录存在,服务就会知道您是该域名的所有者。
ACM 可以执行的两项功能
我们已经解释了安全证书的作用,主要是针对面向公众的网站。这些证书的颁发是 ACM 执行的关键角色之一。然而,这并不是它在您的 AWS 环境中唯一可以执行的角色。ACM 提供了两项独立的服务。第一项是为 Elastic Load Balancing、API Gateway 和 CloudFront 等服务以及其他面向前端的服务管理、配置和续订企业级 TLS 证书。第二项服务是作为私有证书颁发机构。这使您能够为您的应用程序和基础设施颁发安全和可信的私有证书,以支持您的工作负载和组织。
现在我们知道了 ACM 可以执行的功能,我们将通过一个实际操作,使用 ACM 创建并配置一个证书,然后在一个公开可用的 CloudFront 分发中使用该配置的证书。
将证书添加到 Amazon CloudFront
在充分理解 ACM 服务之后,我们将继续本章的最后一个实际操作。我们将从使用 ACM 创建一个 TLS 证书开始,然后创建一个非常简单的 CloudFront 分发,并使用我们的安全证书对其进行加密,以保护任何尝试连接到该分发的人。
如果您没有可用的域名,您可以使用 Amazon Route 53 服务轻松注册一个域名,以非常低的成本完成此练习。否则,您可以阅读以下练习步骤以了解过程:
-
登录到 AWS 管理控制台,搜索 ACM 服务。一旦它从下拉菜单中出现,点击图标进入主服务页面。为了让证书与 CloudFront 服务兼容,我们需要在
us-east-1区域创建它。如果你在其他区域创建证书,你将无法在本练习的第二部分中看到它。 -
在 ACM 主页面,找到标有提供证书的图标和标题。点击该标题下方的蓝色开始使用按钮。
-
在请求证书页面,由于我们没有可用的私有证书颁发机构,只有一个选项可供选择。保持此选项被选中,然后点击页面底部的蓝色请求证书按钮。
-
创建证书的第一步是向证书添加域名。除非你只希望证书用于单一子域(例如 www),否则可以使用星号作为通配符,覆盖你的整个域名。在文本框中以
*.devopsandbeyond.com的形式输入你的通配符域名,然后点击蓝色的下一步按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.8_B17405.jpg图 19.8 – 将通配符域名添加到我们在 ACM 创建的证书中
-
下一步将是验证你是否真正拥有该域名。我们假设你通过 Route53 管理你的 DNS,并选择DNS 验证。保持DNS 验证选项被选中,然后点击蓝色的下一步按钮。
-
这将带你到添加标签页面。只需点击页面底部的蓝色审查按钮。当你进入审查页面后,确认你的域名输入无误后,按下蓝色的确认并请求按钮。
-
然后你需要将请求的 CNAME 添加到你的 DNS 文件中。获取该值并前往 Route53 服务。将该条目作为新的 CNAME 记录添加到你的域名 Route53 托管区。你可能需要等待几分钟,直到值传播完成,然后验证状态会变成绿色并显示为成功。一旦完成,你可以点击屏幕底部的蓝色继续按钮:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.9_B17405.jpg
图 19.9 – 在添加 DNS 条目后,验证状态显示为成功
现在我们的证书已创建完成,我们可以继续创建 CloudFront 分发。Amazon CloudFront 是 AWS 本地的内容分发网络(CDN)。CloudFront 允许你使用单一来源向全球的众多客户同时提供内容,相较于从单一位置(如服务器或自动扩展组)提供内容,其延迟更低。
-
现在,我们需要从 AWS 管理控制台顶部的搜索栏导航到 CloudFront 服务。进入服务主页后,点击橙色的创建 CloudFront 分发按钮,开始创建新的 CloudFront 分发。
-
页面标题现在应该命名为
devopspro-beyond;然而,你的存储桶将会有不同的名称。从下拉列表中选择你的源存储桶。源存储桶的名称将以.s3.us-east-2.amazonaws.com结尾。 -
在下一个文本框中,在源路径文本框中输入
/pages。 -
保持 CloudFront 创建的名称不变,继续进入S3 存储桶访问部分。选择是的,使用 OAI选项。此选项将允许我们保持存储桶私密,并要求用户通过 CloudFront 分发访问,而不是直接绕过 CDN 访问源中的资源。点击白色的创建一个新的 OAI按钮;你可以保留 CloudFront 提供的名称。然后点击橙色的创建按钮。
-
当对话窗口关闭时,在存储桶策略标题下,选择是的,更新存储桶策略选项。
-
向下滚动直到你看到
将 HTTP 重定向到 HTTPS选项被选中。 -
我们可以保持其他选项不变,直到进入设置部分。我们首先要做的事是优化成本,所以在价格类别下,我们要选择仅使用北美和欧洲。
-
现在,我们将安装来自 ACM 的自定义证书。在自定义 SSL 证书 – 可选标签下,使用下拉菜单选项找到你在练习第一部分创建的证书,位于ACM 证书标题下。
-
选择证书后,向下滚动至页面底部,点击橙色的创建分发按钮。
-
当 CloudFront 分发正在创建时,记下分发域名;这就是你如何在不添加 Route53 别名的情况下访问 CloudFront 的方式:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_19.10_B17405.jpg
<html> <head> <title> Chapter 19 - Protecting Data in Flight and at Rest </title> </head> <p> Protecting Transmission of data - <b> VPN </b> </p> <p> Protecting Data at Rest - <b> KMS </b> </p> <p> Protecting Data in Flight - <b> SSL / TLS certificates </b> </p> </html> -
返回到 S3。在那里,找到你指定为 CloudFront 分发源的存储桶。点击该存储桶的名称进入它。
-
进入存储桶后,我们需要点击白色的
pages,就像我们在 CloudFront 分发选项中所做的那样。在你命名文件夹后,点击橙色的创建文件夹按钮。 -
点击新创建的页面目录,然后点击我们在本节开始时创建的橙色
index.html文件。当索引页面准备好上传时,点击橙色的上传按钮。
我们刚刚了解了如何使用 ACM 创建并实现安全证书。现在,让我们回顾一下我们在本章学到的内容。
总结
在本章中,我们讨论了如何保护你在亚马逊账户中的数据,包括静态数据和传输中的数据。我们从账户级别开始,讨论了如何在数据传输到你的 VPC 时使用通过 IPSec 隧道的安全 VPN 连接进行加密。然后,我们探讨了 KMS 以及 Amazon 管理密钥和 CMK 之间的区别。最后,我们讨论了如何使用 ACM 保护传输中的数据。我们看到 ACM 如何简化了在多个 AWS 服务上创建和实施 SSL 和 TLS 证书的过程。
在下一章中,我们将探讨如何通过 AWS 提供的两个强大自动化工具——Systems Manager 和 Config,在你的组织中强制执行标准和合规性。
审查问题
-
公司所在的安全部门出台了新的合规性规定,要求所有加密密钥必须每 12 个月轮换一次,不得有例外。以下哪个选项不符合新规定?
a. 使用导入的密钥材料与 CMK
b. 使用 AWS 管理的密钥
c. 使用 AWS 客户管理的对称 CMK
d. 使用 AWS 客户管理的非对称 CMK
-
你被带入一家处理机密数据的公司。然而,他们在亚马逊管理控制台和使用 CLI 时都未加密地传输数据。你可以采取哪些步骤立即通过加密保护数据传输?
a. 在 KMS 中创建一组 CMK。使用信封加密,让每个用户在执行任何 CLI 命令之前加密每个交易。
b. 使用 ACM 创建证书以创建安全登录,并加密传输到亚马逊管理控制台的通信。
c. 在主 VPC 上创建客户网关和 VPN 网关。确保任何需要开发团队访问的其他 VPC 要么通过对等连接,要么通过过渡 VPC 连接器连接。
d. 要求所有用户为他们的账户添加多因素认证,以确保通过 CLI 和 AWS 管理控制台的安全通信。
审查答案
-
b
-
c
第二十一章:通过 Systems Manager 的角色和 AWS Config 执行标准和合规性
Systems Manager 是一个由多个单独功能组成的服务,这些功能被分为五个类别:运营管理、应用管理、变更管理、节点管理和共享资源。学习如何有效使用这个工具,可以让你作为一个 DevOps 专业人员变得更加高效,特别是在实现标准和检查一个或多个 AWS 环境或账户中的合规性时。随着组织对自动化和合规性要求的增加,拥有一个可以检查合规性、对不一致性发出警报并修复违规行为的工具,对于防止环境漂移至关重要。
在本章中,我们将讨论以下主要内容:
-
AWS Systems Manager 的各种功能
-
在 Systems Manager 中使用操作手册
-
AWS Config 基础知识
AWS Systems Manager 的各种功能
DevOps 是开发和运维两项职责的结合。AWS Systems Manager (SSM) 关注这些职责中的运维部分,为你提供了大量的工具,用于日常运营任务。这些工具涵盖了从创建预定义的操作手册,到在 Linux 或 Windows 实例上快速、轻松且重复地执行功能。Systems Manager 还可以为你提供一个接口,以便在一个统一的地方跟踪你的资源或资源组。
作为额外的好处,Systems Manager 不仅有助于管理 AWS 云中的实例,还可以通过在本地服务器上安装轻量级代理来管理这些服务器,并允许该代理与 AWS 账户进行通信。
Systems Manager 的关键特性和优势
Systems Manager 不仅仅是一个服务;它是一个供你使用的完整工具集。你可能不会使用它的所有功能,但了解它们可以帮助你快速解决问题:
图 20.1 – 组成 Systems Manager 的许多关键组件的概览
现在我们已经了解了一些 AWS Systems Manager 的功能,让我们深入探讨如何更有效地使用它来管理实例和节点。
使用 Systems Manager 进行节点管理
Systems Manager 为运维团队成员提供了许多功能,但有一类功能特别属于节点管理这一类别。
我们将查看 AWS Config 中一些专门为节点管理目的创建的特殊服务。
Fleet Manager
同时了解您控制的所有不同实例可能是一项令人生畏的任务。SSM Fleet Manager 为您提供了一个用户界面,让您查看所有在您控制下的实例。Fleet Manager 还允许您收集这些实例的数据,并传递回去,无需逐个进入服务器或实例。
清单
如果您需要查看本地服务器、云 EC2 实例或两者的状态,那么 Systems Manager 的清单功能对您非常有用。
混合激活
如果您有不在 AWS 云或本地的服务器,您可以使用 SSM 混合激活来管理这些设备,以及需要在单一管理控制台中管理的其他 EC2 实例。混合激活功能帮助您了解创建本地服务器激活所需的前提条件。包括创建 IAM 服务角色,确保操作系统兼容,并安装 Systems Manager 代理。
会话管理器
管理所有不同的 PEM 密钥,尤其是在开发人员自己创建密钥时,可能是一个繁重的任务。会话管理器通过允许授权用户使用基于 Web 的控制台执行命令,无需复制密钥,从而帮助减轻这一负担。您只需找到您需要远程创建会话的机器名称,然后立即启动会话。
本章稍后我们将通过一个练习来讲解如何使用会话管理器功能。
运行命令
通过 Systems Manager 的运行命令功能,您可以安全地更新您注册的管理实例的配置。命令文档是为执行运行命令而创建的。然后,使用实例 ID 或标签,针对指定的管理实例运行命令。
提示
您应始终在非生产或测试实例上测试您创建的运行命令。这样,您可以确保命令在执行之前会按预期执行,并且在生产流量到达服务器之前不会产生任何问题。
状态管理器
Systems Manager 的状态管理器允许您执行以下操作:
-
您可以配置网络设置。
-
您可以让您的实例加入 Windows 域。
-
它允许您在实例启动时使用引导脚本安装软件。
-
它允许您在整个生命周期内,在 Windows、Linux 甚至 macOS 管理的实例上运行脚本。
补丁管理器
如果您的环境中没有运行不可变基础设施,您应该有一个策略来保持您的实例系统补丁的最新状态。补丁管理器允许您在维护计划中添加这些系统补丁。
在 EC2 实例上运行远程命令
以前,如果你想在 EC2 实例上运行远程命令,必须创建一个 PEM 编码的密钥。SSM 会话管理器改变了这一切,它允许你通过浏览器使用具有正确权限的角色登录实例,而不是管理和轮换密钥。
注意
PEM代表隐私增强邮件,但这只是额外的知识,了解 PEM 的定义并不是考试的要求。
在接下来的练习中我们将看到这一点如何运作。在使用 Systems Manager 远程访问实例之前,我们需要设置一个 IAM 角色,该角色将允许 SSM 服务有权限访问任何具有该角色的实例。幸运的是,AWS 已经有一个托管的 IAM 策略,包含了我们完成此任务所需的所有权限;然而,我们仍然需要创建一个可以附加到 EC2 实例的角色。让我们开始吧:
-
打开浏览器,访问 Amazon Web 控制台,导航到 IAM 服务:
console.aws.amazon.com/iam/。 -
从左侧导航栏中选择角色,然后在出现的主框中按下蓝色的创建角色按钮。
-
在选择受信任实体类型页面,确保选择了AWS 服务。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.2_B17405.jpg
图 20.2 – 创建角色时选择 AWS 服务作为实体类型
-
然后,从常见使用场景列表中,找到EC2并点击选择它。选择后,你可以点击页面右下角的蓝色下一步:权限按钮。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.3_B17405.jpg
图 20.3 – 在创建 IAM 角色时的常见使用场景
-
现在你已经进入了附加权限策略页面,在屏幕中间的搜索框中,搜索名为 AmazonEC2RoleforSSM 的策略。策略出现在搜索结果中后,选择其旁边的框。一旦选择了该策略,你可以点击蓝色的下一步:标签按钮继续。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.4_B17405.jpg
图 20.4 – 向 IAM 角色添加托管权限策略
-
在添加标签页面,由于我们不会为此角色添加标签,只需选择页面底部的下一步:审查按钮即可。
-
在
Remote2EC2SSM页面上,你可以根据需要更改角色描述,使其更符合该角色的功能。更新完成后,点击页面底部的蓝色创建角色按钮。太好了!你的角色现在应该已经创建完成。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.5_B17405.jpg图 20.5 – 添加角色名称和描述
创建好角色后,我们可以开始创建一个临时的 EC2 实例,用于测试 SSM 的功能。
-
在顶部菜单的左侧找到 Services 菜单项。点击 services 以弹出下拉菜单,显示所有 AWS 服务。点击 EC2,它应该靠近顶部,位于 Compute 标题下方,进入 EC2 服务页面。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.6_B17405.jpg
图 20.6 – EC2 服务页面
-
进入 EC2 页面后,在页面中间找到 Launch instance 部分。点击该部分中的橙色 Launch instance 按钮开始启动实例。当你点击该按钮时,会出现两个选项;选择标有 Launch instance 的选项。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.7_B17405.jpg
图 20.7 – 从主 EC2 页面启动 EC2 实例
-
现在你应该会看到一个页面,可以选择要使用的 AMI。选择任何 2017.09 或更晚版本的 Amazon Linux 或 Amazon Linux 2,因为它已经预装了 AWS SSM 代理。点击蓝色的 Select 按钮选择镜像。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.08_B17405.jpg
图 20.8 – 在 AMI 选择页面上的 Amazon Linux 2
-
我们的测试不需要太多计算能力,因此可以使用 t2.small 实例。点击灰色的 Next: Configure Instance Details 按钮,因为我们需要确保将角色附加到实例上。
-
一旦进入
Remote2EC2SSM,并选择该字段的值。完成后,点击灰色的 Next: Add Storage 按钮。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.9_B17405.jpg图 20.9 – 配置 EC2 实例时选择 Remote2EC2SSM 角色
-
在
name字段中无需更改内容,使用RemoteTest作为值。确保将 N 大写,否则它不会正确设置实例名称的值,而只会设置标签和值对。设置好键值对后,可以点击页面底部的蓝色 Review and Launch 按钮。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.10_B17405.jpg图 20.10 – 使用标签设置实例名称
-
在 Review Instance Launch 页面上,点击页面底部的蓝色 Launch 按钮。这时会弹出一个对话框,询问你想使用哪个密钥对。不过,我们将清除顶部下拉菜单中的值,使其显示 Proceed without a key pair。勾选框以确认你在没有密钥对的情况下继续,然后点击蓝色的 Launch instances 按钮来启动 EC2 实例。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.11_B17405.jpg
图 20.11 – 在没有密钥对的情况下启动我们的 EC2 实例
现在我们的实例已经开始启动,我们已经完成了本练习的所有前置条件。我们现在可以转到 AWS 控制台中的系统管理器服务,登录而无需密钥,并执行命令。
-
在 AWS 管理控制台顶部的搜索栏中,输入系统管理器,然后点击列表中出现的菜单项:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.12_B17405.jpg
图 20.12 – 从 AWS 管理控制台搜索时显示的系统管理器服务
-
一旦你进入系统管理器服务页面,找到左侧菜单中的节点管理标题。在此标题下,点击名为会话管理器的菜单项。
-
当主会话管理器页面出现时,点击主窗口右上方的橙色开始会话按钮。
-
现在我们已经进入了之前创建实例时的
Remote Test。点击实例名称旁边的单选按钮选择该实例,然后点击橙色的开始会话按钮,远程访问该实例,而无需使用 PEM 密钥。 -
一旦
ssm-user登录,新的标签页或浏览器窗口将会弹出。这是系统管理器会话管理器连接的用户。
你刚刚看到会话管理器如何从操作的角度使访问实例变得更加容易。你不再需要为实例创建和管理密钥。然而,让我们来讨论一些使用会话管理器时需要考虑的问题。
在系统管理器中使用运行手册
由于我们已经有一个托管实例正在运行,我们可以在 AWS 系统管理器中创建一个运行手册,看看如何轻松地在一个或一千个实例上执行命令,所有这些都只需通过单击鼠标即可远程完成。
在我们开始之前,我们将使用的clamav.json脚本文件将可以在本书 GitHub 仓库的Chapter-20文件夹中找到。由于文件不是特别长,我们将在本练习中也展示它。
本练习还建立在前一个练习的基础上,因此,如果你希望完成本练习但未进行过在 EC2 实例上运行远程命令的练习,你需要通过执行前一个练习中的第 1 到第 14 步来设置环境。让我们开始吧:
-
如果你之前已经退出了 AWS 管理控制台,请以管理员用户重新登录,并通过顶部搜索栏或左上角的服务下拉菜单导航到系统管理器服务。
-
我们需要创建一个文档供系统管理器运行。虽然 AWS 已经创建了几个预定义的运行文档,但我们将创建一个自定义文档。在系统管理器服务的左侧导航菜单中,在共享资源标题下,点击文档。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.13_B17405.jpg
图 20.13 – 系统管理器服务中的文档菜单项
-
现在我们在文档页面上,我们需要找到右上角的橙色创建文档按钮。当你点击它时,会出现两个选项。选择命令或会话选项。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.14_B17405.jpg
图 20.14 – 显示两个不同选项的创建文档按钮
-
一旦
Linux_ClamAV_Installer被找到。 -
目标类型:保持此值为空。
-
文档:命令文档。
图 20.15 – 创建文档时的文档详情页面
-
在创建文档页面的底部是内容部分。这是我们加载要运行的脚本的地方。你可以直接从开始练习时下载的clamav.json脚本中剪切并粘贴脚本,或者手动输入脚本,如图所示。一旦脚本放入内容框中,点击橙色的创建文档按钮:
{ "description": "Install ClamAV on Amazon Linux, Run freshclam and clamscan", "schemaVersion": "2.2", "mainSteps": [ { "inputs": { "runCommand": [ "#!/bin/bash", "sudo amazon-linux-extras install -y epel", "sudo yum -y install clamav", "sudo touch /var/log/freshclam.log", "sudo chmod 600 /var/log/freshclam.log", "sudo freshclam ", "sudo clamscan -r /var --leave-temps" ] }, "name": "ALclamInstall", "action": "aws:runShellScript" } ] } -
按下创建文档按钮后,你将被带回主文档页面。在这里,你应该看到页面顶部的绿色横幅,确认你的文档已成功创建。如果你想快速而轻松地找到刚刚创建的文档,点击顶部菜单中的中间标签我拥有的。此时,你应该能看到你的文档。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.16_B17405.jpg
图 20.16 – 显示文档成功创建的通知
-
文档创建完成后,我们可以在左侧菜单选项中找到节点管理标题下的运行命令菜单项。点击运行命令以进入运行命令功能。
-
在运行命令功能屏幕上,点击主窗口右上角的橙色运行命令按钮以开始该过程。
-
为了让命令文档运行,我们将运行刚刚创建的文档。你可以通过在搜索框中输入
Linux来找到它。使用单选按钮选择文档的一个实例。由于我们只有一个文档版本,所以我们将保留默认版本(1)。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.17_B17405.jpg图 20.17 – 基于搜索词查找我们创建的文档
-
在目标部分,我们将手动选择我们的实例,因为我们在启动实例时使用的唯一标签是名称标签。当您点击手动选择实例时,如果看不到该实例,请输入实例的名称,即远程测试。选择实例名称旁边的选择框。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.18_B17405.jpg
图 20.18 – 选择要运行命令的目标实例
-
对于
devopspro-beyond。一旦选择了您的存储桶,您可以点击页面底部的橙色运行按钮。 -
一旦启动运行命令,您应该会看到一个屏幕,显示您的实例和命令运行状态为进行中。
-
几分钟后,您应该会看到命令运行成功。
现在我们已经学习了如何在多个实例上运行远程命令,接下来我们来看看 AWS 系统管理器的一些使用案例。
系统管理器的使用案例
系统管理器可以以多种方式帮助您处理日常的运营管理任务。让我们来看一些系统管理器的实际使用案例。
您需要确保在 AWS 账户中运行的 EC2 实例保持最新的安全补丁。
如果您有合规性或安全性要求,要求所有发布的安全补丁必须在特定时间框架内安装,例如从发布日起的 7 天内,那么在没有自动化的情况下,这将是一项艰巨的任务。如果您没有使用不可变基础设施,并且需要维护需要更新的长期运行实例,尤其如此。
使用维护窗口服务时,该服务是 SSM 的一部分,您可以将维护窗口分配给一组资源,这些资源将在其主要任务计划之外运行,然后将其与补丁管理器服务结合使用,安装安全补丁。此组合适用于 Linux 和 Windows 操作系统,也适用于已安装 SSM 代理的本地服务器。
成功的关键之一是确保您的实例上有正确的标签,这样您就可以根据标签将资源分组。通过维护窗口,您可以在创建资源组时组合标签,仅针对您计划修补的特定类型的实例进行操作。
现在我们已经学习了如何使用 AWS 系统管理器管理我们的许多操作任务,并帮助保持资源的合规状态,接下来我们将学习 AWS Config 服务。通过 AWS Config,我们将学习如何不断记录环境的历史,直观地查看发生了哪些变化,甚至主动修复不符合我们为账户设置的规则的项目。
AWS Config 基础知识
在大多数情况下,AWS 账户中的资源以某种形式不断变化。实例在启动和停止,同时也在创建和销毁。安全设置不断变化,用户通过启用和禁用端口来允许正确的通信协议。
AWS Config 服务使您能够全面了解 AWS 账户中发生的事情。它还允许您查看事物如何随时间变化。
使用 AWS Config 服务,您将获得以下功能:
-
您可以评估 AWS 资源配置,查看它们是否符合账户的期望设置。
-
将当前配置设置保存为受支持资源的快照的功能。
-
您可以检索单个或多个受支持资源的历史配置。
-
您可以设置接收通知的功能,当资源被创建、删除或修改时,您将收到通知。
-
获取对资源之间关系的视图。
Config 提供的另一个价值是,您可以使用常见的预定义规则,甚至编写自己的规则来检查环境的合规性。
理解 AWS Config 的概念
在我们深入了解 AWS Config 服务之前,让我们先看一些将要讨论的关键术语和概念。
AWS 资源
您通过 AWS 管理控制台、CLI 或任何可用的 SDK 创建和管理的实体是AWS 资源。这些可以包括 EC2 实例、EBS 卷、DynamoDB 表、RDS 实例和安全组、S3 存储桶、SNS 主题等等。AWS Config 使用Amazon 资源名称(ARN)来标识每个唯一的资源。要查看完整的受支持资源列表,请访问docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html。
配置记录器
当您运行 AWS Config 服务时,配置记录器会保存并存储各种受支持 AWS 资源的值和更改作为配置项。然而,在它开始记录之前,必须先创建并启动配置记录器。
配置历史
当您想了解某个特定的受支持 AWS 资源发生了什么更改,以及这些更改发生的时间时,可以使用配置历史。配置历史是一个特定资源在配置记录器运行期间的所有数据(配置项)的累积。
配置快照
与名称所暗示的有所不同,配置快照不是时间点的配置项的图形化展示。相反,它是一个基于代码的记录,记录了在特定时间点如何使用您的受支持资源及其不同的设置。这些快照可以保存到指定的 S3 存储桶中,以便可以在未来或过去的配置快照之间进行检索或比较。
配置项
支持的 AWS 资源的即时视图被捕获为配置项。捕获的信息包括属性、元数据、当前配置、关系和相关事件。
现在我们已经了解了 AWS Config 使用的概念和组件,让我们深入了解一下 AWS Config 的工作原理。
理解 Config 的工作方式
启动服务后,AWS Config 开始扫描账户中支持的资源。随着发现这些资源,它为每个资源生成一个配置项。
当这些资源发生变化时,配置记录器会生成并记录一个新的配置项。
图 20.19 – 理解 AWS Config 的工作流程
如果您已启用规则以供 Config 服务评估,则 Config 服务将持续检查配置项是否符合规则的标准。如果某个项不符合规则的标准,则将触发与该规则关联的 Lambda,并执行相关操作。
例如,如果公司已启用强制要求所有 EBS 数据卷必须加密,无论是通过 CloudFormation、CLI、SDK 还是手动创建,那么可以创建一个简单的 AWS 规则,以便在发现违规卷后向包含电子邮件组列表的 SNS 主题发送通知。
可以创建一个更复杂的规则,不仅将通知推送到 SNS 主题,而且还可以使用相应 Lambda 函数中的 AWS SDK 来终止任何创建时加密的 EBS 卷。
当 AWS 编译您的配置项历史时,您可以查看 AWS 发现的资源清单,以及查看任何特定 AWS 资源的合规性历史。
如果您正在使用配置规则,那么资源在发生更改时可以进行持续检查。您也可以设置定期检查,例如每隔 12 或 24 小时进行一次。
现在我们对 AWS Config 的工作原理有了很好的理解,让我们通过下一个练习自己试一试,以便能够获得一些实践经验。
部署 AWS Config – 一个实际例子
为了了解 AWS Config 服务的工作原理,我们将部署一个配置记录器以及两个将检查我们账户的规则。一旦记录器已经部署并开启,我们可以过一段时间再回来查看其发现情况。
注意
因为我们正在使用 CloudFormation 模板来部署我们的 Config 记录器,所以一旦完成使用,我们可以轻松地将其关闭。如果您要从 AWS 管理控制台启动 Config 记录器,则在需要时关闭默认的 Config 记录器并将所有设置重置为零将会很具挑战性。
在开始之前,确保你已经从本书的 GitHub 仓库中下载了名为 configTemplate.yml 的 CloudFormation 模板,位于 Chapter-20 文件夹下:
-
打开浏览器并使用管理员用户登录到你的 AWS 账户。登录后,进入 CloudFormation 服务。
-
在右上角,点击创建堆栈按钮。点击后,选择使用新资源选项。
-
在
configTemplate.yml中选择以下选项。 -
使用这些选项后,点击橙色的下一步按钮。
-
你将看到关于
MaximumExecutionFrequency的所有参数:One_Hour
填写完这些参数后,点击橙色的下一步按钮。
-
在创建堆栈时点击初始的下一步按钮后,你将进入配置堆栈选项页面。只需点击页面右下角的橙色下一步按钮继续。
-
一旦进入审核页面,在页面底部,你需要勾选能力部分的框,确认堆栈可能会创建 IAM 资源。完成后,点击橙色的创建堆栈按钮,开始通过 CloudFormation 创建 Config 记录器和规则。
-
不到 5 分钟,资源应已创建完成,包括配置记录器、新的 S3 桶用于捕捉配置快照,以及一个专门用于 AWS Config 服务通知的 SNS 主题。
-
现在,在 AWS 管理控制台中间的搜索栏里搜索 Config 服务。当图标出现后,点击它进入该服务:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.20_B17405.jpg
图 20.20 – 从搜索结果中看到的 AWS Config 服务图标
-
从AWS Config仪表板开始,这是你进入该服务后看到的第一个屏幕,我们会立即看到我们的合规状态。在我们的 CloudFormation 模板中,我们自动启用了两条规则。这些规则在我的演示账户中已经显示符合合规要求。然而,如果你的根账户没有启用 MFA,那么它可能会显示你未遵守一个或多个 Config 规则。https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_20.21_B17405.jpg
图 20.21 – AWS Config 仪表板上的合规状态
-
要查看我们当前在 AWS Config 中的规则,只需通过左侧菜单进入规则项。一旦点击此项,我们应该看到通过模板加载的两条规则的名称。
-
如果我们想查看 AWS Config 可以检查的我们账户中的资源,可以进入资源菜单项。加载完资源清单后,在资源类别的下拉菜单中,将选择项更改为AWS 资源。这将允许你查看 AWS 账户中 Config 可以跟踪的项目。
-
在任何这些资源上,点击蓝色的资源标识符按钮,将进入资源详情页面。如果你想查看资源随时间变化的时间线,请前往资源详情页面的右上角。这里,你会看到一个名为资源时间线的按钮。点击此按钮将打开时间线界面,显示资源随时间的变化。
我建议在你对账户中的不同资源进行一些更改时,可以将配置记录器保持开启一天左右。记得通过 CloudFormation 模板将配置记录器关闭;否则,你将承担 AWS Config 服务的费用。
现在我们已经学会了如何启动配置记录器并在 AWS 账户中启用一些规则,接下来让我们深入了解 AWS Config 提供的不同类型的规则。
配置规则结构
AWS Config 可以通过使用配置规则不断检查你的 AWS 资源是否符合合规要求。这些规则描述了你的资源应该如何构建的理想状态。
你可以使用配置规则来帮助确定你的环境和资源是否符合行业指南、内部最佳实践以及你需要执行的特定政策。
规则可以基于几种不同类型的触发器运行:
-
配置更改:当配置服务检测到资源发生变化时。
-
定期检查:配置服务按常规计划运行,例如每 3 小时或每 24 小时,检查资源是否发生变化。
托管规则与自定义规则
有许多 Amazon 已经设计好的预定义规则,可以用于许多常见的使用场景。这些规则可以检查资源,例如 EBS 卷是否已加密,或者某些端口是否已打开以允许流量通过。
这些托管规则可以通过额外的修复项进行自定义。
可以为任何需要检查和/或执行的资源或政策创建自定义规则。
通过使用托管规则和自定义规则,你可以自动地将你的组织保持在其期望的合规状态。
现在我们已经学习了如何使用 Config 和 SSM 来帮助保持我们的 AWS 账户合规,接下来让我们回顾一下本章所学的内容。
总结
在本章中,我们讨论了一些可以帮助简化 DevOps 角色中操作部分的工具。这包括 AWS Systems Manager,它本身提供了多种服务来帮助你完成任务。这些任务包括能够快速在远程实例上创建会话、创建可重复的流程、安装软件或从实例收集文件。我们还了解到,Systems Manager 可以与云中的计算实例以及本地服务器配合使用。
我们还研究了 AWS Config 服务。我们了解了它如何保留支持的 AWS 资源状态的时间线。我们还研究了 Config 规则的工作原理,以及它们如何用于标记不符合我们组织标准的资源。
在下一章中,我们将探讨使用 Amazon Inspector。这是一项帮助你主动发现账户中安全漏洞的服务。
问题
-
一家公司要求你配置 EC2 实例,以便它们可以通过 AWS Systems Manager 进行管理。该公司使用的是一种不同版本的 Linux 作为其基础的 Amazon Machine Image。哪些操作能确保一旦从该 AMI 启动实例,它能够在 Session Manager 控制台中找到?(选择两个答案)
-
将 Systems Manager Agent 安装为基础 AMI 的一部分。
-
创建一个名为
ssm-user的密钥对,并在启动实例时使用该密钥对。 -
确保实例所关联的任何安全组允许来自端口
22的流量。 -
为任何已启动的实例添加一个实例角色,该角色允许 Systems Manager 权限。
-
-
你正在为一家公司工作,该公司要求每周报告在两个区域内正在运行的 EC2 实例中使用的前五大操作系统。获取这些信息的最快且最具成本效益的方法是什么?
-
使用 Amazon Athena 收集关于所有运行实例的 CloudTrail 数据。创建一个 QuickSight 报告,显示每个区域前五大操作系统的图表和详细数据。将此报告分享给请求的相关人员。
-
确保所有实例具有允许 Systems Manager 服务访问的实例配置文件。使用 Systems Manager Inventory 创建一个报告,显示每个区域的前五大操作系统。
-
使用 EC2 实例控制台按操作系统对所有实例进行分组。从排序后的数据中创建报告。
-
创建一个 Lambda 函数,使用 CLI 调用所有 EC2 实例的操作系统类型。将此输出发送到 S3 存储桶,由相关人员下载。
-
-
一家电子商务公司的安全部门已执行一项新公司政策,规定任何 Web 流量不得通过不安全的 HTTP 或端口
80传输。任何之前允许通过端口80的流量,现在必须使用安全证书重定向到端口443。任何发现开放端口80的安全组将违反此新政策并立即暂停。定期监控是否有任何安全组允许流量进入端口80的最佳方法是什么?-
使用 Trusted Advisor 扫描已创建的非安全安全组。设置一个 SNS 主题,让 Trusted Advisor 可以发送通知。
-
向所有 VPC 添加一个网络 ACL 规则,阻止进入端口
80的流量。 -
使用 CloudTrail 日志来确定是否有任何安全组开放了端口
80。 -
在 AWS Config 中设置规则,检查是否有流量被允许通过端口
80访问任何安全组。如果发现安全组违反此规则,请向安全部门的 SNS 主题发送通知。
-
审查答案
-
a 和 d
-
b
-
d
1924

被折叠的 条评论
为什么被折叠?



