Jenkins + AWS CodeDeploy + AutoScaling 持续集成

本文主要记录如何结合jenkins,codedeploy,s3, 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组内的实例获取的都是最新的部署包.