AWS 认证 DevOps 工程师（三）

原创于 2025-06-27 17:09:17 发布 · 899 阅读

27 ·

CC 4.0 BY-SA版权

License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译

文章标签：

#默认分类

默认分类专栏收录该内容

10503 篇文章

订阅专栏

原文：annas-archive.org/md5/b44a68a3321a441a0fdffa7dcbaf1892

译者：飞龙

协议：CC BY-NC-SA 4.0

第九章：使用 CodeDeploy 和 CodePipeline 部署工作负载

团队们正在寻找一种易于使用的工具，能够自动化发布过程，并提供一致的发布流程。我们将介绍如何将CodePipeline与第三方工具 Jenkins 结合，来自动化我们的部署发布周期，进而与CodeDeploy集成，实现实际的代码部署。

本章我们将讨论以下主要内容：

关于 AWS CodePipeline
设置代码管道
使用 Jenkins 构建工作负载
关于 AWS CodeDeploy
AWS CodeDeploy 使用案例

技术要求

如果你打算跟随本章中的练习进行操作，需要注意，前一章的内容 第八章，《使用 CodeCommit 和 CodeBuild 创建工作负载》是本章的前提。如同现实世界中一样，我们在前面章节中所做的工作基础上继续构建。因此，如果你没有在上一章创建开发者用户，你需要为该用户设置相应的身份与访问管理（IAM）权限。

关于 AWS CodePipeline

AWS CodePipeline 可以被看作是一个管弦乐团中的指挥。通过代码或 AWS 控制台，你可以将软件开发生命周期过程以可视化方式组织起来，过程可以是完全自动化的，也可以在某些阶段设置手动检查，确保每个阶段顺利通过。整个过程会以图形化的方式呈现给你的团队成员（包括开发者、测试人员和其他人员），让他们了解哪些部署成功，哪些部署失败。

AWS CodePipeline 帮助你自动化发布软件和基础设施更改的步骤，实现持续交付，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.1_B17405.jpg

图 9.1 – CodePipeline 及其与其他 AWS 开发工具的集成

不同的 AWS 开发服务，其中 CodePipeline 是其中之一，如图 9.1所示，并展示在系统开发生命周期（SDLC）的各个阶段下。

CodePipeline 动作结构

CodePipeline 结构包括几个不同的类别，允许原生 AWS 服务进行操作，或允许支持的第三方服务集成并执行必要的操作。

这里列出了六个有效的动作类别：

源
构建
测试
部署
审批
调用

每个动作类别都有一组可以调用动作或允许从该资源调用动作的提供者，如下表所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/014.jpg

表 9.1 – CodePipeline 源动作和动作提供者

除了动作集成外，还有一些其他 AWS 服务无需特定的动作类别即可集成，具体如下：

Amazon CloudWatch：CloudWatch 可以监控使用管道构建的资源，或者监控正在测试并集成到管道中的资源。
Amazon CloudWatch Events：CloudWatch Events 可以检测整个管道的变化，甚至可以检测管道某些阶段的变化。CloudWatch Events 甚至可以监听其他外部服务，并在特定情境发生时触发 CodePipeline 运行，例如当有人更新了 CloudFormation 堆栈时。这时可能需要重新部署软件。
AWS Cloud9：Cloud9 是一种基于云的集成开发环境（IDE），可以通过网页浏览器访问。
AWS CloudTrail：如果 CloudTrail 服务在特定区域处于激活状态，任何通过 AWS 控制台、软件开发工具包（SDK）或命令行接口（CLI）进行的应用程序编程接口（API）操作都会被捕获并记录。
AWS KMS：密钥管理服务（KMS）可以与 AWS CodePipeline 集成，用于源 S3 存储桶和工件，这些存储桶和工件要么是加密的，要么需要加密。假设工件来自与执行 CodePipeline 的帐户不同的帐户，那么加密该存储桶和对象的密钥将需要是客户管理的密钥。

从表 9.1中可以看到，既有原生的 AWS 服务，也有您可能已经在使用的第三方合作伙伴工具，这些工具可以集成到您的代码管道阶段中。

我们刚刚查看了不同的操作以及相应的 AWS 服务和第三方服务，这些服务可以帮助执行这些操作。接下来，我们将看看一些 AWS CodePipeline 的使用案例，包括真实世界的使用案例。

AWS CodePipeline 的使用案例

在考虑使用 CodePipeline 能做什么时，有一些特定场景已经确定 CodePipeline 作为工具是最合适的选择。接下来我们将看看这些场景中的一些。

自动化您的构建和发布过程

CodePipeline 允许开发人员专注于他们正在编写的代码，然后将代码提交到 Amazon 托管的代码库或第三方代码库，如 GitHub 或 Bitbucket Cloud。开发人员推送的新代码提交将触发构建过程。

为开发人员创建一致的工具集

在组织中让新开发人员快速上手并提高生产力的最具挑战性部分之一是入职过程。CodePipeline 通过提供一致的工具集来帮助这个过程，无论团队成员位于哪个时区，或使用什么操作系统。

使用 CodePipeline 与第三方提供商集成

假设你的团队当前使用像 Jenkins 这样的第三方工具进行代码构建或测试，BlazeMeter 进行负载测试，或 StormRunner 进行测试过程，那么 CodePipeline 可以帮助将所有这些工具统一协调展示。

使用一个服务账户从 CodePipeline 服务中调用，而不是每个个人或团队请求自己的许可证，也可能会带来成本节约的好处。

使用 Elastic Beanstalk 和 CodePipeline 持续部署你的 Web 应用程序

尽管 Elastic Beanstalk 常被认为是一个帮助开发者快速启动代码、并且接触较少 AWS 基础设施的服务，但这些代码可以成为组织中的成功项目。集成 CodePipeline 使得不再依赖于 Elastic Beanstalk CLI 或在 AWS 管理控制台中追踪部署，而是采用一种更结构化、可追踪的方式。

现在我们已经检查了一些 CodePipeline 成功使用的不同场景，接下来我们可以进入实际操作示例。在这里，我们将按照步骤设置我们自己的 AWS CodePipeline，并利用 CodeCommit 仓库。

设置代码管道

体验 AWS CodePipeline 的最佳方法之一是通过设置代码管道的练习。通常，这些管道的设置工作会由指定工具的团队成员完成。这些工具团队成员拥有与开发人员不同的独特权限集。

我们需要设置工具团队组并为他们分配正确的权限集。之后，我们可以创建工具团队成员并将其关联到工具团队 IAM 组。然后，我们可以以该工具团队成员身份登录，并让他们构建管道。

在设置管道之前创建我们的代码库

在设置我们的代码管道之前，我们将先创建一个全新的 CodeCommit 仓库。事先创建仓库将使我们能够拥有一套新的代码，用来执行管道中的各个步骤。

在我们 GitHub 仓库的chapter9部分，会有一个名为code的文件夹。这个文件夹将包含我们需要上传到即将创建的 CodeCommit 仓库的源代码，具体步骤如下：

打开浏览器，访问 AWS CodeCommit 首页，console.aws.amazon.com/codesuite/codecommit/home，如果出现提示，请登录。
点击屏幕右上方的橙色创建仓库按钮。
在chapt9中设置仓库名称。我们将添加描述，说明这个仓库是用于CodePipeline的，以便与在上一章节中创建的chapt8仓库区分开来，后者是作为测试创建的，参见第八章，使用 CodeCommit 和 CodeBuild 创建工作负载，如以下截图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.2_B17405.jpg

图 9.2 – chapt9 仓库的 CodeCommit 仓库设置
点击橙色的创建按钮。
由于我们已经在第八章中创建了一个可以上传文件的用户，使用 CodeCommit 和 CodeBuild 创建工作负载，现在只需点击左侧菜单中的Repositories（仓库）菜单项，如以下截图所示。这样就会显示我们在 CodeCommit 中的所有仓库名称，并允许我们复制需要的链接，以便将仓库克隆到本地工作站：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.3_B17405.jpg

图 9.3 – CodeCommit 的侧边菜单，仓库部分高亮显示
现在，点击chapt9仓库右侧的SSH链接，如以下截图所示。此时会弹出一个小对话框，确认该链接已被复制，你可以准备将仓库克隆到本地工作站：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.4_B17405.jpg

图 9.4 – 已复制到剪贴板的 SSH 克隆统一资源定位符（URL）

此时，我们暂时完成了 AWS 控制台的操作，接下来将切换到本地工作站的终端，进行下一组命令操作。
现在，打开终端，进入到你的主目录根目录。在 Linux 系统中，你可以通过$cd ~命令快速进入该目录。接下来，执行以下命令将仓库克隆到本地。现在，我们可以使用剪贴板中的 URL 来克隆仓库：
```
$ git clone ssh://git-codecommit.us-east-2.amazonaws.com/v1/repos/chapt9
```
一旦你成功克隆了仓库，你应该会收到一条确认消息，表示你已经克隆到一个空的仓库。
尽管我们有一个空的代码库，我们将从 GitHub 仓库的/code目录中获取示例代码，然后将其复制（或者如果你不希望在本地机器上有两个代码副本，可以选择移动）到这个新的本地CodeCommit仓库，这样我们就可以将其推送到CodeCommit。

确保你从已经克隆了 GitHub 示例代码的目录开始，如以下代码片段所示：
```
$ cp -R * ~/chapt9/
```
如果你不想通过命令行复制文件，也可以使用文件资源管理器（File Explorer）或 Finder，将文件复制到新的 git 仓库中。
现在我们已经将文件复制到CodeCommit本地目录中，接下来我们需要将所有文件添加到提交中。添加文件并编写commit消息后，我们将文件推送到代码库。我们可以通过几个简单的命令完成这一切。首先，我们需要从克隆的示例代码所在的目录切换到本地CodeCommit代码库，如下所示：
```
$ cd ~/chapt9
```

由于我们当前在本地目录中，我们现在可以添加所有文件并将其推送到远程的CodeCommit代码库。我们通过使用git add、git commit和git push命令来完成，操作如下：

$ git add * 
$ git commit -m "adding sample code to CodeCommit"
[master (root-commit) f85e8f2] adding sample code to CodeCommit
 2 files changed, 52 insertions(+)
 create mode 100644 buildspec.yml
 create mode 100644 src/app.py
$ git push 
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 825 bytes | 825.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
To ssh://git-codecommit.us-east-2.amazonaws.com/v1/repos/chapt9
 * [new branch]      master -> master

现在，示例代码已经准备好，我们可以继续进行下一步，即创建工具团队成员。我们的工具团队成员是专注于创建和管理管道及流程的人，而不仅仅是编写代码的人。

创建我们的工具团队成员

就像我们之前创建了开发组和成员一样，我们也需要为工具团队成员做同样的事情。重要的是要区分团队成员的职责，并只赋予每个人执行其工作职责所需的权限。在创建工具成员之后，我们将以该工具团队成员的身份登录，然后运行名为pipeline1.yml的 CloudFormation 模板来构建管道。

让我们继续设置工具团队成员的组，如下所示：

打开你的终端并输入以下命令，以便我们创建新的组：
```
$aws iam create-group --group-name Tools
```
运行命令后，你应该看到类似下面的确认信息：
```
{
    "Group": {
        "Path": "/",
        "GroupName": "tools",
        "GroupId": "AGPAW24Q7QQFSHYZHE6N6",
        "Arn": "arn:aws:iam::470066103307:group/tools",
        "CreateDate": "2021-05-14T01:25:58+00:00"
    }
}
```
注意返回的组名称对应的 ARN。你需要将其保存到记事本中，或者滚动到上方进行复制和粘贴，方便我们下一步将创建的策略附加到该组时使用。
接下来，我们需要使用预先制作的策略文档来创建策略，该文档应该已从 GitHub 仓库的Chapter9文件夹中下载，文件名为IAM_Tools.json，如下所示：
```
JSON after creation, as in the following statement:
```
{

“Policy”: {

“PolicyName”: “Tools_Members”,

“PolicyId”: “ANPAW24Q7QQF6FPOCHV5V”,

“Arn”: “arn:aws:iam::470066103307:policy/Tools_Members”,

“Path”: “/”,

“DefaultVersionId”: “v1”,

“AttachmentCount”: 0,

“PermissionsBoundaryUsageCount”: 0,

“IsAttachable”: true,

“CreateDate”: “2021-05-16T19:32:41+00:00”,

“UpdateDate”: “2021-05-16T19:32:41+00:00”

}

}

创建策略后，我们将把策略附加到组中，操作如下：

policy-arn field use the value which was returned to you in step 1:

–policy-arn arn:aws:iam::470066103307:policy/Tools_Members \

–group-name tools


If the policy attachment is successful, then there will be no confirmation message.

现在我们已经创建了tools组，可以创建一个用户成为工具团队成员。这个工具团队成员将是我们用于创建实际代码管道的用户。让我们继续创建我们的新用户，如下所示：
```
aws iam create-user --user-name peter 
```
现在，我们可以将新用户添加到tools组中，使其拥有该组的权限，如下所示：
```
aws iam add-user-to-group --user-name peter --group-name Tools
```
就像我们在第八章中创建的开发者用户一样，使用 CodeCommit 和 CodeBuild 创建工作负载，我们需要为工具用户设置一个初始密码，该密码将在第一次登录时由用户重置，具体如下：
```
aws iam create-login-profile --user-name peter --password Dev0psPRO --password-reset-required
```

到此为止，我们已经创建了工具用户，并且准备好以工具用户身份登录 AWS 控制台，搭建 AWS 管道。

创建管道

在创建了我们的工具用户（在我们这个例子中是 Peter）后，我们将从使用 AWS CLI 切换到浏览器和管理控制台，并假装这些操作是由工具用户执行的。在开始之前，你需要确保从本书的 GitHub 仓库中的Chapter9文件夹下载pipeline1.yml文件。

打开一个新的浏览器窗口，不带有任何 cookie 或会话，这样我们就可以作为 Peter 登录 AWS 控制台。你可能需要打开一个隐身窗口或使用一个不同的浏览器。例如，如果你一直在 Chrome 中使用管理员权限，则可以在 Firefox 或 Edge 中打开一个新会话，按以下步骤操作：

使用你的账号号码或账号别名以及用户名称peter和我们之前创建的Dev0psPRO密码，登录 AWS 控制台。
系统会立刻提示你更改用户peter的密码。将此密码更改为你喜欢的任何密码，但请记下或者设置一个你能记住的密码，因为你可能需要稍后访问此用户。以下截图显示了该过程：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.5_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.5_B17405.jpg)

图 9.5 – 工具用户 peter 的密码更改
更改密码后，AWS 控制台将带你进入主控制台页面。使用顶部的统一搜索框搜索CloudFormation服务。服务出现后，点击服务图标，进入主 CloudFormation 页面，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.6_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.6_B17405.jpg)

图 9.6 – CloudFormation 服务图标
在主CloudFormation服务页面上，点击橙色的创建堆栈按钮。
在创建堆栈页面，使用以下选项：

a. 准备堆栈—确保选中模板已准备好

b. 指定模板—选择标有上传模板文件的复选框
然后，点击pipeline1.yml文件并打开它。选中文件后，点击屏幕底部的橙色下一步按钮，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.7_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.7_B17405.jpg)

图 9.7 – 创建 CodePipeline 堆栈
一旦点击C9-demo并输入你希望接收堆栈通知的电子邮件地址。你可以将电子邮件地址留空，或者输入你自己的电子邮件地址。如果你创建的分支名为main，则无需做任何更改；但是，如果你创建的分支名为master（如我们的示例），则需要在master中更改默认值，然后再继续，否则管道将无法立即执行。填写完这些值后，点击屏幕底部的橙色下一步按钮，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.8_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.8_B17405.jpg)

图 9.8 – 添加值到指定堆栈详细信息屏幕
在配置堆栈选项屏幕上，我们不会添加任何标签。只需滚动到页面底部，点击橙色的下一步按钮。
现在，在审查 C9-demo页面上，滚动到页面底部，并勾选蓝色区域中的框，确认该堆栈将创建一个 IAM 角色，在功能标题下显示。勾选框后，你可以点击橙色的创建堆栈按钮，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.9_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.9_B17405.jpg)

图 9.9 – 在审核中的“功能”部分检查确认信息
一旦点击，你将被带到CREATE_IN_PROGRESS状态，直到我们的代码管道创建完成。完成后，我们就可以继续进行下一步了。
在 CloudFormation 过程完成后，我们将能够返回统一搜索栏，搜索CodePipeline服务。一旦CodePipeline的图标出现，如下图所示，点击它即可进入当前的管道：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.10_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.10_B17405.jpg)

图 9.10 – 从统一搜索栏中的 CodePipeline
你应该能够看到刚刚创建的管道，名称为C9-demo。点击此名称查看管道的详细信息。

我们可以从我们创建的管道中看到，现在已经创建了一个包含三个阶段的管道：源、构建和部署。在部署阶段包含了集成过程，包括手动审批流程，以及 CloudFormation 创建过程。

注意

如果你没有完成前面的练习，即创建名为chapt9的 CodeCommit 仓库，那么你将遇到管道问题。这个chapt9仓库是我们 AWS 代码管道的代码源。如果你将仓库命名为其他名称，你需要修改 CloudFormation 模板，或者进入 AWS 控制台修改源阶段。

现在，随着我们构建了 AWS 代码管道，我们可以继续让我们的开发者测试提交，并查看管道在实际操作中的各个阶段，就像它在现实生活中运行一样。然而，在此之前，我们需要为开发者用户提供更多的 IAM 权限，因为他们在最初创建时，只拥有 CodeCommit 权限并且只能修改自己的密码。

更新我们的开发者用户

在上一章，第八章，使用 CodeCommit 和 CodeBuild 创建工作负载，我们为开发者创建了一个用户组。我们为他们提供了一组权限，限定在 AWS CodeCommit 和 CodeBuild 服务内。由于现在我们要加入 CodePipeline 和 CodeBuild，因此我们需要扩展他们的权限，以便他们也能使用这些服务。在 GitHub 的 Chapter9 仓库中，有一个名为 IAM_Developers.json 的文件——请务必下载该文件，以便更新开发者的权限。在更新命令时，您需要使用管理员用户。我们将按以下步骤进行：

注意

在执行这些命令之前，请确保您已经从 GitHub 仓库的 Chapter9 文件夹下载了 IAM_Developers.json 文件，并且位于下载该文件的同一目录下。

我们需要做的第一件事是找到附加到开发者的策略的 ARN。我们在 第八章，使用 CodeCommit 和 CodeBuild 创建工作负载 的练习中创建了该策略。登录到终端并运行以下命令，提取开发者组的 ARN：
```
aws iam list-policies --query 'Policies[?PolicyName==`CC_Developers`].Arn' --output text
```
执行此命令后，我们应该会得到当前用于 Code Commit 开发者组的 ARN 返回结果。接下来，我们将在下一步中使用该 ARN 更新我们的策略。

在获得 ARN 后，我们可以创建一个新的策略版本，并将该版本设置为默认，如下所示：

aws iam create-policy-version \
--policy-arn arn:aws:iam::470066103307:policy/CC_Developers \
--policy-document file://IAM_Developers.json --set-as-default

如果成功，我们将返回一个JavaScript 对象表示法（JSON）消息，显示我们现在正在使用策略的第二个版本，如以下代码片段所示：

{
    "PolicyVersion": {
        "VersionId": "v2",
        "IsDefaultVersion": true,
        "CreateDate": "2021-05-16T19:01:09+00:00"
    }
}

更新我们的开发者用户组，以允许访问 CodePipeline，允许开发者查看之前创建的管道，并查看在管道各个步骤中可能遇到的错误。这些权限的范围被限制为不允许开发者创建或修改任何新的或现有的管道。

CodePipeline 概念

使用 AWS CodePipeline 时，需要了解几个基本概念和术语，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.11_B17405.jpg

图 9.11 – CodePipeline 转换表示

理解 CodePipeline 和阶段需求

在开始构建管道时，有一些规则和要求是应该了解的，因为这有助于你避免在调试错误时遇到麻烦。请查阅接下来的清单，了解最佳实践，并记住考试时的知识点：

管道中的所有阶段名称必须是唯一的。
只有管道中的第一个阶段可以包含源操作。
一个管道必须至少包含两个阶段。
单个阶段中的所有操作必须是唯一的。
阶段的输入操作必须与前一阶段的输出操作完全匹配。
输出工件名称必须在管道中唯一。如果某个阶段的输出工件名为TestPackage，则该管道中的其他阶段不得有名为TestPackage的输出工件。
对于所有支持的操作类型，唯一有效的所有者字符串是AWS、ThirdParty或Custom。

有其他更复杂的要求；然而，如果你理解了这些要求，那么你就为使用 CodePipeline 服务打下了坚实的基础，并且对 DevOps 专业考试中的阶段细节有了深入理解。

现在我们已经整体了解了 AWS CodePipeline 中的各个阶段，让我们来看看一个未被自动化的方面：审批操作。

CodePipeline 中的审批操作

在 CodePipeline 中，可以在阶段之间使用审批操作进行暂停。审批操作允许在继续进入管道的下一个阶段之前，手动审核操作。

经审核人批准的操作将进入管道的下一个阶段。如果审批被拒绝，则管道不会继续到下一个阶段。你也有 7 天时间来批准管道操作，否则管道将失败。

在 AWS CodePipeline 中使用审批操作的常见原因如下：

在进入下一阶段之前，进行手动质量保证（QA）测试
在继续之前，允许进行代码审查或变更管理审查
允许在发布到生产环境之前手动审核网页

使用 Jenkins 构建你的工作负载

AWS 提供的开发者工具几乎可以为你提供所有所需的功能，而无需额外的配置或设置。有些情况下，团队已经围绕现有工具构建了部分持续集成/持续部署（CI/CD）流程，并且可能希望保留已经投入时间和精力精细化的部分工作。

使用 Jenkins 服务器的团队可以属于这种情况之一。借助其庞大的插件生态系统，Jenkins 能够为 CI/CD 流程提供极大的功能支持。

许多团队在 CI 过程的构建阶段使用 Jenkins，因为在 Jenkins 中，构建步骤可以通过 Shell 脚本来实现，无需创建额外的buildspec文件。

下图展示了 Jenkins 与 CodePipeline 一起使用的情况：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.12_B17405.jpg

图 9.12 – Jenkins 与 CodePipeline 一起使用

Jenkins 本身有插件，可以与许多 AWS 服务兼容，包括开发者服务套件。

现在我们已经了解了 CodePipeline 服务，包括如何将 Jenkins 构建服务器等第三方工具集成进来，接下来看看如何使用 AWS CodeDeploy 部署我们的工作负载，不论是单独部署还是作为管道的一部分。

关于 AWS CodeDeploy

AWS CodeDeploy 是一个帮助自动化将应用程序代码和文件部署到 EC2 实例、本地服务器、Lambda 函数和运行在 AWS ECS 上的容器的服务。

CodeDeploy 是一个服务，它使以下事项变得更加简便：

更新 Lambda 函数并创建新版本。
在应用程序部署期间避免停机
快速发布新功能
在部署失败的情况下，及时回滚到已知的良好版本。

AWS CodeDeploy 专注于以下三个平台的部署：

EC2/本地实例
Lambda 函数
ECS 容器化应用程序

使用这三个平台作为基础，你需要在名为 appspec 的文件中描述你的部署。这个文件可以使用 JSON 或 YAML Ain’t Markup Language（YAML）格式编写。

CodeDeploy 可以分发多种类型的文件和组件，包括以下内容：

可执行文件
包
脚本
多媒体文件

现在我们已经掌握了 CodeDeploy 的基础知识，接下来看看在使用 CodeDeploy 服务时需要理解的基本概念。

需要理解的基本 CodeDeploy 概念

当我们开始使用 CodeDeploy 服务时，有一些组件需要首先理解。

应用程序

这是一个唯一的名称，CodeDeploy 使用它来标识你想要部署的应用程序。它使用这个唯一名称来确保在特定部署过程中引用的是正确版本的部署、部署组、修订版或回滚。

计算平台

这是 CodeDeploy 实际部署应用程序的平台。CodeDeploy 部署有很多选择。只要满足操作系统要求，部署可以发生在 EC2 实例或本地服务器上。这些部署可以包括配置文件、镜像、可执行文件及其他类型的文件。

CodeDeploy 还可以用于更新 Lambda 函数。CodeDeploy 还具备将流量从一个版本的 Lambda 函数转移到新版本的能力，支持多种部署选项，包括 金丝雀、线性和 一次性全部部署。

如果你在 ECS 平台上使用容器，则可以使用 CodeDeploy 来更新任务，采用 蓝绿部署 策略，首先安装新版本的任务集，然后将流量切换到任务集的最新版本。与 Lambda 部署一样，这些部署可以采用金丝雀、线性或一次性方式进行。

部署配置

使用一组成功或失败标准以及部署规则，CodeDeploy 会根据每次部署的部署配置来进行引导。在部署配置中，特别是在 EC2 或本地部署的情况下，你可以设置成功的最小健康实例数量，以确保部署成功。如果你部署的是 Lambda 应用程序或 ECS 任务，则可以在部署配置中指定流量在部署过程中如何路由。以下是可用的部署方式：

金丝雀：流量分两次进行转移，并且你可以指定在第一次转移前初始转移的流量百分比，剩余流量会在指定的分钟数后进行转移。
线性：流量按相等的增量进行转移。你可以预定义可以转移的百分比和转移之间的时间间隔。
一次性：所有流量会同时从原始的 Lambda 函数或 ECS 任务转移。

部署组

部署组适用于 EC2 实例，无论是单独的还是在自动扩展组（ASGs）中，并且会明确标记用于指定部署目标。

部署组可以简单地通过一个标签来指定部署组，或者你可以通过在一个部署组中使用多达 10 个标签来进行更复杂的配置。

部署类型

部署类型是 CodeDeploy 用来将最新版本的应用程序部署到部署组中的技术。有两种不同类型的部署方式：就地部署和蓝绿部署。

在就地部署中，虽然可能更具成本效益，但部署组中当前实例上的应用程序会被停止，同时安装最新版本的应用程序。新版本的应用程序会重启并进行验证。就地部署仅适用于 EC2 实例或本地部署。

蓝绿部署会配置一组新的资源。这可以包括创建新的 Lambda 函数版本，ECS 中创建新的任务集，或者在 EC2 中创建新的实例。

蓝绿部署不适用于本地部署。

修订版

AWS Lambda 部署的修订版是一个 YAML 或 JSON 格式的文件，包含有关要部署的 Lambda 函数的信息。Lambda 的修订版存储在 S3 存储桶中。

对于 EC2 或本地部署修订版，这不仅仅是一个文件，而是一个包含组件（如网页、可执行文件、源代码和部署脚本）的文件集合，以及应用程序的规范，然后将其打包成归档格式。EC2 或本地实例的修订版可以存储在 S3 存储桶或 GitHub 仓库中。

目标修订版

这是已经上传到代码仓库中的应用程序的最新版本，将被作为目标进行部署。

安装 CodeDeploy 代理文件

当使用 CodeDeploy 与 EC2 实例时，代理文件会被放置在这些实例上，使得实例能够从 CodeDeploy 服务进行部署。同时，配置文件也会被放置在实例上，并且该文件指定了代理如何工作。这些实例不仅必须在 AWS 云中，还可以位于本地数据中心的特定操作系统上。

查看以下列表，了解哪些操作系统已经使用 AWS CodeDeploy 代理进行过测试：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/021.jpg

表 9.2 – 测试过的操作系统，用于使用 AWS CodeDeploy 代理

任何你希望与 CodeDeploy 一起使用的 EC2 实例，也需要附加一个服务角色，以授予它足够的权限，以便 CodeDeploy 服务能够执行其职责。

理解 appspec 文件

应用程序规范文件，或者通常所说的 appspec 文件，在大多数情况下是一个 YAML 文件（虽然它也可以格式化为 JSON 格式），它有特定的几个部分，以及一些可选的部分，具体取决于你要执行的部署类型。

appspec 文件详细说明了在部署过程中你希望执行的部署操作。

如果你正在为容器做 ECS 部署、为 EC2 或本地实例部署，或者试图部署到 Lambda 实例，那么 appspec 文件有不同的类型。

以下是一个 appspec 文件的示例：

version: 0.0
Resources:
  - myLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "myTestFunction"
        Alias: "myTestFunctionAlias"
        CurrentVersion: "1"
        TargetVersion: "2"
Hooks:
  - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift"
  - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"

在我们示例中的 appspec 文件中，重要的项目包括版本、资源和钩子。

部署回滚和内容重新部署

AWS CodeDeploy 可以回滚一个已经被手动停止或在部署过程中失败的部署。严格来说，这些回滚是新的部署，并且会接收新的部署标识符（ID）。回滚确实会恢复一组代码的先前版本。回滚可以通过自动回滚或手动过程两种方式进行。

自动回滚

您的部署组可以配置为在部署失败时或在部署过程中达到某些监控阈值时自动回滚。如果设置了其中一个阈值并在部署过程中触发了自动回滚，那么部署将回到上一个已知的良好配置。

您还可以选择在开始新的部署时，通过配置部署组的高级配置选项来覆盖先前设置的自动回滚选项。

手动回滚

即使您没有设置自动回滚部署，使用 AWS CodeDeploy，您仍然可以推出之前版本的部署。这将创建一个新的部署版本。如果您的部署失败，或者实例进入未知状态，您可以通过推送应用程序和配置更新来修复它们。

回滚和重新部署工作流

如果回滚是自动或手动触发的，那么 CodeDeploy 将开始尝试删除在部署过程中成功安装的所有文件。

清理文件（如果存在）是一种日志文件，CodeDeploy 会保存它，以便知道哪些文件已被安装，并在开始新的部署之前删除这些文件。

在部署过程中，CodeDeploy 代理会记录正在部署的文件名，以便在需要回滚时有记录。

在回滚的情况下，CodeDeploy 会参考清理文件，以便知道需要删除哪些文件。然后，它可以在自动回滚的情况下继续执行之前的版本部署。

现在了解了部署和回滚的工作原理，让我们来看一下 AWS CodeDeploy 的一些使用案例。

AWS CodeDeploy 的使用案例

在我们了解了 AWS CodeDeploy 服务之后，让我们思考一些在什么情况下该服务最适合我们使用。

将应用更新部署到本地数据中心的服务器

如果您的本地硬件上运行的是兼容的操作系统，则可以使用 AWS CodeDeploy 来协调部署，并通过单一界面查看成功和失败。安装 AWS CodeDeploy 代理是必要的前提条件。这些操作系统包括 Windows Server、Ubuntu Server 或 RHEL。

将应用更新部署到 AWS 云中的 Windows 或 Linux 服务器

如果您正在将应用程序部署到 Linux EC2 实例上的 NGINX 或 Apache 服务器，或 Windows 服务器上的 Internet Information Services (IIS) 实例，则可以使用 CodeDeploy 代理来协调文件的放置，并重新启动任何需要更新文件的服务。

使用一次部署推送将应用更新部署到多个区域

当您寻找一种方法来构建解决方案，以在多个区域中为部署创建自动化端到端（E2E）发布流程时，AWS CodeDeploy 可以通过 AWS CodePipeline 的帮助来实现此目标。在尝试保持 Lambda 部署以实现高可用性（HA）或灾难恢复（DR）策略时尤为如此。在以下图表中，您可以看到 CodeDeploy 被用来在多个区域进行部署：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.13_B17405.jpg

图 9.13 – 使用 CodePipeline 和 CodeDeploy 进行多区域部署

使用 S3 作为源代码的起点将通过 AWS 代码流水线启动部署。如果流水线成功，则它将进入一个调用阶段，其中 Lambda 函数将源代码复制到复制区域的 S3 存储桶中。

将源代码复制到B区域的 S3 存储桶将在第二个区域设置的另一个流水线上重新启动该过程。

以蓝/绿方式将新任务部署到 ECS

CodeDeploy 可以让您无缝切换网络或应用负载均衡器后面的任务集。它通过部署任务集的新版本，然后在负载均衡器级别切换监听器到新版本来实现这一点，如以下图表所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_9.14_B17405.jpg

图 9.14 – 使用 CodeDeploy 进行蓝/绿部署

注意

我们将更深入地探讨第十三章，蓝绿部署。

在将任务部署到 Amazon ECS 并在切换流量之前使用 Lambda 进行验证

使用 CodeDeploy 部署组以及 Lambda 函数的帮助，您可以创建一个测试，以确保新任务成功运行。这个 Lambda 函数可以在部署appspec文件中指定，如果验证失败，则部署将停止并回滚。如果验证成功，则继续部署。

监控 CodeDeploy 作业

无论您的 CodeDeploy 作业是作为 CodeDeploy 服务的独立运行还是作为部署流水线的一部分运行，监控它们的状态并在发生故障时及时通知，对于及时解决问题至关重要。

将 CodeDeploy 与 CloudWatch 的监控功能结合使用，可以在部署过程中监控特定的指标。利用这些指标，您可以创建 CloudWatch 警报。最多可以将 10 个 CloudWatch 警报与一个 CodeDeploy 部署组关联。触发任何一个警报将导致部署停止，并且部署状态将显示为 Stopped。为了使用 CloudWatch 服务监控 CodeDeploy，您必须授予 CodeDeploy 服务角色权限以使用 CloudWatch 服务。

CloudWatch 事件可以帮助不仅检测，而且根据您创建的规则反应 CodeDeploy 作业的故障。一旦创建了这些规则，CloudWatch 事件将启动针对特定目标的动作。以下目标将与来自 CodeDeploy 作业的规则的 CloudWatch 事件配合使用：

AWS Lambda 函数
Kinesis 流
Amazon 简单队列服务 (SQS) 队列
CloudWatch 警报动作
Amazon 简单通知服务 (SNS) 主题（和通知）

CodeDeploy 监控用例

如果您的团队使用 Slack 作为通讯渠道，那么您可以通过 Lambda 函数集成 Slack 通知，每当 CodeDeploy 部署失败时。

如果在部署过程中发生特定事件，可以使用 CloudWatch 警报动作以编程方式重启、停止或终止 EC2 实例。

现在我们已经了解了如何监控我们的 CodeDeploy 部署，让我们回顾一下本章中学到的内容。

总结

在本章中，我们介绍了将要深入探讨的其他 AWS 开发者工具。我们了解了如何使用 AWS CodeDeploy 将软件部署到不同的环境，包括云端和本地环境。我们研究了如何使用 CodeDeploy 不仅推送应用程序的新版本，还能在部署过程中控制流量。我们还学习了 AWS CodePipeline 编排工具，它作为一项服务，不仅能够整合我们从开发角度看到的其他三个服务，还能整合其他第三方合作伙伴工具。

在下一章中，我们将介绍 AWS OpsWorks 服务，以及它如何帮助通过堆栈管理基础设施和应用服务，尤其是当您的团队成员熟悉 Chef 或 Puppet 时。

复习问题

一家公司的开发团队成员进行了多次部署。最后一次部署覆盖内容失败。您被要求回滚到之前的正常版本，并且包含应用程序所需的所有文件。您会选择哪种方式来尽可能迅速地完成此任务？

a. 手动回滚到最后一个已知的应用版本，并添加修订所需的文件。

b. 手动回滚到上一个部署版本，然后手动添加应用程序修订所需的文件。

c. 自动回滚到最后一个已知版本，并添加应用程序修订所需的文件。

d. 自动回滚到最后一个已知的应用版本，并手动添加应用程序修订所需的文件。
你已经构建了一个执行代码发布过程的 AWS 代码管道。这个管道有两个阶段：源阶段和部署阶段。源阶段使用第三方提供商 GitHub 来提供部署所需的代码。AWS CodeDeploy 被用来将新版本的应用程序部署到目标组中的多个 EC2 实例。最近的几次部署都没有成功，且在 CodeDeploy 阶段出现了失败。你需要增加监控和通知的能力，以缩短平均修复时间（MTTR）。如何在检测到问题时尽快创建通知？

a. 为 CodeDeploy 和 CodePipeline 设置 CloudWatch 事件。使用 Amazon Inspector 创建评估目标来评估代码部署问题，并创建一个 SNS 主题，以便在发生部署问题时能够收到通知。

b. 为 CodeDeploy 和 CodePipeline 设置 CloudWatch 事件。使用 AWS Lambda 函数帮助评估代码部署问题，并创建一个 SNS 主题，以便在发生部署问题时能够收到通知。

c. 为管道运行所在的区域设置一个新的 AWS CloudTrail 路径。使用 AWS Config 来评估任何代码部署问题，并创建一个 SNS 主题，以便在发生部署问题时能够收到通知。

d. 设置一个新的 AWS CloudTrail 来捕获来自 CodeDeploy 和 CodePipeline 的 API 事件。使用 AWS Lambda 函数帮助评估代码部署问题，并创建一个 SNS 主题，以便在发生部署问题时能够收到通知。

审查答案

第十章：使用 AWS OpsWorks 管理和部署您的应用堆栈

如果您的运营团队已经使用 Puppet 或 Chef 管理基础设施和应用，那么您应该已经听说过 OpsWorks。我们将查看堆栈如何使用预定义的代码为您创建基础设施应用，甚至是数据层。需要对应用进行更新？我们也会讨论这个问题。

本章我们将涵盖以下主要内容：

OpsWorks 基础
可用的 OpsWorks 平台
OpsWorks 与 Chef Automate
创建和部署食谱

技术要求

虽然不是必需的，但熟悉 Chef 或 Puppet 平台会在阅读本章时有所帮助。您需要了解完整堆栈应用的不同组件及它们之间如何相互作用。

OpsWorks 基础

在 第七章，使用 CloudFormation 模板部署工作负载 中，我们介绍了 基础设施即服务（IaaS）的 Amazon Web Services（AWS）提供的服务。现在我们将看看 AWS 提供的 平台即服务（PaaS）之一——OpsWorks。

OpsWorks 本质上是 Chef 和 Puppet 自动化包的封装。为什么要使用 OpsWorks？以下要点概述了您选择将 OpsWorks 作为客户或企业解决方案的原因：

简单：OpsWorks 使用简单。
高效：OpsWorks 通过使用脚本化配置帮助减少错误。
灵活：使用 OpsWorks 可以简化任何规模的部署。
强大：OpsWorks 有助于减少部署时间和部署成本。
安全：OpsWorks 服务允许细粒度的访问控制。

重要提示

OpsWorks 是少数不需要特定区域的服务之一。它是一个全球服务，显示所有已创建的堆栈，无论您的云资源当前所在的区域是哪个。

如果您的团队精简，负责所有或大部分组件，OpsWorks 特别有用：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.1_B17405.jpg

图 10.1 – OpsWorks 从应用中为用户提供服务

通过一系列事件，您可以使用 AWS OpsWorks 构建和管理您的应用：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.2_B17405.jpg

图 10.2 – OpsWorks 操作概览

首先，您需要为您的应用创建一个堆栈。多个应用可以共存于同一个堆栈中，它们应该都是同一系统的组件，例如 LAMP 堆栈、Rails 部署，或甚至是单层或双层应用。

其次，在您的堆栈被配置后，您需要定义您的层。在 LAMP 堆栈的情况下，这些层包括带有 PHP 页面和 MySQL 数据存储的 Apache Web 服务器。

第三，你将通过代码版本库和部署代码（如 Puppet 清单或 Chef 配方）来定义你的应用程序。

第四，必须定义 EC2 实例的数量和大小，以便为我们的应用提供一个部署位置。

最后，在第五步中，我们需要为不同的层选择一个部署策略。这个策略可以根据你是进行手动部署还是自动化部署而有所不同。

了解 OpsWorks 的组件

当我们开始讨论 OpsWorks 时，理解一些特定的关键词将是至关重要的。现在让我们看看构成 OpsWorks 各个部分的组件。

堆栈

堆栈表示你希望管理的云基础设施和应用程序。

你不能在一个堆栈中混合使用 Windows 和 Linux 实例。不过，你可以在同一个堆栈中运行不同版本的 Linux。

你的堆栈可以包含自定义的亚马逊机器映像（AMIs），只要映像所基于的操作系统是支持的操作系统之一。OpsWorks 不支持自定义 Windows AMIs。

层

层定义了如何设置和配置一组实例，以及相关的资源。OpsWorks 中的每个堆栈都包含一个或多个层。你可以把层看作是 OpsWorks 用来配置一组或多组 EC2 实例的蓝图。

在层级中，你可以定义如何配置实例，安装哪些软件包，以及定义在生命周期中会发生的关键事件。

在 OpsWorks 中，你可以定义几种不同类型的层：

负载均衡器层。
数据库层。
应用服务器层。
自定义 OpsWorks 层（当没有预定义的层能满足你的需求时）。
其他层：Linux 堆栈可以创建用于监控的 Ganglia 层，或者用于缓存的 Memcached 层。

实例

OpsWorks 中的实例包括计算资源，如 EC2 实例或本地服务器。

用户可以通过两种方式将实例添加到 OpsWorks 堆栈中：

你可以使用 OpsWorks 来配置实例。
对于基于 Linux 的堆栈，你可以注册一个已创建的 EC2 实例或本地服务器，这样就能让 OpsWorks 管理这个实例。

AWS OpsWorks 支持 AWS EC2 平台上几种操作系统的 64 位版本，包括 Ubuntu、Amazon Linux 以及 Windows Server。

应用

在 OpsWorks 中，应用表示你想应用于应用服务器的代码。代码本身将存储在应用程序库中，如 GitHub 或 S3。当你部署应用时，OpsWorks 会触发一个部署事件。

OpsWorks 中的生命周期事件

在 OpsWorks 管理的实例生命周期中，会发生五个系列的事件。这些事件如下：

设置
配置
部署
卸载
关闭

让我们更详细地看看一些事件：

设置：每次实例启动时都会触发此事件。它还用于软件包的初始安装。
部署：此事件在部署新软件版本时触发。部署事件还允许进行可定制的软件部署。
配置：当实例发生状态变化时，所有实例都会触发配置事件。此事件用于确保所有实例的配置是最新的。

OpsWorks 中的访问管理

如果你需要为每个用户提供访问实例的权限，无论是 Linux 还是 Windows 实例，那么 OpsWorks 可能是你在寻找的解决方案。AWS OpsWorks 服务提供了一种简单的方法，让用户可以使用自己的凭证登录到服务器，而无需使用自定义脚本。

如果你曾经创建过 EC2 实例并尝试通过 SSH 访问，那么你很可能会使用 EC2 用户或 Ubuntu 用户，具体取决于你用来配置实例的操作系统类型。如果你希望自定义用户能够访问单个 EC2 实例，那么这可能会变成一个复杂的设置，需要为每个用户配置并通过 LDAP 或 Active Directory 服务器进行身份验证。

如果你在 AWS 上分配 Windows 服务器，也是如此。你需要使用创建实例时所用的密钥对，然后使用该密钥对解密管理员密码。

重要说明

所有 AWS OpsWorks 堆栈的用户必须来自身份与访问管理（IAM）用户。

OpsWorks 让你可以为用户提供快速、轻松访问堆栈中实例的权限，而无需设置 Active Directory 或 LDAP 服务器。

OpsWorks 中的用户类型

AWS OpsWorks 服务中有两种类型的用户：管理员用户和常规 OpsWorks 用户。

OpsWorks 中的常规用户不需要附加策略或任何特殊的 OpsWorks 权限。根据每个堆栈，你可以指定以下四个权限中的一个或多个：

查看：此权限允许用户仅查看堆栈。
部署：部署权限还包括查看权限，并为用户添加额外的权限，以便更新和部署应用程序。
管理：管理权限包括部署权限，并增加了堆栈管理权限，例如添加层或实例。
拒绝：拒绝权限用于在堆栈中拒绝特定权限。

将用户导入到 OpsWorks

在我们迄今为止执行的所有操作中，我们已经在使用的帐户中创建了多个 IAM 用户。我们将在下一次练习中使用这些用户来练习将用户导入到 OpsWorks 中：

以管理员用户身份登录到 AWS 终端。
登录后，在顶部搜索框中导航到OpsWorks。一旦OpsWorks出现，点击OpsWorks图标进入OpsWorks服务：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.3_B17405.jpg

图 10.3 – AWS 控制台顶部搜索栏中的 OpsWorks 服务
即使导入用户后，他们出现在 OpsWorks 服务的任何一个部分，我们还是将用户导入到OpsWorks Stacks中。点击右下角的蓝色按钮，该按钮标记为前往 OpsWorks Stacks。
现在，在 OpsWorks Stacks 服务中，查看左侧菜单，找到名为用户的菜单项。点击用户，进入用户管理界面：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.4_B17405.jpg

图 10.4 – OpsWorks Stacks 侧边菜单栏中的用户菜单项
在主窗口面板中，在任何现有用户下方，找到标记为**导入 IAM 用户到 US East（俄亥俄州）**的链接。点击该链接进入导入页面。
一旦点击此链接，新的菜单将会出现，允许你选择要导入到 OpsWorks 的用户。选择一个或多个你想要导入到 OpsWorks 的用户，然后点击蓝色的导入到 OpsWorks按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.5_B17405.jpg

图 10.5 – 在 OpsWorks 服务中选择要导入的用户
现在，我们应该可以看到已导入到 OpsWorks 中的用户列表。如果我们想添加更多用户或限制他们的权限（例如，给予某个用户自我管理的权限以添加自己的 SSH 密钥，或更改自己的密码），我们可以通过编辑该用户来做到这一点。让我们编辑一个用户。点击开发者 Mariel 旁边的编辑链接。
在另一个终端窗口中，打印出你之前为第八章中的练习所创建的开发者公钥的内容，创建使用 CodeCommit 和 CodeBuild 的工作负载。将此公钥复制到剪贴板，以便在下一步中使用：
```
$cat ~/.ssh/cc_developer.pub 
```
切换回 AWS 控制台，现在在用户 Mariel 的屏幕上，向下滚动，直到你看到位于公钥 SSH左侧的多行文本框。将你之前复制的公钥粘贴到此框中：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.6_B17405.jpg

图 10.6 – 将开发者的公钥添加到 OpsWorks 用户
添加公钥后，我们的开发者可以使用以下方式登录到实例：
```
$ ssh -i ~/.ssh/cc_developer mariel@INSTANCE-DNS
```

我们现在已经完成了将之前创建的 IAM 用户导入到 OpsWorks 的练习，并且设置了开发者之前创建的 SSH 密钥，以便他们可以使用自己的用户名轻松登录到 OpsWorks 实例。

接下来，我们将探讨一些你可能希望使用 OpsWorks 服务的场景。

AWS OpsWorks 的使用案例

看完这一部分，你可能会想，怎样的情况适合将这个服务投入实际使用。我们将探讨几个场景，详细说明在何种情况下使用 OpsWorks 服务是有意义的。你需要明白，在评估测试题目或实际场景时，OpsWorks 是 AWS 提供的一系列部署和管理工具中的一种。Elastic Beanstalk 也是一个可以用来配置、部署和管理实例和代码的工具。我们将在下一章 第十一章 中更深入地讨论 使用 Elastic Beanstalk 部署你的应用程序。

可用的 OpsWorks 平台

OpsWorks 本质上是一种配置管理服务，提供受管的 Chef 和 Puppet 实例。这两种软件包都是行业认可的自动化平台，可以让你通过代码和自动化配置服务器。

现在，让我们更深入地了解 OpsWorks 提供的三种平台。

OpsWorks Stacks

OpsWorks 的最初服务提供形式是 OpsWorks Stacks。通过使用层，它帮助你管理和组织 EC2 实例。

OpsWorks for Chef Automate

如果你的团队熟悉 Chef 食谱的创建，并且知道如何使用 Chef 的一些高级功能，如 Knife，但又不想处理维护自己的 Chef 服务器的麻烦和头痛问题，那么 Chef Automate 可以成为你团队的合理选择。

如果你当前使用 Chef 管理一些本地基础设施，OpsWorks for Chef Automate 可以被配置为从单一来源管理混合环境。

OpsWorks for Chef Automate 还具有执行合规性扫描的功能。这些合规性扫描允许你定期审计应用程序，以检测漏洞和不符合要求的配置。

你无需担心 Chef 服务器的补丁、更新或备份问题，因为这些正是 OpsWorks 为你处理的任务之一。OpsWorks for Chef Automate 还允许你通过 Chef 控制台或通过命令行工具 Knife 来管理 Chef 实例。

OpsWorks for Puppet Enterprise

Puppet 帮助通过其工具集强制执行基础设施的期望状态。

如果你是现有的 Puppet 用户，那么 OpsWorks for Puppet Enterprise 将是最合适的选择。使用 OpsWorks for Puppet Enterprise，你可以在几分钟内启动一个 Puppet 主服务器，然后让 OpsWorks 服务处理诸如备份、软件升级和恢复等操作任务。

使用 OpsWorks 的 Puppet Enterprise 版本时，Puppet 主服务器将为需要运行 Puppet Agent 的实例提供并配置所有 Puppet 模块。

现在我们已经查看了 OpsWorks 的不同选项，包括两个基于 Chef 食谱的选项，以及一个基于 Puppet 清单的选项。接下来，我们将查看一个快速示例。这个示例将帮助我们更好地理解当我们在为客户选择最佳解决方案时，OpsWorks 的不同组件如何协同工作，同时也有助于我们准备 DevOps 专业考试。

创建并部署一个食谱

在这个示例中，我们将使用 OpsWorks 来设置一个 stack，并创建一个层。在我们创建好层之后，将使用一个公开的食谱将其部署到我们的应用程序：

作为管理员用户登录到 AWS 控制台，并使用统一搜索框搜索 OpsWorks 服务。当你看到 OpsWorks 图标出现时，点击图标进入 OpsWorks 主页面：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.7_B17405.jpg

图 10.7 – 通过统一搜索框访问 OpsWorks 服务
在 OpsWorks Stacks 页面上，点击左下角的蓝色 前往 OpsWorks Stacks 按钮。这是 OpsWorks 的原始提供选项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.8_B17405.jpg

图 10.8 – OpsWorks 服务页面上的 OpsWorks Stacks 选项
一旦进入 OpsWorks Stacks 页面，点击页面右上方的蓝色 创建 stack 按钮。此时将开始创建一个新的 OpsWorks stack。
接下来，我们将创建一个名为 Chef-11 的 stack，并选择以下选项：
- chapt-10
- 美国东部 (俄亥俄)
- 11.10
- 是
- Git
- 仓库 URL – github.com/amazonwebservices/opsworks-example-cookbooks.git
保持其他设置不变。
点击蓝色的 添加 Stack 按钮。
请参见下图：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.9_B17405.jpg

图 10.9 – 添加选项以创建 stack
现在我们应该看到一个 恭喜！您的 stack 已创建 的通知。接下来的步骤是向我们的 stack 中添加一个层。我们可以点击 添加一个层 链接并点击添加层：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.10_B17405.jpg

图 10.10 – 显示添加层链接的恭喜横幅
现在在层的页面上，我们将从下拉列表中选择 PHP 应用服务器。选择后，我们可以点击蓝色按钮 添加层：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.11_B17405.jpg

图 10.11 – 在 OpsWorks 中添加层
有了我们的层，接下来需要向该层添加一个实例。在 PHP 应用服务器 页面上，我们需要点击最右侧的 Add instance 链接：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.12_B17405.jpg

图 10.12 – 在 OpsWorks 中显示我们创建的层
现在，使用以下信息添加实例：

php-app1

c5.large

子网 – （保持选定的默认子网）

当你填写完所有这些选项后，点击选择窗口右下角的蓝色 Add Instance 按钮：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.13_B17405.jpg

图 10.13 – 向 OpsWorks 层添加实例
添加实例后，您可以启动实例。您会注意到在屏幕上该实例类型被指定为 24/7 实例。点击 Actions 列下的 start 链接来启动实例。
大约一分钟后，实例状态应从 stopped 或 booting 变为 online。

恭喜，你现在已经成功启动了堆栈！

现在我们已经了解了如何创建 OpsWorks 堆栈，包括其层、实例和应用，接下来我们将更详细地了解 OpsWorks 中的部署。我们将继续使用我们刚刚创建的堆栈，利用该堆栈创建一个应用并将其部署到堆栈中。

OpsWorks 中的部署

当你在 OpsWorks 中部署应用时，其主要目的是将应用代码和所有文件部署到服务器实例上。我们之前在 OpsWorks 中创建了一个堆栈、一个层和一个实例。现在我们将添加一个应用并将其部署到堆栈中：

返回到 OpsWorks 控制台并进入我们之前创建的堆栈——命名为 chapt-10。你可以通过点击堆栈名称进入该堆栈。
进入堆栈后，在左侧菜单中点击名为 Apps 的项，进入应用页面。在该页面顶部，点击蓝色的 Add App 按钮以创建一个新的应用：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.14_B17405.jpg

图 10.14 – OpsWorks 左侧菜单中的应用和部署
使用以下值来填充你的应用：
- SampleAPP
- PHP
- Git
- 仓库 URL – github.com/awslabs/opsworks-demo-php-simple-app.git
其他所有值可以留空。在填写完这些值后，点击屏幕底部的蓝色 Add App 按钮：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.15_B17405.jpg

图 10.15 – 添加应用设置
您现在应该看到一个显示我们应用程序的屏幕。现在是时候使用 OpsWorks 部署应用程序了。OpsWorks 通过在应用程序右侧的Actions列下方直接提供deploy链接来简化这一过程。点击deploy链接开始部署过程：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.16_B17405.jpg

图 10.16 – 应用程序创建后，已准备好部署
在部署屏幕上，在您部署之前，点击当前已选择Deploy的下拉菜单，查看所有不同的部署选项。在这一部分，您不仅可以部署应用程序，还可以让 OpsWorks 撤销部署、回滚、启动或停止 Web 服务器。确保保留部署设置，并保持所有默认选项。然后点击屏幕底部的蓝色Deploy按钮。

我们刚刚使用自定义配方完成了应用程序的配置，并将该应用程序部署到我们之前创建的实例上。

监控 OpsWorks

您可以通过多种方式监控您的 AWS OpsWorks 堆栈：

使用 Amazon CloudWatch
使用 Amazon CloudWatch Logs
使用 Amazon CloudWatch Events
使用 Amazon CloudTrail

使用 Amazon CloudWatch，有 13 个自定义指标用于详细监控堆栈中每个实例的状态。OpsWorks 中还创建了一个自定义监控页面，总结了这些数据，并使这些指标易于理解。如果您运行的是 Windows 实例，监控页面将不会显示这些 Windows 实例的指标。指标将显示整个堆栈的数据，但您也可以专注于特定的层或特定的实例。

如果您仍在运行上一个练习中的部署，您可以点击Monitoring菜单图标，进入仪表盘。这将为您提供关于应用程序状态的快速见解：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_10.17_B17405.jpg

图 10.17 – OpsWorks 中的监控仪表盘

我们刚刚覆盖了从创建堆栈到监控堆栈的完整 OpsWorks 流程。现在让我们回顾一下我们学到的内容。

总结

在本章中，我们讨论了 OpsWorks 服务如何帮助我们同时提供和部署我们的基础设施和应用程序。它通过使用堆栈和层来实现这一点。我们还了解到，OpsWorks 是将当前使用 Chef 或 Puppet 来提供服务器和/或应用程序的团队迅速过渡到其当前环境的一个好方法。

在下一章中，我们将学习 Elastic Beanstalk 服务及其如何帮助您将应用程序部署到环境中，为这些应用程序创建版本，并使用多种不同的编程语言来监控这些应用程序。

复习问题

你被引入到一家公司，该公司正在启动迁移到 AWS 云的工作。他们有一个庞大的 Chef 配方库，目前用于管理他们的本地系统。这些配方已经迁移到一个私有 GitHub 仓库。负责管理和维护 Chef 服务器的人员大约在一个月前离职。公司目前没有足够的资源在本财年内重写所有配方。你会推荐哪些 AWS 服务来帮助他们迁移？

a) 使用 AWS 服务器迁移服务将当前的 Chef 服务器迁移到 AWS 云。

b) 在 EC2 上启动最新版本的 Chef，并设置自动扩展以保证冗余。在本地托管区域的 Route 53 中添加一个记录指向 Chef 服务器。创建一个基础 AMI，已经预安装了 Chef 代理，并且连接到在 Route 53 中配置的 DNS 记录。

c) 将应用程序设置为 OpsWorks 中的堆栈。创建所有不同的用户作为 IAM 用户，然后将它们导入到 OpsWorks 中。接着根据需要将 OpsWorks 用户分配到各个堆栈中。

d) 创建一个 CodePipeline 实例，根据需要安装和配置应用程序，使用无头 Chef 在用户的init脚本中进行配置。
一家公司开发了一个 PHP 购物车平台。该平台目前由 AWS OpsWorks 管理和部署，开发、QA 和生产环境分别使用不同的堆栈。由于最初开发该平台的 PHP 开发人员大多已经离开公司，管理层已批准开始用 Python 重新开发该平台。公司应如何管理部署？

a) 创建一个新的 OpsWorks 堆栈，包含一个新的层和新的 Python 代码。为了过渡到新堆栈，组织应使用蓝绿部署。

b) 创建一个新的 OpsWorks 堆栈，使用新的 Python 代码管理应用程序的独立部署，放置在次要堆栈中。

c) 使用新的 Python 应用程序代码更新现有的堆栈，并通过 Deploy 生命周期事件部署该应用程序。

d) 在 OpsWorks 堆栈上创建一个新的层，并使用新的 Python 代码。为了顺利过渡到新的堆栈，组织应使用滚动部署。
一家企业在其本地数据中心管理一组 Windows 服务器和 Linux 服务器（Red Hat Enterprise Linux 和 Amazon Linux），并且还管理着 AWS 账户。在最近的审计中，首席技术官被告知没有针对核心应用程序补丁和操作系统更新的流程。无论是在本地数据中心还是 AWS 云中，所有服务器的补丁管理都没有基准级别。你被召来帮助解决这个问题。你会推荐什么解决方案，既能够提供和维护操作系统和核心应用程序补丁的最一致性，又能确保最可靠性？

a) 使用 AWS Systems Manager 将凭证存储在参数存储中，然后为实例创建资源组。允许 Systems Manager Run 命令使用存储在参数存储中的凭证远程部署补丁。

b) 在所有服务器上安装 OpsWorks 代理，包括本地服务器和 AWS 账户中的服务器。使用一个堆栈，为不同的操作系统创建不同的层。每当需要应用操作系统或核心应用程序补丁时，创建维护窗口。

c) 在所有服务器上配置 AWS Systems Manager 代理，包括本地服务器和 AWS 账户中的服务器。为实例创建资源组，然后允许 Systems Manager Patch Manager 在预配置的基准下运行，并使用设置的维护窗口。

d) 在所有服务器上安装 OpsWorks 代理，包括本地服务器和 AWS 账户中的服务器。创建两个不同的堆栈，一个用于 Windows，另一个用于 Red Hat Linux 实例。创建一个 Lambda 任务，每天两次请求 RSS 源，检查是否有新的补丁更新。如果发现更新，将触发 OpsWorks 层上的部署。

审查答案

第十一章：使用 Elastic Beanstalk 部署你的应用程序

了解并理解 Elastic Beanstalk 对于 DevOps Pro 考试至关重要。如何使用该服务的细微差别、该服务的局限性，特别是 Beanstalk 与容器的交互方式，对于通过考试和快速让应用团队在现实世界中启动应用程序都是至关重要的知识。

在本章中，我们将涵盖以下主要主题：

理解 Elastic Beanstalk 的内建功能
在 IAM 控制台中创建服务角色
安装并使用 Elastic Beanstalk 命令行接口（EB CLI）
理解通过 .ebextensions 进行高级配置选项
使用 Elastic Beanstalk 部署应用程序
Elastic Beanstalk 的应用场景

技术要求

由于 Elastic Beanstalk 需要一些本地开发，并且我们将在本章中用 Python 编写示例程序，因此你需要在工作站本地安装 Python 3.x。在撰写本文时，Elastic Beanstalk 支持的最新 Python 版本为 3.8.5，因此我们将在本章使用该版本的 Python。作者建议你安装 pyenv Python 运行时管理器，以帮助你在本地工作站上开发和管理多个 Python 版本。你可以在该项目的 GitHub 页面找到有关信息及安装方法，网址为 github.com/pyenv/pyenv。

理解 Elastic Beanstalk 的内建功能

Elastic Beanstalk 是一个灵活的平台，允许开发人员在如 Python、Java、Ruby、.NET、PHP（超文本预处理器）、Go 甚至 Docker 容器等语言中开发并快速扩展他们的应用程序。Elastic Beanstalk 是一个平台即服务（PaaS），这意味着它作为所有其他服务的抽象层，帮助协调和管理这些服务。这使得那些急于开始使用 Amazon Web Services（AWS）云的开发人员，虽然可能对设置基础设施或监控等内容了解不多，仍然能够顺利开始，并专注于他们所选择语言中的应用程序开发。

Elastic Beanstalk 持续更新其支持的语言和平台。尽管它并不总是支持语言的最新版本，但它确实尽力保持更新并逐渐淘汰旧版本。记住这一点很重要，因为旧版应用程序不能直接推送到云端并一直运行下去。有时候，应用程序需要升级，以便保持 Elastic Beanstalk 服务的功能。以下是 Elastic Beanstalk 集成的一些服务：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.1_B17405.jpg

图 11.1 – 一些 Elastic Beanstalk 集成的服务概览

在 Elastic Beanstalk 服务可供使用之前，开发人员必须弄清楚哪些服务可以协同工作，不仅仅是计算、负载均衡和路由，还需要——无论是手动还是借助像 CloudFormation 模板这样的服务——将安全性、存储和监控集成到他们的应用程序中。对于那些希望快速启动并运行 AWS 云服务的开发人员来说，这可能是一个挑战，因为他们习惯于创建应用程序代码，而不是配置环境。

Elastic Beanstalk 中的不同环境

使用 Elastic Beanstalk 构建并部署的任何类型应用程序都允许你将该应用程序中包含的所有不同组件作为单一环境进行管理。通过 Beanstalk 框架运行的环境主要分为两类：Web 服务器环境和工作环境。

Web 服务器环境

在 Web 服务器环境中，Elastic Beanstalk 管理三项内容：负载均衡器、自动扩展组（ASG）以及请求的 弹性计算云（EC2）实例数量。即使你的应用程序已被容器化，这些容器仍然需要 EC2 实例来运行，因此 Web 服务器环境将启动一组相应的 EC2 实例来运行容器。

Web 服务器环境还会创建一个 53 服务，因此它具有高度可用性和可扩展性。如果需要，你可以注册自己的域名，并使用 Route 53 服务将其指向负载均衡器，这样你可以使用自定义的 URL 而非原本为你创建的通用 CNAME，从而驱动流量访问你的 Web 应用程序。

工作环境

Elastic Beanstalk 提供的工作环境与 Web 服务器环境的主要区别在于，在工作环境中，53。Beanstalk 会自动安装一个守护进程，用于自动扩展，以下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.2_B17405.jpg

图 11.2 – Elastic Beanstalk 中的 Web 服务器和工作环境

接下来，我们将介绍构成 Elastic Beanstalk 的不同组件。

构成 Elastic Beanstalk 的不同组件

无论你正在使用 Beanstalk 服务构建哪种类型的环境，它都将由多个组件组成。

应用程序

在 Elastic Beanstalk 中，组件的逻辑分组称为 应用程序。这包括环境和环境配置以及版本。所有这些项目都被组合成类似文件夹的结构，而这个文件夹就是应用程序。

应用版本

Elastic Beanstalk 允许将特定版本的应用程序打包并标记。每个特定打包的应用程序版本被称为应用版本。这些版本会被打包并发送到背后的简单存储服务（S3）服务，用于部署到一个或多个环境，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.3_B17405.jpg

图 11.3 – 应用版本只能部署到单个环境

你可以在 Elastic Beanstalk 中运行多个版本的应用，分别运行在不同的环境中，例如在生产环境中运行当前稳定版本，在测试环境中运行最新版本。每次只能将一个版本部署到单个环境。

环境

在 Elastic Beanstalk 中运行特定应用版本的一组运行资源被称为环境。

环境配置

当你定义环境的参数和设置时，这些就构成了环境配置。当你对应用进行迭代，并更改环境的底层配置设置时，Beanstalk 会自动部署这些更改，并根据你的配置添加或删除项目，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.4_B17405.jpg

图 11.4 – 更深入地了解 Elastic Beanstalk 配置

配置模板

Elastic Beanstalk 中的配置模板是创建自定义环境配置的起点。

已保存的配置

已保存的配置是存储在 S3 中的YAML Ain’t Markup Language（YAML）文件，可以在其他运行中的环境或环境创建过程中使用。保存的配置定义了以下值：

平台版本
层级
配置选项设置
标签

平台

当你选择操作系统和编程语言时，所有的网页和应用服务器都构成了你的平台。

现在我们已经了解了 Elastic Beanstalk 的组件和平台，接下来我们将进行一个练习，创建一个 Elastic Beanstalk 应用，从创建必要的权限开始。

在 IAM 控制台中创建服务角色

在开始之前，我们需要为 Beanstalk 创建一个服务角色，供其在推送环境和应用时使用。如果没有这样做，或者没有更新几年前创建的服务角色，可能会在本章后续操作中出现错误并带来挫败感。

首先，使用管理员用户登录到AWS 管理控制台，然后按照以下步骤操作：

登录后，导航到IAM 服务。
在左侧菜单中，点击角色。
在创建角色页面，保持信任实体为AWS 服务，然后在页面中间，选择Elastic Beanstalk作为您希望创建服务角色的服务。点击Elastic Beanstalk服务。
选择Elastic Beanstalk服务后，屏幕底部会出现一组新的选项，供您选择使用案例。选择Elastic Beanstalk的使用案例。点击Elastic Beanstalk用例后，该选项会以蓝色高亮显示，如下图所示，然后您可以点击屏幕右下角的蓝色按钮下一步：标签：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.5_B17405.jpg

图 11.5 – 在身份与访问管理（IAM）中选择 Elastic Beanstalk 用例
点击下一步后，进入角色页面，默认的 Beanstalk 策略应该已经为您填充。点击屏幕底部的蓝色按钮下一步：标签，继续到下一个页面。
标签是可选的，您可以根据需要添加；否则，点击屏幕底部的蓝色下一步：审查按钮。
在 AWSServiceRoleForElasticBeanstalk 页面，点击页面底部的蓝色创建角色按钮以创建此角色。

现在我们已经创建了服务角色，可以继续使用 Elastic Beanstalk 服务。

安装和使用 Elastic Beanstalk 命令行界面（EB CLI）

AWS CLI 提供了多个命令，允许用户利用 Elastic Beanstalk。

EB CLI 提供的基本命令包括从在本地环境中创建正确的项目结构，到快速高效地拉取实例的日志文件以供审核的命令。我们将回顾 EB CLI 提供的基本命令，并简要说明其功能，如下所示：

eb create：此命令将在 Elastic Beanstalk 中创建一个新的本地环境，并将初始应用版本部署到该目录结构中。
eb status：此命令返回您的环境状态，包括应用程序名称、区域、CNAME 和健康状态等信息。
eb health：此命令返回环境中实例的健康状态，每 10 秒更新一次。
eb events：此命令返回当前 Elastic Beanstalk 环境的日志语句列表，列出最近的事件。事件示例包括资源的创建，如实例或负载均衡器，或环境状态更改为不同的健康级别。
eb ssh：如果您没有为特定的无类域间路由（CIDR）地址范围配置端口22，此命令将临时打开安全组的22端口，允许所有传入流量。然后，它会提示您连接到正在运行的实例，或者允许您选择要通过安全外壳（SSH）连接的实例。
eb logs：此命令可以执行两个与文件日志相关的明确命令，如下所示：

a. 它可以切换日志流到 CloudWatch Logs 服务。

b. 它可以获取实例日志，供您本地查看。
eb open：此命令将使用您的默认浏览器打开应用程序的公共 URL。
eb deploy：此命令将使用当前的源包将您的应用程序部署到 Elastic Beanstalk 服务。
eb config：此命令将允许您更改环境配置设置。
eb terminate：此命令将关闭并停止您的实例和环境，以免产生额外费用。

安装 EB CLI

获取 eb-cli-setup 脚本的最简单方法是通过 GitHub：github.com/aws/aws-elastic-beanstalk-cli-setup。

如果您使用的是 Mac 并且喜欢通过 brew 包管理器安装软件，则也可以通过这种方式安装 EB CLI。在尝试安装 EB CLI 之前，请确保您当前的 brew 版本是最新的。以下是您需要的代码：

$ brew update 
$ brew install awsebcli

无论您选择哪种方法，安装完成后，您应该能够从终端提示符直接访问 EB CLI，只需输入简单的 $ eb 命令。

注意

如果您之前曾在计算机上安装过 EB CLI，在继续之前最好使用 pip3 install --upgrade awsebcli 命令更新该软件包。

现在，安装了 CLI，我们来看看如何使用 EB CLI 创建和部署一个项目。

使用 EB CLI 创建项目

我们将使用终端来调用 eb cli 命令，并创建我们的 Elastic Beanstalk 项目。首先，打开终端窗口。然后，按照以下步骤操作：

打开终端窗口后，使用 EB CLI 创建一个新文件夹来开始我们的项目。最好从家目录的根目录开始，这样如果需要稍后返回，文件夹更容易找到。我们将把本地文件夹命名为 11-beanstalk。以下是您需要的代码：
```
$ cd ~
$ mkdir 11-beanstalk
```
我们需要确保已在系统上安装 virtualenv 程序，以支持 Python 3.x 编程语言。我们将使用 pip 来完成此操作，如下所示：
```
$ pip3 install -U virtualenv
```
现在，创建好文件夹后，我们可以进入该文件夹以创建 Python 的虚拟环境。一旦启用了虚拟环境，你会看到提示符稍作变化，命令提示符前会添加 11，如下代码片段所示。这表示你已经进入虚拟环境：
```
$ cd ll-beanstalk
$ virtualenv eleven
```

如果虚拟环境创建成功，你应该会看到类似以下内容的输出：

created virtual environment CPython3.9.1.final.0-64 in 767ms
  creator CPython3Posix(dest=/Users/abook/11-beanstalk/eleven, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/Users/abook/Library/Application Support/virtualenv)
    added seed packages: pip==21.1.2, setuptools==57.0.0, wheel==0.36.2
  activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator

既然我们已经创建了虚拟环境，我们现在需要激活它，如下所示：
```
$ source eleven/bin/activate 
```

在虚拟环境提示符显示时，我们将安装flask本地，以便使用 Python 创建一个快速的 Web 应用，如下所示：

flask package will also install a number of dependent packages that flask needs, including flask is a lightweight web application framework written in Python. It uses Jinja templates for rendering pages but can also just parse text or HyperText Markup Language (HTML). It can also be combined with other Python libraries to do more complex calculations and then render the results.

在环境设置好后，我们可以将从Chapter-11 GitHub 仓库获取的文件移动并复制到我们的11-beanstalk目录。首先进入克隆了 GitHub 仓库文件的目录，这样复制命令会更简短，如下所示：
```
application.py file that runs the application but also the templates folder (this holds the Jinja templates) along with the static folder (this holds the Cascading Style Sheets (CSS) style sheet). 
```
现在，让我们使用 pip freeze 命令捕获我们在远程环境中安装时所需的所有依赖，并将其输出到一个名为 requirements.txt 的文件中，如下所示：
```
$ pip freeze > requirements.txt
```
此时，我们应该在本地测试我们的flask应用程序，确保它运行正常并准备好部署。使用以下命令测试你的应用：
```
$ python3 application.py
```
假设应用程序启动成功，你应该看到类似以下内容的返回：
```
* Serving Flask app 'application' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
 * Restarting with stat
 * Debugger is active!
* Debugger PIN: 688-856-306
```
显示本地 URL 后，你可以打开网页浏览器查看应用程序的运行情况。

测试完本地应用后，按Ctrl + C在终端窗口停止本地服务器的运行。
在本地测试应用程序后，我们现在可以使用 EB CLI 创建环境。使用你仍然打开的命令提示符，我们将启动 Elastic Beanstalk 环境。确保在运行下一个命令之前，你仍然在11-beanstalk文件夹内，如下所示：
```
us-east-2
```
flask-quiz
(Y)es
Python 3.8
(Y)es
DevOps-pro（无密码）

创建好环境后，我们将继续学习如何使用 .ebextensions 自定义环境。

了解使用 .ebextensions 的高级配置选项

Elastic Beanstalk 允许你向应用程序的源代码添加配置文件，以自定义和配置环境中的 AWS 资源。

我们可以在目录中创建一个隐藏文件夹，用于创建和存储我们的自定义配置。

在11-beanstalk目录中，我们将创建一个.ebextensions目录，如下所示：

$ mkdir .ebextensions

我们现在可以运行一个 tree 命令，设置级别为 1，并要求它显示所有文件（以便显示隐藏的 .ebextensions 文件夹），查看我们当前的工作环境结构，如下所示：

$ tree -a -L 1

这应该显示如下的当前结构：

.
├── .ebextensions
├── .elasticbeanstalk
├── .gitignore
├── application.py
├── eleven
├── requirements.txt
├── static
└── templates

接下来，我们将把所有其他名为cloudwatch.config的文件一起复制到.ebextensions文件夹中，如下所示：

$ mv cloudwatch.config .ebextensions/.

如果需要，您也可以在 GitHub 的Chapter-11文件夹中找到此文件。

在创建了额外资源后，我们现在可以查看 Elastic Beanstalk 中为应用程序提供的部署类型，然后再开始部署应用程序。

Elastic Beanstalk 的部署类型

Elastic Beanstalk 支持多种部署类型，让我们详细了解每种部署方式。

一次性部署

使用一次性部署策略时，Elastic Beanstalk 会将指定版本的应用程序部署到环境中的所有实例中，所有实例同时进行部署。

这种部署方式需要的时间最短，相关成本也最低；然而，它也伴随最大的风险。如果部署过程中出现问题，应用程序可能会出现停机。这种部署策略最适用于开发和测试环境，生产环境中应很少甚至不应使用。

滚动部署

滚动部署将把应用程序的新版本推送到现有的 EC2 实例，但不同于一次性将应用推送到所有实例，它采用批次的方式来控制每次更新多少实例。

虽然这种部署方式不如“一次性部署”方法快速，但它同样可以保障在应用出现问题时，不会导致所有实例同时宕机。与蓝绿部署方式相比，滚动部署实例的成本也较低，因为你正在利用已经启动并运行的 EC2 实例，而不需要创建全新的环境。

附加批次滚动部署

尽管与滚动部署非常相似，附加批次滚动部署有一个明显的区别。这个区别在于，它确保在整个部署过程中保持应用的全部容量。

这种部署类型将在开始实际部署之前启动一组额外的实例。如果您需要保证流量持续稳定，并确保在执行应用程序更新时不影响容量，这将是一个不错的选择。

不可变部署

当你想到不可变基础设施时，你应该想到的是不对当前实例进行更新。这与不可变部署的概念相同，因为我们会设置一整套新的实例并部署到这些实例上，在它们变为健康状态后，才会将 Elastic Beanstalk 的域名系统（DNS）从旧环境切换过来，具体示意图如下所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.6_B17405.jpg

图 11.6 – 部署期间的不可变部署

这是部署应用程序最安全的方式之一，但也可能是最昂贵的，因为你需要设置双倍数量的实例，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.7_B17405.jpg

图 11.7 – 部署后的不可变部署

在对新版本的实例完成健康检查后，旧版本的实例会被关闭，流量会被引导到新版本的应用程序。如果任何实例存在问题，流量在一开始就不会被引导到这些实例。

流量拆分

流量拆分部署与不可变部署有些相似，因为它会创建一整套新的实例。主要的区别在于，在流量拆分部署中，旧的实例不会在新版本启动并健康后立即终止。相反，流量会按照你在控制台或通过 CLI 设置的控制节奏，逐步从一个版本转移到下一个版本，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.8_B17405.jpg

图 11.8 – 显示流量百分比的流量拆分部署

现在我们已经了解了不同的部署策略，我们将使用 EB CLI 和我们的终端来创建并部署一个 Beanstalk 应用程序。

使用 Elastic Beanstalk 部署应用程序

理解这些服务的最佳方式是通过动手示例来测试它们。Elastic Beanstalk 尤其如此，因为你需要在阅读 DevOps 专业考试中的问题和答案时，能够考虑到服务的功能。

我们将继续使用本章前面开始的示例代码。如果你没有做第一部分的练习，并且想要部署应用程序，建议你回到本章标题为使用 EB CLI 创建项目的部分。

如果你之前关闭了终端窗口，你需要重新打开它，并导航回11-beanstalk文件夹。我们之前已经在本地初始化了环境，现在可以继续按照以下步骤进行：

由于我们之前已经初始化了环境，我们可以按以下方式创建我们的初始环境——development：

$ eb create development

终端应显示类似于以下的返回信息：

Creating application version archive "app-210606_181258".
Uploading: [##################################################] 100% Done...
Environment details for: development
  Application name: flask-quiz
  Region: us-east-2
  Deployed Version: app-210606_181258
  Environment ID: e-mscggmggrw
  Platform: arn:aws:elasticbeanstalk:us-east-2::platform/Python 3.8 running on 64bit Amazon Linux 2/3.3.0
  Tier: WebServer-Standard-1.0
  CNAME: UNKNOWN
  Updated: 2021-06-06 22:12:41.224000+00:00
Printing Status:
2021-06-06 22:12:40    INFO    createEnvironment is starting.
2021-06-06 22:12:41    INFO    Using elasticbeanstalk-us-east-2-182968331794 as Amazon S3 storage bucket for environment data.

尽管新环境的设置可能需要几分钟的时间，但一旦完成，你可以通过使用eb open命令查看运行中的 Web 应用程序，如下所示：
```
$ eb open
```
你可以通过在 EB CLI 中使用events命令查看应用程序的所有事件，像这样：
```
$ eb events 
```
如果你想检查环境的健康状况，你可以登录 AWS 控制台查看可视化仪表板，或者你也可以使用 eb health 命令快速查看环境的统计信息，如下所示：
```
$ eb health
```
或者，如果你从控制台查看 Beanstalk 应用程序的健康状况，你将看到一个非常易于阅读的用户界面（UI），如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_11.9_B17405.jpg

图 11.9 – 查看 Elastic Beanstalk 监控仪表板
如果你愿意，你可以直接通过命令行使用 eb logs 命令检查日志文件。

完成后，你应该通过运行以下命令来停用虚拟环境：

zip ../eleven.zip -r * .[^.]* command to use as the source bundle to upload.

如果在部署过程中遇到问题，请按照下一节的指导来帮助排查问题。

使用 EB CLI 排查部署问题

如果在部署环境时遇到问题，请执行以下步骤：

找到声明Web 服务器网关接口（WSGI）路径的那一行。以下是一个示例：
```
WSGIPath: application
```
在冒号后编辑这一行，确保 .py 出现在“应用程序”一词后面。
保存并关闭文件。
尝试使用 eb deploy 命令再次部署你的应用程序。

现在我们已经完成了部署我们的 Beanstalk 应用程序并查看应用程序日志和事件的练习，我们将接下来讨论使用 Elastic Beanstalk 的使用案例和反模式。

Elastic Beanstalk 使用案例

Elastic Beanstalk 使开发人员能够轻松地在云端启动和运行，而无需担心底层基础设施或底层组件的管理。接下来，我们将看看使用 Elastic Beanstalk 的一些最佳使用案例。

你有一个小型的开发团队，需要快速启动

如果你有一个较小的团队，需要快速启动 AWS，但对其他组件、服务和相互连接不太熟悉，那么 Elastic Beanstalk 可以成为一个很好的选择，帮助按时完成任务。

你没有内部的 DevOps 专业知识

类似于之前的示例，如果一个公司或开发团队有一个需要快速部署到 AWS 的应用程序，那么 Elastic Beanstalk 提供了一个非常可行的解决方案，而无需任何高级 DevOps 专业知识。由于该产品本身可以与 Git 配合使用，这是大多数开发人员都熟悉的工具，因此在最短的时间内启动和运行是一项简单的任务。然后，Beanstalk 负责处理诸如 DNS、自动扩展、应用程序日志的轻松访问，甚至是无需额外设置的环境度量仪表板。

Elastic Beanstalk 反模式

正如我们刚才看到的，Elastic Beanstalk 在某些情况下非常适用，但也有一些情况它并不是一个好的选择。在这里，我们将探讨一些已知的使用 Elastic Beanstalk 的反模式，了解在哪些情况下你应该考虑选择 AWS 的其他服务。

需要大量环境变量的应用程序或项目

Elastic Beanstalk 的一个限制是它只有 千字节 (KB) 的存储空间用于存储所有的键值对。考虑到这一点，如果你有很多环境变量，例如不同数据库连接字符串、用户名和密码，适用于每个你创建的环境，那么你可能会遇到这个硬性限制，Elastic Beanstalk 对你的应用程序来说就不再是一个好的选择。

非常大的应用程序

Elastic Beanstalk 部署包的最大大小只能是 512 .ebextensions 目录。如果你有大量静态资源，比如图片或媒体文件，可以将它们存储在 S3 中，并在应用程序或动态存储（如 DynamoDB）中存储指针，这样可以减少源包的大小。

总结

本章中，我们介绍了 Elastic Beanstalk 服务，这是 AWS 提供的另一种部署服务。我们介绍了 Elastic Beanstalk 提供的不同部署选项，并使用 EB CLI 工具创建和部署 Beanstalk 应用程序。我们还探讨了使用 Elastic Beanstalk 的最佳情况，以及一些反模式，说明在这些情况下 Elastic Beanstalk 并不适合。

在下一章中，我们将探讨如何使用 Lambda 函数和步骤函数，以无服务器的方式部署我们的代码。

复习问题

你被引入了一家公司，该公司有一个应用团队，他们的应用程序是两层架构——一个是 Web 层，另一个是数据库层。应用团队需要一种快速地在 AWS 上配置和部署环境的方法。以下哪种选项是最快且最理想的设置方式？

a. 使用 Elastic Beanstalk 服务来配置一个环境，然后将应用程序推送到该环境。

b. 创建一个带有两个层的 OpsWorks 堆栈，一个用于应用程序，另一个用于数据库。将应用程序部署到应用层。

c. 使用 CloudFormation 创建一个 S3 存储桶、一个 RDS 数据库和一个 EC2 实例。使用用户数据脚本从 S3 存储桶加载应用程序，并传递 RDS 连接字符串、用户名和密码等参数。

d. 创建一个 RDS 数据库，然后使用 Lambda 部署应用程序。
你被引入了一家公司，这家公司正在尽可能快地自动化迁移到 AWS 云。该公司要迁移的应用程序是使用多种不同编程语言构建的。你如何才能尽快将这些应用程序迁移并部署到云端？

a. 创建一个主 CloudFormation 模板，利用嵌套堆栈设计来部署应用程序。在为每个应用程序创建 Docker 容器后，创建每个应用程序的子模板。

b. 在一个 Docker 容器中开发每个应用程序，并使用 Elastic Beanstalk 进行部署。

c. 在一个单独的 Docker 容器中开发每个应用程序，并使用 Elastic Beanstalk 进行部署。

d. 使用 OpsWorks 创建堆栈。为每个应用程序创建一个单独的层，然后将每个应用程序部署到对应的层。
如果你的应用程序需要较长时间完成其活动或工作流，Elastic Beanstalk 可以为你提供哪项服务？

a. Beanstalk 可以管理 Elastic Load Balancing（ELB）服务，并在每个实例上运行守护进程。

b. Beanstalk 可以管理一个简单通知服务（SNS）主题，并在每个实例上运行守护进程。

c. Beanstalk 可以管理 Lambda 函数，并在每个实例上运行守护进程。

d. Beanstalk 可以管理一个 SQS 队列，并在每个实例上运行守护进程。
你被邀请加入公司，帮助在主要区域发生故障时自动化恢复策略。该公司优先考虑减少恢复策略的成本，但同时也需要在必要时能够快速恢复完整的基础设施。你会如何建议公司以最低成本实现这一目标？

a. 在另一个区域创建一个试点灯基础设施，并根据 CloudWatch 事件自动调整大小。

b. 通过在灾难恢复（DR）区域使用 Elastic Beanstalk 创建一个全新的环境来创建重复的基础设施。在发生故障时，将 Route 53 记录切换到 DR 区域的负载均衡器。

c. 使用 Elastic Beanstalk 创建另一个环境，作为应用程序的副本，以防发生故障。

d. 使用 CloudFormation 在发生故障时在另一个区域启动资源。

审核答案

第十二章：Lambda 部署和版本控制

随着越来越多的应用架构走向无服务器，越来越多的云预算受到审视，AWS Lambda 成为开发者和运维人员工具箱中越来越可行的选择。了解如何利用 Lambda 和 Step Functions 的灵活性和强大功能是当今 AWS 环境成功的关键。

本章将涵盖以下主要内容：

AWS Lambda 概述
Lambda 函数
Lambda 触发器和事件源映射
使用 Lambda 部署版本
使用 Lambda 层
监控 Lambda 函数
Lambda 最佳使用案例和反模式
使用 Lambda 协调 Step Functions

技术要求

与前几章一样，我们将使用 Python 编程语言创建 Lambda 函数。建议具备基本的 Python 工作知识，以便跟随示例并在必要时进行调试和故障排除。

AWS Lambda 概述

AWS Lambda 是一种允许您将代码作为函数运行的服务，无需设置任何服务器或进行容器编排。它会自动根据接收到的请求数量进行扩展。Lambda 函数最吸引人的特点之一是它们仅按运行时间收费。这意味着您可以在一个或多个区域内配置平台，等待请求，而不必担心因空闲资源而产生的账单。

Lambda 让您专注于代码，而不是服务器，因为它是一个无服务器的 PaaS（平台即服务）产品。作为 PaaS 也意味着，除非 AWS 向您暴露，否则您无法访问底层计算平台进行调整，例如运行时（编程语言）、您的环境、函数需要使用的内存量以及分配的 CPU 数量：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.1_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.1_B17405.jpg)

图 12.1 – 带触发器的 Lambda 架构

许多 Lambda 函数是由其他 AWS 服务触发的事件。这也是该服务如此有吸引力的原因之一。Lambda 函数可以用于基于 S3 存储桶事件进行后台处理。然后，您可以将它们放入一个解耦的架构中，使用消息队列，如简单队列服务（Simple Queue Service）或Amazon MQ，由一个或多个并发的 Lambda 函数进行处理，将数据存入后端数据存储中。

然后，可以使用诸如API 网关的服务通过 GraphQL 和AppSync来检索数据。

无服务器而非服务器

无服务器这一术语应立刻让人联想到一些关键概念。在 AWS 的世界中，这可以归结为四个基本原则：

无需配置服务器：不需要实际配置或维护任何服务器或实例。您也不需要对容器进行编排。
系统和架构随使用情况自动扩展：随着请求、数据或事件的到来，底层平台和基础设施应自动进行扩展以满足所需的需求。
按价值付费：那些处于空闲状态、等待被使用的资源不应产生费用。只有在资源被实际使用时才会产生费用。
系统是为可用性和容错性而构建的：一旦您启动平台，它应该自动跨多个可用区扩展，从而提高您的可用性和容错性。

与那些在实际应用中使用过无服务器平台的人交谈时，他们通常会感觉从转向无服务器架构中获得了诸多好处。一个这样的好处是更高的灵活性和更快的行动能力，因为他们不再花费大量时间来设置和配置基础设施。将自己从实例和容器配置中解脱出来，能够更好地专注于他们的业务以及客户想要且认为有价值的功能。他们还觉得与以前数据中心的客户使用的容量相比，他们的规模增加了。这是因为 Lambda 会根据某个特定函数的调用次数自动扩展。

同步与异步调用

当您调用 Lambda 函数时，可以选择两种方式之一：同步或异步。

Lambda 将在同步调用中运行该函数，等待响应，然后返回响应代码以及函数返回调用中包含的任何数据。您可以使用 AWS CLI 中的invoke命令来同步调用函数。

使用异步调用时，您将事件推送到 Lambda，但不会等待即时响应。Lambda 会先将事件排队，然后再将其发送到函数：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.2_B17405.jpg

图 12.2 – Lambda 中的异步调用

Lambda 管理着函数的事件队列，并在收到错误时，会尝试重试事件。如果重试失败，它会再尝试两次，每次重试的间隔时间会更长。

现在我们初步了解了如何调用 Lambda 函数，让我们深入研究一下 Lambda 函数本身。

Lambda 函数

您编写的代码就是运行的函数，无需配置或管理任何服务器。该函数本身就是资源，可以接收传递给它的事件，无论是您自己还是其他 AWS 服务传递的事件。

您可以使用几种支持的语言来创建 Lambda 函数，包括 Python、Node.js、Ruby、Java、Go 和.NET。您甚至可以通过使用容器来创建自定义运行时。

Lambda 的基本概念

当你启动 Lambda 函数时，这个过程称为调用函数。Lambda 函数处理事件。事件可以通过几种不同方式发送到你的函数：你可以手动调用函数，如使用测试事件，或者可以配置 AWS 资源或服务来调用它并启动进程。

由于我们正在讨论 Lambda 函数，有几个关键概念需要理解。

函数

函数是你处理事件的代码。当你通过事件、计划任务或手动调用 Lambda 进程时，函数会被调用。

标识符

Lambda 函数可以有版本和别名。一旦版本创建，它就是代码的固定版本，并且末尾带有一个数字标识符。虽然 $LATEST 版本是你可以不断更新的 Lambda 代码版本，但如果你想调用某个快照版本，如 test-function:1，则需要在版本号后追加版本号。

运行时

Lambda 中的运行时允许你选择语言以及语言版本，以便执行你的函数。这个运行时并不包含在函数内部；它位于 Lambda 服务和函数代码之间。你不仅可以使用 Lambda 服务提供的运行时，还可以在服务本身不支持的语言和版本下构建自己的运行时。

事件

Lambda 中的事件是一个包含待处理数据的 JSON 文档。事件可以是简单的和单层的，如下例所示：

{
  "URL": https://packtpub.com
}

它们也可能是复杂的，来自 AWS 服务，并且包含需要复杂解析的嵌套键值对。这些复杂的事件可以包含有价值的数据，能够自动化流程并使你作为 DevOps 专业人员的工作变得更轻松，只要你学会如何利用它们的力量。

Lambda 处理器

处理器可以是任何名称，但默认名称，尤其是在 AWS 控制台中创建函数时，是 Lambda_function.Lambda_handler：

def Lambda_handler(event, context):
  greeting = 'I am a DevOps Pro and my name is {} {}'.format(event['firstname'], event['lastname'])
  print(message)
  return {
    'greeting': greeting
}

在我们示例的 Lambda 代码中，我们可以看到有两个参数被传递给 Lambda 处理器：event 和 context。

event 参数是一个 JSON 格式的文档，其中包含 Lambda 函数需要处理的数据。虽然它通常是一个字典对象，但也可以是列表、字符串、整数或浮动点数。

通过事件处理器和解析器的组合，你可以获取有关哪些特定资源调用了 Lambda 函数的信息，然后从那里执行必要的操作。通过使用 returns，例如之前简单示例中的问候语，你可以基于找到的信息调用函数内部的其他方法。你甚至可以让整个函数返回一个值。这在 Step Functions 中尤其有用，我们将在本章后面讨论这个。

context参数在运行时传递给 Lambda 函数。此参数包含有关调用、运行时环境和函数本身的信息。

Lambda 的限制

在创建 Lambda 函数时，了解 Lambda 服务的一些限制是很有帮助的。一个函数的最小内存为 128 MB，最大为 3,008 MB。Lambda 函数允许的最长执行时间为 15 分钟或 900 秒。环境变量最大只能有 4 KB。每个函数的并发执行限制为 1,000 次。如果你在提取数据或使用/tmp磁盘空间时，有 512 MB 的限制。

创建 Lambda 函数

了解 Lambda 函数的工作原理后，我们将开始创建我们的 Lambda 函数。我们将创建的函数会接收一个传入的 URL，并计算该网页上的单词数。由于我们需要外部包，因此我们首先需要创建一个 ZIP 包，然后将其上传到 Lambda 服务中。

有时，你可以直接在 AWS 管理控制台中使用 Lambda 服务内置的编辑器编写一个简单的函数。这包括 Python 语言及其boto和botocore模块，它们允许你利用 Python 的random来帮助生成随机数和随机值，OS允许你调用操作系统功能，math、gzip和logging模块，以及其他许多模块。

按照以下步骤构建我们的 Lambda 包，以便上传：

让我们首先打开终端并为我们的 Lambda 函数创建一个角色。终端打开后，我们将导航到目录的起始位置，然后为我们的 Lambda 创建一个新目录。创建后，进入该目录：
```
$ cd ~/
$ mkdir my-wc-function
$ cd my-wc-function
```

我们将使用以下 JSON，保存为名为Lambda-role-policy.json的文件；你也可以在本书的 GitHub 仓库中的Chapter-12文件夹里找到这个文件：

{
    "Version": "2012-10-17",
    "Statement": [
        { "Effect": "Allow",
          "Principal": {
              "Service": "Lambda.amazonaws.com"
}, 
          "Action": "sts:AssumeRole"
        }
    ]
}

使用此文件在以下命令中创建我们 Lambda 函数将使用的角色：

$ aws iam create-role --role-name Lambda-12 --assume-role-policy-document file://Lambda-role-policy.json

该命令应返回一个 JSON 格式的输出，显示角色创建成功，类似于以下输出：

{
    "Role": {
        "Path": "/",
        "RoleName": "Lambda-12",
        "RoleId": "AROAW24Q7QQF5NLSQX3L5",
        "Arn": "arn:aws:iam::470066103307:role/Lambda-12",
        "CreateDate": "2021-06-15T01:06:06+00:00",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "Lambda.amazonaws.com"
                    },
                    "Action": "sts:AssumeRole"
                }
            ]
        }
    }
}

我们的角色已经为 Lambda 创建好了；然而，由于目前没有附加任何策略，它不能做太多事情。我们不会编写自定义策略，而是使用 AWS 为 Lambda 创建的预定义策略：
```
$ aws iam attach-role-policy --role-name Lambda-12 --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
在我们的角色创建并准备好使用后，让我们删除当前目录中的文件，以防它被随后的zip包一起部署。如果你希望保存它，我建议使用copy或move命令将其转移到/tmp目录或Downloads，以便稍后访问：
```
$ rm Lambda-role-policy.json
```

现在，我们将创建一个新的文件，名为Lambda_function.py。在这个函数中，我们将剪切并粘贴（或者如果你敢的话，直接输入）以下代码。或者，你也可以在本书的 GitHub 仓库中的Chapter-12目录找到完整的文件：

import requests
from bs4 import BeautifulSoup
from collections import Counter 
from string import punctuation # already included in Lambda modules 
def Lambda_handler(event, context):
# get the URL from the event 
r = requests.get("https://aws.amazon.com/blogs/compute/using-Lambda-layers-to-simplify-your-development-process/") #demo 
  bs = BeautifulSoup(r.content)
# gather all the words within the paragraphs 
  p_txt = (''.join(s.findAll(text=True))for s in bs.findAll('p'))
  count_p = Counter((x.rstrip(punctuation).lower() for y in p_txt for x in y.split()))
# gather all the text in the divs 
  d_txt = (''.join(s.findAll(text=True))for s in soup.findAll('div'))
  count_div = Counter((x.rstrip(punctuation).lower() for y in d_txt for x in y.split()))
# create a sum total of the words 
  word_sum = p_txt + d_txt
# return the number of words 
  return word_sum

现在，你的my-wc-function目录结构应该是这样的：
```
my-wc-function$
| Lambda_function.py
```
此时，我们可以开始使用–target在本地安装我们的依赖模块：
```
:pip install --target ./package requests
pip install --target ./package bs4
```
现在，让我们来制作部署包。首先，我们将进入刚刚创建的package目录，然后创建初始的zip文件。注意zip命令中的两个点，它们是告诉zip文件要在当前目录中创建，而不是在package目录中：
```
$ cd package
$ zip -r ../my-wc-package.zip .
```
创建好我们的初始zip文件后，我们可以将 Python 文件添加到zip文件中：
```
$ cd ../
$ zip -g my-wc-package.zip Lambda_function.py
```
运行此命令后，你应该看到Lambda_function.py文件已经被添加到之前创建的zip包中。
现在，我们已经创建了部署包，准备继续使用 AWS 管理控制台上传并测试我们的函数。所有这些也可以从 CLI 继续，但控制台有一些 CLI 中没有的功能。
打开你的浏览器，登录管理账户后访问 Lambda 服务。你可以通过直接访问console.aws.amazon.com/Lambda来进入该服务。
找到并点击主屏幕右上方的橙色创建函数按钮。
一旦你进入my-word-count_python。
python 3.8。
我们之前创建的Lambda-12角色：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.3_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.3_B17405.jpg)

图 12.3 – 在 Lambda 创建函数屏幕上选择我们创建的现有角色

填写完所有值后，点击橙色的创建函数按钮。
一旦你创建了你的函数（这应该会将你带到该 Lambda 函数的主屏幕），我们需要上传我们创建的 ZIP 文件。因此，在你的本地系统中找到my-wc-package.zip。点击保存按钮将 ZIP 文件及其代码发送到 AWS Lambda：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.4_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.4_B17405.jpg)

图 12.4 – 将我们之前创建的.zip 文件上传到我们的 Lambda 函数
一旦你上传了 ZIP 文件，多个文件夹应该出现在Lambda_function.py文件的左侧。
为了查看我们新创建的函数的效果，我们需要创建一个测试事件。点击橙色的Test1，然后点击对话框底部的橙色创建按钮。
创建好测试事件后，我们可以运行测试。点击测试按钮旁边的箭头，出现时选择Test1选项。选中正确的测试事件后，我们可以再次点击橙色的测试按钮开始测试。

运行测试后，你应该能在执行结果页面看到我们演示 URL 中所有单词的计数。

本次练习带领我们从头创建和测试一个 Lambda 函数，该函数依赖于第三方库。接下来，我们将学习如何为我们的函数设置触发器和源映射，以便在特定事件发生时自动运行。

Lambda 触发器和事件源映射

Lambda 触发器特别适用于当一段数据上传到特定的 S3 桶时启动多个应用程序。AWS 在许多讲座和演示中提供了将图像上传到桶的示例。然后，这张图像会触发 Lambda 函数，该函数会调整图像大小，使其更加压缩，然后将其放入 GIF 文件夹中。很多时候，这个函数还会在 DynamoDB 表中为新调整大小的图像放置一个指针。这些调整大小的图像对最终用户来说更易于访问并且下载更快，这一切都在上传源图像后自动发生：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.5_B17405.jpg

图 12.5 – 上传图像到 S3 桶的流程，触发 Lambda 函数进行图像调整大小

我们可以通过桶触发器做的不仅仅是图像调整大小，尤其是在企业和 DevOps 环境中。记住，S3 可以作为源代码存储，因为它具有版本控制功能（如果已启用）。假设一个新文件已上传到某个特定文件夹，并具有特定的文件扩展名（例如*.py）。在这种情况下，这次上传可以触发我们的 CodePipeline 作业来构建一个新的容器，并将该容器通过我们设定的所有步骤，直到遇到任何手动审批步骤。

现在我们已经看过触发器如何调用 Lambda，让我们看看如何将流式数据推送到不同的队列服务，以便 Lambda 可以异步处理数据。

查看事件源映射

由于 Lambda 是一个自动可扩展的服务，它可以接收来自其他服务的某些信息并处理这些信息。这些信息可能会直接进入 Lambda 函数，也可能不会。这些中介服务，例如消息队列，接收数据流，然后触发 Lambda 函数。

Lambda 可以从事件源读取的服务

以下服务可以为 Lambda 服务提供事件源映射：

DynamoDB
Kinesis
亚马逊 MQ
亚马逊托管的 Apache Kafka 流媒体服务
亚马逊 SQS

现在我们已经了解了 Lambda 函数如何被不同的 AWS 服务甚至其他源调用，让我们学习如何通过版本来更新我们的函数。

使用 Lambda 部署版本

如果你有一个已知的 Lambda 函数的良好状态，你可以通过发布该函数的版本来冻结它，避免未来的更改。一旦发布，这个版本将被用户和服务独立调用并使用，不受未来版本更改或更新的影响，包括对 $Latest 函数进行的迭代。

当你发布一个 Lambda 函数的版本时，它包含以下信息：

函数代码以及与之相关的所有依赖项。
调用函数的 Lambda 运行时。
所有的函数设置，如内存、VPC 关联和 IAM 角色。
添加到函数中的任何环境变量。
一个唯一的 Amazon 资源名称（ARN），以便可以识别该函数的特定版本：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.6_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.6_B17405.jpg)

图 12.6 – Lambda 版本及其如何映射到别名

版本可以通过两种方式之一来引用：通过限定 ARN 或通过未限定 ARN。

一个限定的 ARN 会在函数 ARN 末尾有版本后缀：

arn:aws:Lambda:us-east-2:470066103307:function:my-word-count_python:5

一个未限定的 ARN 将不会在函数 ARN 末尾有后缀：

arn:aws:Lambda:us-east-2:470066103307:function:my-word-count_python

现在我们已经了解了 Lambda 函数的版本，接下来我们来看一下如何将别名与版本一起使用。

在 Lambda 中使用别名

别名允许你为 Lambda 部署的特定版本创建命名指针。如果你已经将 Lambda 函数的 ARN 传递给用户或其他应用程序，这尤其有用。

除非你处于测试环境中，否则你不会想要传递基础的 Lambda ARN，因为那会指向 $Latest 版本。这个 $Latest 版本会不断变化，并且在测试和部署新功能和修复时可能会出现错误和漏洞。相反，通过使用别名，你可以将用户指向一个特定的、稳定的函数版本，并且在发布、测试并准备好发布新版本时，可以无缝过渡到新版本。

使用 Lambda 层

Lambda 层是一个预先发布的代码依赖项和库的集合。如果你发现你（或你的团队）在多个函数中使用相同的代码片段，可以创建一个层，利用 Lambda 层的好处。首先，当其中一个依赖项发生变化时，你不再需要更新每个函数；而是只需要维护一个单一的层，所有函数都可以利用这个层，并且只需要维护一次：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.7_B17405.jpg

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.7_B17405.jpg)

图 12.7 – 带有和不带有层的 Lambda 函数

层是加速团队之间开发的好方法。共享功能，如日志记录、网络或甚至数据库连接，可以一次性编写并打包成层，然后从各个函数中调用。

将 Lambda 层添加到我们的函数中

我们已经有了一个来自上次练习的 Lambda 函数。现在，让我们通过添加一个不仅适用于这个特定函数，而是可以在我们的代码库和组织中多个函数间共享的层来扩展函数的功能。

我们已经完成了为 Lambda 函数添加层的过程。接下来，我们将学习如何使用原生 AWS 服务来监控我们的函数，以及哪些指标最有效。

监控 Lambda 函数

一旦你开发并部署了 Lambda 函数，你的工作并没有完成。为了确保其在运行时能够正确工作，应当监控特定的指标。幸运的是，Lambda 可以与多个其他 AWS 服务集成，帮助你不仅监控你的函数，还能在需要时排查它们。

如果你前往 AWS 控制台所在区域，并且你的 Lambda 函数已经部署，你会发现垂直菜单栏中有一个名为 Monitor 的菜单项，点击它可以进入监控功能：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.8_B17405.jpg

图 12.8 – 来自 Lambda 函数控制台的 Monitor 菜单项

一旦进入 Lambda 控制台的 Monitor 部分，你会立即看到一个预先构建的仪表盘，它允许你一目了然地查看 Lambda 函数的基本但重要的图形化指标。以下是呈现的指标：

调用次数
持续时间
错误计数和成功率
限制
异步传输失败
迭代器年龄
并发执行

仪表盘的默认时间范围为 3 小时；然而，也有从 1 小时到 1 周的预设迭代。你还可以选择自定义时间范围，查看仪表盘上的监控数据。

关于 AWS 管理控制台中 Monitoring 部分的另一个非常实用的功能是，它有一些按钮，可以让你直接跳转到函数的 CloudWatch 日志、使用 ServiceLens 查看函数的 X-Ray 跟踪，或者如果你启用了该附加功能，还可以通过 CloudWatch 查看 Lambda Insights。

使用 X-Ray 帮助排查你的函数

当你尝试排查应用程序问题，尤其是找出在应用程序执行过程中或其调用的其他服务中出现瓶颈的地方时，你可能需要比当前的指标和日志提供的更多信息。这时，AWS 服务可以变得特别有用。

X-Ray 会收集有关你应用程序请求的数据，然后提供详细信息，包括每个过程的逐步时间。每次调用函数时，Lambda 都会运行 X-Ray 守护进程。该 X-Ray 守护进程监听 UDP 端口 2000 的流量并收集分段数据。然后，这些分段数据会被传递到 X-Ray API 进行展示。

注意

我们将深入探讨 X-Ray 服务，以及它如何在第十四章《CloudWatch 与 X-Ray 在 DevOps 中的角色》中更详细地用于监控和观察 Lambda 函数。

现在我们已经了解了如何监控我们的 Lambda 函数，接下来我们将讨论 AWS Lambda 的最佳使用场景和反模式。

Lambda 的最佳使用场景和反模式

现在我们已经详细了解了 AWS Lambda 作为代码服务的功能，接下来让我们看看什么时候使用 Lambda 最为合适，以及 Lambda 在哪些情况下不是最佳选择。这些信息对 AWS 专业人士和追求 AWS DevOps 认证的人来说都至关重要。

AWS 的 Lambda 服务非常灵活、经济实惠，并与大量 AWS 服务进行交互。它还允许你使用你熟悉的多种语言编写代码，并将其作为你的运行时环境。

那么，让我们继续前进，看看在什么场景下 Lambda 最能发挥作用。

AWS Lambda 的最佳使用场景

随着越来越多的团队开始关注无服务器解决方案和模式，我们来看看使用 Lambda 服务在哪些地方是合理的。

你希望专注于代码，而不是底层的基础设施

如果你或你的团队希望专注于功能和代码库，而不是配置和修补服务器，无服务器 Lambda 函数是一个非常好的选择。你只需要专注于代码，选择运行时、内存大小、函数的最大运行时间以及一些其他选项，Lambda 服务会处理其余的工作。这包括按需扩展和管理底层硬件。

作为专注于代码的回报，你确实会放弃一些功能。你将无法登录到底层的计算实例，实际上这些实例是容器，无法查看进程或在日志生成时进行监视。相反，你需要添加日志语句或日志库，以便通过 CloudWatch 日志调试代码。

你需要一个具有成本效益的解决方案

成本优化是我们在第一章《Amazon Web Service 基础》提到的五大服务支柱之一。组织总是寻找如何让他们的解决方案更加具有成本效益，而使用 Lambda 通常是一个不错的选择。Lambda 服务没有空闲费用，因为费用是按使用量计算的。该服务还提供一个每月一百万次调用的永久免费层。

其中一个特别有用的场景是，如果你正在构建 DevOps 管道，在每次部署时将应用程序部署到主区域和次区域（或灾难恢复区域），而无需担心额外费用。在次区域进行的部署不会产生费用，因为除非主区域发生区域或服务故障，否则不会调用该区域。如果发生问题，你将比其他人领先一步，因为你无需搭建任何基础设施或资源。相反，你只需要重新指向正在调用哪个区域的 Lambda 函数。

Lambda 反模式

既然我们刚刚讨论了 Lambda 在平台中的最佳使用场景，接下来我们将看看 Lambda 不太适合的场景。

在应用程序开发完成后，你不想更新运行时环境

使用 AWS Lambda 服务时，支持特定数量的运行时。不过，这些语言和版本并不是一成不变的。由于某些语言版本因缺乏支持而被弃用，AWS 将不再支持这些运行时，也不允许部署使用这些运行时的新 Lambda 函数。

很多时候，解决方法可能只是将 Lambda 控制台中的运行时版本从旧版本切换到新支持的版本。如果存在依赖于旧版本运行时的包、库或模块，那么可能需要更新或替换这些内容。如果原始开发人员或承包商不再在场，这可能会成为一个问题。

你需要从你的函数中调用一个异步调用

当你需要调用外部服务，比如外部 API 来执行任务时，这是一个异步调用。Lambda 可以成功地实现这一点。然而，调用到初始服务的请求可能并不会立即返回响应。让函数等待服务的响应并不是最佳模式，因为 Lambda 服务的计费是基于资源消耗的。

现在我们已经了解了何时使用和不使用 Lambda 函数，接下来我们将学习如何使用 Step Functions 协调多个 Lambda 函数。

使用 Lambda 协调 Step Functions

有时你需要将多个 Lambda 函数协调在一起执行一个更大的任务。Step Functions 可以根据状态机接收到的输入做出决策，执行并行步骤，甚至与其他服务（如 SNS）连接，以请求人工输入。

Step Functions 还会创建一个可视化工作流，让你看到流程中的每个步骤。当 Step Functions 运行时，你可以看到状态机的成功或失败。

理解 Step Functions 中的状态机

状态机是 Step Function 的编排功能。它定义了步骤的执行顺序，以及从前一个状态接收到的任何数据，并将其传递给其他状态以供使用。

状态机命令始终以 JSON 格式编写。即使你已经使用 YAML 格式编写了 CloudFormation 模板，你仍然需要以 JSON 格式创建你的状态机及其各种状态。

以下是一个状态机的示例：

{
  "Comment": "A Sample State Machine",
  "StartAt": "StepOne",
  "States": {
    "StepOne": {
      "Type": "Pass",
      "Result": "Hello World!",
      "End": true
    }
  }
}

现在我们理解了什么是状态机以及它们如何与 Step Functions 区别开来，让我们看看 Step Functions 是如何工作的。

Step Functions 是如何工作的？

Step Functions 通过使用三步流程来工作：

定义你应用中的步骤。
验证任何状态变化。
运行你的应用并根据需要进行扩展。

注意

你知道吗，与 Lambda 函数不同，你不能从 S3 存储桶事件触发 Step Function？相反，你需要让存储桶事件调用一个单独的 Lambda 函数，然后再调用 Step Function。

现在我们已经了解了 Step Functions 的基本原理，接下来让我们更仔细地看看 Step Functions 中可用的不同状态。

Step Functions 中可用的状态

当你开始配置你的 Step Functions 状态时，你开始创建一个 状态机。你通过使用 Amazon 状态语言 来实现这一点，Amazon 状态语言是一种基于 JSON 的语言，用于定义状态机中的不同状态。有些状态可以执行操作，有些是过渡状态，还有一些在任务失败或成功时停止：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.9_B17405.jpg

图 12.9 – Step Functions 中可用的不同状态

让我们仔细看看这些状态及其执行的功能。

任务状态

当你创建一个由状态机执行的单个工作单元时，你正在创建一个 task 状态。task 状态是你可以调用 Lambda 函数的地方。

选择状态

choice 状态允许状态机根据逻辑评估在不同的分支之间进行选择。你提供一组选择规则，这些规则评估输入或输出变量。根据这些值是否为真，状态机的下一步将被定义。

虽然默认选择不是必需的，但建议这样做，以防没有任何选择与逻辑匹配。否则，你的状态机会停止并报错。

并行状态

顾名思义，parallel 状态可用于创建状态机的多个分支，这些分支同时执行。对于那些彼此独立的任务，这可以显著加快执行时间。

失败状态

一个fail状态会停止你的状态机的执行，但可以选择在字段中输入Cause（原因）、Error（错误）或两者。这些字段在调试较大和更复杂的状态机时尤其有用，与其在代码中硬编码错误代码，不如传递一些系统信息。

Succeed 状态

Succeed状态是一个终止状态，没有下一个字段。

等待状态

如果你需要在步进函数中添加暂停，可以添加一个wait状态。wait状态可以通过暂停的秒数或恢复的时间戳来定义。

创建步进函数

理解步进函数的最佳方式之一是创建一个，然后观察它的执行过程。我们已经创建了一个S3存储桶，用于存储已被步进函数调用的 Lambda 函数。如果你完成了初始的 Lambda 函数练习，你应该已经拥有以 ZIP 格式保存的 Lambda 函数，准备上传到这个新的存储桶。模板文件可以在本书的 GitHub 仓库中找到，在Chapter-12文件夹中，名为step_function.yml：

在运行模板之前，我们需要上传my-wc-package.zip文件。这可以是我们至今一直使用的S3存储桶。我们将通过命令行使用 S3 复制命令来完成此操作。确保你在包含 ZIP 文件的相同目录中，或者已将 ZIP 文件移动到当前工作目录：
```
$aws s3 cp my-wc-package.zip s3://devopspro-beyond/
```
打开终端并转到你从Chapter-12文件夹下载 CloudFormation 模板的目录。使用以下 CLI 命令从step_function.yml模板创建步进函数。我们需要知道我们上传文件的存储桶，以便将其作为参数传递。我们还将把我们的堆栈命名为stepTest：
```
$aws cloudformation create-stack --stack-name stepTest --template-body file://step_function.yml --parameters ParameterKey=LambdaFunctionBucket,ParameterValue=devopspro-beyond --capabilities CAPABILITY_IAM
```
设置好步进函数和 Lambda 函数后，我们将使用管理员用户登录到 AWS 管理控制台。登录后，导航到步进函数服务。
一旦进入步进函数服务页面，你应该能看到一个名为第十二章的状态机。点击该状态机的名称，进入它：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.10_B17405.jpg

图 12.10 – 创建的第十二章状态机
现在，在第十二章状态机中，点击开始执行按钮。这将打开一个对话框，你可以在其中命名执行。只需保持默认值不变，并点击对话框底部的橙色开始执行按钮。
一旦你开始执行，你应该能够看到状态机的映射和步骤的流动。你可以点击任何单个步骤来查看输入和输出值：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_12.11_B17405.jpg

图 12.11 – 由 AWS 生成的状态机图形视图

通过这一章的学习，你不仅了解了创建 Step Function 的过程，还将之前创建的 Lambda 函数融入到了我们的状态机中。现在，让我们快速回顾一下这一章的内容。

总结

在这一章中，我们了解了 Lambda 服务及其在无服务器架构中的应用。我们考察了 Lambda 函数的不同组件，从事件到运行时环境。我们查看了 Lambda 可以被调用的不同方式，甚至可以从头开始构建一个函数。之后，我们了解了如何使用 Step Functions 来编排多个 Lambda 函数。

在下一章中，我们将深入探讨蓝绿部署及其变体。我们还将讨论它们在 DevOps 过程中扮演的重要角色，因为这可以在不同的测试问题中以多种方式提出。

问题

你团队中的一位开发人员创建了一个由 S3 桶事件触发的 Lambda 函数。该函数应该在对象放入桶中时被调用。然而，函数并没有正常工作。这个问题需要进行调试和修复。开发人员如何简单快速地完成这一任务？

a. 使用 Lambda 监控控制台帮助调试问题。

b. 使用 AWS CloudTrail 日志。

c. 打开 AWS 支持案例，注明 Lambda 函数的 ARN 和 S3 桶的名称。

d. 使用 AWS CloudWatch Logs。
你被要求帮助构建一个使用 AWS Lambda 的无服务器应用程序。这个应用程序需要进行监控，但公司不希望引入任何第三方服务进行监控。虽然记录和跟踪调用其他函数的功能可能会比较棘手，但 AWS 有哪些服务可以帮助你完成这项任务？（选择 3 项）

a. AWS CloudTrail

b. AWS CloudWatch

c. AWS Inspector

d. AWS X-Ray
你被引入一家公司，帮助他们处理无服务器架构。公司目前有一个架构，包含多个 Lambda 函数，这些函数互相调用，并充当状态机。公司使用了过时的编码模式来协调状态机，并发现当代码出错时修复起来很困难。你可以建议他们使用什么服务来帮助重构他们的应用并管理状态机？

a. AWS Data Pipeline

b. AWS Step Functions

c. AWS Cognito

d. AWS Beanstalk

答案

d
a, b, d
c

第十三章：蓝绿部署

通过在两个相同的环境之间切换流量来发布应用，更广为人知的就是使用蓝绿部署。了解如何通过不同的 AWS 服务进行蓝绿部署，可以帮助减少发布新版本应用时的风险。掌握各种服务的技术并理解每种服务的使用，对于通过 AWS DevOps 专业认证考试至关重要。

在本章中，我们将涵盖以下主要内容：

理解蓝绿部署的概念
你可以在蓝绿部署中使用的 AWS 服务
蓝绿部署在 AWS 中的优势
更新自动扩展组启动配置
在数据层中使用蓝绿部署的最佳实践

理解蓝绿部署的概念

当你使用蓝绿部署技术时，你在降低停机时间和风险方面采取了一个有效的措施。你通过运行一个复制环境，其中一个环境承担活跃流量，另一个环境接收更改。一旦更改完成并进行测试后，之前指向初始环境（蓝色环境）的流量可以切换到绿色环境。这个切换可以一次性完成，也可以分阶段进行，这取决于你的部署计划和所使用的服务。如果部署出现问题，你可以快速将流量重新引导回已知的稳定环境，即蓝色环境，同时修复新的环境。

蓝绿部署的基础是两个独立的环境。一个环境，即蓝色环境，指的是当前应用或工作负载运行的环境。第二个环境，即绿色环境，是一个复制的环境，你可以在其中部署更新的应用代码或工作负载更改。使用这两个独立环境的协作可以实现接近零停机时间的发布和回滚能力。

执行蓝绿部署时，你正在使用不可变的基础设施。这意味着你不会在现有基础设施上进行升级或更新，而是为每个部署过程创建一套新的资源。

部署过程不容易

传统的部署方式倾向于就地升级。然而，使用就地升级时，需要考虑许多风险因素：

资源限制
潜在的停机时间
来自其他系统的依赖
回滚不成功部署的困难

由于部署过程中的成本和复杂性，团队有时会选择部署到现有基础设施。这是一种可行的部署策略，但它存在固有的风险，特别是在执行像一次性全量部署这样的操作时，所有实例或应用程序都会同时更新。如果在部署过程中出现问题或故障，这通常会导致停机、收入损失、品牌信任度丧失和客户信心下降，具体情况取决于停机时间的长短。

问题

在开始规划部署时，尝试问自己，哪些解决方案能够减少停机时间、处理依赖关系，并且能以更高效的方式协调工作负载？

在执行部署时，有多个风险需要规避，包括以下几点：

应用程序故障
基础设施故障

使用蓝绿部署策略有助于减轻这些风险和业务影响，因为它可以实现几乎无缝的从一个环境切换到另一个环境。

在谈论部署，尤其是蓝绿部署时，环境这个术语经常被使用。理解“环境”定义对于理解哪些资源会发生变化至关重要。知道什么被定义为环境，在处理 AWS DevOps 专业考试的一些问题时也非常重要。

环境是一个事物变化的边界，也是需要部署事物的地方。这可以是你应用程序的一个组件，也可以是应用程序的一个完整层级，例如 Web 层。

可用于蓝绿部署的 AWS 服务

AWS 提供了许多原生工具，可以让你执行蓝绿部署。这些工具提供了多种部署选项，从使用像 CloudFormation 这样的服务全面控制环境的各个方面，到对 Route 53 或 Auto Scaling 等服务进行细粒度的更改。这些更细粒度的选项只允许你对应用程序的特定部分进行修改，但在实施蓝绿部署时，它们同样有效。

让我们来看一下 AWS 提供的不同服务，它们可以帮助我们进行蓝绿部署。

AWS CloudFormation

使用 AWS CloudFormation，你可以利用该服务的模板功能，既可以描述你正在部署的 AWS 资源，又可以快速创建包含所需更新的环境副本。所有这些都可以通过 CloudFormation 支持的两种语言之一：JSON 或 YAML 来完成。

模板可以是更广泛基础设施中的小组件。通过 CloudFormation 模板，您可以创建一组相关的项目，例如自动扩展组，然后使用该组的输出更新先前创建的模板，该模板包含负载均衡器，并更新其指向的位置，或者使用新创建的自动扩展组手动进行切换。

AWS Elastic Beanstalk

Elastic Beanstalk 是一项服务，帮助开发者集中精力于代码，而由它管理底层基础设施。这包括如 ELB、EC2 实例、带有 EBS 卷的 EC2 实例存储、弹性 IP、自动扩展组、安全组，甚至通过 CloudWatch 指标进行监控等内容。

在 Elastic Beanstalk 中执行蓝绿部署时，您可以轻松克隆环境。这些克隆可以是当前应用程序代码库的精确副本，或者如果自上次部署以来您推送了功能和更改，它们甚至可以是代码的最新版本。Elastic Beanstalk 使使用该服务的用户可以轻松地通过“交换环境 URL”功能从一个环境切换到另一个环境。此功能会在后台进行 DNS 切换，并将流量从先前的（蓝色）环境重定向到新的（绿色）环境。

AWS CodeDeploy

AWS CodeDeploy 是一项托管部署服务，帮助自动化将您的软件部署到本地服务器、EC2 实例、AWS Lambda 函数和 AWS Fargate 容器。当使用 AWS CodeDeploy 创建部署时，您可以选择就地部署或蓝绿部署。

使用蓝绿部署选项，您可以在环境配置中设置 CodeDeploy 自动复制您的 EC2 自动扩展组，或手动配置实例进行蓝绿部署。还可以启用负载均衡选项。此外，还可以选择在部署完成后自动重定向流量，或者允许在部署到新实例或自动扩展组后手动重定向流量。

甚至可以使用 CodeDeploy 服务将 CloudFormation 模板集成在一起，以执行蓝绿 ECS 部署。

AWS ELB

AWS ELB（ELB）是一项计算服务，允许您将流量路由并分发到多个实例、IP 地址、Lambda 函数、容器，甚至虚拟容器。由于 ELB 是一项托管服务，它还可以执行健康检查，以确定哪些实例健康，哪些实例需要停止接收流量：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.1_B17405.jpg

图 13.1 – 应用程序负载均衡器使用目标组同时将流量部署到两个版本的应用程序

使用应用负载均衡器的目标组，你可以通过金丝雀部署（蓝绿部署的一种变体）将应用的新版本推送到部分用户。通过使用多个与同一应用负载均衡器连接的目标组，你可以确定将多少流量引导到应用程序的每个版本。

Amazon ECS

亚马逊 ECS (ECS) 使用任务使 Docker 容器的分组在 AWS EC2 实例上更易于运行、停止和管理。通过 ECS，你可以使用服务调度程序安排容器何时被放置在实例上。ECS 还允许你在同一区域但不同的可用区内，将运行相同任务的多个容器分布在多个 ECS 兼容实例上：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.2_B17405.jpg

图 13.2 – 使用 ALB 在 ECS 中从目标组 1 切换到目标组 2

容器的使用使得部署，特别是蓝绿部署，更加简便。容器不像完整的实例那么复杂，多个容器可以在同一个 EC2 实例中运行，即使它们运行的是不同版本的应用程序。

Amazon 弹性 Kubernetes 服务

亚马逊 弹性 Kubernetes 服务 (EKS) 允许你在 AWS 云和本地环境中运行和扩展 Kubernetes 应用程序。它通过提供安全的集群来帮助管理集群，并允许集群具有高可用性。

EKS 可以在专用的 EC2 实例上运行，也可以在 AWS Fargate 上运行，后者为容器提供按需计算能力。使用 Fargate 无需为实例进行配置，选择服务器类型或管理虚拟机。

你可以借助 AWS Fargate 上的 EKS 和 CodeDeploy 服务的蓝绿部署功能来执行蓝绿部署。当你为 EKS 创建新的蓝绿部署时，指定一个前端 Kubernetes 任务的应用负载均衡器名称，CodeDeploy 服务会处理新绿色服务的部署，然后逐步淘汰旧的蓝色任务。

AWS OpsWorks

AWS OpsWorks 是一项配置管理服务，允许你根据 Chef 或 Puppet 框架来配置堆栈。

使用 OpsWorks，蓝绿部署变得更简单，只需克隆整个堆栈。

Amazon CloudWatch

Amazon CloudWatch 是一项指标和监控服务，允许用户跟踪和观察已部署的资源。CloudWatch 服务还具有设置警报并通过其他服务（如 Amazon SNS 或 Amazon SES）发送通知的能力。

当在蓝绿环境中的资源上设置了指标时，你就可以在开始将流量导向新环境时评估该环境。保持关注你在 CloudWatch 中设置的指标，并确保所有服务在切换到新环境时保持稳定状态，这有助于缓解切换到新环境时的焦虑。

亚马逊 Route 53

亚马逊 Route 53 是一种 DNS 服务，可以在蓝绿部署中使用，通过将 DNS 记录指向新的绿色环境。这使得 DevOps 专业人员和网络管理员可以通过更新 DNS 记录快速且轻松地重定向流量。Route 53 还包括高级功能，例如调整资源记录的 生存时间（TTL），以及使用加权策略等先进技术，使得流量可以逐步转移到新环境，而不是一次性全部重定向。

现在我们已经了解了可以用来实现蓝绿部署的不同服务，让我们来看一下使用蓝绿部署的好处。

使用 AWS 的蓝绿部署的好处

使用蓝绿部署策略相比于原地部署提供了多重好处。需要注意的是，尽管这些好处相当显著，但在蓝绿过程中新创建的附加环境会带来额外的成本。验证完部署后，副环境可以被拆除，或者如果部署失败，回滚完成后副环境也可以被移除。

在 AWS 中执行蓝绿部署的技术

在 AWS 中实现蓝绿部署可以通过多种方式进行。已经出现了一些经过验证的模式，用于成功实现这些部署。在我们查看每种技术时，将重点介绍所使用的具体服务。不同的应用程序倾向于采用不同的模式。

使用 Route 53 更新 DNS 路由

Route 53 服务允许你在启动新环境后使用托管区域。将额外的记录添加到记录集中，然后就可以为终端用户创建无缝过渡到新的应用程序部署：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.3_B17405.jpg

图 13.3 – 显示使用 Route 53 托管区域的蓝绿部署

这种切换可以一次性完成，将所有流量强制导向新的绿色环境。你也可以使用加权记录将一部分流量发送到绿色环境，最初作为金丝雀测试。这些金丝雀用户将生成日志和指标，可以在一段时间内进行评估。如果在新环境中没有报告错误，那么你可以改变策略的权重，使得 100%的流量现在都被引导到绿色环境。

这种技术不仅限于在相同的可用区集或甚至相同的区域内创建新的绿色环境。您可以在完全不同的区域创建新的绿色环境。如果您计划在环境中切换区域，请确保已考虑到您的数据层以及在区域切换期间可能受到的影响。

这也不限于实例或服务在负载均衡器后监听请求的情况。使用 Route 53 的 DNS 路由切换可以应用于以下所有场景：

由 ELB 管理的 EC2 实例组或集群
由 ELB 管理的 Auto Scaling 组中的实例
具有公共地址或弹性 IP 地址的单个实例
在指定环境中的 Elastic Beanstalk Web 应用程序
在 ECS 或 EKS 中运行的服务

部署过程 – DNS 路由

使用 Route 53 切换托管区实现蓝/绿部署的过程详见以下内容：

开始时将所有流量的 100%引导到蓝色环境，使用当前版本的应用程序部署。
部署应用程序的新版本到绿色环境。
测试绿色堆栈部署是否成功，可以通过运行一系列手动或脚本化的测试来进行验证。
更新 Route 53 托管区中的加权记录，将一部分流量引导到新的绿色环境。
监控新环境以检测错误或失败。
更新 Route 53 托管区中的加权记录，将剩余流量转移到绿色环境。
如果部署出现问题，请更新 Route 53 记录，将所有流量重新导向蓝色环境。

现在我们已经看到如何使用 DNS 和 Route 53 进行蓝/绿部署，接下来让我们看看如何在不改变 DNS 设置的情况下进行蓝/绿部署。

在 ELB 后面交换自动缩放组

在我们的第二个蓝/绿部署选项中，我们将排除 DNS 选项。在许多组织中，负责应用部署的团队与处理包括由 Route 53 服务托管的 DNS 记录在内的网络配置的团队并不相同。因此，我们需要为这些情况做好准备：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.4_B17405.jpg

图 13.4 – 通过交换自动缩放组部署蓝/绿环境

一旦启动了新的自动缩放组，您需要在注册新的自动缩放组（即绿色自动缩放组）到 ELB 之前，在新的绿色堆栈上执行一系列测试。

重要说明

我们将进行创建和部署自动缩放启动模板的实际操作练习，详见第十八章，自动缩放和生命周期挂钩。

这里需要注意的一个重要事项是，ELB 仅在注册和注销方面参与部署过程。在部署软件的新版本时，你并没有部署一个新的负载均衡器。

部署过程 – 替换自动伸缩组

通过替换自动伸缩组来执行蓝绿部署的过程如下：

在开始之前，确保你的 ELB 实例不属于你的部署环境。
开始时，ELB 实例指向蓝色自动伸缩组。
部署新的绿色自动伸缩组。
测试绿色自动伸缩组。
将绿色自动伸缩组注册到 ELB 实例。
从 ELB 实例中注销蓝色自动伸缩组。

现在我们已经了解了如何通过替换自动伸缩组来执行蓝绿部署，接下来我们将探讨另一种也使用自动伸缩组的蓝绿部署技术。

更新自动伸缩组的启动配置

每个自动伸缩组都与一个启动配置相关联。启动配置包含在伸缩事件发生时启动新实例所需的信息。

创建一个新的启动模板（或启动配置）。这个新的启动配置包含更新的 AMI、更新的用户数据，或者两者：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.5_B17405.jpg

图 13.5 – 通过替换启动配置部署蓝绿环境

部署过程 – 更新自动伸缩组启动配置

通过更新自动伸缩组启动配置来执行蓝绿部署的过程如下：

确保你的 ELB 实例不参与部署过程。
从将流量导向当前使用蓝色启动配置的自动伸缩组开始。
创建一个新的启动配置（绿色启动配置），并将其附加到自动伸缩组。
将自动伸缩组扩展为其原始大小的两倍。
一旦绿色自动伸缩组的实例启动并变得健康，将自动伸缩组缩减回原始大小。

更新 ECS

将你的应用程序打包到容器中可以让部署变得更容易。

使用目标组，可以让你在单个负载均衡器后运行多个服务。一个可以是蓝色服务，另一个可以是绿色服务。

执行蓝绿部署的关键环节之一是应用程序负载均衡器。ECS 任务是在应用程序负载均衡器上注册的：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.6_B17405.jpg

图 13.6 – 使用 ECS 服务更新进行蓝绿部署

在使用这种方法时，你需要考虑以下事项：

你的代码需要是完全无状态的。
不支持金丝雀部署。
在任务切换期间，长期运行的连接将被突然终止。

部署过程——更新 ECS

通过更新 ECS 进行蓝绿部署的过程如下：

从一个定义了任务定义并指向应用负载均衡器的蓝色服务开始。
接下来，创建一个新的任务定义，该任务定义基于新创建的容器中的新应用版本；这个版本就是你的绿色版本。
使用绿色任务定义扩展绿色服务，并将该绿色服务映射到应用负载均衡器。
通过将任务数设置为零来缩减蓝色服务的规模。

现在我们已经了解了如何使用容器和 ECS 执行蓝绿部署，让我们看看如何使用 Elastic Beanstalk 服务在蓝绿部署中快速交换应用版本。

交换 Elastic Beanstalk 应用程序的环境

如果你打算使用蓝绿部署策略与 Elastic Beanstalk 配合使用，则必须确保你的应用环境与数据库分离：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.7_B17405.jpg

图 13.7 – 通过交换 Elastic Beanstalk 应用程序进行蓝绿部署

部署过程——交换 Elastic Beanstalk 环境

执行交换 Elastic Beanstalk 环境以进行蓝绿部署的过程如下：

打开 AWS 管理控制台，进入 Elastic Beanstalk 服务，确保你处于正确的区域来管理你的 Beanstalk 应用。
克隆你的环境。你可以在不对当前平台做任何更改的情况下进行克隆，或者选择Clone with latest platform来使用平台 Git 分支的最新版本。这个新平台将成为你的绿色环境。
如果你仅克隆了环境，你将需要将应用的新版本部署到绿色环境。
你现在可以使用绿色环境 ELB 所赋予的唯一 DNS 名称测试新环境。
在环境概览页面，选择Environment Actions | Swap URLs。
来自 Route 53 的流量现在将被定向到绿色环境。

我们已经看到如何使用 Elastic Beanstalk 服务的 Swap URLs 功能轻松进行蓝绿部署。接下来，让我们看看如何通过克隆 OpsWorks 堆栈在 OpsWorks 服务中执行蓝绿部署。

克隆 OpsWorks 堆栈并更新 DNS 记录

当你在 AWS OpsWorks 中创建应用时，你需要首先创建一个堆栈。一个 OpsWorks 堆栈由一个或多个层组成。堆栈创建后，可以轻松克隆为其精确副本，从而创建一个全新的环境。在这个新环境中，你可以更新你的配方并部署应用的新版本。你甚至可以在 ELB 上使用本地 DNS 名称，在将任何流量路由到新堆栈之前测试应用的新版本。

将托管应用程序的 OpsWorks 堆栈与 Route 53 服务结合使用，指向你的 CNAME 流量，你可以在部署新版本应用程序时，快速轻松地在堆栈之间切换。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.8_B17405.jpg

图 13.8 – 克隆 OpsWorks 堆栈

部署过程——克隆 OpsWorks 堆栈

通过克隆 OpsWorks 堆栈来进行蓝绿部署的过程如下：

从你当前的堆栈开始，这是你的蓝色堆栈，包含当前版本的应用程序。
接下来，通过克隆堆栈创建新的堆栈，这就是你的绿色环境。你可以通过在控制台中点击克隆链接或使用 CLI 来完成此操作。
将新版本的应用程序部署到绿色环境的应用程序层。此时，应该没有任何流量被指向绿色环境。
如果需要，预热你的 ELB，以便它能处理你的客户基础的流量。
当你准备将绿色堆栈提升为用于生产的堆栈时，更新 DNS 记录，指向通过 Route 53 的 ELB。这可以一次性完成，也可以逐步进行。
当你对部署感到满意时，你可以停用蓝色堆栈。

现在我们已经讨论了使用各种 AWS 服务进行的不同蓝绿部署技术，接下来我们将讨论数据层。

在蓝绿部署中使用最佳实践来管理数据层

部署新版本应用程序时可能出现的一个更重要的风险是对数据库进行更改。尤其是在执行蓝绿部署时，这一点尤为重要，因为蓝绿部署的核心目的是减轻风险，并能够快速回滚。

如果你使用的是 Amazon RDS，建议在开始部署之前创建数据库快照，特别是如果你将执行任何数据库更改。这将允许你在数据部署没有按计划进行时从快照中恢复，并尽可能减少停机时间。

将模式更改与代码更改分开

在进行部署时，将任何数据库更改（例如模式更改）与应用程序部署分开是至关重要的。你执行某些数据库更新的顺序可能取决于你正在执行的模式更改类型。

通常，当需要进行模式更改时，你可以采取两种方法，而何时使用其中一种方法取决于模式更改是否向后兼容，并且能否与当前版本的应用程序一起工作：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/aws-cert-dop-engi/img/Figure_13.9_B17405.jpg

图 13.9 – 在蓝绿部署期间进行数据库模式更改的过程

第二种方法是在进行部署后进行模式更改竞争。这种方法最适合那些与当前应用版本不兼容的更改，如果在部署之前进行，将导致当前版本应用的错误。

有时你需要执行两个独立的模式更改。这种情况发生在你既有一组非破坏性更改，也有一组破坏性更改。通过将更改分为两个独立的部署，你对数据库进行了较小的增量更改，因此通过将步骤分解为较小、易于管理的部分，从而减少了风险。

总结

在本章中，我们讨论了蓝绿部署，它们是什么，以及如何成功地进行蓝绿部署。我们还谈到了在 AWS 中可以用来成功执行蓝绿部署的服务，以及使用每项服务执行部署的过程。最后，我们探讨了在实施部署时如何处理数据更新，重点讲解了哪些模式更改应该首先进行。

在下一章中，我们将开始关注环境和工作负载的监控与日志记录。这从了解 CloudWatch 和 X-Ray 服务在 DevOps 中的角色开始。

复习题

一家公司聘请你帮助他们在 AWS 上设计应用架构。该公司要求有一个可以自动扩展的硬化 AMI，作为应用的一部分。该应用同时监听 HTTP 和 TCP 端口，因此你决定使用可以处理这两种协议的经典负载均衡器。还有一个虚拟 CNAME，托管在 Route 53 上。蓝绿部署必须是此架构的一部分。你可以在 Route 53 中使用哪种路由策略来实现蓝绿部署？

a. 多选

b. 延迟

c. 加权

d. 简单
你正在执行蓝绿部署，更新 Elastic Beanstalk 中的应用环境。创建了一个与现有的蓝色环境相同的绿色环境，并将新版本的应用程序部署到绿色环境后，接下来应该做什么来切换到新的绿色环境？

a. 更新 DNS 记录，指向绿色环境。

b. 使用 Amazon Route 53 将流量重定向到新的绿色环境。

c. 替换当前指向环境负载均衡器的自动扩展启动配置。

d. 选择交换环境 URL 选项。
一家公司聘请了你，因为他们需要帮助在 AWS 上实施蓝绿部署流程。在新环境部署后，他们希望能够逐步将流量从蓝色环境切换到新的绿色环境。应用程序已经部署在 EC2 实例上，这些实例位于一个自动扩展组中，背后有应用程序负载均衡器。Route 53 正在将消费者流量路由到负载均衡器。最后，应用程序的数据层由 PostgreSQL RDS 多可用区数据库实例组成。

哪三个步骤可以成功实现蓝绿部署过程？

a. 创建一个新的应用程序负载均衡器和一个新的自动扩展组。

b. 在当前负载均衡器后创建一个新的自动扩展组。

c. 在 Route 53 中创建一个新的别名记录，指向绿色环境，并为两个记录设置故障转移策略。

d. 在 Route 53 中创建一个新的别名记录，指向绿色环境，并在两个记录之间使用加权路由。

e. 在你的新自动扩展组中，设置 EC2 实例使用相同的 RDS 实例。

f. 在你的新自动扩展组中，设置 EC2 实例使用 RDS 的故障转移节点。