服务范围：站点部署，网站部署，网站设置，数据库设置 ，防火墙设置，系统配置，DEDECMS，帝国等开源模板导数据前配置，安全组设置，安全策略设置，服务器设置，80端口配置及设置，开启或关闭端口。

服务说明	价格
网站设置： 1、开源网站设置，及其它网站设置。	100元/个
网站/程序/服务器/应用部署： 1、部署网站、程序、服务器、应用等。 2、配置网站、程序、服务器、应用等。	200元/个
数据库设置： 1、数据库安全设置。 2、数据库应用设置等。 3、数据库性能调优。	200元/次
防火墙设置： 1、第三方防火墙设置。 2、服务器防火墙设置，安全组设置，安全规则设置等。	200元/次
系统设置： 1、系统安全设置，环境要求设置等。 2、80端口配置及其它端口配置等。	100元/次
端口配置及设置： 1、如：80端口配置，或其它指定端口配置。 2、开启或关闭指定端口。	200元/次
备注： 1、如果您无法确认或者需要更多服务，可以联系工作人员交流。 2、交付时间：1天内（通常2小时）

万能配置(网站_服务器_数据库_安全组及端口_系统配置及设置_ftp)，首发于服务器安全维护工作室。

兼职企业运维技术顾问，首发于服务器安全维护工作室。

在大型企业云迁移项目组，经常会遇到企业将线下数据中心的子网迁移到 AWS 云上。线下的子网划分一般会根据子网的使用功能不同进行划分，例如防火墙子网、负载均衡器子网、配合部署高可用架构的心跳线子网、应用系统子网等。不同企业的子网划分规则、子网的掩码大小和路由规则均不相同，并且在迁移后的系统上线后，企业还会经常划分新的网段以部署新的应用系统，这就需要有一个通用的模板来协助网络管理人员简化工作流程，提高工作效率。在我所经历过的一个项目中，生产 VPC 的子网划分有47个之多，且子网掩码有/24, /25, /26. 27/, /28等不同，在添加新的子网时，需要仔细计算新的子网 CIDR 以及为新建子网配置路由表。

动态创建子网的方案概述

因为 CloudFormation 不支持程序逻辑，只支持静态资源的创建，所以在本方案中采用 AWS Lambda 来基于输入参数动态创建不同类型的子网。我们定义了3种不同类型的子网：公共子网 (Public Subnet)， 外部子网 (External Subnet)，内部子网 (Internal Subnet) Subnet。
公共子网的路由表有如下路由信息：

部署在公共子网中的服务器可以直接与 Internet 进行通信（缺省分配 Internet IP 地址，并且有指向 Internet Gateway 的缺省路由）。
外部子网的路由表有如下路由信息：

部署在外部子网的服务器可以通过 NAT Gateway 与 Internet 进行通信，并且可以不通过互联网访问 S3 和 dynamodb。
内部子网的路由表有如下路由信息：

部署在内部子网的服务器不能访问 Internet，但是能直接访问 S3 和 dynamodb。
本方案使用2个 CloudFomation 模板， 第一个模板(CreateBaseVpc.json)创建共享资源，例如 VPC、Internet Gateway、公共子网 (Public Subnet) 路由表、在各个可用区内创建公共子网、NAT Gateway、 VPC Endpoint (S3 endpoint和DynamoDB endpoint)和创建外部子网路由表。在这个模板中还创建了3个 Lambda 功能函数：

• SharedInfra – 对应 python 程序 create_shared_infra.zip

功能：根据输入的参数，在程序运行的AWS Region的每个AZ内创建公共子网，将在 CreateBaseVpc.json 模板中建立的公共子网路由表关联到每个公共子网。 在每个公共子网内创建 NAT Gateway 和VPC endpoint，创建内部子网路由表，创建外部子网路由表。删除已经创建完成的资源，包括：子网、路由表、vpc endpoint、NAT Gateway、Elastic IP。

• CreateExternalRoute – 对应 python 程序 create_external_route.zip

功能：创建外部子网路由表中的路由。因为 NAT Gateway 的创建速度比较慢，创建路由时一定要等待 NAT Gateway 的状态变成 available 后才可以成功。如果将此功能与 SharedInfra 放在一起，在执行的时候容易发生 Lambda 运行超时错误。删除已经创建的路由信息。

• SubnetAutomation – 对应 python 程序 subnet_creation.zip

功能：根据输入的参数，计算网路的子网掩码，创建公共子网、外部子网和内部子网，并将在公共子网路由表、内部子网路由表和外部子网路由表关联到相应的子网上。删除已经创建完成子网。在 CreateBaseVpc.json 模板运行时，通过创建用户定义资源 ExternalRouteCreation和SharedInfraCreation 分别触发 Lambda 功能 CreateExternalRoute 和 SharedInfra，从而完成共享资源的创建。并提供了 SubnetAutomation 的功能函数 ARN，供运行第二个模板时调用。

第二个模板 (SubnetAuto.json) 创建动态资源，例如根据输入参数的不同计算子网掩码、创建子网并分配路由表。

本方案中创建子网时的输入参数并不需要 CIDR，只需要指定子网要提供的可用 IP 地址的个数即可，程序在计算可用 IP 地址时已经排除了 AWS 子网子网中保留的5个 IP 地址。例如：如果要创建有50个 IP 的子网，则子网掩码是/26，共计有64-5=59个可用IP地址；如果要创建有16个 IP 的子网，则子网掩码是/27，共计有32-5=27个可用 IP 地址。

创建子网的参数输入规则如下：

1. 每个子网包含4个部分，之间使用“:”分隔 – 功能: IP 地址数量:可用区:子网类型
2. 可用区根据Region的不同可选项为：1a,1b,1c,1d,1e等
3. 子网类型的可选项为：p（公共子网），e（外部子网）或者 i（内部子网）
4. 不同子网之间使用“,”分隔。

安装和运行

1. 在浏览器中输入：https://github.com/shaneliuyx/autosubnet_creation， 下载2个 json 文件和3个 zip 文件。将3个 zip 文件上传到一个 S3 存储桶中。
2. 打开 AWS 控制台，并选择 CloudFormation，选择存储在本地的 json 文件 json，运行 CloudFormation 模板。
3. 假设输入缺省的 PublicSubnetCapacity 和 VpcCidr 如下：

1. 选择 Next，直至 AWS 资源开始创建
2. 最终运行结果如下：

创建的 Subnet 如下：

公共子网路由表：

1. 打开 AWS 控制台，并选择 CloudFormation，选择存储在本地的 json 文件 json，运行 CloudFormation 模板。
2. 输入 SubnetParameters：web1:50:1a:p,web1:50:1b:p,app1:50:1a:e,app1:50:1b:e,db1:50:1a:i,db1:50:1b:i

这将创建6个子网，其中 Web、APP 和 DB 各2个子网，分布在2个 AZ 中:

1. 运行结果如下:

创建的子网：

内部子网路由表：

外部子网路由表：

假设现在还要创建一个包含16个有效 IP 的公共子网用于部署网络设备，可以再运行一次SubnetAuto.json，输出参数：net1:16:1a:p,net1:16:1b:p
则可以创建出如下子网：

与其他 CloudFormation 模板配合使用，进行 Landing Zone 部署

Landing Zone 中文名称翻译成着陆区，是指 AWS 的基本环境，用户在其上部署安全和运维流程。Landing Zone 的内容包含：账户结构、账户安全基线、网络结构和AWS用户访问管理。下面简单的介绍一下 AWS Landing Zone 的最佳实践。

• 账户结构

AWS 建议账户的划分与企业的组织架构和运维部门的组织架构一致。例如按照如下结构划分账户：

• 账户安全基线

AWS 建议在所有账户内打开 CloudTrail 和 AWS Config 功能。所有日志信息要复制到安全账户内的 S3 存储桶中。建立跨账户访问的 Auditor 角色。

• 网络结构

AWS 建议删除缺省 VPC，建立客户自己定义的 VPC。建立共享 VPC（包含目录服务、邮件服务器等），应用 VPC 与共享 VP C建立 Peer 关系。通过 VPN 或者 Direct Connect 与线下的数据中心建立网络连接，或者采用 Transit VPC（参考 https://aws.amazon.com/answers/networking/aws-global-transit-network/ ，https://aws.amazon.com/blogs/aws/aws-solution-transit-vpc/ ）建立集中的网络控制机制。网络输入输出的安全控制（建立堡垒机，建立 Security Group、网络 ACL 或者第三方的防火墙工具）

• AWS 用户访问管理

包括建议基于 SAML 的单点登录，建立跨账户角色访问机制等。

上述介绍的建立 VPC 和子网的方法可以看成建立 Landing Zone 的基础，在此之上，我们还可以使用 CloudFormation 建立堡垒机，打开 CloudTrail 和 AWS config，建立不同账户间的日志（log）复制机制，建立 Config Rule 进行合规性检查等等。 AWS 已经开发出多个 QuickStart CloudFormation 脚本协助用户完成上述工作，但是这些脚本在中国区（BJS）运行时需要做一些修改。下表列出了一些可用的资源，其中中国区部署模板是我针对中国区的特点修改过的，可以在BJS正常运行。

建立 VPC 并基于参数动态创建子网的 CloudFormation 模板，首发于服务器安全维护工作室。

宏的使用有两个主要步骤。首先，我们需要定义宏。当然，为此我们需要使用 CloudFormation 模板。然后，为了在我们的模板中使用宏，我们需要将它添加为整个模板的转换函数，或者直接调用它。在本博文中，宏和转换函数这两个术语基本可以互换。已经准备好了解其工作原理了？

创建 CloudFormation 宏

宏的创建有两个要素：一是定义，二是实现。如要创建宏的定义，我们需要一个类型为 AWS::CloudFormation::Macro 的 CloudFormation 资源，该资源定义了需要使用的 Lamda 函数以及应当调用的宏。

Type: "AWS::CloudFormation::Macro"
Properties:
  Description: String
  FunctionName: String
  LogGroupName: String
  LogRoleARN: String
  Name: String

宏的 Name 必须在整个区域是唯一的，并且通过 FunctionName 引用的 Lambda 函数必须与要创建的宏位于同一区域。您执行宏模板时，将会使该宏对其他模板也同样可用。宏的实现由 Lambda 函数完成。宏可以位于自己的模板中，也可与其他宏组合，但无法在注册宏的模板中使用该宏。Lambda 函数会收到与以下类似的 JSON 负载：

{
    "region": "us-east-1",
    "accountId": "$ACCOUNT_ID",
    "fragment": { ... },
    "transformId": "$TRANSFORM_ID",
    "params": { ... },
    "requestId": "$REQUEST_ID",
    "templateParameterValues": { ... }
}

负载的 fragment 部分包含了整个模板或者模板的相关区段 — 具体取决于如何从调用宏的模板中调用转换函数。区段始终在 JSON 中，即使模板在 YAML 中亦是如此。

Lambda 函数预计将会返回一个简单的 JSON 应答：

{
    "requestId": "$REQUEST_ID",
    "status": "success",
    "fragment": { ... }
}

requestId 需要输入负载中收到的相同，如果 status 包含除 success（不区分大小写）以外的任何值，则变更集的创建将会失败。然后，fragment 必须包含转换后模板的有效 CloudFormation JSON。即使您的函数未执行任何操作，仍然需要返回它的区段以包含到最终模板中。

使用 CloudFormation 宏

如要使用宏，我们只需使用要求的参数调用Fn::Transform。如果您希望利用宏来对整个模板进行句法分析，则我们可以按照与 SAM: Transform: [Echo] 相同的方式，将其列入模板中的转换函数列表中。在我们执行模板时，通过调用每个宏的制定函数并返回最终模板，转换函数将会被收集到变更集中。

假设我们有一个名为 EchoFunction 的 虚拟 Lambda 函数，它只是记录通过它的数据并返回未加任何修改的区段。我们将宏定义为一种正常的 CloudFormation 资源，与以下类似：

EchoMacro:
  Type: "AWS::CloudFormation::Macro"
  Properties:
    FunctionName: arn:aws:lambda:us-east-1:1234567:function:EchoFunction
	Name: EchoMacro

Lambda 函数的代码可能简单如下：

def lambda_handler(event, context):
    print(event)
    return {
        "requestId": event['requestId'],
        "status": "success",
        "fragment": event["fragment"]
    }

然后在部署此函数并执行宏模板后，我们可以在任何其他模板的顶层的转换函数中调用宏，与以下类似：

AWSTemplateFormatVersion: 2010-09-09 
 Transform: [EchoMacro, AWS::Serverless-2016-10-31]
 Resources:
    FancyTable:
      Type: AWS::Serverless::SimpleTable

CloudFormation 会首先调用我们定义的 Echo 宏，然后调用 AWS::Serverless 转换函数，从而创建模板的变更集。它将按照列表中的顺序执行转换函数中列举的宏。

此外，我们还可以使用内部函数 Fn::Transform 调用宏，该函数允许我们输入额外的参数。例如：

AWSTemplateFormatVersion: 2010-09-09
Resources:
  MyS3Bucket:
    Type: 'AWS::S3::Bucket'
    Fn::Transform:
      Name: EchoMacro
      Parameters:
        Key: Value

内联转换函数将拥有其所有同级节点和下级节点的访问权限。转换函数的处理顺序为由深到浅，这意味着最顶层的转换函数将会最后执行。我知道大多数人都会说：不对，你不能在宏中包含宏 — 但想法不错。

在您执行 CloudFormation 模板时，它将会直接要求您创建一个变更集，并且您可以在部署前预览输出结果。

示例宏

我们正在推出多个参考宏，以帮助开发人员上手，同时我预计许多人也将发布更多的宏。以下四个宏是在此功能发布前，一个小的内部骇客马拉松的优胜作品：

以下是我认为有人可能会感兴趣实现的一些理念：

• 自动注册 R53 域 + AWS Certificate Manager (ACM) 凭证预置
• 自动分配带自定义域的 S3 静态网站或 Amazon CloudFront
• 扩展 CloudFormation 映射以读取 DynamoDB 表
• 自动为 Amazon Virtual Private Cloud 设置 IPv6
• 自动订阅 Webhook 以与 Slack、Twitter、Messenger 集成

如果您有任何奇妙的想法，我非常期待您写出来！

现已推出

CloudFormation Macros 从今天开始已在所有支持 AWS Lambda 的 AWS 区域推出。使用 Macros 不会发生额外的 CloudFormation 费用，这意味着您只需承担正常的 AWS Lambda 函数费用。更多信息请参阅文档。

使用 AWS Lambda 支持的宏扩展 AWS CloudFormation，首发于服务器安全维护工作室。

在本文中，我们将向您展示如何使用 AWS Config 监控 Amazon Simple Storage Service (S3) 存储桶 ACL 和策略，确定是否存在允许公开读写访问权限的违规行为。如果 AWS Config 发现违反策略的行为，我们会使其触发 Amazon CloudWatch Event 规则以触发 AWS Lambda 函数，从而更正 S3 存储桶 ACL，或通过 Amazon Simple Notification Service (Amazon SNS) 通知您存在违反策略且允许公开读写访问权限的行为。我们将通过五个主要步骤为您演示此过程。

1. 启用 AWS Config 来监控 Amazon S3 存储桶 ACL 和策略，以发现违规行为。
2. 创建 IAM 角色和策略，为 Lambda 函数授予读取 S3 存储桶策略和通过 SNS 发送提醒的权限。
3. 创建和配置 CloudWatch Events 规则，在 AWS Config 检测到违反 S3 存储桶 ACL 或策略的行为时触发 Lambda 函数。
4. 创建 Lambda 函数，以使用 IAM 角色审核 S3 存储桶 ACL 和策略、更正 ACL，并通知您的团队策略违规行为。
5. 验证监控解决方案。

注意：本文假设您的合规性策略要求您所监控的存储桶不允许公开读写访问权限。例如，如果您打算开放提供静态内容的存储桶，可以从本文着手，根据您的需要定制解决方案。

在本文末尾，我们将提供一个可实施本文所述解决方案的 AWS CloudFormation 模板。您可以使用该模板在多个区域快速部署解决方案。

重要说明：如果使用部署的某些资源（包括使用所提供的 CloudFormation 模板部署的资源），则在使用这些资源期间会产生费用。在提供 AWS Config 规则的每个区域使用这些规则都会产生费用。

架构

以下是我们将要实施的架构图：

步骤 1：启用 AWS Config 和 Amazon S3 存储桶监控功能

以下步骤将演示如何设置 AWS Config 来监控 Amazon S3 存储桶。

1. 登录 AWS 管理控制台，并打开AWS Config 控制台。
2. 如果这是您第一次使用 AWS Config，请选择开始使用。如果您已经使用过 AWS Config，请选择设置。
3. 在设置页面中的 Resource types to record (要记录的资源类型) 下，取消选中 All resources (所有资源) 复选框。在 Specific types (具体类型) 列表中，选择 S3 下的存储桶。

    

4. 选择用于存储配置历史记录和快照的 Amazon S3 存储桶。我们会创建一个新的 Amazon S3 存储桶。

    

   1. 如果您更希望使用账户中现有的 Amazon S3 存储桶，请选择 Choose a bucket from your account (从您的账户中选择存储桶) 单选按钮，然后使用下拉菜单选择现有的存储桶。

       

5. 在 Amazon SNS topic (Amazon SNS 主题) 下，选中 Stream configuration changes and notifications to an Amazon SNS topic (将配置更改和通知流式传输至 Amazon SNS 主题) 旁边的复选框，然后选择 Create a topic (创建主题) 旁边的单选按钮。
   1. 您也可以选择之前创建和订阅的主题。

       

   2. 如果您创建了新的 SNS 主题，则需要订阅它才能收到通知。我们将在后面的步骤中演示此操作。
6. 除非您已经有要使用的角色，否则请在 AWS Config role (AWS Config 角色) 下选择 Create a role (创建角色)。我们使用系统自动推荐的角色名称。

    

7. 选择下一步。
8. 配置 Amazon S3 存储桶监控规则：
   1. 在 AWS Config rules (AWS Config 规则) 页面上搜索 S3，选择 s3-bucket-publice-read-prohibited 和 s3-bucket-public-write-prohibited 规则，然后单击下一步。

       

   2. 在审核页面上，选择确认。AWS Config 此时会分析您的 Amazon S3 存储桶，捕获它们当前的配置，并根据我们选择的规则评估配置。
9. 如果您创建了新 Amazon SNS 主题，请打开 Amazon SNS 管理控制台并找到您创建的主题：

    

10. 复制该主题的 ARN（以 arn: 开头的字符串），您需要在后面的步骤中使用它。
11. 选择主题旁边的复选框，然后在操作菜单下选择订阅主题。
12. 选择电子邮件作为协议，输入您的电子邮件地址，然后选择创建订阅。
13. 几分钟后，您会收到一封电子邮件，要求您确认订阅与此主题有关的通知。选择对应链接以确认订阅。

步骤 2：为 Lambda 创建角色

我们的 Lambda 需要相关权限，才能检查和修改 Amazon S3 存储桶 ACL 和策略，记录 CloudWatch 日志并发布到 Amazon SNS 主题。现在，我们将设置自定义 AWS Identity and Access Management (IAM) 策略和角色来支持这些操作，并将它们分配到我们将在下一节中创建的 Lambda 函数。

1. 在 AWS 管理控制台中，在服务下选择 IAM 以访问 IAM 控制台。
2. 创建具有以下权限的策略，或者复制以下策略：

   
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "SNSPublish",
               "Effect": "Allow",
               "Action": [
                   "sns:Publish"
               ],
               "Resource": "*"
           },
           {
               "Sid": "S3GetBucketACLandPolicy",
               "Effect": "Allow",
               "Action": [
                   "s3:GetBucketAcl",
                   "s3:GetBucketPolicy"
               ],
               "Resource": "*"
           },
           {
               "Sid": "S3PutBucketACLAccess",
               "Effect": "Allow",
               "Action": "s3:PutBucketAcl",
               "Resource": "arn:aws:s3:::*"
           },
           {
               "Sid": "LambdaBasicExecutionAccess",
               "Effect"quot;: "Allow",
               "Action": [
                   "logs:CreateLogGroup",
                   "logs:CreateLogStream",
                   "logs:PutLogEvents"
               ],
               "Resource": "*"
           }
       ]
   }
   
   

3. 为 Lambda 函数创建角色：
   1. 从要使用该角色的服务列表中选择 Lambda。
   2. 选择您之前创建的策略旁边的复选框，然后选择 Next: Review (下一步：审核)
   3. 指定角色名称，为其输入描述，然后选择创建角色。在该示例中，我们将角色命名为 LambdaS3PolicySecuringRole。

步骤 3：创建和配置 CloudWatch 规则

在这一节中，我们将创建一个 CloudWatch 规则，以便在 AWS Config 确定您的 Amazon S3 存储桶不合规时触发 Lambda 函数。

1. 在 AWS 管理控制台中，在服务下选择 CloudWatch。
2. 在左侧的事件下，选择规则。
3. 单击创建规则。
4. 在 Step 1: Create rule (第 1 步：创建规则) 中的事件源下，选择下拉列表并选择生成自定义事件模式。
5. 复制以下模式，并将其粘贴到文本框中：

   
   {
     "source": [
       "aws.config"
     ],
     "detail": {
       "requestParameters": {
         "evaluations": {
           "complianceType": [
             "NON_COMPLIANT"
           ]
         }
       },
       "additionalEventData": {
         "managedRuleIdentifier": [
           "S3_BUCKET_PUBLIC_READ_PROHIBITED",
           "S3_BUCKET_PUBLIC_WRITE_PROHIBITED"
         ]
       }
     }
   }
   
   			

   该模式会在检查 Amazon S3 存储桶的公开访问权限时匹配 AWS Config 生成的事件。

6. 我们将在稍后添加 Lambda 目标。现在，选择您之前创建的 Amazon SNS 主题，然后选择配置详细信息。

    

7. 输入规则的名称和描述。在该示例中，我们指定名称 AWSConfigFoundOpenBucket
8. 单击创建规则。

步骤 4：创建 Lambda 函数

在这一节中，我们将创建新的 Lambda 函数，用于检查 Amazon S3 存储桶的 ACL 和存储桶策略。如果发现存储桶 ACL 允许公开访问权限，该 Lambda 函数会将其覆盖，改为私密。如果找到了存储桶策略，Lambda 函数会创建 SNS 消息，将该策略添加到消息正文中，然后将其发布到我们创建的 Amazon SNS 主题。存储桶策略可能很复杂，而覆盖策略可能会导致访问权限意外丢失，因此该 Lambda 函数不会尝试对您的策略进行任何更改。

1. 获取之前创建的 Amazon SNS 主题的 ARN。
2. 在 AWS 管理控制台中，在服务下选择 Lambda 进入 Lambda 控制台。
3. 在控制面板中，选择创建函数。或者，如果您直接进入了函数页面，也可以选择右上角的创建函数按钮。
4. 在创建函数页面上：
   1. 选择从头开始创作。
   2. 为该函数提供一个名称。我们使用 AWSConfigOpenAccessResponder。
   3. 我们编写的 Lambda 函数与 Python 3.6 兼容，所以请在运行语言下拉列表中选择 Python 3.6。
   4. 在角色下选择选择现有角色。选择您在前一节中创建的角色，然后选择创建函数。

       

5. 现在，我们根据之前创建的规则添加 CloudWatch 事件。
   1. 在 Add triggers (添加触发器) 部分，选择 CloudWatch Events。CloudWatch Events 框应该会显示在 Lambda 函数左侧，还会显示一条内容为 Configuration required (需要配置) 的备注。

       

   2. 在规则下拉框中，选择您之前创建的规则，然后选择添加。
6. 向上滚动到 Designer (设计者) 部分，然后选择您的 Lambda 函数的名称。
7. 删除默认代码，然后粘贴以下代码：

   
   import boto3
   from botocore.exceptions import ClientError
   import json
   import os
   
   ACL_RD_WARNING = "The S3 bucket ACL allows public read access."
   PLCY_RD_WARNING = "The S3 bucket policy allows public read access."
   ACL_WRT_WARNING = "The S3 bucket ACL allows public write access."
   PLCY_WRT_WARNING = "The S3 bucket policy allows public write access."
   RD_COMBO_WARNING = ACL_RD_WARNING + PLCY_RD_WARNING
   WRT_COMBO_WARNING = ACL_WRT_WARNING + PLCY_WRT_WARNING
   
   def policyNotifier(bucketName, s3client):
       try:
           bucketPolicy = s3client.get_bucket_policy(Bucket = bucketName)
           # notify that the bucket policy may need to be reviewed due to security concerns
           sns = boto3.client('sns')
           subject = "Potential compliance violation in " + bucketName + " bucket policy"
           message = "Potential bucket policy compliance violation. Please review: " + json.dumps(bucketPolicy['Policy'])
           # send SNS message with warning and bucket policy
           response = sns.publish(
               TopicArn = os.environ['TOPIC_ARN'],
               Subject = subject,
               Message = message
           )
       except ClientError as e:
           # error caught due to no bucket policy
           print("No bucket policy found; no alert sent.")
   
   def lambda_handler(event, context):
       # instantiate Amazon S3 client
       s3 = boto3.client('s3')
       resource = list(event['detail']['requestParameters']['evaluations'])[0]
       bucketName = resource['complianceResourceId']
       complianceFailure = event['detail']['requestParameters']['evaluations'][0]['annotation']
       if(complianceFailure == ACL_RD_WARNING or complianceFailure == ACL_WRT_WARNING):
           s3.put_bucket_acl(Bucket = bucketName, ACL = 'private')
       elif(complianceFailure == PLCY_RD_WARNING or complianceFailure == PLCY_WRT_WARNING):
           policyNotifier(bucketName, s3)
       elif(complianceFailure == RD_COMBO_WARNING or complianceFailure == WRT_COMBO_WARNING):
           s3.put_bucket_acl(Bucket = bucketName, ACL = 'private')
           policyNotifier(bucketName, s3)
       return 0  # done
   			

8. 向下滚动到环境变量部分。该代码使用一个环境变量来存储 Amazon SNS 主题的 ARN。
   1. 输入 TOPIC_ARN 作为密钥。
   2. 输入之前创建的 Amazon SNS 主题的 ARN 作为值。
9. 在 Execution role (执行角色) 下选择选择现有角色，然后从下拉菜单中选择之前创建的角色。
10. 保留其他内容不变，然后在顶部选择保存。

步骤 5：验证效果

到现在为止，我们已经有了一个 Lambda 函数、一个 Amazon SNS 主题、监控 Amazon S3 存储桶的 AWS Config，以及在发现存储桶不合规时触发 Lambda 函数的 CloudWatch 规则。我们来进行测试，确保它们能够正常工作。

我们有在受 AWS Config 监控的区域中创建的 Amazon S3 存储桶 myconfigtestbucket，还有关联的 Lambda 函数。ACL 或策略中未设置该存储桶的公开读写访问权限，所以它是合规的。

我们来更改存储桶的 ACL，以允许公开列出对象：

保存后，该存储桶便可公开访问了。几分钟后，AWS Config 控制面板会发现一项不合规的资源：

在 Amazon S3 控制台中，我们可以看到：在调用由之前创建的 CloudWatch 规则触发的 Lambda 函数后，存储桶中不再公开列出对象。

请注意，AWS Config 控制面板此时显示没有不合规的资源了：

现在，我们来配置允许列表访问的存储桶策略，以尝试进行 Amazon S3 存储桶策略检查：

对 myconfigtestbucket 存储桶设置该存储桶策略后，AWS Config 会在几分钟后检测到该存储桶不再合规。因为这是存储桶策略而不是 ACL，所以我们将一条通知发布到我们之前创建的 SNS 主题，以通知我们可能违反策略的行为：

获知该策略允许公开列出存储桶后，我们现在可以修改或删除该策略，随后 AWS Config 会检测到资源符合策略。

结论

在本文中，我们演示了如何使用 AWS Config 监控 Amazon S3 存储桶是否使用公开的读写访问权限 ACL 和策略。另外，我们演示了如何使用 Amazon CloudWatch、Amazon SNS 和 Lambda 覆盖公开的存储桶 ACL，或者在存储桶使用可疑策略时提醒您。您可以使用 CloudFormation 模板在多个区域快速部署该解决方案。通过该方法，您将能够轻松找出并保护公开的 Amazon S3 存储桶 ACL 和策略。将该解决方案部署到多个区域后，可以使用 AWS Config 聚合器来聚合结果。阅读本文了解更多信息。

利用 AWS Config 监控和响应 Amazon Simple Storage Service (S3) 允许公开读写访问权限，首发于服务器安全维护工作室。

除了提供IP资源及网络连接，Amazon VPC还提供DNS及DHCP等基础设施服务。当您将实例启动到默认 VPC 中时，我们为实例提供与其公有 IPv4 和私有 IPv4 地址对应的公有和私有 DNS 主机名。当您在非默认 VPC 中启动实例时，我们会为实例提供私有 DNS 主机名，并根据您为 VPC 和实例指定的设置来决定是否提供公有 DNS 主机名。

对于 us-east-1 区域，公有 (外部) DNS 主机名采用 ec2-<public-ipv4-address>.compute-1.amazonaws.com 形式，对于其他区域，则采用 ec2-<public-ipv4-address>.region.amazonaws.com 形式。例如，公有IP为54.222.212.110的EC2实例，其公有DNS名为ec2-54-222-212-110.cn-north-1.compute.amazonaws.com.cn。我们将公有 DNS 主机名解析为该实例在所在网络外的公有 IPv4 地址及其在所在网络内的私有 IPv4 地址。

私有 (内部) DNS 主机名解析为实例的私有 IPv4 地址，并对 us-east-1 区域采用 ip-<private-ipv4-address>.ec2.internal 形式，对其他区域采用 ip-<private-ipv4-address>.region.compute.internal 形式 (其中 private.ipv4.address 是反向查找 IP 地址)。例如，私有IP地址为10.206.2.239的EC2实例，其私有DNS名为ip-10-206-2-239.cn-north-1.compute.internal。您可以使用私有 DNS 主机名在同一网络中实现实例之间的通信，但我们无法解析实例所在网络之外的 DNS 主机名。要解析实例所在网络之外的主机名，可自建DNS服务器来为VPC及外部网络提供DNS服务。

常见的应用场景是在混合IT架构下，客户数据中心通过VPN或是Direct Connect专线连接到AWS上的VPC，在VPC中配置1台DNS服务器，在客户数据中心也配置1台DNS服务器，服务器的主从角色客户可自行定义。通过多台DNS服务器为不同位置的客户端提供DNS服务，即能保证服务的高可用，又能就近提供服务，减少DNS查询延迟。

接下来，我将基于上述架构图一步一步说明如何使用BIND搭建DNS服务器。本文不会涉及BIND的高级配置，如需了解BIND的高级配置，可参考BIND官方网站。

安装配置DNS主服务器

首选需要准备一台EC2实例用于安装BIND软件，如何创建EC2实例可参考Amazon EC2入门指南。本次示例选用Amazon Linux操作系统的AMI来创建实例，实例类型选用了通用型实例类型: m4.large。BIND对服务器硬件资源要求不高，在不启用DNSSEC的情况下(不在本文讨论范围)，普通配置的服务器即可承载DNS服务。m4.large配置有2颗vCPU和8G内存，运行DNS服务能够支持中等规模的DNS请求，当请求增加时，也可方便的调整实例类型到更大的配置。

创建EC2实例时需要指定安全组来开放服务端口，DNS服务通过UDP 53端口提供DNS查询相应，通过TCP 53端口提供区域传送。因此，安全组队VPC网段开放UDP 53端口，对客户数据中心的DNS服务器开放TCP 53端口，如下图所示：

DNS服务器作为基础设施服务的重要性无须多言，Amazon EC2持续监控EC2实例的状态以及底层硬件的状态，分别称为实例状态检查和系统状态检查。我们可创建状态检查报告，当任一状态检查失败时，执行重启操作，并将警报发送至指定邮箱。

创建好警报之后，通过SSH登陆至EC2实例，并yum命令安装bind软件：

yum install bind-utils bind

安装好之后，我们接下来将创建一个示例的DNS域：aws.local，我们首先需要编辑/etc/named.conf文件，修改以下内容：

listen-on 缺省配置为127.0.0.1，DNS服务只会绑定到系统的环回接口，其他客户端无法访问，需要添加EC2实例的私有IP地址，才能提供外部访问

allow-query缺省配置为localhost，即只允许DNS服务器所在的EC2实例对自己进行DNS查询，添加VPC的网段可允许来自VPC内部的主机进行DNS查询。注：也可将此参数设置为0.0.0.0/0，因为前面安全组设置里只允许了VPC内的IP访问UDP 53端口。

此外，还需要增加对aws.local这个域的定义，在/etc/named.conf中增加以下内容，allow-transfer指定了只允许从DNS服务器进行区域传送，限定允许区域传送的范围颗可提高DNS服务的安全性：

上述配置说明aws.local域的具体解析配置在文件/var/named/aws.local.db 里，其内容如下，在这个示例配置中，定义了两条A记录，分别是dns.aws.local对应10.206.0.212和www.aws.local对应10.206.0.213

配置Amazon VPC使用自建DNS服务器

Amazon VPC通过DHCP服务为VPC中的EC2及其他连网组件动态分配IP地址，动态主机配置协议 (DHCP) 提供了将配置信息传递到 TCP/IP 网络中主机的标准。DHCP 消息中的options字段包含配置参数。这些参数包括域名、域名服务器以及“netbios-node-type”。接下来我们将创建一个新的DHCP选项集，并在选项集中将域名服务器指向刚才创建的DNS服务器。

在AWS控制台中选择VPC服务，并在左边的菜单中选择“DHCP选项集”，点击“创建DHCP选项集”按钮，输入以下信息，域名服务器可指定多个DNS服务器，按照顺序第一个为VPC内的DNS服务器，第二个为客户数据中心的DNS服务器：

创建好DHCP选项集之后选择左边菜单中“您的VPC”选项，选中要修改的VPC，从“操作”下拉菜单中选择“编辑DHCP选项集”

选择刚才创建的DHCP选项集并保存：

在您将新的 DHCP 选项集与 VPC 关联之后，任何现有实例以及您在 VPC 内启动的所有新增实例都将使用这些选项。 无需重新开始或重新启动实例。根据实例更新 DHCP 租赁权的频率，它们会在几个小时内自动拾取更改。如果您愿意，您也可以使用实例上的操作系统，直接更新租赁权。

安装配置DNS从服务器

在客户数据中心安装配置DNS服务器的步骤与在Aamazon EC2中安装配置DNS服务器的步骤相同，除了/etc/named.conf的配置稍有差别：

从服务器的type类型为slave，file参数对应的域配置文件会自动根据从主DNS服务器接收到的更新来进行创建和更新，masters指定aws.local域的主域名服务器，最后一个参数allow-transfer禁用了区域传送。

配置好从DNS服务器之后，可将客户数据中心内的连网设备设置为从DNS服务器，第二DNS服务器设置为AWS上的主DNS服务器。

总结

Amazon VPC提供DHCP服务和DNS服务，为VPC中的EC2实例提供IP地址分配和域名解析服务，为每个EC2实例创建特定格式的DNS域名。如果用户希望使用自定义域名，或者希望使用一套域名统一管理云上和云下的资源，可自行搭建DNS服务器来提供DNS解析服务，Amazon VPC能够支持客户。

在Virtual Private Cloud中自建基于BIND的DNS服务器，首发于服务器安全维护工作室。

测试环境：

配置完毕后的拓扑如下：

环境搭建完毕后，登陆主备ECS服务器，分别配置nginx+keepalived

MASTER服务器（nginx1）配置文件/etc/keepalived/keepalived.conf内容以及解释如下：

BACKUP服务器（nginx2）的配置需要修改：

其它保持一致即可

为了实现nginx服务异常的时候能够自动切换，需要自己写一个脚本，脚本没有硬性的要求，能够实现目标即可，这里 监控nginx进程数为例：

重新启动nginx1的nginx和keepalive服务

查看日志可以看到keepalive重新发送了IP宣告的报文

1 2 3 4 5

Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) Entering MASTER STATE Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) setting protocol VIPs. Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.1.3 Oct 23 17:22:14 iZ239aqzdi7Z Keepalived_healthcheckers[25609]: Netlink reflector reports IP 192.168.1.3 added Oct 23 17:22:19 iZ239aqzdi7Z Keepalived_vrrp[25610]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.1.3

重新访问http://121.43.187.37/测试，重新访问到了服务器NGINX1，到HAVIP控制台查看，192.168.1.1的服务器重新夺回了控制权，成为了为主服务器

这样就实现了阿里云环境下的HA切换。

实际测试，阿里云的多个HAVIP可以绑定到同样的两台机器，可以配置多组vrrp_instance来实现双主。或者两台服务器同时为两个业务服务，避免资源浪费。同时能够做到主备

阿里云下配置keepalive，利用HAVIP实现HA，首发于服务器安全维护工作室。

1、如果对HTTP或者TCP转发协议不挑剔，换成TCP转发并不开启http健康检查就OK了。

优势：方便，控制台操作下就好了。

劣势：只是这样也失去了应用层异常的发现能力。

2、为健康检查单独建立一个没有开启日志的virtualhost，通过不同的端口或者hostname，让健康检查请求不会请求到业务host。

优势：web service级别的异常依然能够被健康检查发现。

劣势：virtualhost级别的异常，SLB健康检查就无法发现了。

3、利用nginx等web服务器的规则，为健康检查的文件名（URI）做单独的日志配置，以Nginx为例：

如下配置，健康检查配置一个业务上无意义的check.html。针对这个文件做的请求，不记录日志。

阿里云SLB健康检查的日志特殊处理，首发于服务器安全维护工作室。

VPC结构图

虚拟路由器配置

添加路由

为了让内网服务器借助EIP访问公网，所以设置所有目标地址0.0.0.0/0下一跳都转发到绑定了公网IP的ECS实例上。这里的下一跳ECS不支持搜索，需要提前记号名称：

绑定EIP的主机配置

iptables添加SNAT规则

iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -j SNAT --to-source 192.168.2.20

注意： ubuntu 14.04 系统保存iptables设置需要安装iptables-persistent包，然后通过 service iptables-persistent save 的方式保存配置，安装完iptables-persistent后该服务随系统一起启动并会把保存的配置应用

开启IP转发

echo "net.ipv4.ip_forward=1" >>  /etc/sysctl.conf && sysctl -p

阿里云VPC网络无EIP的主机上网，首发于服务器安全维护工作室。

這篇文章將一步一步介紹如何使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成持續整合與持續交付的開發流程。

前言

什麼是持續整合＆持續交付？

持續整合＆持續交付（Continuous Integration & Continous Delivery），簡稱 CI & CD，具體介紹可以參考「山姆鍋對持續整合、持續部署、持續交付的定義」這篇文章。

簡單來說就是盡量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。

我使用了哪些工具？

• Git – 版本管理
• GitHub – 程式碼託管、審查
• CircleCI – 自動化建置、測試、部署
• Docker – 可攜式、輕量級的執行環境
• AWS Elastic Beanstalk – 雲端平台
• Slack – 團隊溝通、日誌、通知

看完這篇你可以學到什麼？

• 瞭解 GiHub 的工作流程（GitHub Flow），利用 Pull Request 以及分支來完成代碼審查（Code Review）與環境配置，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。
• 使用 Docker，統一開發者、測試人員、以及產品的執行環境。
• 使用 EB CLI 將應用程式部署到 AWS Elastic Beanstalk 平台上。
• 使用 CircleCI 將以上工作全部自動化。偵測 GitHub 分支上的程式碼，若有更新則觸發：建置 Docker 環境、單元測試、然後自動部署新版本到 AWS EB。
• 使用 Slack，讓團隊成員能夠即時接收 GitHub 與 CircleCI 每一項動作的通知。

內容大綱

• Node.js
  • 在本地端執行 Node.js
  • 在本地端測試 Node.js
• GitHub
• CircleCI
  • 在 CircleCI 測試 Node.js
• Code Review with GitHub Flow
• Docker
  • 在 Docker 執行 Node.js
  • 在 CircleCI 測試 Docker
• AWS Elastic Beanstalk
  • 在本地端部署 AWS
  • 在 CircleCI 部署 AWS
• Slack

Node.js

安裝：

• node: 0.10

這篇文章以 Node.js 的應用程式作為範例，其他語言（Ruby on Rails、Python、PHP）也同樣適用此工作流程。

建立新專案

1. 建立一個專案資料夾（這裡以 hello-ci-workflow 為例）：

$ mkdir hello-ci-workflow
$ cd hello-ci-workflow

在本地端執行 Node.js

1. 初始化 Node.js 的環境，填寫一些資料之後會在目錄下產生一個 package.json 的檔案：

$ npm init

1. 安裝 Node.js 的 web framework，以 Express 為例：

$ npm install express --save

--save: 寫入 package.json 的 dependencies。

1. 完成之後，package.json 大概會長這個樣子：

// package.json
{
  "name": "hello-ci-workflow",
  "main": "index.js",
  "dependencies": {
    "express": "^4.12.3"
  },
  "scripts": {
    "start": "node index.js"
  }
}

1. 在 index.js 裡寫一段簡單的 Hello World! 的程式：

// index.js
var express = require('express');
var app = express();

app.get('/', function (req, res) {
  res.send('Hello World!');
});

var server = app.listen(3000, function () {

  var host = server.address().address;
  var port = server.address().port;

  console.log('Example app listening at http://%s:%s', host, port);

});

1. 執行 npm start 或 node index.js：

$ npm start

1. 打開瀏覽器 http://localhost:3000 看結果：

在本地端測試 Node.js

1. 安裝 Node.js 的單元測試，以 Mocha 為例：

$ npm install mocha --save-dev

--save-dev: 寫入 package.json 的 devDependencies，正式上線環境不會被安裝。

// package.json
{
  "name": "hello-ci-workflow",
  "main": "index.js",
  "dependencies": {
    "express": "^4.12.3"
  },
  "devDependencies": {
    "mocha": "^2.2.4"
  },
  "scripts": {
    "start": "node index.js"
  }
}

1. 根目錄 test 資料夾，並新增一個測試腳本 test.js：

$ mkdir test
$ cd test
$ touch test.js

1. 加入一筆錯誤的測試 assert.equal(1, [1,2,3].indexOf(0))：

// test/test.js
var assert = require("assert")
describe('Array', function(){
  describe('#indexOf()', function(){
    it('should return -1 when the value is not present', function(){
      assert.equal(1, [1,2,3].indexOf(0));
    })
  })
})

1. 執行 mocha 測試：

$ ./node_modules/.bin/mocha


  Array
    #indexOf()
      1) should return -1 when the value is not present


  0 passing (9ms)
  1 failing

結果顯示 1 failing，測試沒通過，因為 [1,2,3].indexOf(0) 回傳的值不等於 -1。

1. 將 test.js 的測試修正：

// test/test.js
assert.equal(-1, [1,2,3].indexOf(0));

1. 再次執行 mocha 測試：

$ ./node_modules/.bin/mocha


  Array
    #indexOf()
      ✓ should return -1 when the value is not present


  1 passing (6ms)

結果顯示 1 passing，通過測試。

GitHub

安裝：

• git: 2.3

帳號：

• GitHub

1. 初始化 git 環境：

$ git init .

1. 輸入 git status 會顯示目前哪些檔案有過更動：

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

  index.js
  node_modules/
  package.json
  test/

1. 將 node_modules 加到 .gitignore 黑名單，因為這個資料夾是由 npm install 自動產生的，不需要放到 GitHub 上：

# .gitignore

# Dependency directory
# https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git
node_modules

1. 將更動 commit：

$ git add .
$ git commit -m "first commit"

1. 打開 GitHub，新增一個 repository：

1. 輸入 repository 的名稱，以 hello-ci-workflow 為例：

1. 使用 git remote add 將新創建的 GitHub repository 加入到 remote：

$ git remote add origin https://github.com/<USER_NAME>/hello-ci-workflow.git

<USER_NAME> 改成自己的帳號。

1. 使用 git push 將程式碼傳到 GitHub：

$ git push -u origin master

成功之後前往 https://github.com/<USER_NAME>/hello-ci-workflow 就可以看到剛才上傳的檔案：

CircleCI

帳號：

• CircleCI

加入 GitHub repository

1. 點選左邊欄的 Add Projects 按鈕：

1. 選擇自己的 GitHub 帳號：

1. 搜尋要加入的 GitHub repository，然後點選 Build project 按鈕，以 hello-ci-workflow 為例：

1. 完成之後 CircleCI 就會自動執行第一次的建構，不過因為還沒加入測試腳本，所以建構結果會顯示 no test：

在 CircleCI 測試 Node.js

1. 在專案根目錄底下建立一個 circle.yml，並加入 mocha test：

# circle.yml
machine:
  node:
    version: 0.10

test:
  override:
    - ./node_modules/.bin/mocha

1. 完成之後將檔案 push 上 GitHub：

$ git add circle.yml
$ git cimmit "add circle.yml"
$ git push

1. Push 成功之後，CircleCI 會自動觸發建構和測試：

1. 測試通過，建置成功：

代碼審查（Code Review）with GitHub Flow

目前開發中比較常用的 workflow 有 Git flow 和 GitHub flow 兩種，可以參考以下幾篇文章：

Git flow：

• Git flow 開發流程
• git-flow cheatsheet
• A successful Git branching model

GitHub flow：

• Understanding the GitHub Flow
• Git Flow 和 Github Flow 的不同
• 在 GitHub 當中使用的 work flow

這裡我們使用 GitHub flow，它的核心精神是：

• 所有在 master 分支上的程式都一定要是通過測試，可以部署的產品版本。
• 要開發功能、修復 Bug、做任何事情，都要從 master 開一條新的分支。
• 隨時 commit 和 push 你的程式碼到 GitHub 上，與大家討論。
• 功能完成時，使用 pull request 讓大家作 code review。
• 確認沒問題之後才可以 merge 回 master，並且部屬新版本到線上。

建立一條分支

1. 為了確保 master 這條主線上的程式碼都是穩定的，所以建議開發者依照不同的功能、建立不同的分支，這裡以 test-github-flow 為例，使用 git branch 新增分支、然後 git checkout 切換分支：

$ git branch test-github-flow
$ git checkout test-github-flow

加入 commits

1. 在 test.js 裡加入一行錯誤的測試 assert.equal(3, [1,2,3].indexOf(5))：

// test/test.js
// ...
assert.equal(3, [1,2,3].indexOf(5));

$ git add test/test.js
$ git commit -m "add a error test case"

新增一個 Pull Request

1. Push 到 GitHub 的 test-github-flow 分支：

$ git push -u origin test-github-flow

1. 打開 GitHub 之後，會出現 test-github-flow 分支的 push commits，點選旁邊的 Compare & pull request 按鈕：

1. 點選之後會進入 Open a pull request 的填寫頁面，選擇想要 merge 的分支、輸入描述之後，點選 Create pull request 按鈕：

檢視＆討論你的程式碼

1. 新增一個 pull request 之後，其他人就會在 GitHub 上出現通知：

1. 點進去之後可以看見相關的 commits 與留言，但是下面有一個紅紅大大的叉叉；因為每次 GitHub 只要有新的 push，就會觸發 CircleCI 的自動建置和測試，並且顯示結果在 GitHub 上：

1. 點選叉叉，前往 CircleCI 查看錯誤原因：

1. 就會發現剛剛 push 到 test-github-flow 的測試沒通過：

回到 GitHub，因為測試沒通過，所以審查者不能讓這筆 pull request 被 merge 回 master。

1. 找到剛剛 commit 的那段程式碼，留言告知請開發者修正錯誤之後，再重新 commit push 上來：

1. 修正 test.js 的測試腳本：

// test/test.js
// ...
assert.equal(-1, [1,2,3].indexOf(5));

1. 再次 commit & push：

$ git add test/test.js
$ git commit -m "fix error test case"
$ git push

1. 回到 GitHub 的 pull request 頁面，可以看到最新一筆的 commit 成功通過 CircleCI 的測試了：

Merge＆部署

1. 審查之後，確定沒有問題，就可以點選 Merge pull request 的按鈕，將 test-github-flow 的程式碼 merge 回主線 master：

Docker

安裝：

• boot2docker: 1.5（Mac only）
• docker: 1.5

什麼是 Docker？為什麼要用它？

因為 Docker 最近很火，所以網路上不缺關於介紹它的文章，原諒我這裡只稍微提一下：

以往開發人員面對開發環境不同的問題，常常出現「明明在我的電腦上可以跑」的囧境，所以為了解決這類問題，通常會使用虛擬機器（VM）搭配一些工具（Vagrant、Chef）來協助統一開發人員、測試人員、上線產品的執行環境。

Docker 也是類似的解決方案，不同於 VM 的是，Docker 運行起來更輕巧、可攜度更高。配置好一份設定之後，就可以讓大家馬上進入開發狀況，減少不必要的環境問題，提升效率。

在 Docker 執行 Node.js

1. 在專案根目錄底下建立一個 Dockerfile：

# Dockerfile

# 從 [Docker Hub](https://hub.docker.com/) 安裝 Node.js image。
FROM node:0.10

# 設定 container 的預設目錄位置
WORKDIR /hello-ci-workflow

# 將專案根目錄的檔案加入至 container
# 安裝 npm package
ADD . /hello-ci-workflow
RUN npm install

# 開放 container 的 3000 port
EXPOSE 3000
CMD npm start

1. 使用 docker build 建構您的 image：

$ docker build -t hello-ci-workflow .

-t hello-ci-workflow 是 image 名稱。

1. 使用 docker run 執行您的 image：

$ docker run -p 3000:3000 -d hello-ci-workflow

-d 在背景執行 node，可以使用 docker logs 看執行結果。

1. 打開瀏覽器 http://localhost:3000 看結果：

其實每一次都要 build 和 run 還蠻麻煩的，推薦可以試試 Docker Compose，用起來有點像 Vagrant。

在 CircleCI 測試 Docker

1. 修改 circle.yml：

# circle.yml
machine:
  # 環境改成 docker
  services:
    - docker

dependencies:
  override:
    # 建構方式使用 docker build
    - docker build -t hello-ci-workflow .

test:
  override:
    - ./node_modules/.bin/mocha
    # 使用 curl 測試 docker 是否有順利執行 node
    - docker run -d -p 3000:3000 hello-ci-workflow; sleep 10
    - curl --retry 10 --retry-delay 5 -v http://localhost:3000

1. Push 更新到 GitHub：

$ git add Dockerfile circle.yml
$ git commit -m "add Docker"
$ git push

1. 查看 CircleCI 建構＆測試結果：

AWS Elastic Beanstalk

帳號：

• Amazon Web Services

安裝：

• AWS EB CLI: 3.x

最後要將程式上線啦！現在 PaaS 雲端平台的選擇非常多（Heroku、Google App Engine、Azure、OpenShift、Linode），這裡我選擇 Amazon 推出的 Elastic Beanstalk 當作範例，以下是它的特色：

• 支援的開發環境多（Java、.NET、PHP、Node.js、Python、Ruby、GO），重點是有支援 Docker！
• 只需要上傳程式碼，Elastic Beanstalk 即可幫你完成從容量配置、負載均衡（load balancing）、自動擴展（auto scaling）到應用程式的運行狀況監控的部署。

1. 初始化 EB 環境：

$ eb init -p docker

-p 可以指定 EB 的應用平台，例如 php 之類；這裡使用 docker。

該命令將提示您配置各種設置。 按 Enter 鍵接受預設值。

如果你已經存有一組 AWS EB 權限的憑證，該命令會自動使用它。 否則，它會提示您輸入 Access key ID 和 Secret access key，必須前往 AWS IAM 建立一組。

1. 初始化成功之後，可以使用 eb create 快速建立各種不同的環境，例如：development, staging, production；這裡我們以 env-development 為例：

$ eb create env-development

等待 Elastic Beanstalk 完成環境的建立。 當它完成之後，您的應用已經備有負載均衡（load-balancing）與自動擴展（autoscaling）的功能了。

1. 使用 eb open 前往目前版本的執行結果：

$ eb open env-development

在本地端部署 AWS

1. 稍微修改 index.js：

// index.js
// ...
app.get('/', function (req, res) {
  res.send('Hello env-development!');
});
// ...

1. 執行 eb deploy 部署新版本到 AWS Elastic Beanstalk：

$ eb deploy env-development

1. 部署完成之後，執行 eb open 打開網頁：

$ eb open env-development

env-development 上的應用程式更新完成。

在 CircleCI 部署 AWS

1. git checkout 將分支切換回主線 master：

$ git checkout master

1. eb create 新增一組新的環境，作為產品上線用，命名為 env-production：

$ eb create env-production

$ eb open env-production

這樣就成功啟動第二組機器了，目前我們有 env-development 和 env-production 兩組環境。

前往 AWS IAM 新增一組帳號給 CircleCI 使用：

1. Dashboard > Users
2. Create New Users
3. Enter User Names: CircleCI > Create
4. Download Credentials
5. Dashboard > Users > CircleCI
6. Attach Pollcy
7. AWSElasticBeanstalkFullAccess > Attach Pollcy

前往 CircleCI，設定您的 AWS 權限：

1. Project Settings
2. Permissions > AWS Permissions
3. 打開剛才下載的 credentials.csv，輸入 Access Key ID & Secret Access Key
4. Save AWS keys
5. 在 .elasticbeanstalk 目錄底下，建立 config.global.yml：

# .elasticbeanstalk/config.global.yml
global:
  application_name: hello-ci-workflow
  default_region: us-west-2 # EB 所在的 region，預設是 us-west-2

1. 修改 circle.yml：

# circle.yml
machine:
  # 安裝 eb 需要 python
  python:
    version: 2.7
  services:
    - docker

dependencies:
  pre:
    # 安裝 eb
    - sudo pip install awsebcli
  override:
    - docker build -t hello-ci-workflow .

test:
  override:
    - npm test
    - docker run -d -p 3000:3000 hello-ci-workflow; sleep 10
    - curl --retry 10 --retry-delay 5 -v http://localhost:3000

# 新增一筆部署腳本
deployment:
  production:
    branch: master
    commands:
      - eb deploy env-production

這樣就能在 GitHub 的 master 支線有更新時，觸發 CircleCI 的自動建置、測試、然後部署。

1. 接下來馬上來試試看流程，修改 index.js：

// index.js
// ...
app.get('/', function (req, res) {
  res.send('Hello env-production!');
});
// ...

1. Commit & Push：

$ git add .
$ git cimmit "test deploy production"
$ git push

1. 前往 CircleCI 看結果：

1. 部署成功，eb open 打開瀏覽器來看看結果：

$ eb open env-production

Slack

帳號：

• Slack

到這邊其實已經差不多結束了，最後來講講 Slack 吧。

Slack 是一款給團隊使用的即時溝通工具，類似的產品還有 Gitter 與 HipChat。

至於跟 Skype、Lync 這些軟體有什麼不一樣的地方呢？

它們整合了許多開發工具（GitHub、CircleCI）的服務，例如 GitHub 有新的 push、pull request、issue；CircleCI 的單元測試沒有通過之類的通知，會即時出現在你的團隊的 Slack 上面，既然我們已經將大部分的工作自動化，勢必需要讓相關人員知道這些工具發生了哪些事情，所以使用 Slack 是必要的。

1. 登入 Slack 頁面
2. 點選 Configure Integrations > CircleCI

1. 選擇要接收 CircleCI 通知的 channel
2. 點選 Add CircleCI Integration 按鈕
3. 複製畫面上的 webhook URL

1. 返回 CircleCI
2. 點選 Project settings > Chat Notifications
3. 貼上將複製的 Webhook URL > Save

1. 類似的步驟，將 GitHub 的通知加入 Slack：

1. 測試 Slack 通知，是否能夠順利運作，新增一條 test-slack 分支：

$ git branch test-slack
$ git checkout test-slack

1. 修改 index.js：

// index.js
// ...
app.get('/', function (req, res) {
  res.send('Hello Slack!');
});
// ...

1. Commit & Push：

$ git add index.js
$ git commit -m "index.js: update to test slack"
$ git push -u origin test-slack

1. CircleCI 通過測試，開啟一個 Pull Request
2. 將 test-slack merge 回 master，觸發 CircleCI 自動部署

That’s it! On your next build, you’ll start seeing CircleCI build notifications in your Slack chatroom.

結束！可以看見 Slack channel 會顯示每一個步驟的通知過程：

eb open 打開瀏覽器查看結果，成功自動部署新版本：

$ eb open env-production

結語

「書山有路勤為徑，學海無涯苦作舟。」——韓愈

DevOps 的開發流程與工具每天都在不斷推陳出新，請站在巨人的肩膀上、保持一顆「活到老、學到老」的心。

我將這個範例的程式碼放在 GitHub 上，有興趣的人可以參考看看。

文章若有需要改進的地方，還請不吝指教，感激不盡。

參考

• DevOps – Wikipedia [中文]
• Continuous integration（持續整合）- Wikipedia [中文]
• Continuous delivery（持續交付）- Wikipedia
• 山姆鍋對持續整合、持續部署、持續交付的定義
• Integrate CircleCI with GitHub
• Understanding the GitHub Flow · GitHub Guides
• Dockerizing a Node.js Web App
• Integration with Docker Containers – CircleCI
• Continuous Integration and Delivery with Docker
• Getting Started with EB CLI 3.x
• Slack Integration | The Circle Blog
• Docker in Action – Fitter, Happier, More Productive [中文]
• CircleCIからAWS Elastic Beanstalkにpush
• Delivery pipeline and zero downtime release
• Re-Blog: CI & CD With Docker, Beanstalk, CircleCI, Slack, & Gantree
• Node With Docker – Continuous Integration and Delivery
• 深入浅出Docker（四）：Docker的集成测试部署之道

使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成持續整合與持續交付的開發流程，首发于服务器安全维护工作室。