Jenkins + AWS CodeDeploy + AutoScaling 持续集成

Aws AutoScaling部分

1、使用Auto Scaling的优点

1)、保持基础设置堆栈配置一致(例如软件nginx、php等安装配置一致)

2)、快速设置扩展(只需要设定Auto Scaling组内的所需实例数量即可完成实例的扩展)

3)、制定明确的扩展策略(比如根据CPU的利用率时增加或是缩减实例数量)

4)、控制实例资源成本(在Auto Scaling组内的实例通常都比较小，不然就失去了AutoScaling自动扩展的意义)

2、Auto Scaling组件说明

Auto Scaling组：EC2实例放在组中，用于扩展和管理的逻辑单元，在创建组时，可以指定其最小，最大和所需EC2的实例数量

(备注：auto Scaling 组是与启动配置相关联的)

Auto Scaling启动配置：EC2实例启动时的模板(指定实例类型，密钥对，安全组和磁盘空间大小)

3、创建启动配置步骤

1)、为EC2实例创建IAM角色

https://console.aws.amazon.com/iam/

2)、为Auto Scaling 创建启动配置(下图为已经设置好的启动配置模板)

3)、为EC2实例启动时添加必要的用户数据(主要为应用程序事先搭建好基础环境)

脚本如下：

#!/bin/bash

#run all command as root,system: ubuntu16.04

#enter /opt/patpat-devops folder

cd /opt/patpat-devops

#download aws codedeploy agent,and start

rm -rf codedeploy-agent

mkdir codedeploy-agent

cd codedeploy-agent

wget https://xxxx.com/latest/install

chmod +x ./install

./install auto

service codedeploy-agent start

service codedeploy-agent status

#backto patpat-devops folder

cd /opt/patpat-devops

#download nginx1.14, not need single start

wget https://xxxx.com/nginx/nginx1.14.tar

tar -xf nginx1.14.tar

mv nginx /usr/local/programs/

#replace /etc/logrotate.d/nginx

/cp -f /usr/local/programs/nginx/logrotate.d/nginx /etc/logrotate.d/nginx

#copy supervisor.d/nginx.conf to supervisor

/cp -f /usr/local/programs/nginx/supervisor.d/nginx.conf /usr/local/programs/supervisor/conf.d/

rm nginx1.14.tar

#download php7,not need single start

wget https://xxxx.com/php/php7.tar

tar -xf php7.tar

mv php7 /usr/local/programs/

#copy supervisor.d/php-fpm.conf to supervisor

/cp -f /usr/local/programs/php7/etc/supervisor.d/php-fpm.conf /usr/local/programs/supervisor/conf.d/

rm php7.tar

#start supervisor,nginx,php,zabbix start server

isExistApp=`pgrep supervisor`

if [ -n  $isExistApp ]; then

    echo "supervisor is activing, will reload"

    #restart server

    /usr/local/bin/supervisorctl reload 

else

    echo "supervisor is not active, will start server"

    #start server

   /usr/local/bin/supervisord -c /usr/local/programs/supervisor/supervisord.conf     

fi

#change nginx log permession

chmod -R 777 /usr/local/programs/nginx/logs

echo "Install finished!"

备注：具体在创建实例的时候在”配置详细信息”选项卡里面进行添加

4)、创建Auto Scaling 组 (下图为已经创建好的Auto Scaling组)

Auto Scaling结合ELB使用

此时aws auto scaling创建完成，随后Auto Scaling会根据给定的按需实例设置启动一台EC2实例

AWS Code Deploy部分

1、CodeDeploy部署的前提条件

需要在Auto Scaling启动配置中的EC2启动模板事先安装好CodeDeploy agent代理

Install or reinstall the aws CodeDeploy agent for Amazon Ubuntu Server

$ sudo apt-get install ruby

$ sudo apt-get install wget

$ cd /home/ubuntu

$ wget https://bucket-name.s3.amazonaws.com/latest/install

$ chmod +x ./install

$ sudo ./install auto

$ sudo service codedeploy-agent status

$ sudo service codedeploy-agent start

$ sudo service codedeploy-agent status

备注：bucket-name 是包含适用于您所在区域的AWS CodeDeploy 资源工具包文件的 Amazon S3sds-s3-latest-bucket-name 存储桶的名称，对于美国东部(俄亥俄)区域，bucket-name 替换为 aws-codedeploy-us-east-2

2、Code Deploy组件

部署：部署一个包括应用程序和AppSpec文件的新修订；AppSpec指定如何将应用程序部署到部署组中的实例

应用程序：部署组和修订的集合；EC2/本地应用程序使用EC2/本地计算平台

修订版：修订版是可部署内容(如源代码、构建后项目、网页、可执行文件和部署脚本以及 AppSpec 文件)的特定版本，AWS CodeDeploy 代理程序可通过 GitHub 或 Amazon S3 存储桶访问修订版

部署组：部署组是用于在CodeDeploy部署中对EC2实例的AWS CodeDeploy实体；它是一组与您以之为目标进行部署的应用程序关联的实例；可以通过指定标签、Auto Scaling组名称或同时指定此二者，将实例添加到部署组中

备注：可以为一个应用程序定义多个部署组，如模拟和生产

部署配置：部署配置为部署组指定如何进行部署的行为，包括如何处理部署故障；可以使用部署配置向多实例部署组执行零停机部署；例如，如果您的应用程序需要部署组中至少有50% 的实例在运行中且提供流量，可以在您的部署配置中指定这一点，从而使部署不会导致停机；如果没有与部署或者部署组相关联的部署配置，则在默认情况下，AWS CodeDeploy将会一次部署到一个实例中

3、AWS CodeDeploy部署类型

就地部署

停止部署组中每个实例上的应用程序，安装最新的应用程序修订版，然后启动和验证应用程序的新版本；您可以使用负载均衡器，以便在部署期间取消注册每个实例，然后在部署完成后让其重新提供服务；只有使用EC2/本地计算平台的部署才能使用就地部署

对部署组中的实例依次执行脱机操作/更新应用/恢复联机的操作，完成滚动部署

蓝绿部署

创建一组新的替换实例，并安装新版本的应用程序。成功后，切换流量到这些新实例，删除旧实例，完成部署；AWS CodeDeploy 运行您在切换流量之前，对新版本应用程序进行测试；如果发现问题，您可以快速回滚到旧版本

EC2/本地计算平台上的蓝/绿部署：部署组中的实例(原始环境)将被不同的实例集(替代环境)所代替，步骤如下：

1)、系统将为替代环境配置实例

2)、替代实例上将安装最新的应用程序修订

3)、对于应用程序测试和系统验证等活动来说，等待时间可选

4)、替代环境中的实例在Elastic Load Balancing负载均衡器中进行注册，使得流量重新路由至这些实例；系统将撤销原始环境中的实例注册，进而终止或因其他使用情形而保持运行

备注：蓝/绿部署只能与Amazon EC2实例配合使用

4、就地部署概述

停止部署组中每个实例上的应用程序，安装最新的应用程序修订版，然后启动和验证应用程序的新版本。您可以使用负载均衡器，以便在部署期间取消注册每个实例，然后在部署完成后让其重新提供服务

1)、在本地开发计算机或类似环境上创建可部署的内容，然后添加application specification file (AppSpec file)；AppSpec file对AWS CodeDeploy是唯一的；它定义了AWS CodeDeploy执行的部署操作；将可部署的内容和AppSpec file捆绑成一个存档文件，然后将其上传到Amazon S3存储桶或GitHub存储库；此存档文件称为应用程序修订(简称修订)

2)、向AWS CodeDeploy提供有关您的部署的信息，例如，要从中提取修订的Amazon S3存储桶或GitHub，以及要将其内容部署到的一组Amazon EC2实例；AWS CodeDeploy将一组Amazon EC2实例称为一个部署组，部署组中包含单独标记的Amazon EC2实例和/或Amazon EC2 Auto Scaling组中的Amazon EC2实例

每次您成功上传要部署到部署组的新应用程序修订时，该捆绑包就会设置为部署组的目标修订；也就是说，当前设为部署目标的应用程序修订为目标修订，这也是将为自动部署提取的修订

3)、每个实例上的CodeDeploy-Agent将轮询 AWS CodeDeploy，以确定从指定的Amazon S3存储桶或GitHub存储库中提取的内容和提取时间

4)、每个实例上的CodeDeploy-Agent将从指定的Amazon S3存储桶或GitHub存储库中提取目标修订，并按照 AppSpec file中的说明向实例部署内容

AWS CodeDeploy将保留您的部署的记录，以便您可以获取部署状态、部署配置参数、实例运行状况

5、蓝/绿部署概述

在蓝/绿部署中将流量从一组实例(原始环境)重新路由到另一组实例(替换环境) ，相比就地部署提供了多种优势：

1)、可以提前在新实例上安装和测试应用程序，并通过直接将流量切换到新服务器来将应用程序部署到生产中

2)、可以更快、更可靠地切换回最近的应用程序版本，因为只要原始实例没有终止，就可以将流量路由回原始实例；而在就地部署中，必须通过重新部署上一个版本的应用程序来回滚版本

3)、如果您使用EC2/本地计算平台，则会为蓝/绿部署预置新实例，并且新实例反映最新的服务器配置；这将帮助您避免在长时间运行的实例上有时出现的问题类型

wiki： https://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-in-place

6、AppSpec 文件

appspec.yml是YAML格式、用于定于CodeDeploy服务在整个阶段所做的操作和文件拷贝路径和权限等。这个文档名称必须是appspec.yml,而且文档中的空格个数也有严格的要求, 参考详细解析 .

如果没有AppSpec file，AWS CodeDeploy无法将应用程序修订中的源文件映射到其目标，也无法为您向EC2/本地计算平台中进行的部署运行脚本

AppSpec 文件是一种配置文件，用于指定待复制文件和待执行脚本；AppSpec文件使用 YAML 格式，它位于您的修订版的根目录下；AppSpec文件为AWS CodeDeploy 代理程序所用，由两个部分组成；文件部分指定了您的版次中待复制的源文件，以及每个实例的目标文件夹；挂接部分指定了在部署各阶段运行的脚本的位置(作为从修订包根下起始的相对路径)；部署的各阶段被称为部署生命周期事件；下面是一个示例 AppSpec文件

appspec.yml示例：

version: 0.0                                      # 固定写法

os: linux

files:                                                 # You can specify one or more mappings in the files section.

  - source: /

    destination: /var/www/html/WordPress

hooks:                                              # The lifecycle hooks sections allows you to specify deployment scripts.

ApplicationStop:                             # Step 1: Stop Apache and MySQL if running.

    - location: helper_scripts/stop_server.sh

BeforeInstall:                                  # Step 2: Install Apache and MySQL.

# You can specify one or more scripts per deployment lifecycle event.

    - location: deploy_hooks/puppet-apply-apache.sh

    - location: deploy_hooks/puppet-apply-mysql.sh

AfterInstall:

    - location: deploy_hooks /change_permissions.sh              # Step 3: Set permissions.

      timeout: 30

      runas: root

    - location: helper_scripts/start_server.sh                             # Step 4: Start the server.

      timeout: 30

      runas: root

appspec.yml生产环境示例：

version: 0.0                                        # AppSpec file的版本；允许的唯一值为0.0

os: linux                                             # 指定部署到的实例的操作系统值(linux、windows)

files:                                                   # 定义文件映射关系

  - source: /                                        # 表示本版本包的全部文件和目录(相对路径，从修订的根目录开始)

    destination: /var/www/alpha-website_desktop/       # 被部署服务器的完整路径

hooks:                                               # 定义CodeDeploy各阶段执行的操作

  BeforeInstall:                                  # CodeDeploy部署之前

    - location: codedeploy-scripts/install_dependencies    # 运行的软件包依赖脚本

      timeout: 300                               # 安装超时时间

      runas: root                                 # 以什么用户进行软件安装

  AfterInstall:                                    # CodeDeploy部署之后

    - location: codedeploy-scripts/change_applications_configure

    - location: codedeploy-scripts/change_permissions

      timeout: 300

      runas: root

  ApplicationStart:                           # 应用启动

    - location: codedeploy-scripts/start_server

      timeout: 300

      runas: root

  ApplicationStop:                           # 应用停止

    - location: codedeploy-scripts/stop_server

      timeout: 300

      runas: root

appspec.yml部署生命周期：

部署生命周期说明

部署会经过一组预定义阶段，称为部署生命周期事件。部署生命周期事件可让您将代码作为部署的一部分运行

下表以执行顺序列出了目前支持的各种不同的部署生命周期事件，以及您可能想使用它们的时间示例

In-place deployments(就地部署)

Blue/green deployments(蓝绿部署生命周期)

蓝绿部署流量切换过程

CodeDeploy部署方式：

CodeDeploy与AutoScaling集成原理 https://aws.amazon.com/cn/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/

使用Auto Scaling配置CodeDeploy

使用Auto Scaling配置CodeDeploy非常简单。只需转到AWS CodeDeploy控制台，然后在部署组配置中指定Auto Scaling组名称

此外，还需要：

1、在Auto Scaling实例上安装CodeDeploy代理。您可以将代理程序作为基本AMI的一部分进行烘焙，也可以在启动期间使用用户数据来安装代理程序

2、确保CodeDeploy用于与Auto Scaling交互的服务角色具有正确的权限

###Auto Scaling Lifecycle Hook####

事件中的Auto Scaling和CodeDeploy之间的通信基于Auto Scaling生命周期挂钩；建议不要尝试手动设置或修改这些挂钩，因为CodeDeploy可以为您执行此操作；Auto Scaling生命周期挂钩告诉Auto Scaling在实例即将更改为某些Auto Scaling生命周期状态时发送通知；CodeDeploy仅侦听有关已启动且即将放入InService的实例的通知；此状态发生在EC2实例完成引导之后，但在它被放置到您已配置的任何Elastic Load Balancing负载平衡器之后；Auto Scaling在继续处理实例之前等待CodeDeploy的成功响应

挂钩是Auto Scaling组配置的一部分；您可以使用describe-lifecycle-hooks CLI命令查看Auto Scaling组上安装的挂钩列表；创建或修改部署组以包含Auto Scaling组时，CodeDeploy将执行以下操作：

1)、使用传入的CodeDeploy服务角色与部署组一起使用以获取Auto Scaling组的权限

2)、在Auto Scaling组中安装生命周期挂钩，用于实例启动，将通知发送到CodeDeploy拥有的队列

3)、将已安装的挂钩的记录添加到部署组

从部署组中删除Auto Scaling组或删除部署组时，CodeDeploy将执行以下操作：

1)、使用部署组的服务角色来访问Auto Scaling组

2)、获取部署组中记录的挂钩，并将其从Auto Scaling挂钩中删除

3)、如果正在修改(未删除)部署组，请从部署组中删除该挂钩的记录

如果创建钩子有问题，CodeDeploy将尝试回滚更改；如果删除钩子有问题，CodeDeploy将在API响应中返回不成功的钩子删除并继续

以下是Auto Scaling scale-in事件期间发生的事件序列：

1、Auto Scaling要求EC2提供新实例

2、EC2使用Auto Scaling提供的配置旋转新实例

3、Auto Scaling查看新实例，将其置于Pending：Wait状态，并将通知发送到Code Deploy

4、CodeDeploy从Auto Scaling接收实例启动通知

5、CodeDeploy验证实例和部署组的配置

1)、如果通知看起来正确，但部署组不再包含Auto Scaling组(或者我们可以确定先前已删除部署组)，则CodeDeploy将不会部署任何内容，并通过实例启动将Auto Scaling告知CONTINUE；Auto Scaling将尊重实例启动时的任何其他约束; 如果出现其他问题，此步骤不会强制Auto Scaling继续

2)、如果CodeDeploy无法处理消息(例如，如果存储的服务角色未授予适当的权限)，则CodeDeploy将使挂钩超时；CodeDeploy的默认超时为10分钟

6、CodeDeploy为实例创建新部署以部署部署组的目标修订；(目标修订版是部署组的最后一个成功部署的修订版；它由CodeDeploy维护)；您需要至少部署到部署组一次，以便CodeDeploy识别目标修订版；您可以使用get-deployment-group CLI命令或CodeDeploy控制台获取部署组的目标修订

1)、部署正在运行时，它会将心跳发送到Auto Scaling，让它知道该实例仍在处理中

2)、如果部署出现问题，CodeDeploy将立即告知Auto Scaling ABANDON实例启动。Auto Scaling终止实例并使用新实例重新启动该过程

最佳实践

1)、设置或修改Auto Scaling生命周期挂钩 -不要手动设置或修改Auto Scaling挂钩，因为配置错误可能会破坏CodeDeploy集成(备注：在CodeDeploy中配置添加AutoScaling组，生命周期挂钩就已经建立)

2)、注意部署失败 - 当部署到新实例失败时，CodeDeploy会将实例标记为终止；Auto Scaling将终止实例，启动新实例，并通知CodeDeploy以启动部署；当你有暂时的错误时，这很好。但是，缺点是如果您的目标修订版存在问题(例如，如果部署脚本中存在错误)，则启动和终止实例的此循环可以进入循环；我们建议您密切监视部署并设置Auto Scaling 通知，以跟踪Auto Scaling启动和终止的EC2实例

3)、Auto Scaling部署疑难解答-对涉及Auto Scaling组的部署进行故障排除可能具有挑战性；如果部署失败，我们建议您取消Auto Scaling组与部署组的关联，以防止Auto Scaling不断启动和终止EC2实例。接下来，将使用相同基本AMI启动的标记EC2实例添加到部署组，将目标修订部署到该EC2实例，并使用该实例对脚本进行故障排除。如果您有信心，请将部署组与Auto Scaling组关联，将黄金版本部署到Auto Scaling组，扩展新的EC2实例（通过调整Min，Max和Desired（）），并验证部署是否成功

4)、订购启动脚本的执行 - CodeDeploy代理在启动时立即查找并执行部署；部署执行和启动脚本(如用户数据，cfn-init等)之间没有排序；我们建议您将启动脚本作为启动脚本的一部分(也可能是最后一步)安装，以便您可以确定在实例安装了不属于CodeDeploy部署的依赖项之前，不会执行部署；如果您希望将代理程序烘焙到基本AMI中，我们建议您将代理程序服务保持在停止状态，并使用启动脚本启动代理程序服务

5)、将多个部署组与同一Auto Scaling组关联 - 通常，应避免将多个部署组与同一Auto Scaling组关联；当Auto Scaling使用与多个部署组关联的多个挂钩扩展实例时，它会同时发送所有挂钩的通知；因此，将创建多个CodeDeploy部署；这有几个缺点。这些部署是并行执行的，因此您将无法依赖它们之间的任何顺序；如果任何部署失败，Auto Scaling将立即终止实例；当实例关闭时，正在运行的其他部署将开始失败，但它们可能需要一个小时才能完成；Host Agent一次只处理一个部署命令，因此您还需要考虑两个限制；第一，其中一个部署可能会因为时间过长而失败；例如，如果部署中的步骤需要五分钟以上才能完成，则可能会发生这种情况；其次，部署之间没有先发制人，因此无法在一个部署与另一个部署之间强制执行步骤排序；因此，我们建议您最小化与Auto Scaling组关联的部署组的数量，并将部署合并到单个部署中

Jenkins+Git+CodeDeploy持续集成

参考官方教程: https://aws.amazon.com/cn/blogs/china/aws-devops-jenkins-and-codedeploy/

需要Jenkins安装codedeploy插件，插件截图：

Jenkins关于项目配置目录规则

project-configure/

├── geodata

│   └── geoip.mmdb

├── xxxx                                                                               # 公司名称

│   ├── alpha                                                                           # alpha环境

│   │   ├── xxxx-alpha-website_api                                    # 具体的项目名称

│   │   │   ├── codedeploy                                                      # CodeDeploy目录存放codedeploy必须的appspec.yml和脚本文件夹

│   │   │   │   ├── appspec.yml                                               # 用于定义CodeDeploy服务在整个阶段做的操作和文件拷贝路径和权限等

│   │   │   │   └── codedeploy-scripts                                   # CodeDeploy中脚本执行所在文件夹

│   │   │   │       ├── change_applications_configure          # CodeDeploy部署完成后，配置文件拷贝，服务重启操作

│   │   │   │       ├── change_permissions                            # codedeploy部署完成后，相关目录权限变更等设置

│   │   │   │       ├── install_dependencies                           # codedeploy部署前系统软件包依赖关系安装

│   │   │   │       ├── start_server                                           # 启动服务脚本

│   │   │   │       └── stop_server                                           # 停止服务脚本

│   │   │   ├── project-conf.d                                                # 项目中的.env配置文件目录

│   │   │   └── server-applications                                       # 软件(nginx，php)应用程序配置文件存放文件夹

│   │   │       └── nginx

│   │   │           └── conf.d

│   │   │               └── xxxx-alpha-website_api.conf            

│   ├── production                                                                # 线上生产环境

│   │   ├── xxxx-api

│   │   │   ├── codedeploy

│   │   │   │   ├── appspec.yml

│   │   │   │   └── codedeploy-scripts

│   │   │   │       ├── change_applications_configure

│   │   │   │       ├── change_permissions

│   │   │   │       ├── install_dependencies

│   │   │   │       ├── start_server

│   │   │   │       └── stop_server

│   │   │   ├── project-conf.d

│   │   │   └── server-applications

│   │   │       └── aws-kinesis-agent

│   │   │           └── agent.json

│   └── test                                                                           # 测试环境

└── README                                                                       # CodeDeploy目录说明

相关目录说明：

目录层级：

平台/环境/项目

目前只有patpat和ace平台，环境有production、test、alpha

项目目录包含项目配置，codedeploy配置，服务器端配置，每个项目配置下面分别有下面三个目录：

codedeploy/

project-conf.d/

server-applications/

说明：

1. codedeploy目录存放codedeploy必须的appspec.yml和scripts脚本文件

2. project-conf.d目录存放项目参数配置文件，例如.env

3. server-applications目录存放目标服务器上的nginx，php，kinesis-agent等应用程序配置，需要结合上面的codedeploy使用

务必严格按照此格式配置，每次修改配置后需要重新在jenkins上构建发布！

AWS codedeploy采取蓝绿部署，无状态部署，所以每次修改配置后需要重新构建启动新机器

构建截图

Jenkins与codedeploy结合部署文件上传至指定的S3存储桶

发布流程

Jenkins主要实现将构建好的部署包上传至s3存储桶，事先在EC2实例上的CodeDeploy-Agent在轮询过程中发现s3存储桶上有新的修订版(jenkins部署上传到S3的压缩包)时，获取存储桶的新的修订版并解压，CodeDeploy根据新的修订版里的appspec.yml对EC2实例进行自动部署，这样保证每次在同一个CodeDeploy组内的实例获取的都是最新的部署包