1     构建混合云的关键技术点

1.1   网络连接

第一点，公有云具备用户自定义网络的能力。这里自定义网络泛指云上的私有网络，Amazon VPC允许企业用户在AWS云上自定义逻辑隔离的专用网络的能力，包括允许用户可以自行划分子网、配置路由，设置公网、VPN网关等基础能力。

第二点，多样、稳定的网络接入能力。混合云最突出的特点就是连接，连接方式主要分为两种：公网接入和专线接入。

为保护用户的信息安全，公网接入在Internet上的流量通常需要经过IPsec VPN加密，AWS提供了托管VPN服务和用户自建VPN两种方式，如果采用用户自建方式，一般小型VPN网关（200Mbps以下）可以通过虚拟软件VPN网关实现，中或大型VPN网关（300Mbps及以上）可通过硬件VPN网关设备实现。VPN部署一般半天即可完成，可以快速满足企业用户需求。

AWS Direct Connect（简称DX专线）为企业上云提供了专线接入能力，能够全时段、全方位的保障用户数据传输隔离加密，并保证可用网络带宽，用户无需担心容量太大而无法承载的问题。

示图1：AWS DX专线与VPN混合组网示意图

1.2   安全与监控

混合云在网络层面上将私有云和公有云进行了连接，如果发生网络故障或者攻击，需要有能力保障网络间故障不会相互影响，将攻击或者故障限制在一定范围之内。云上的网络环境需要具备灵活、易配置的网络安全访问控制能力。Amazon VPC提供了有状态的EC2实例级别的网络防火墙功能（安全组），还则提供了无状态的子网级别的网络访问控制（网络ACL）。

监控方面，Amazon VPC 提供了流日志（flow log）功能，可以利用此项功能来捕获传入和传出的网络IP流量信息。流日志数据使用 Amazon CloudWatch Logs 存储，创建流日志后，用户可以在 Amazon CloudWatch Logs 中监控和查看其VPC网络的流量传入和传出状态，并可通过CloudWatch预设告警策略以及时反馈网络异常。VPC流日志还可以帮助用户排查网络故障等问题，比如流量为什么没有进入到EC2实例的原因。另外，针对VPC流日志的分析，可以帮助检查AWS云上的网络安全设置，消除网络安全漏洞。

1.3   统一服务，混合云管理平台

云管理平台的定义是Gartner提出来的，总结起来就是两块，第一是管理，管理公有云、私有云，形成混合云。第二是自服务，镜像划分，计量与计费，以及基于策略的负载优化。云管理平台最终的目标是应用在云平台上运行时取得最优化的效果。

企业用户构建混合云平台之后，首先需要解决的就是服务门户的统一，资源状态监控界面的统一，在一个平台上实现本地数据中心（或私有云）和公有云资源的统一申请、统一审批、统一监控、统一计费。这样能够大幅度降低用户跨平台切换带来的复杂运维工作量，让用户跨平台的资源使用与监控更加方便。

示图2：混合云管理平台（CMP）功能示例图

2     常见的混合云应用场景

2.1   利用AWS公有云应对业务的爆发式增长

大多数互联网业务呈指数型增长，很难预测基础设施的储备量。一般在业务成长初期很长一段时间内，小规模的物理机托管可以满足用户需求。但随着市场推广活动展开，业务规模爆发增长，原物理托管机房可部署机位有限，只能选择公有云作为弹性手段，快速部署业务，满足用户需求。

今天已经有越来越多的企业用户将他们的互联网业务系统，诸如电子商务系统、Web网站、移动端产品和信息订阅服务系统迁移到AWS云上。应对业务规模爆发增长的用户需求，AWS云服务采用多种方式确保应用系统的可靠性和稳定性，作为最基础的云服务，Amazon EC2提供了大小可调的计算容量，用户可以根据自己的实际需求，完全控制所需的计算资源。配合AWS的Auto Scaling功能，用户可以按照事先设定的条件自动扩展Amazon EC2容量，确保所使用的Amazon EC2数量在需求峰值期间实现无缝增长以保持性能，同时也可以在需求平淡期间自动减少Amazon EC2数量以降低成本。此外，Elastic Load Balancing可以在多个Amazon EC2实例之间自动分配应用程序的访问流量，也可以检测出系统中不健康的实例并自动更改路由，将应用的访问流量导向健康的实例。通过不同功能云服务之间的组合，AWS云平台可以确保应用系统的高可靠性和稳定性。

示图3：混合云架构下的电商平台三层系统架构图

与早期基于传统数据中心的系统相比，依托AWS云平台的新系统在稳定性、可靠性和响应速度等方面都有了极大的提升，同时大幅度降低了固定资产投资(CAPEX)和运营成本（OPEX）。在传统数据中心模式下，用一台服务器的寿命大约为5年来计算，购入一台与Amazon EC2 c3.4xlarge机型（16 vCPU,30 GB 内存）配置对应的物理服务器，加上网络和托管费用， 核算出5年的总费用；如果按这个需求迁移到AWS云平台后，企业用户在总费用上可以节省20%。

使用AWS云服务也大幅度降低了用户的运营成本。在传统数据中心模式，企业用户的运维团队工作任务繁重，需要做很多简单、重复的工作，比如服务器的上下架、系统重装、硬件检修等。采用AWS云服务之后，运维人员可以把主要精力放在研究和部署更好的技术架构和方案上，提升了工作效率，减少了人力投入，运维人员的人力成本可以节省一半左右。

2.2   利用AWS公有云实现多地容灾的高可用架构部署

与前一类用户不一样，很多企业用户已经具有很大规模，在本地数据中心或运营商机房中运行大量服务器，他们的核心问题不再是担心基础设施部署速度无法满足业务增长，更多的是从稳定性、可靠性等寻求从单中心向多中心化发展，通过消灭单点，解决单数据中心故障带来的业务风险。

根据业务可靠性要求不同，一般多地容灾常见的采用方式有同城容灾、异地双活、两地三中心等。按照传统建设模式，用户只能重新选址并租赁数据中心，发起服务器、网络设备采购，部署网络环境等，中间涉及到一系列的商务沟通、基础设施建设等操作，周期往往从6个月到1年不等。而在公有云蓬勃发展的今天，他们可以不必担心此类问题，直接注册个账号，购买服务器，拉个专线，基础架构就搞定了。

AWS的混合云容灾架构，就是在AWS的云环境中实现“两地三中心”，同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。AWS云资源池通过软件定义的方式，能够打造与企业内部完全相同的复杂IT环境，实现企业级应用的完整镜像。

成立于2005年的IGG，是全球领先的手机游戏开发商及运营商，为全球游戏玩家提供游戏和相关服务。为了给玩家提供最佳的用户体验，IGG需要在全球多个区域部署服务器。在使用AWS云服务之前，IGG拥有自建的机房，同时也采用多家公司的主机租用服务。随着业务的快速发展，原有的服务部署模式开始面临多方面的挑战，主要体现在三个方面：其一是服务器资源管理不方便、扩展性和灵活性受限制，当访问峰值来临时，部署新服务器的周期较长，而当某款游戏的访问量暂时降低时，又会造成已有服务器资源的浪费；其二是开发和运营新游戏时难以控制成本，因为对游戏运营公司来说，一款游戏是否成功受很多因素的影响，但在运营每一款新游戏时都需要投入大量的IT资源，万一不成功，则会浪费已购置的服务器资源；其三是如何建立双活的灾备系统以确保在任何情况下都能为全球玩家提供持续可靠的服务。

为了应对这些挑战，IGG开始考虑采用公有云服务作为自有数据中心（下面简称：自有IDC）的补充。经过考察、分析和对比，IGG决定采用AWS云服务，并从几年前开始尝试使用AWS在新加坡、法兰克福、日本、美国等可用区的云服务部署海外游戏节点。2016年8月，为了提升整个游戏运营系统的稳定性和可靠性，IGG决定为其位于北加州的核心业务系统建立双活灾备系统。使用AWS云服务给IGG带来的最大好处是用较低的成本建立起远程的双活灾备中心，实现了核心业务异地实时同步备份，在主机房出现故障时能快速切换到云端，保证服务的连续性。整个灾备系统完全满足IGG的业务需求：RTO不超过30分钟、RPO为0，增强了IGG游戏运营系统的稳定性和可靠性。除此之外，使用AWS云服务也节省了灾备系统的成本，因为利用AWS云服务建立双活灾备系统时并不需要1:1的资源配置，这点相比传统的本地灾备具有极大的性价比优势。

示图4: 基于AWS云服务的IGG双活灾备中心

AWS混合云容灾架构的用户价值: 从容灾系统的TCO上看，AWS混合云容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装，省去了大量前提投入成本。更重要的是，容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源，对于不开机的资源将完全不收取EC2虚拟机资源的费用，又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算，一个典型的容灾系统项目，以5年为周期进行计算，TCO只需花费原有私有云容灾环境的1/3，而第一年的投入资金更是传统项目的1/10。

另外，随着应用容灾系统迁移至AWS云中，可以将企业现有的容灾中心转变成生产中心，从而扩大客户自建数据中心的承载能力，或大幅降低IT资源的运营成本，享受更多AWS云带来的好处。下图从AWS混合云容灾开始，到容灾切换，到生产系统平滑上云的进阶演进图：

 示图5：AWS混合云容灾，到容灾切换，到生产系统平滑上云的进阶演进图

2.3   利用AWS公有云实现混合云备份

将数据备份到云端的好处显而易见：管理和操作更加便捷，无需搭建IT备份系统架构、将一次性大额支付变为每月或每年的按需付费，进而减少企业对IT资源的投入等等。现在越来越多的企业客户更倾向于通过其现有的备份软件或云网关，将其现有的备份体系架构扩展到云上。这样做的好处可以用云备份替换离线磁带，大大降低本地存储的资源开销，利用云端完成备份工作，更具性价比。

AWS Storage Gateway （又称“AWS存储网关”，架构图见示图6）是AWS提供的一种混合云存储服务，企业本地数据中心的内部应用程序可以借助它来无缝地使用 AWS 云上的存储资源（如S3，Glacier等），AWS存储网关可以帮助企业用户实现本地数据中心向AWS云端进行备份、存档、灾难恢复、云突增、分级存储分层和迁移。并具有无缝集成能力，企业应用程序或备份工具可以使用 NFS、iSCSI 等标准存储协议通过本地存储网关镜像设备连接到AWS云端的该存储网关，同时存储网关连接 Amazon S3、Amazon Glacier、Amazon EBS 等 AWS 存储服务，可实现文件、卷和虚拟磁带的存储或备份。

示图6：AWS存储网关服务架构示意图（Gateway-Cached Volume）

AWS存储网关具有高度优化的数据传输机制，能够进行带宽管理、自动实现网络弹性、高效传输数据，并为活动数据的低延迟本地访问提供本地缓存。

当然从企业用户的混合云备份需求角度，通常需要考虑：

• 如何实现对于虚拟机和物理机进行统一管理?
• 如何缩短备份时间?
• 如何快速恢复? 能否恢复到任何环境（如物理机,虚拟机,云中的虚拟机） ?
• 能否确保备份与恢复数据的完整性及安全性?
• 如何实现冷热数据的分级存储，降低云上的存储成本？
• 如何避免重复备份数据?

目前已经有很多国内外备份服务厂商基于AWS存储网关构建了一体化AWS混合云备份方案，利用AWS云存储资源便宜的特点帮助企业用户实现AWS云端备份，而且方案能很好的满足前述提到用户对混合云备份的要求。下图为国内某备份服务厂商基于AWS存储网关的混合云备份解决方案。

示图7：国内某备份服务厂商基于AWS存储网关的混合云备份解决方案

该备份服务厂商的AWS混合云备份解决方案具有如下优势和技术特点：

• 操作简便：提供功能丰富，操作简便的用户界面，支持手工备份、时间计划、多任务多计划、备份状态监控、版本管理、恢复操作、并提供一键式故障转移切换功能。
• 块级别全局重复删除数据：基于源端的重复数据删除技术，相同数据块仅发送和存储一次，可以减少备份时间80%以上，这不仅带来效率的提高、带宽、存储空间的节约；还保证窄带宽条件下大数据异地灾备。
• 瞬间恢复：通过Snapshot技术，保证备份期间不需要关闭应用，定时对发生变更的数据块进行标记并实施迁移 （最小支持一分钟），在下一个备份时间点只检索被标记的数据块，这不仅节省磁盘IO，并且能够瞬间恢复数据。
• 冷热数据分级存储功能：充份利用Amazon S3提供的生命周期管理策略的功能，用户通过简单的策略制定就可以自动化实现冷热数据的分级存储，冷数据自动归档存储到更便宜的Amazon Glacier上，既实现了用户长期归档的需求，还可以大幅降低云上的存储成本。
• 支持Windows/Linux/Unix等多种环境的网络集中备份，同时支持多种应用服务类型，如各种常见的应用服务器、数据库（如MySQL、SQL Server、Oracle、Sybase、DB2）、 Domino、AD、Exchange、File server等等。
• 三重数据安全：

1. 硬盘锁：数据与设备进行绑定，数据只能恢复到原有硬件
2. 无规则存放：数据以无规则的块存储，避免坚守自盗
3. 通信与数据加密：私有通信协议,可选AES数据加密

• 异地灾备与恢复: 备份到异地云计算中心，支持恢复到本地物理机、虚拟机、AWS云上虚拟机等多种不同平台，当本地数据中心出现物理故障时，这种异地恢复机制既可以满足企业用户异地灾备恢复的需求，还可以实现数据异地使用的业务价值。
• 传输优化：经优化的灾难恢复和复制，几分钟内返回到联机状态。

AWS之旅：混合云构建及常见的应用场景，首发于服务器安全维护工作室。

通过本文章，您将了解如何通过AWS CodePipeline，AWS CodeBuild，AWS CloudFormation 来实现基于Amazon ECS的持续集成持续部署方案。

开发人员在GitHub中提交的新版本代码，会自动触发代码获取，打包镜像，上传镜像仓库，更新新版本容器服务，注册到负载均衡器等操作。

方案中会涉及使用如下组件：

GitHub：示例使用的源，一个提交到GitHub上的PHP示例网站。AWS CodePipeline支持GitHub， AWS CodeCommit服务，或者S3作为源。此次实例使用的Demo软件工程可以从以下链接Fork：

https://github.com/awslabs/ecs-demo-php-simple-app

Docker：作为发布服务使用的容器。演示方案的Build阶段会使用AWS CodeBuild托管的ubuntu／docker 1.12.1基础镜像。

Amazon EC2：作为ECS的容器宿主机集群。

Amazon VPC：服务所在的网络。

Amazon ECS：AWS托管的容器编排服务。文档链接 http://docs.aws.amazon.com/zh_cn/AmazonECS/latest/developerguide/Welcome.html

Amazon ECR：AWS 托管的容器镜像仓库。文档链接 http://docs.aws.amazon.com/zh_cn/AmazonECR/latest/userguide/what-is-ecr.html

AWS CodePipeline：AWS 托管的持续集成持续交付服务，可以快速可靠的更新应用程序和服务，集成支持GitHub，Jenkins等主流开源工具。文档链接 http://docs.aws.amazon.com/zh_cn/codepipeline/latest/userguide/welcome.html

AWS CodeBuild：AWS 托管的构建服务，用于打包代码生成可部署的软件包。文档链接 http://docs.aws.amazon.com/zh_cn/codebuild/latest/userguide/welcome.html

AWS CloudFormation：批量创建和管理AWS资源的自动化脚本。文档链接http://docs.aws.amazon.com/zh_cn/AWSCloudFormation/latest/UserGuide/Welcome.html

2.方案架构

流程如下：

1. 开发者将一个新版本的代码工程提交到GitHub
2. Pipeline的Source阶段，检测到指定GitHub的repo有新版本的更新，从GitHub上拉取代码工程，开启已设定好的CICD Pipeline
3. Pipeline的Build阶段，AWS CodeBuild将新版本的代码工程打包为Docker镜像
4. AWS CodeBuild将打包好的镜像推送到Amazon ECR
5. Pipeline的Deploy阶段，AWS CodePipeline触发AWS CloudFormation，其定义了Amazon ECS的Task definition和service
6. AWS CloudFormation创建新版本的Task definition关联到新版本的Docker镜像，并更新Service
7. Amazon ECS从Amazon ECR中取到新版本的Docker镜像，并运行来替换旧Task以完成服务的更新部署

3. 搭建

搭建部分分为以下几个步骤：基础设施，与CICD Pipeline的搭建。

3.1   基础设施部分的搭建

这里需要准备好网络，负载均衡器，S3以及运行ECS所需要的宿主机集群。

3.1.1 网络搭建

创建VPC，子网，Internet Gateway，路由表。将Internet Gateway Attach到VPC上，路由表配置0.0.0.0/0指向Internet Gateway，并关联子网。

之后的EC2宿主机集群，负载均衡器等都使用在这个网络里。

3.1.2 负载均衡器

创建ALB应用负载均衡器，监听80端口

选择对应的子网

新建安全组，端口80，并新建目标组

注册目标此时不选择，ECS创建服务时会注册集群和对应端口进来。

下一步审核后创建。

3.1.3 ECS宿主机集群

在ECS的界面下，创建集群

实例配置保持默认或根据情况自行选择，示例中保持默认。

联网配置，选择创建好的VPC，子网，创建Role允许宿主机上的ECS代理调用ECS服务的API。

创建后画面下面会显示集群信息

集群一览会显示

修改ECS宿主机集群的安全组，inbound源设置为建好的应用负载均衡器的安全组ID

3.1.4 ECR镜像仓库创建

创建一个用于Build阶段上传存放软件工程Docker镜像的镜像仓库

ECS界面下，创建存储库，创建好后如下

3.1.5 S3桶创建

创建一个S3桶用来存放Deploy阶段CloudFormation使用的脚本模版，创建桶时选择和以上服务同一Region，并且打开桶的版本控制。

将CloudFormation模版压缩zip后上传到桶中。

示例中将模版文件service.yaml放在templates文件夹后压缩为templates.zip。

service.yaml如下，注意缩进

Parameters:

  Tag:

    Type: String

    Default: latest


  DesiredCount:

    Type: Number

    Default: 0


  TargetGroup:

    Type: String


  Cluster:

    Type: String


  Repository:

    Type: String


Resources:

  ECSServiceRole:

    Type: AWS::IAM::Role

    Properties:

      Path: /

      AssumeRolePolicyDocument: |

        {

            "Statement": [{

                "Effect": "Allow",

                "Principal": { "Service": [ "ecs.amazonaws.com" ]},

                "Action": [ "sts:AssumeRole" ]

            }]

        }

      Policies:

        - PolicyName: root

          PolicyDocument:

            Version: 2012-10-17

            Statement:

              - Resource: "*"

                Effect: Allow

                Action:

                  - ec2:*

                  - elasticloadbalancing:*


  Service:

    Type: AWS::ECS::Service

    Properties:

      Cluster: !Ref Cluster

      Role: !Ref ECSServiceRole

      DesiredCount: !Ref DesiredCount

      TaskDefinition: !Ref TaskDefinition

      LoadBalancers:

        - ContainerName: simple-app

          ContainerPort: 80

          TargetGroupArn: !Ref TargetGroup


  TaskDefinition:

    Type: AWS::ECS::TaskDefinition

    Properties:

      Family: !Sub ${AWS::StackName}-simple-app

      ContainerDefinitions:

        - Name: simple-app

          Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${Repository}:${Tag}

          EntryPoint:

            - /usr/sbin/apache2

            - -D

            - FOREGROUND

          Essential: true

          Memory: 128

          MountPoints:

            - SourceVolume: my-vol

              ContainerPath: /var/www/my-vol

          PortMappings:

            - ContainerPort: 80

          Environment:

            - Name: Tag

              Value: !Ref Tag

        - Name: busybox

          Image: busybox

          EntryPoint:

            - sh

            - -c

          Essential: false

          Memory: 128

          VolumesFrom:

            - SourceContainer: simple-app

          Command:

            - /bin/sh -c "while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"

      Volumes:

        - Name: my-vol

到此基础设施部分的搭建工作结束。

3.2   Pipeline的搭建

分为Source，Build以及Deploy三阶段：

Source阶段设置GitHub上的软件工程位置，并设置Deploy阶段会使用的CloudFormation脚本模版来更新ECS服务，

Build阶段使用AWS CodeBuild来打包软件工程到Docker镜像并上传到ECR，

Deploy阶段使用Source阶段引入的CloudFormation脚本，找到对应的宿主机集群，负载均衡器，以及上传到ECR的Docker镜像等对象，更新服务。

AWS CodePipeline创建后的展示图是这样的，串起了整个CICD流程

在AWS CodePipeline界面点击创建管道Pipeline，可以看到画面左侧一个基本流程，从源，到生成Build，到部署Deploy，到角色等配置。实际应用中用户可以随实际需要，或随着CICD流程的由简入繁在创建后编辑加入新的阶段或操作。

点击下一步。

3.2.1 Source阶段配置

源提供商下拉菜单选择GitHub，

点击连接到GitHub来授权访问权，来允许AWS CodePipeline从GitHub上获取软件工程源内容，认证后选择GitHub上软件工程所在位置和分支

此次实例使用的Demo软件工程可以从以下链接Fork：

https://github.com/awslabs/ecs-demo-php-simple-app

点击下一步。

3.2.2 Build阶段配置

AWS CodePipeline在Build阶段支持包括AWS CodeBuild，Jenkins在内的引擎，此方案选用AWS 托管的CodeBuild服务

选择新建构建项目

选择AWS CodeBuild托管的镜像，支持Ubuntu系统，运行时支持包括Java，Python，Go语言，Node.js，Docker在内的众多选择，此次方案使用Docker。

构建规范这里选择使用buildspec.yml，里面预定了AWS CodeBuild在Build生命周期中要执行的动作，如login到ECR，打包Docker镜像，给Docker镜像打tag，上传Docker镜像到已login的ECR镜像仓库。

Buildspec.yml放在GitHub软件工程源代码目录中，如果复制粘贴的话注意yaml文件的缩进

version: 0.2

phases:

  pre_build:

    commands:

      - $(aws ecr get-login)

      - TAG="$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | head -c 8)"

  build:

    commands:

-    docker build --tag "替换创建好的ECR镜像仓库的URI:${TAG}" .

  post_build:

    commands:

      - docker push "替换创建好的ECR镜像仓库的URI:${TAG}"

      - printf '{"tag":"%s"}' $TAG > build.json

artifacts:

  files: build.json

选择Role

新建一个Role，这个Role允许AWS CodeBuild来调用相关的AWS服务，此方案中需要调用包括S3，ECR，CloudWatch在内的服务。

*默认创建的Role不具备对ECR的权限，需要在保存构建项目后，到IAM找到新创建的Role，编辑添加对ECR的权限否则后面Pipeline执行到Build时会报错。

保存构建项目。

点击下一步。

3.2.3 Deploy

AWS CodePipeline部署阶段支持包括AWS CloudFormation，AWS CodeDeploy，AWS Elastic Beanstalk在内的服务提供商，此方案选用AWS CloudFormation来部署ECS容器服务。

这里暂时选择无部署，等Pipeline创建好后，编辑引入Deploy的CloudFormation模版源，再进行配置。

点击下一步。

3.2.4 角色

配置AWS CodePipeline对AWS服务的调用权限，包括S3，AWS CodeBuild，AWS CloudFormation，IAM等。点击创建角色到IAM界面选择相对应的策略创建。

创建好后画面回到Pipeline，IAM创建好的Role已经显示在里面。

点击下一步。

3.2.5 审核后创建管道。

管道创建好后会自动运行，现有的从GitHub软件工程源代码抓取工程，打包Docker镜像并推送到ECR上。界面上显示如图

3.2.6 添加Deploy阶段CloudFormation需要的模版源以及配置Deploy阶段

点击编辑，点击Source阶段右上角的画笔图标

可以看到AWS CodePipeline的编辑界面在南北纵向和东西横向都可以添加

在GitHub这个Source右侧，点击添加操作，选择源，操作名称Template，选择S3，输入创建好的S3桶的地址

画面往下拉，注意在输出项目这里，输入Template。

Pipeline中各阶段的传递需要制定南北向的输入输出，即Source阶段S3源的输出Template，在Deploy阶段用输入Template来衔接。

点击更新。

点击Build阶段下面的添加阶段，画面右侧选择部署，选择AWS CloudFormation

操作模式选择创建或更新堆栈，输入创建的堆栈名称，模版这里输入Template::templates/service.yaml，也就是对应的输入是S3源桶中templates.zip里的service.yaml文件。功能选择CAPABILITY_NAMED_IAM。

同样需要创建一个Role，允许AWS CloudFormation调用包括IAM，ECS，ECR在内的AWS服务。

在IAM界面创建好后选择Role。

高级这里点开

在参数覆盖这里输入CloudFormation需要传入的参数，其中的固定参数也可以在S3的service.yaml中直接定义。

{

  "Tag" : { "Fn::GetParam" : [ "MyAppBuild", "build.json", "tag" ] },

  "DesiredCount": "2",

  "Cluster": "CICD-DEMO-CLUSTER-01",

  "TargetGroup": "arn:aws:elasticloadbalancing:us-east-2:305890642658:targetgroup/CICD-DEMO-TG-01/b7649674ee8ab97b",

  "Repository": "cicd-demo-ecr-01"

}

Tag是Build阶段传出的Docker镜像Tag使用的值，传入CloudFormation中用于建立Task Definition的Container时从ECR拉取对应版本的Docker镜像。

DesiredCount，即想要在ECS的Service中建立的Task的数量。

Cluster，即建立好的宿主机集群的名称。

TargetGroup，即建立好的宿主机集群的应用负载均衡器的ARN。

Repository，即建立好的ECR的镜像仓库名称。

输入项目这里输入Build阶段和S3模版源的输出。

点击添加操作。

保存管道更改。

4. 运行以及模拟版本更新

4.1   运行

访问负载均衡器的DNS地址来确认目前服务已经运行正常。

4.2   模拟版本更新

4.2.1 修改代码

在开发本地更新代码，示例中在src/index.php加入一行文字

<h1 style="color:FF7F00;">Amazon ECS Awesome!</h1> 4.2.2 提交新版本后查看AWS CodePipeline各阶段触发 

4.2.3 刷新服务来确认新修改的部分已经发布

使用AWS CodePipeline，AWS CodeBuild与AWS CloudFormation实现Amazon ECS上的持续集成持续部署解决方案，首发于服务器安全维护工作室。