第一种，AWS CodeDeploy为Auto Scaling组创建了副本，启用新的Amazon EC2实例，将应用程序部署到这些新实例，然后重定向用户流量重定到新部署的代码。
第二种，可使用实例标签或Auto Scaling组来选择用于绿色环境的实例。AWS CodeDeploy会将代码部署到标记的实例上。

那么，如何设置你的第一个蓝色环境？最佳做法，当然是采用AWS CodeDeploy的in-place部署方式。当然也可以从已有的空白Auto Scaling组开始。

蓝绿部署的示例

我们来看一下如何使用Auto Scaling组来实现蓝绿部署。

概述

下图中，示例环境包括一组Amazon EC2实例，可作为AWS CodeDeploy的工作站。服务发布管理员或开发人员可以使用此工作站部署新版本的代码。蓝色环境包含一个Auto Scaling组，其中另有两个实例用作Web服务器。 Web服务器，最初将包含应用程序的第一个版本和AWS CodeDeploy客户端。负载均衡器以轮转的方式，将流量引导到两个Web服务器。

服务发布管理员使用工作站实例，将新版本的应用程序推送到AWS CodeDeploy，并启动蓝绿部署。 AWS CodeDeploy会创建Auto Scaling组的副本，启动两个新的Web服务器实例，并安装新版本的应用程序，然后将负载均衡器重定向到新实例。原实例仍然是原Auto Scaling组的一部分。如果需要，均可重新关联到负载均衡器中。

构建该示例的先决条件

以下是需要的准备工作。

具有使用Amazon EC2，Amazon S3，Amazon VPC，AWS CodeDeploy和AWS CloudFormation权限的IAM用户。
选定构建示例环境的AWS区域和可用区域。
Amazon EC2密钥对。
熟悉上述服务和AWS管理控制台，如何连接到Amazon EC2实例。

其他注意事项

本示例中，您将会为使用到的基础AWS服务付费，本例中提供的资源仅为培训目的。在实施与本博文中描述的类似技术时，请务必考虑相关的安全需求。

步骤1：创建初始环境

1. 下载包含示例模板的存档，并将其保存在相应的目录。https://github.com/awslabs/codedeploy-blue-green/

2. 登录到AWS管理控制台并打开AWS CloudFormation控制台，网址为 https://console.aws.amazon.com/cloudformation/

3. 如果这是一个新的AWS CloudFormation帐户，请单击创建新堆栈 。否则，单击创建堆栈 。

4. 在将模板上传到Amazon S3选项中，单击Choose File，从您下载的存档中选择YAML文件，然后单击下一步。

5. 在指定详细信息的堆栈名称中，输入bluegreen 。

6. 在AZName中，选择一个可用区域。（在这篇博文中，使用us-east-1a）

7. 在BlueGreenKeyPairName中，选择要使用的密钥对。

8. 在NamePrefix中，使用bluegreen的默认值，除非已经运行了以bluegreen开头的名称的应用bluegreen 。NamePrefix用于为创建的资源分配名称标签。单击下一步 。

9. 在选项页面上，单击下一步 。

10. 选择确认框以允许创建IAM资源，然后单击创建。CloudFormation将需要大约10分钟来创建示例环境。除了创建图中所示的基础设施之外，CloudFormation模板还设置了一个AWS CodeDeploy应用程序和蓝绿部署组。

步骤2：查看初始环境

1. 看看CloudFormation的堆栈输出。应该会看到以下类似内容。 WorkstationIP是工作站实例的IP地址。 AutoScalingGroup和LoadBalancer是由CloudFormation为Auto Scaling组和弹性负载均衡器创建的DNS名称。

2. 将LoadBalancer值复制到浏览器中并浏览到该链接，将会显示以下应用程序。这是一个PHP应用程序，用来查询Amazon EC2实例的元数据。如果刷新页面，则会根据轮转的负载均衡算法，看到IP地址和实例ID的变化。

3. 回到EC2控制台，查看实例。将看到与此示例相关联的三个运行中的实例：工作站和Auto Scaling组创建的两个Web服务器实例。这些Web服务器实例构成蓝色环境。

步骤3：部署新版本的代码

1. 通过WorkStationIP中显示的地址，连接到工作站实例。这个实例正在运行Ubuntu操作系统，用户名是ubuntu 。登录后，将看到两个目录：scripts目录包含Bourne shell脚本；newversion目录包含对PHP应用程序的更新。

2. 以下是newversion/content/index.php中新版本的PHP代码。与最初安装代码的唯一区别是应用程序版本号。

3. 现在看下面的scripts/pushnewversion.sh的shell脚本。使用aws deploy push命令，将代码打包，上传到Amazon S3。

4. 运行pushnewversion.sh脚本，将看到一条消息，告诉您如何使用AWS命令行解释器来部署代码，不过这里我们将使用AWS CodeDeploy控制台来部署。

5. 打开AWS CodeDeploy控制台 https://console.aws.amazon.com/codedeploy/

6. 点击bluegreen-app的链接。如果选择了NamePrefix的默认名称，请改为单击该名称，展开Revisions，将看到刚从工作站实例推送的修订版本，单击Deploy revision 。

7. 在Create Deployment页面上，选择bluegreen-app应用程序和bluegreen-dg部署组。保留所有其他默认值，然后单击Deploy。AWS CodeDeploy将配置Auto Scaling组和实例，部署代码，设置运行状况检查以及将流量重定向到新实例。这个过程需要几分钟。部署完成后，如下图所示。由于部署组中的设置，AWS CodeDeploy会跳过终止原始实例这一步。

步骤4：查看更新的环境

1. 在浏览器上打开负载均衡器的DNS地址。应该看到新版本的应用程序，如下图所示。应用程序版本从1变为2，如预期。

2. 回到EC2控制台并查看实例。将看到已被Auto Scaling组标记的四个实例。 IP地址为10.200.11.11和10.200.11.192的实例是我们在蓝色环境中看到的。部署过程创建了现在属于绿色环境的IP地址为10.200.11.13和10.200.22的实例。

3. 转到Auto Scaling组控制台。将看到现在有两个Auto Scaling组，每个组有两个实例。名称以CodeDeploy开头的Auto Scaling组是在部署过程中创建的。

4. 使用AWS CodeDeploy已经成功完成了蓝绿部署。

步骤5：清理

1. 重新登录到到AWS CodeDeploy工作站实例。

2. 运行scripts/cleanup.sh脚本。将会删除部署包并关闭Auto Scaling组。

3. 转到CloudFormation控制台，选择之前创建的堆栈，然后将其删除。

结论

AWS CodeDeploy帮助开发人员将代码部署自动化到Amazon EC2和本地实例。其蓝绿部署选项帮助服务发布管理员，创建新的生产环境，并在问题出现时非常便捷地回滚到之前的环境。有关AWS CodeDeploy的更多信息，请参阅AWS CodeDeploy文档。现在，您只需点击几次即可开始使用。

在蓝绿的世界中享受生活！

黄帅，AWS中国专业服务的咨询顾问，主要为企业客户提供云架构设计、迁移技术指导和DevOps落地实践。加入AWS之前，有多年企业产品SaaS转型的研发和运维经历，以及丰富的DevOps实战经验。

使用 Amazon EC2 Run Command 在不使用 SSH 访问的情况下大规模地管理实例

以下博文的投稿者为 Ananth Vaidyanathan (EC2 Systems Manager 高级产品经理) 和 Rich Urmston (Pegasystems 公司云架构高级总监)，介绍了如何使用 EC2 Run Command 在不使用 SSH 的情况下管理大量 EC2 实例。

-Jeff

企业通常具有若干托管环境和成千上万的 Amazon EC2 实例。安全地管理系统非常重要，同时也要避免棘手的安全外壳 (SSH)。Run Command 是 Amazon EC2 Systems Manager 的一部分，可以让您以可控制和可审查的方式对实例 (或使用标签的实例组) 运行远程命令。这有效地提升了每天都要依赖 Run Command 服务的 Pega 云操作的效率。

您可以通过标准 IAM 角色和策略控制 Run Command 访问，定义文档以获取输入参数，控制用于返回命令输出的 S3 存储桶。您还可以与其他 AWS 账户共享文档或将文档公开。总而言之，Run Command 提供了一组很有用的远程管理功能。

优于 SSH

Run Command 优于 SSH 且 Pegasystems 已将其作为主要远程管理工具的原因如下：

Run Command 所需时间较短 – 安全地连接到一个实例需要几个步骤，例如要连接的跳转盒或要列入白名单的 IP 地址等。使用 Run Command，云操作工程师可以直接从笔记本电脑调用命令，而不必找到密钥甚至实例 ID。相反，系统安全性依赖于 AWS 身份验证、IAM 角色和策略。

Run Command 操作完全经过审查 – 使用 SSH，无法真正控制他们的操作，也没有审查跟踪。使用 Run Command，每个调用的操作都会在 CloudTrail 中进行审查，包括调用用户的信息、运行命令的实例、参数和操作状态。您拥有完全控制权，能够限制工程师可以在系统上执行的功能。

Run Command 无需管理 SSH 密钥 – Run Command 利用标准 AWS 凭证、API 密钥和 IAM 策略。通过与企业身份验证系统的集成，工程师可以根据其企业凭证和身份与系统进行交互。

Run Command 可以同时管理多个系统 – 使用 SSH 完成某些简单任务会很麻烦，如查看 Linux 服务的状态或在托管实例队列中检索日志文件。Run Command 允许您通过 ID 或标签指定实例列表，并在指定队列中并行调用命令。除非是最小的 Pega 群集，否则这会在进行故障排查或管理时提供巨大的优势。

Run Command 使自动化复杂任务更容易 – 实现操作任务标准化需要详细的程序文档或描述准确命令的脚本。在整个队列中管理或部署这些脚本会很麻烦。Run Command 文档提供了一种封装复杂功能并处理文档管理和访问控制的简单方式。当与 AWS Lambda 结合使用时，文档提供了强大的自动化平台来处理任何复杂任务。

示例 – 重新启动 Docker 容器

下面是一个用于重新启动 Docker 容器的简单文档示例。它包含一个参数，即要重新启动的 Docker 容器的名称。它使用 AWS-RunShellScript 方法调用命令。该服务自动收集输出并将输出返回调用方。有关最新文档架构的示例，请参阅创建 Systems Manager 文档。

{
  "schemaVersion":"1.2",
  "description":"Restart the specified docker container.",
  "parameters":{
    "param":{
      "type":"String",
      "description":"(Required) name of the container to restart.",
      "maxChars":1024
    }
  },
  "runtimeConfig":{
    "aws:runShellScript":{
      "properties":[
        {
          "id":"0.aws:runShellScript",
          "runCommand":[
            "docker restart {{param}}"
          ]
        }
      ]
    }
  }
}

在 Pegasystems 上实际应用 Run Command

Pegasystems 配置系统位于AWS CloudFormation上，后者用于部署和更新 Pega 云资源。在此之上是 Pega Provisioning Engine，这是一个无服务器的基于 Lambda 的服务，它管理着 CloudFormation 模板和 Ansible 操作手册库。配置管理数据库 (CMDB) 跟踪每个部署和更新的所有配置详细信息和历史记录，并使用分层目录命名约定布置其数据。下图显示了不同系统的集成方式：

对于云系统管理，Pega 操作使用名为 cuttysh 的命令行版本和基于 Pega 7 平台的图形版本，名为 Pega Operations Portal。这两种工具都允许您浏览部署环境的 CMDB，查看配置设置，并通过 Run Command 与部署的 EC2 实例进行交互。

CLI 演示

下面是一个 CLI 演示，用于查看客户部署并使用 Run Command 与实例交互。启动 cuttysh 工具可以显示 CMDB 的根目录和配置客户的列表：

% cuttysh
d CUSTA
d CUSTB
d CUSTC
d CUSTD

您可以使用标准 Linux shell 命令 (例如 cd、 ls、 cat 和 grep) 与 CMDB 进行交互。带有 s 前缀的项目表示可查看其属性的服务。带有 d 前缀的项目表示 CMDB 层次结构中可导航的子目录。在此示例中，将目录更改为 CMDB 层次结构的客户 CUSTB 部分，然后再将其更改为名为 env1 的配置 Pega 环境，位于 Dev 网络下。此工具显示了为该环境配置的项目。这些条目映射到配置的 CloudFormation 模板。

> cd CUSTB
/ROOT/CUSTB/us-east-1 > cd DEV/env1

ls –l 命令显示配置资源的版本。这些版本号映射到源代码控制 – CloudFormation、Ansible 和构成 Pega 云版本的其他组件的托管项目。

/ROOT/CUSTB/us-east-1/DEV/env1 > ls -l
s 1.2.5 RDSDatabase 
s 1.2.5 PegaAppTier 
s 7.2.1 Pega7

现在，使用 Run Command 与部署的环境进行交互。要执行此操作，可使用 attach 命令并指定要进行交互的服务。在以下示例中，可挂载到 Pega Web Tier。使用 CMDB 和实例标签中的信息，CLI 可以找到相应的 EC2 实例，并显示有关它们的一些基本信息。此部署有三个实例。

/ROOT/CUSTB/us-east-1/DEV/env1 > attach PegaWebTier
 # ID         State  Public Ip    Private Ip  Launch Time
 0 i-0cf0e84 running 52.63.216.42 10.96.15.70 2017-01-16 
 1 i-0043c1d running 53.47.191.22 10.96.15.43 2017-01-16 
 2 i-09b879e running 55.93.118.27 10.96.15.19 2017-01-16

在这里，您可以使用 run 命令调用 Run Command 文档。在以下示例中，您可以对实例 0 (列表中的第一个实例) 运行 docker-ps 文档。EC2 执行命令并将输出返回到 CLI，CLI 将显示输出。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-ps
. . 
CONTAINER ID IMAGE             CREATED      STATUS        NAMES
2f187cc38c1  pega-7.2         10 weeks ago  Up 8 weeks    pega-web

使用相同的命令和已定义的其他文档，您可以重新启动 Docker 容器，甚至将文件的内容撤回到本地系统。当您获得文件时，Run Command 还会在 S3 存储桶中留下一个副本，以备您希望将链接传递给同事。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-restart pega-web
..
pega-web

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 get-file /var/log/cfn-init-cmd.log
. . . . . 
get-file

Data has been copied locally to: /tmp/get-file/i-0563c9e/data
Data is also available in S3 at: s3://my-bucket/CUSTB/cuttysh/get-file/data

现在，利用 Run Command 可一次完成多个操作。在以下示例中，您挂载到具有三个正在运行的实例的部署，并希望查看每个实例的正常运行时间。将 par (并行) 选项与 run配合使用，CLI 将指示 Run Command 对所有实例并行执行正常运行时间文档。

/ROOT/CUSTB/us-east-1/DEV/env1 > run par uptime
 …
Output for: i-006bdc991385c33
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.42, 0.32, 0.30

Output for: i-09390dbff062618
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.08, 0.19, 0.22

Output for: i-08367d0114c94f1
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.36, 0.40, 0.40

Commands are complete.
/ROOT/PEGACLOUD/CUSTB/us-east-1/PROD/prod1 >

总结

Run Command 通过提供更快的系统访问和跨一组实例运行操作，可以提高工作效率。Pega 云操作将 Run Command 与其他操作工具集成，为管理系统提供了一种简单安全的方法。这大大提高了操作效率，并更好地控制了每个主体在托管部署可以执行的操作。Pega 持续改进过程会定期评估操作者需要访问权限的原因，并将这些操作转换为新的 Run Command 文档以添加到库中。事实上，它们的长期目标是停止在启用 SSH 时部署云系统。如果您有任何问题或建议，请给我们留言！

-Ananth 和 Rich

AWS Marketplace 中的 Box 平台 – Lambda 蓝图和示例代码

Box 是一个基于云的文件共享和内容管理系统，具有一个最近已在 AWS Marketplace 中提供的 API (Box 平台 – 云内容管理 API)。凭借一系列协作相关功能的推出，以及对安全性的重视，Box 已经在许多企业中得到了广泛应用 (请参见其成功案例页面中的列表)。

Box API 允许开发人员将内容体验构建到 Web 和移动应用程序中。今天我想向您介绍一些 [lambda] 蓝图和模板，这些蓝图和模板将可以帮助您在构建 AWS 应用程序时使用此 API 来简化用户身份验证和将元数据添加到新上传的内容中。这些模板基于 Box 节点 Lambda 示例而创建，可作为您开发工作的一个强大起点。我们来看一看这些蓝图，顺便查看一些我们在 Box 的好友所撰写的博客文章。

适用于 Lambda 的 Box 蓝图

蓝图显示了您如何通过 [apigateway] 调用 Box API 和将 Box webhook 连接到 Lambda 函数。要找到它们，请直接打开 Lambda 控制台，搜索 box：

第一个蓝图使用存储在 BOX_CONFIG 环境变量中的安全凭证。您可以从 Lambda 控制台内设置此变量：

此蓝图中的代码会检索并记录通过凭证确定的用户的 Box User 对象。第二个蓝图会实施一个 Box webhook，置于 API Gateway 终端节点后面。它会接受请求，验证它们，然后将它们记录到Amazon CloudWatch中：

查看方便的博客文章

Box 的开发人员关系团队撰写了一些博客文章，向您展示如何将 Box 与多项 AWS 服务结合使用：结合使用 Amazon Cognito 和 Box 平台来管理用户身份验证 – 这篇文章向您展示了如何使用Amazon Cognito来为您的应用程序用户的登录页面提供支持。Cognito 将会处理身份验证和用户池管理，博客文章中所列出的代码会在用户首次登录时在 Box 中创建一个应用程序用户。该代码在 GitHub 上作为 box-node-cognito-lambdas-sample 提供。

利用 Amazon Rekognition 将基于深度学习的图像识别功能添加到您的 Box 应用程序中 – 这篇文章向您展示如何构建由Amazon Rekognition提供支持的图像标记应用程序。对于用户拍摄并上传的照片，应用程序会使用存储在Amazon Dynamodb中的元数据自动标记这些照片。文件上传时，代码会通过一个 webhook 激活。您可以在 GitHub 上的 box-node-rekognition-webhook 中找到代码。感谢我们在 Box 的好友抽出时间来创建了这些非常有用的开发人员资源。

-Jeff

全新推出 – Auto Scaling for Amazon DynamoDB

Amazon DynamoDB 拥有十万多的客户，客户身处各种行业，使用案例也各不相同。这些客户依赖于 DynamoDB 在任何规模下都能提供的一致性能和覆盖全球 16 个地理区域的服务网络。最近我们注意到一个趋势，客户正在使用 DynamoDB 来为他们的无服务器应用程序提供支持。这是一个很好的搭配：使用 DynamoDB，您无需考虑配置服务器、执行操作系统和数据库软件修补或跨可用区配置复制以确保高可用性之类的事情 – 您只需创建一些表，然后开始添加数据，其他的交给 DynamoDB 处理。

DynamoDB 提供预置容量模式，可以让您设定您的应用程序所需的读取和写入容量。尽管这让您无需考虑服务器，在 AWS管理控制台中进行简单的 API 调用或按钮单击就可以对表的配置进行更改，但客户已经在询问我们，有没有方法让管理 DynamoDB 容量变得更加轻松。

现在，我们推出了 Auto Scaling for DynamoDB，可帮助您实现表和全局二级索引容量管理的自动化。您只要指定所需的目标使用率，并提供读取和写入容量的上限和下限。之后，DynamoDB 将利用 Amazon Cloudwatch 警报来监控吞吐量占用情况，并根据需要上调或下调预置容量。Auto Scaling 对于所有新表和索引默认启用，您还可以对现有表和索引配置此功能。即使您不在左右，DynamoDB Auto Scaling 也将监控您的表和索引，并根据应用程序流量的变化自动调整吞吐量。这使您可以更加轻松地管理 DynamoDB 数据，帮助您最大程度地提高应用程序的可用性，并帮助您降低 DynamoDB 成本。我们来看看它是如何工作的……

使用 Auto Scaling

现在当您创建新表时，DynamoDB 控制台会提出一组适宜的默认参数。您可以原样接受它们，也可以取消选中“Use default settings”，然后输入您自己的参数：

以下是您输入自己的参数的方式：

目标使用率以占用容量与预置容量的比值来表示。以上参数将允许提供足够的空间，使占用容量能够在读取或写入请求突增时倍增 (请参阅容量单位计算，了解更多有关 DynamoDB 读取和写入操作与预置容量之间关系的信息)。预置容量的变化是在后台发生的。

Auto Scaling 的实际操作

为了了解这项重要的新功能的实际操作，我按照入门指南中的指示进行了操作。我启动了一个全新的 EC2 实例，安装了 (sudo pip install boto3) 并配置了 (aws configure) 适用于 Python 的 AWS 开发工具包。然后我使用 Python 和 DynamoDB 一节中的代码创建了一个表，为其填充了一些数据，并手动为该表分别配置了 5 个读取和写入容量单位。我稍作休息，以便 CloudWatch 指标形成简洁的直线，这样我就可以展示 Auto Scaling 的效果了。这是我开始应用负载之前指标的样子：

在步骤3中，我修改了代码，以便继续在 1920 年至 2007 年之间随机选择年份执行查询，运行一份代码，并在一两分钟后查看了读取指标：

占用的容量高于预置的容量，导致出现了大量的受限制读取。现在就是 Auto Scaling 发挥作用的时间了！我返回控制台，单击了我的表中的 Capacity 选项卡。然后我单击 Read capacity，接受默认值，并单击 Save：

DynamoDB 创建了一个新的 IAM 角色 (DynamoDBAutoscaleRole) 和一对 CloudWatch 警报来管理读取容量的 Auto Scaling：

DynamoDB Auto Scaling 将会管理警报的阈值，在扩展过程中上下移动这些阈值。第一个警报被触发，表状态更改为 Updating，同时预置了额外的读取容量：

几分钟内，读取指标中就会显示这一更改：

我启动了我修改后的查询脚本的其他几个副本，并观察额外容量的预置情况，如红线所示：

我删除了所有的脚本，然后去做其他的事情，同时等待缩减警报触发。以下是我返回时所看到的：

第二天，我检查了我的 Scaling activities，看到警报在一夜间已经触发了多次：

这在指标中也有显示：

到现在为止，对于这种情况，您需要根据预期使用情况合理设置您的读取容量，还要准备着为超额容量 (蓝线和红线之间的空间) 付款。否则，您可能将它设置得太低，忘了进行监控，而在流量攀升时容量耗尽。使用 Auto Scaling，您就可以做到两全其美：当需求增加，表明需要更多容量时自动响应，当容量不再需要时，再一次自动响应。

须知事项

DynamoDB Auto Scaling 可用于处理以大致可预测、通常为周期性的方式变化的请求速率。如果您需要处理不可预测的读取活动突增，则应将 Auto Scaling 与 DAX 结合使用 (请参阅 Amazon DynamoDB Accelerator (DAX) – 读取操作密集型工作负载的内存缓存以了解更多信息)。另外，AWS SDK 会检测受限制的读取和写入请求，并在适当的延迟之后重新尝试这些请求。

我之前提到了 DynamoDBAutoscaleRole。该角色为 Auto Scaling 提供它要扩展和收缩表和索引所需的权限。要了解更多有关这一角色及其使用权限的信息，请参阅Using the AWS Management Console With DynamoDB Auto Scaling。

Auto Scaling 拥有完整的 CLI 和 API 支持，包括启用和禁用 Auto Scaling 策略的能力。如果您的流量存在一些可预测的时限性峰值，则您可以通过编程的方式禁用 Auto Scaling 策略，在设定的时间段内预置更高的吞吐量，并在之后重新启用 Auto Scaling。

如 DynamoDB 中的限制页面中所述，您可以按您所需的频率，根据您的需求增加预置容量 (受限于可以申请增加的每帐户限制)。对于每个表或全局二级索引，您每天最多可将容量减少九次。您将按照正常的 DynamoDB 定价为您预置的容量付费。您还可以通过购买 DynamoDB 预留容量进一步节省费用。

现已推出 此功能现已在所有区域推出，您可以立即开始使用。

-Jeff

Amazon S3新版管理控制台的正确打开方式

Amazon Simple Storage Service（简称S3）是AWS在2006年发布的第一款云服务产品，S3作为对象存储具有海量存储、接口灵活、11个9持久性、价格便宜等特点，特别适合存放静态文件如图片、视频、日志以及备份文件等等，同时S3是AWS大数据解决方案中重要组成部分，以EMRFS的形式与EMR（AWS托管的Hadoop平台）结合提供计算与存储分离的灵活架构。

熟悉S3控制台的小伙伴一定发现，自从5月份开始，控制台的界面焕然一新，甚至有点无处下手，但熟悉起来后又有些爱不释手，下面我们将介绍下新版控制台带来了哪些新的功能，以及如何给你的工作带来极大效率提升。

新版控制台的操作说明，图文并茂，详见：

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/what-is-s3.html

一、创建存储桶

创建存储桶的时候除了配置桶名、存储桶区域之外，还可以配置版本控制、日志、标签以及访问权限，现在用户可以在新版控制台使用“从现有存储桶复制设置”的功能，选择相同配置的存储桶即可，避免重复设置。

二、上传对象

在控制台下除了正常的通过点击上传按钮选择上传文件完成上传外，新版控制台支持在存储桶界面下，直接将待上传的对象拖放到页面上。通过新版控制台上传单个文件支持最大78GB。

对存储桶中对象的上传、删除、重命名等操作，页面底部可以看到该操作的进度及其他操作的历史记录。

三、ACL

我们可以通过配置存储桶及对象的ACL来实现存储桶和对象的访问控制，老版控制台的部分名称容易让人引起歧义，以存储桶ACL为例，如下图所示，其中查看权限是指查看该存储桶权限的权限，即查看该存储桶ACL的权限，而不是指查看存储桶的权限，编辑权限同样是指编辑权限的权限，不是编辑存储桶的权限。

在新版控制台中很好的避免了这点误区，分对象访问和权限访问，这里以存储桶的ACL举例，见下图：

其中一个新功能是我们可以在管理用户处添加其他帐号ID或Email向该帐号授权访问，只要对方帐号的IAM user/role拥有对S3的访问权限即可同样以预配置的权限访问该存储桶中的资源，实现跨帐号访问。

四、标签Tag

S3标签是随S3新版控制台一起发布的一个服务特性。标签可以帮助你对存储桶以及对象进行分类或标记，类似我们给EC2等资源添加标签一样，每个S3标签也是一个键值对，每个对象最多可添加10个标签键值对，键值对大小写敏感。通过使用标签，我们可以创建基于标签的IAM policy以实现细粒度的权限控制，比如标签为PHI的值为true时，仅供只读。同时，在使用S3数据生命周期管理、分析、指标等功能的时候，可以创建基于标签的过滤器，实现细粒度的资源管理。

S3 标签作为新服务特性，相应的API也同步发布，比如PUT Object tagging, GET Object tagging, DELETE Object tagging以及其他支持标签的API如PUT Object, GET Object, POST Object, PUT Object-Copy，详细可参考：

http://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/object-tagging.html 需要注意的是，标签遵循最终一致性模型。

五、生命周期管理

数据通常从创建后会经历频繁访问、低频访问、极少访问的数据热度周期，相对于热数据，冷数据适合以成本更低的方式存储，比如热数据存放在S3 standard，冷数据存放在S3-IA，归档数据存放在Glacier等，以达到成本最优的目标。我们可以使用S3数据生命周期管理通过配置相应的规则来实现数据的生命周期管理，随着S3标签的发布，现在我们可以创建基于前缀和/或基于标签的规则，以实现更细粒度的资源管理。详细操作步骤见：

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/create-lifecycle.html

六、存储类分析

存储类分析是新发布的功能，通过该工具，我们可以更加直观的了解到存储桶中的数据活跃情况，帮助我们决策何时将不常访问的数据从S3 Standard转换为S3-IA，即为配置数据生命周期管理提供数据支持。

同时，可以创建筛选条件，选择对整个桶中对象或者具有某些前缀或标签的对象进行分析，即对对象进行分类分析，需要注意的是，分析是从启用该功能后一段时间后才能看到结果（通常是24~48小时），并不是可以立刻可以看到分析结果。

通过存储类分析，我们可以可视化的了解到存储桶数据在过去30天的检索量，占比，以及多个时间范围段内数据存储与检索的情况，该数据每天更新，并且可以以csv的格式导出到S3存储桶以供下载，可使用Quicksight等BI工具进行展现。

csv中字段说明见：

http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/analytics-storage-class.html#analytics-storage-class-export-to-file

配置存储类分析详细操作步骤见：

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-analytics-storage-class.html

七、存储指标

CloudWatch可以监控S3存储桶的使用情况，过去只有两个指标：存储桶大小和对象数量，随着新版控制台的发布，又有两类指标发布，即请求指标和数据传输指标。

请求指标（收费功能）中包含GetRequest, PutRequest, ListRequest, AllRequest, PostRequest, DeleteRequest, HeadRequest, 4xxErrors, 5xxErrors。数据传输指标（收费功能）包含TotalRequestLatency，FirstByteLatency，BytesDownloaded,BytesUploaded。这些指标均为1分钟报告1次，我们可以通过这些指标快速了解和定位S3使用过程中的一些问题，比如当前S3存储桶是否遇到性能瓶颈，是否需要提case提升限制等等。同样可以通过配置基于前缀/标签的过滤器实现细粒度的管理。

S3请求速率及性能注意事项参见：

http://docs.amazonaws.cn/AmazonS3/latest/dev/request-rate-perf-considerations.html

指标详细解释可以见：

http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/cloudwatch-monitoring.html#s3-request-cloudwatch-metrics

配置请求指标操作步骤见：

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-metrics.html

八、存储清单

S3存储清单是S3 提供的一项存储管理工具，S3存储清单可以每天或每周输出指定S3存储桶或存储桶中指定前缀的对象及其相关元数据信息的列表，并以CSV文件的格式存储在指定的S3存储桶中。存储清单遵循最终一致性模型，即列表中可能没有最近添加或删除的对象信息，如果需要确认某一个对象的状态，我们可以使用HEAD Object REST API（或命令行，SDK）来获取该对象的元数据。

对于存储桶中有海量文件的用户而言，存储清单可以方便的帮助用户了解当前存储桶中的文件列表而不是像过去那样需要频繁调用GET Bucket API（每次返回最多1000个对象），从而加速一些业务工作流及大数据作业等等。

配置存储清单时，我们可以指定清单筛选条件、生成频率、存储位置、清单中包含的字段等等，一个存储桶可以配置多个清单。

配置存储清单操作步骤见：

http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-inventory.html

看完上面S3新版控制台的介绍，是不是对这个新工具又有了一些新的认识，不妨将这些新功能用起来，优化成本，提升工作效率，在AWS上面诞生更多的创新应用。

作者介绍

王世帅，AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内教育、医疗行业的应用和推广。在加入AWS之前曾在国航担任系统工程师，负责存储方案的架构设计，在企业私有云方面有丰富经验。

利用Kong及AWS Lambda构建无服务器的后端逻辑

Kong是一个开源的API GW及微服务管理层，基于Nginx, Cassandra或者PostgreSQL构建，最初由Mashape开发，用于为其API Marketplace管理超过15,000个API和微服务，并于2015年开源。Kong具有如下优点：

可扩展性：通过简单地添加更多的机器，Kong可以轻松地水平缩放，这意味着您的平台可以处理几乎任何负载，同时保持低延迟。
模块化：可以通过添加新的插件来扩展，并通过RESTful Admin API轻松配置所有插件。
平台无关性：Kong可以运行在任何地方，包括本地数据中心及公有云，支持物理机，虚机及容器部署。

目前Kong的最新版本为0.10.2，支持的插件如下：

认证：Basic Authentication, Key Authentication, OAuth2.0 Authentication, OAuth 2.0 Introspection, HMAC Authentication, JWT, LDAP Authentication
安全：ACL, CORS, Dynamic SSL, IP Restriction, Bot Detection
流控：Rate Limiting, Response Rate Limiting, Request Size Limiting
无服务器架构：AWS Lambda, OpenWhisk
分析监控：Galileo, Datadog, Runscope
内容转换：Request Transformer, Response Transformer, Correlation ID
日志：TCP/UDP/HTTP Logging, File Logging, Syslog, StatsD, Loggly

通过AWS Lambda插件，Kong可以作为一个统一的API前端，接收用户的请求，并调用不同的lambda函数做相关的处理，最后将结果返回给客户端，目前Lambda插件支持如下region：

us-east-1, us-east-2, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, eu-central-1, eu-west-1

Kong的安装

Kong支持多种安装方式，对于在AWS上运行Kong的情况，主要有三种：

通过marketplace安装，此安装方式会在一台EC2上同时安装Kong及其存储数据库Cassandra，适合单机部署或者测试环境
通过CloudFormation安装，CloudFormation安装方式目前支持如下region，可以通过配置选择存储数据库的类型Cassandra还是PostgreSQL，或者不由CloudFormation创建存储数据库
通过yum在EC2上安装

本文主要讲解第三种方式的安装过程，安装Kong 0.10.1版本

第一步配置Kong的数据存储

Kong支持两种datastore：Cassandra和PgSQL，方便起见，这里利用AWS RDS创建PgSQL作为数据存储

注意事项：

RDS的安全组需要放行5432端口
记录RDS创建过程中设置的用户名，密码及数据库名

比如：username/password：ivan/ivan

DB：kong

第二步安装配置Kong (Amazon Linux)

yum update –y

wget https://github.com/Mashape/kong/releases/download/0.10.1/kong-0.10.1.aws.rpm

yum install kong-0.10.1.aws.rpm –nogpgcheck

cp /etc/kong/kong.conf.default /etc/kong/kong.conf

vim /etc/kong/kong.conf，

修改配置如下

database = postgres

pg_host = postgre-kong.XXXXXXXX.rds.cn-north-1.amazonaws.com.cn

pg_port = 5432

pg_user = ivan

pg_password = ivan

pg_database = kong

简单测试

第三步创建AMI，利用ELB，Autoscaling Group构建高可用架构

注意，如果EC2上已经启动过kong，那么会将生成的id也打包进入AMI，导致基于AMI生成的多台机器的id相同，从而无法建立集群，创建AMI前需要删除id

rm –f /usr/local/kong/serf/serf.id

参考：

https://github.com/Mashape/kong/issues/1751

检查集群状态

第四步创建Lambda函数并且测试

第五步配置Kong API GW并调用Lambda

5.1.配置API

测试

5.2.配置Lambda插件

测试

第六步配置启用额外的插件

6.1为API开启key认证

配置用户并绑定key

测试

6.2为API限速

6.3基于IP地址的过滤

作者介绍

余骏，AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广。在加入AWS之前，他在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。

利用Amazon Elasticache寻找附近的X

基于地理信息的应用已经越来越深入到日常生活中，人们经常会在应用中寻找附近的朋友，车，餐厅或其它资源。而与此同时，随着物理网技术及设备的普及，应用需要更加实时和精确的处理来自各种数据源（包括用户手机，各种传感器设备及其他系统）的大量数据，以完成相关的搜索和计算距离等操作。

架构

对于开发者来说，Redis因为其性能上的优势往往会被采用作为位置数据的缓存，只是在3.2版本之前需要代码中把位置数据进行Geohash后才能有效的排序和分析。不过3.2版本后，Redis已经能够原生支持基于位置信息的存储，计算及搜索了。Amazon ElastiCache是AWS提供的托管型的数据缓存服务，借助该服务，用户能够在云中轻松部署、运行和扩展分布式内存数据存储或缓存。 Amazon ElastiCache 的Redis引擎是一项与 Redis 兼容的内存服务，兼具 Redis 的易用性和强大功能，同时还可为要求最苛刻的应用程序提供适用的可用性、可靠性和性能，提供单节点和多达 15 个分片的群集，从而可将内存数据扩展到高达 3.55TiB。这里，我们可以基于Elasticache并结合AWS其他服务构建出以下的示例架构：

1）终端设备获取GPS位置信息，定时或基于事件将数据上传到云端。在AWS上可以选择使用IoT或Kinesis等托管型服务作为数据收集的接收端，也可以使用部署在EC2／Lambda上的自定义服务。

2）所有位置信息写入可以自动扩展的DynamoDB，基本Schema包含设备Id/Timestamp/Geo location, 方便历史查询或轨迹查询。

3）打开DynamoDB流，用KCL或Lambda监听DynamoDB的数据改变，并将当前变化的位置数据更新到Elasticache中建立基于Geospatial的索引缓存。

4）手机应用搜索附近资源时，部署在EC2/Lambda的查询服务利用Elasticache geospatial直接获取结果。

实现

如前文所述，步骤1和2可选择的方案很多，比如采用AWS IoT服务甚至可以无需任何代码仅通过配置即可完成云端的功能讲数据实时写入相应的DynamoDB表中。因此，本文将着重介绍如何实现前文架构中的3和4步：

a) 打开DynamoDB 流，获取流的ARN用于读取，如下图：

读取DynamoDB流数据有三种方式：利用Kinesis adapter，利用低级别API以及利用Lambda函数来进行读取。从易用性的角度来说，当然是Lambda函数最简单，不需要考虑shard，吞吐和checkpoint等问题而专注于业务逻辑。但是Lambda函数并不是在所有的AWS区域都支持，因此本文采用第一种方式利用Kinesis adapter完成读取。具体参考文档：http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.html

b) 在读取流的同时，我们需要将最新的地理位置信息利用GEOADD更新到Elasticache中。前文提到Redis在3.2版本后，Geospatial Indexing已经被原生支持，而它实际上是Sorted List数据结构的一种扩展，即排序 key扩展成了经纬度，如下图所示的数据结构，并且可以方便的使用基于地理信息的API，例如GEOADD——添加地理位置。

通过Elasticache可以快速构建出一个Redis环境，包括支持shard的集群模式，如下图所示。

构建完成后，通过Elasticache提供的终端节点就可以访问cache了。

需要注意的是如果选择的Redis是集群模式，那么就得同步升级支持Redis集群模式的客户端SDK用以开发。因为Redis的集群提供的是分片功能，它会把不同的slots分布在不同的节点上，需要由客户端通过CRC16(Key)取模从而计算出数据在哪个节点上。目前可以支持redis集群模式的客户端有很多，比如本文用到的java的jedis以及nodejs的ioredis。

综合a，b两步的示例代码的StreamCacheProcessor.java如下(其余代码参考http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.Walkthrough.CompleteProgram.html )：


import java.nio.charset.Charset;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import redis.clients.jedis.GeoCoordinate
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;

import com.amazonaws.services.dynamodbv2.streamsadapter.model.RecordAdapter;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessor;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorCheckpointer;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.ShutdownReason;
import com.amazonaws.services.kinesis.model.Record;

public class StreamsCacheProcessor implements IRecordProcessor {

        private static Log LOG = LogFactory.getLog(StreamsCacheProcessor.class);

  private Integer checkpointCounter;

  private String clusterHost;
  private int port;
  private JedisCluster jedis;

public StreamsCacheProcessor(String clusterHost,int port) {
      this.clusterHost=clusterHost;
      this.port=port;
}

@Override
public void initialize(String shardId) {
      Set jedisClusterNode=new HashSet();
      jedisClusterNode.add(new HostAndPort(clusterHost,port));
      jedis=new JedisCluster(jedisClusterNode);
 checkp ointCounter = 0;
}
@Override
public void processRecords(List records, IRecordProcessorCheckpointer checkpointer) {
 for (Record record : records) {
  String data = new String(record.getData().array(), Charset.forName("UTF-8"));
  LOG.debug("Received the data as:"+data);
  if(record instanceof RecordAdapter)
     com.amazonaws.services.dynamodbv2.model.Record streamRecord = ((RecordAdapter) record).getInternalObject();
    //新增GPS数据更新到Elasticache中
    if(streamRecord.getEventName().equals("INSERT")){
    Map coordinateMap = new HashMap();
    double longitude = Double.parseDouble(streamRecord.getDynamodb().getNewImage().get("longitude").getN());
    double latitude = Double.parseDouble(streamRecord.getDynamodb().getNewImage().get("latitude").getN());
    String deviceId = streamRecord.getDynamodb().getNewImage().get("deviceId").getS();
    coordinateMap.put(deviceId, new GeoCoordinate(longitude, latitude));

    jedis.geoadd("bikes", coordinateMap);
    LOG.info("Updated "+deviceId+" GPS information as:"+longitude+","+latitude);
    }
  }
checkpointCounter += 1;
if(checkpointCounter % 10 == 0){ //checkpoint大小需根据实际需求调整
  try {
    checkpointer.checkpoint();
   }
  catch (Exception e) {
    e.printStackTrace();
   }
  }
 }
 
}

@Override
public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason reason) 
{
  if(reason == ShutdownReason.TERMINATE) {
    try {
      checkpointer.checkpoint();
    }
    catch (Exception e) {
     e.printStackTrace();
    }
   }
  }
}

c）在完成地理信息的实时更新后，可以基于Elasticache的数据利用GEORADIUS搜索周边的资源。使用nodejs示例代码如下：


var express = require('express');
var app = express();
var Redis = require('ioredis');

var cluster = new Redis.Cluster([{
    port:6379,
    host:'lab-cluster.4bh9j8.clustercfg.cnn1.cache.amazonaws.com.cn'
}]);

app.get('/bikes', function(req,res){
if(req.query['longitude'] && req.query['latitude']){
console.log ('longitude = %s,latitude = %s',req.query['longitude'],req.query['latitude']);
cluster.send_command('GEORADIUS',
[ 'bikes',req.query['longitude'],req.query['latitude'],2000,
'm',
'WITHDIST',
'WITHCOORD',
'COUNT',
10], (error, reply) =>{

if (error) {
res.status(500).send("无法获取附近车辆信息");
return;
}

var stations = reply.map( (r) =>{
return {
name: r[0],
distance: `${r[1]} m`,
coordinates: {
latitude:  Number(r[2][1]),
longitude: Number(r[2][0])
} }
});

res.status(200).json(stations);
});
}
});

var server = app.listen(8080,function(){
var host = server.address().address
var port = server.address().port
console.log("应用实例，访问地址为 http://%s:%s", host, port)
});

基于以上代码，服务端就可以返回最近的10个资源以及每个资源离当前位置的距离。例如：
请求
http://hostname or elb address/bikes?longitude=116&latitude=39.4
返回


[
 {
  "name": "48093ba0-f8f1-49f0-b312-285800341b08",
  "distance": "1117.8519 m",
   "coordinates": {
    "latitude": 39.40640623614937,
    "longitude": 116.01002186536789
 }
},
{
  "name": "950fb5df-c0ff-4a95-90ea-2f5f574c5796",
  "distance":"1305.5083 m",
  "coordinates": {
   "latitude": 39.40184880750488,
   "longitude": 116.01500004529953
  }
 },
……
]

d)通过封装http请求构建手机应用。

总结

Redis Geospatial功能可以让开发者更高效的搜索和计算位置信息的记录。同时，AWS Elasticache提供的托管Redis服务大大简化了对于Redis集群的维护工作，包括搭建，备份和迁移等工作。最后，自动扩展的DynamoDB则负责位置信息数据的持久化和检索，而它的流功能也使得数据能够快速实时的流转起来。

作者介绍

赵霏，AWS解决方案架构师。负责基于AWS的云计算方案架构咨询和设计，同时致力于AWS云服务在国内的应用和推广。他拥有超过13年IT行业从业经验，长期专注于企业IT云转型、物联网、移动互联网、Devops等领域，在大规模后台架构、分布式计算和自动化运维等方面有着广泛的设计和实践经验。

基于Amazon EC2 Container Service的持续集成/持续交付解决方案

基本概念

持续集成/持续交付

互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称CI）和持续交付（Continuous delivery，简称CD）。

通过CI/CD构建自动化的代码交付管道，可以实现：

（1）快速交付。通过CI/CD自动化软件发布的过程，可以更快速地发布新的功能，快速迭代反馈并让新功能更快提供给客户。

（2）提高质量。自动化构建、测试和发布过程致使可以轻松测试每次代码更改并捕捉易于修复的小型漏洞，通过标准化发布过程运行每一项更改，从而保证应用程序或基础设施代码的质量。

（3）可配置工作流。通过图形用户界面模拟软件发布过程的各个阶段。

容器

本文涉及到的另外一个概念是容器，相信大家都已经不再陌生，并且很多朋友已经在自己的环境中有实际的运行、部署基于容器的应用，这边简单的回顾下容器的几个重要优势：

一是因为容器可以跨平台，从而让程序猿可以享受到研发生产环境一致性的便利，也就是DevOps。在没有容器之前，常常一个应用做好了在笔记本上可以运转起来，在数据中心就运转不起来，因为操作系统版本不同、库版本不对；或者有的时候生产环境里出现了问题，在笔记本的开发环境中复制不出来。有了容器之后，这些问题就大大减少了。

其二，容器在虚拟机里面可以大幅度提升资源利用率。因为一旦把应用容器化，虚拟机资源就可以通过部署多个容器而得到充分利用，而不是每一个应用去申请一个虚拟机，造成资源的浪费。

Amazon ECS/ECR

Amazon EC2 Container Service (ECS)是一个托管的容器集群管理和调度服务，可使您在 Amazon EC2 实例集群中轻松运行和管理支持 Docker 的应用程序。

使用 Amazon ECS 后，您不再需要安装、操作、扩展您自己的集群管理基础设施，可以根据资源需求和可用性要求在集群中安排支持 Docker 的应用程序。借助 Amazon ECS，您可以从一个容器扩展到覆盖数百个实例的数千个容器，而运行应用程序的方式并不会因此而变得复杂。您可以运行包括应用程序、批量作业和微服务在内的任何东西。Amazon ECS 将基础设施的一切复杂因素全部消除，让您能够集中精力设计、开发、运行容器化应用程序。

Amazon EC2 Container Registry (ECR) 是完全托管的 Docker 镜像仓库，可以让开发人员轻松存储、管理和部署 Docker 容器映像。Amazon ECR 集成在 Amazon EC2 Container Service (ECS) 中，从而简化产品工作流的开发。

本文主要介绍如何在AWS云上，使用Jenkins快速构建针对容器应用的持续集成/持续交付管道。

下图是整个CI/CD的流程图：

开发者commit/push新版本的软件工程到GitHub仓库
GitHub的webhook触发Jenkins预先定义好的构建Pipeline
Jenkins下载GitHub，并基于下载的DockerFile构建新的docker镜像并上传ECR仓库
Jenkins调用aws cli更新ECS的task definition引用新的docker镜像并更新相关的service
ECS基于新的service配置更新集群中的container

可以看到，整个代码的发布过程，开发人员只需要在本地开发新版本的软件并提交到GitHub，之后的一系列代码构建、部署等过程可以完全实现自动化，无需人为干预，大大提高了软件迭代的速度，为敏捷开发、微服务化提供支持，同时，可以根据需要添加测试步骤、代码审查、人工审批等步骤，构建一条更为强大灵活的代码交付流程。

准备工作启动一台EC2用于安装jenkins，本例使用Amazon Linux AMI，建议分配EIP(52.34.X.X)，并且赋予合适role使其能够操作ECR和ECS
安装java jdk 1.8
安装并运行docker daemon,

yum install docker –y

chkconfig docker on

service docker start

安装并运行jenkins

wget -O /etc/yum.repos.d/jenkins.repo http://jenkins-ci.org/redhat/jenkins.reporpm –import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.keyyum install jenkins

chkconfig jenkins on

service jenkins start

将jenkins用户加入docker用户组，使其拥有docker cli执行权限

usermod -a -G docker jenkins
安装git,jq

yum install git jq –y

第一步配置GitHub与Jenkins联动

生成GitHub token，用于jenkins访问GitHub

记录下生成的token字符串

为需要做CI/CD的GitHub创建hook，实现代码更新自动通知Jenkins，Payload URL设置Jenkins Server的地址，默认Jenkins监听8080端口

第二步配置Jenkins的构建步骤

在浏览器中输入jenkins server的地址(52.34.X.X:8080)，开始配置jenkins

初始化登入

安装推荐的插件

安装CloudBees Docker Build and Publish plugin，用于构建docker镜像并上传到ECR仓库

配置github插件，使得jenkins能够连接到github

点击Add GitHub Server增加GitHub服务器，并添加Credentials

在Secret中输入之前记录的GitHub Personal Access Token

点击Test connection测试连通性

创建jenkins项目

设置GitHub项目路径

源代码管理选择Git

勾选GitHub hook trigger for GITScm polling，使得github项目的更改自动触发构建行为

添加三个构建步骤

第一个步骤为通过aws cli登入ECR仓库

第二个步骤为通过CloudBees Docker Build and Publish plugin构建docker镜像并上传到ECR中

第三个步骤为通过脚本注册新的ECS task definition并更新service，实现服务部署，详细代码可以从如下链接获取

https://s3.cn-north-1.amazonaws.com.cn/junyublog/buildstep3.sh

第三步测试

https://github.com/iwasnobody/ecs-cicd-jenkins

本例使用的GitHub工程对外提供一个apache PHP的静态页面

在本地PC上clone下工程兵修改工程下的src/index.php文件

commit并push到GitHub上

Jenkins界面可以看到自动触发了一次新的构建

查看新的镜像已经被上传到ECR

查看jenkins创建了新版本的task definition

查看service已经引用了新版本的task definition

访问应用，确认已经更新到最新版

作者介绍

余骏，AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广。在加入AWS之前，他在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。

新增：Amazon Kinesis Streams 服务器端加密

在这个智能家居、大数据、物联网设备、手机、社交网络、聊天机器人和游戏机的时代，流媒体数据场景无处不在。利用 Amazon Kinesis Streams，您可以构建自定义应用程序，以便从数千个流媒体数据源捕获、处理、分析和存储每小时数 TB 的数据。由于 Amazon Kinesis Streams 允许应用程序从同一个 Kinesis 流并发处理数据，因此您可以构建并行处理系统。例如，您可以将处理后的数据发送到 Amazon S3，使用 Amazon Redshift 执行复杂分析，甚至使用 AWS Lambda 构建强大的无服务器流媒体解决方案。

Kinesis Streams 为消费者提供了多种流媒体使用案例，现在我们通过为 Kinesis Streams 添加服务器端加密 (SSE) 支持，让服务能够更有效地保护您的传输中数据。借助 Kinesis Streams 的这一新功能，现在您可以提高数据安全性和/或满足任何法规和合规性要求，以符合组织的任何数据流式处理需求。
事实上，Kinesis Streams 现在是支付卡行业数据安全标准 (PCI DSS) 合规性计划涵盖的 AWS 服务之一。PCI DSS 是由主要金融机构成立的 PCI 安全标准委员会管理的专有信息安全标准。PCI DSS 合规性适用于存储、处理或传输持卡人数据和/或敏感的身份验证数据的所有实体，其中包括服务提供商。您可以使用 AWS Artifact 索要 PCI DSS 合规性证明和责任摘要。但是，关于 Kinesis Streams 合规性的好消息还不止这些。Kinesis Streams 现在还符合 AWS GovCloud 中的 FedRAMP 标准。FedRAMP 代表“联邦风险与授权管理项目”(Federal Risk and Authorization Management Program)，是美国政府实施的一个项目，为云产品和云服务的安全评估、授权和持续监控提供了一种标准方法。您可以在这里了解有关 AWS 服务的 FedRAMP 合规性的更多信息。

现在您准备好了解关键点了吗？那就记住关键点，而不是纠结于细节。好吧，是有点陈词滥调，但这是我能想到的最好类比了。回到 Kinesis Streams 的 SSE 讨论中，让我来解释 Kinesis 的服务器端加密流程。使用 PutRecord 或 PutRecords API 放入 Kinesis Stream 中的每个数据记录和分区键均使用 AWS Key Management Service (KMS) 主密钥进行加密。通过 AWS Key Management Service (KMS) 主密钥，Kinesis Streams 使用 256 位高级加密标准 (AES-256 GCM 算法) 对传入数据进行加密。

为了对新的或现有流启用 Kinesis Streams 服务器端加密，您可以使用 Kinesis 管理控制台或利用某个可用的 AWS 软件开发工具包。此外，您还可以使用 AWS CloudTrail 服务审核流加密历史记录，验证 Kinesis Streams 控制台中特定流的加密状态，或者检查 PutRecord 或 GetRecord 事务是否已加密。

演练：Kinesis Streams 服务器端加密

我们来快速演练一下 Kinesis Streams 的服务器端加密。首先，我将访问 Amazon Kinesis 控制台并选择 Streams 控制台选项。

进入 Kinesis Streams 控制台后，我可以向我现有的某个 Kinesis 流添加服务器端加密，或者选择创建一个新的 Kinesis 流。对于此演练，我将选择快速创建一个新的 Kinesis 流，因此，我选择 Create Kinesis stream 按钮。

我将该流命名为 KinesisSSE-stream，然后为它分配一个分区。请记住，您的流的数据容量是根据为流指定的分区数量计算的。您可以使用控制台中的 Estimate the number of shards you’ll need 下拉菜单，或者通过在此处阅读更多有关计算方式的内容来估计流中的分区数。为了完成流的创建，现在我单击 Create Kinesis stream 按钮。

创建 KinesisSSE-stream 后，我将在控制面板中选择它，然后选择 Actions 下拉菜单并选择 Details 选项。

在 KinesisSSE-stream 的“Details”页面上，现在有一个 Server-side encryption 部分。在该部分中，我将选择 Edit 按钮。

现在，我可以通过选择 Enabled 单选按钮，使用 AWS KMS 主密钥为我的流启用服务器端加密。选择该选项后，我就可以选择将哪个 AWS KMS 主密钥用于 KinesisSSE-stream 中的数据加密。我可以选择 Kinesis 服务生成的 KMS 主密钥 (Default) aws/kinesis，也可以选择之前我自己生成的一个 KMS 主密钥。我将选择默认主密钥，然后只需单击 Save 按钮即可。

就是这样！从下面的屏幕截图中可以看出，只有大约 20 秒，服务器端加密即添加到我的 Kinesis 流中，现在传入到我的流中的任何数据都将被加密。需要注意的是，服务器端加密仅对在启用加密后传入的数据进行加密。启用服务器端加密之前 Kinesis 流中预先存在的数据将保持未加密状态。

总结

使用 AWS KMS 密钥的 Kinesis Streams 服务器端加密让您可以轻松地自动加密传入流中的流媒体数据。您可以使用 AWS 管理控制台或 AWS 软件开发工具包启动、停止或更新任何 Kinesis 流的服务器端加密。要了解有关 Kinesis 服务器端加密、AWS Key Management Service 或 Kinesis Streams 的更多信息，请查看 Amazon Kinesis 入门指南、AWS Key Management Service 开发人员指南或 Amazon Kinesis 产品页面。

祝流式处理顺利。

– Tara

亚马逊AWS官方博客

2016

步骤1：创建初始环境

步骤2：查看初始环境

步骤3：部署新版本的代码

步骤4：查看更新的环境

步骤5：清理

一、创建存储桶

二、上传对象

三、ACL

四、标签Tag

五、生命周期管理

六、存储类分析

七、存储指标

八、存储清单

Kong的安装

本文主要讲解第三种方式的安装过程，安装Kong 0.10.1版本

第一步 配置Kong的数据存储

第二步 安装配置Kong (Amazon Linux)

第三步 创建AMI，利用ELB，Autoscaling Group构建高可用架构

rm –f /usr/local/kong/serf/serf.id

第四步 创建Lambda函数并且测试

第五步 配置Kong API GW并调用Lambda

第六步 配置启用额外的插件

架构

实现

总结

基本概念

持续集成/持续交付

容器

Amazon ECS/ECR

本文主要介绍如何在AWS云上，使用Jenkins快速构建针对容器应用的持续集成/持续交付管道。

第一步配置Kong的数据存储

第二步安装配置Kong (Amazon Linux)

第三步创建AMI，利用ELB，Autoscaling Group构建高可用架构

第四步创建Lambda函数并且测试

第五步配置Kong API GW并调用Lambda

第六步配置启用额外的插件