基于AWS CodePipeline全自动化蓝绿部署发布Web应用实践

一 背景

随着近年DevOps文化的广泛推广,更快的软件交付速度成为许多技术团队的目标。AWS提供了一整套Code服务来实现CI/CD流水线和自动化部署,其中CodePipeline可以帮助团队实现全自动化的软件发布流程。

二 概述

本文以一个简单的Web应用为例,演示如何利用AWS CodePipeline实现全自动化的发布流水线。主要步骤如下:

1. 开发人员将代码Push到CodeCommit代码仓库,触发CodePipeline
2. CodeBuild从CodeCommit检出最新代码,编译打包并运行测试
3. 手动审核Approve后,触发下一步骤
4. CodeDeploy自动将新的版本部署到不同目标(开发、测试、生产)
5. 添加CloudWatch监控并进行性能测试
6. 回滚到旧版本(如果需要)

通过CodePipeline串联CodeCommit,CodeBuild,CodeDeploy和CloudWatch等服务,实现了完整的CI/CD流水线和全自动化部署。相信这种DevOps实践可以大大增强Web应用的交付速度和稳定性。本文详细介绍了如何配置这套架构,以及各个步骤中的注意事项和最佳实践

三 相关概念

Amazon CodePipeline是一种持续交付服务，您可以使用它对发布软件所需的步骤进行建模、可视化和自动化。您可以快速地对软件发布过程的不同阶段进行建模和配置。CodePipeline自动化了持续发布软件变更所需的步骤。有关CodePipeline定价的信息，请参见定价。

3.1 应用程序（Application）

应用程序是部署的核心，由部署组（Deployment Group）和代码修订（Revisions）组成。一个应用可以包含多个部署组，一个部署组又可以包含多台EC2服务器。同时，一个服务器也可以属于多个部署组，因为一个服务器可能同时运行多个应用。

3.1.1 部署组

创建或修改部署组时，如果添加EC2服务器，可以通过标签（Tag）对已有的EC2服务器进行筛选。所以，在创建EC2时一定要打上标签（Tag），便于在创建应用的部署组时找到对应业务的服务器。

此外，部署组还可以添加自动扩展组（Auto Scaling Group），以及用户自己机房的主机（On-Premise Instance）。

3.1.2 代码修订

代码修订保存了当前应用涉及到得所有代码，代码的存放位置可以在S3或Github。

如果用户自建代码托管，当需要部署时，可以在工作机上同步代码到本地，然后使用AWS命令行进行打包上传。

上面的命令可以将运行目录下得代码打包上传到S3，同时显示在关联应用的代码修订一栏中。

3.2 部署（Deployment）

每一次部署都有唯一的ID标记，并保存所有信息，如代码来源、部署时间、目标服务器、部署结果等。并且针对每一台服务器，都可以详细查看部署过程中的事件（如下载程序、安装前检查、 程序启动、安装后检查等7个事件），以便追踪部署的各个步骤。当部署出错时，可以快速定位和排查。

3.3 部署配置

部署配置存放了一次部署的服务器台数或百分比，在发起部署时需要指定所需配置。CodeDeploy默认提供了三种配置：一次部署一台、一次部署一半数量的服务器，以及一次完成全部部署。部署发起后，CodeDeploy会按照上述策略进行工作，指导完成部署组内全部服务器的更新。

3.4 蓝绿部署

蓝绿部署涉及两个生产环境：

• 蓝色环境指代正在使用的生产环境。
• 绿色环境则将发布一个新版本。

以下是蓝绿部署的一些优点：

• 可在绿色环境下进行测试，而不会中断蓝色环境。
• 切换到绿色环境不需要停机，只需要重定向用户流量。
• 问题发生时，可很方便地从绿色环境回滚到蓝色环境，只要将流量重定向回蓝色环境即可，而无需重新构建。

四 实现流程

4.1 架构图

4.2 实现流程

开发人员提交代码，出发codepipeline，进行codebuild/codedeploy，实现蓝绿部署，构件存储在S3中，

用户通过LB进行访问。

五 实战

5.1 源码准备

• 目录结构

.
├── README.md
├── appspec.yml				# 用于后续codedeploy 配置
├── buildspec.yml			# 用于后续将源码codebuild 存储在S3中；
└── index.html				# 发布的web页面
├── deploy.sh					# 部署脚本
├── stop.sh						# 停止服务脚本
└── validate.sh				# 验证服务脚本

• 内容

# index.html
web app index
version: v1


# buildspec.yml
version: 0.2

phases:

  pre_build:
    commands:
      - echo "start pre build"

  build:
    commands:
      - echo "start build"


artifacts:
  files:
    - '**/*'
  name: webapp
  
  
# appspec.yml
version: 0.0 
os: linux 
files:
  - source: /index.html
    destination: /var/www/html

hooks:
  ApplicationStart:
    - location: deploy.sh
      timeout: 10
  ValidateService:
    - location: validate.sh
      timeout: 10

  ApplicationStop:
  - location: stop.sh
    timeout: 10
    
# deploy.sh
#!/bin/bash
systemctl restart httpd


# stop.sh
#!/bin/bash
systemctl stop httpd

# validate.sh
#!/bin/bash
systemctl status httpd

5.2 CodeCommit操作

5.2.1 创建CodeCommit仓库

codecommit创建完成后，可以看到连接步骤，需要具备一个IAM用户创建codecommit的凭证用于后续提交代码。

5.2.2 创建IAM用户

• 创建具备CodeCommit权限的IAM用户

• 为用户生成codeCommit凭证

• 提交代码到codeCommit中

git clone https://git-codecommit.cn-north-1.amazonaws.com.cn/v1/repos/xuel-codecommit-web

查看codeCommit已经存在代码

5.3 CodeBuild操作

5.3.1 创建Codebuild后存储构件的S3

5.3.2 创建CodeBuild

源选择codecommit

环境选择Amazon Linux 2，角色选择新建服务角色

由于源码项目中已存储buildspec文件，在此不用指定

配置构件，将构件存储在S3中，配置日志信息。

5.3.3 测试构件

查看构建日志已经成功

查看打包完成的S3文件。

5.4 CodeDeploy操作

5.4.1 创建目标部署资源

5.4.1.1创建启动模版

创建模版名称和说明

创建模版系统镜像

创建实例类型及密钥对

网络配置，创建独立安全组放行8000端口，新建独立网络接口，启用分配公务IP地址，便于后期测试。

存储卷使用默认

资源标签

IAM实例配置使用具备访问codedeploy的ec2实例角色

配置启用用户数据，在其中为安装httpd服务及安装codedeploy-agent服务，完成启动模版配置。

5.4.1.2 配置Auto Scaling

配置启动模版

选择VPC及子网，在此选择公有子网

负载均衡器在codedeploy阶段选取，在auto scaling中不配置

配置组大小

添加标签完成创建。

查看实例已创建出来

5.4.1.3 创建ALB

由于部署为多台EC2实例，需要配ALB作为统一应用入口，后去关联codedeploy。

• 创建目标群组

选择目标类型为实例

• 注册目标

注册完成查看运行状况健康

• 创建关联负载均衡

• 创建ALB

查看目标组已于负载均衡器管理完成

测试负载均衡访问

5.4.2 创建codedeploy

5.4.2.1 创建应用程序

5.4.2.2 创建部署组

配置目标组，选择蓝绿部署，管理负载均衡器

5.4.2.3 创建部署

选择build出来的S3构件

开始部署

查看负载均衡组已经创建新的组，查看创建了两个新的实例

查看步骤预置实例已完成

查看替换应用程序

流量重新路由

查看LB后端目标组

查看已经将流量重新路由到替换实例

测试LB访问，已经发布成功。

查看目前只剩下新的实例，历史主机已删除。

5.5 CodePipeline操作

创建CodePipeline为将codecommit/codebuild/codedeploy串联起来，实现代码提交，自动完成蓝绿不俗。

添加源阶段

添加构建阶段

添加部署阶段

创建管道

5.6 测试

测试变更web内容，提交代码变更测试。

已开始出发构建

在发布过程中，如果想回滚可以通过停止并回滚实现业务回滚。

完成发布

5.7 添加审批

一般在build不deploy中间需要添加人工审批，批准是否可以正常发不到环境。

创建主题

再次发布Pipeline，可以看到需要手工审批才能往下执行。

测试访问

5.7 清理

删除自动化伸缩组，可实现自动清理EC2资源，或者将其中实例设置为0。

其他资源对应进入删除即可。

六 反思

1. 代码仓库的选择:可以选择CodeCommit或GitHub,看团队的习惯。CodeCommit完全托管在AWS,集成性更好;GitHub更成熟,社区更大。
2. 部署策略的选择:CodeDeploy支持蓝绿部署、滚动部署、 immutable 部署等多种策略,需要根据应用特性选择最佳策略。
3. IAM权限的管理:需要给予CodePipeline、CodeBuild和CodeDeploy正确的IAM权限才能正常运行,同时不能过于开放可能带来安全风险。
4. 保留旧实例的时长:在蓝绿部署和滚动部署中,旧实例会被保留一段时长,需要根据业务需要设置恰当的时长。
5. 部署组的选择:可以将EC2实例放入Auto Scaling Group,然后在CodeDeploy上为该组配置部署,这样可以更轻松的缩容和扩容。
6. 回滚策略的制定:在发布新的版本时,需要有清晰的回滚策略和方案,在出现问题时可以快速回滚到正常版本。
7. 监控和告警:要监控流水线的运行,部署的状态和结果,以及生产环境的各项指标,并设置相关告警,特别是在发布期间更需要密切监控。
8. 流水线的优化:在实践中不断总结经验,优化流水线的各个步骤,提高发布效率和稳定性。

七 其他

• 后期可以将LB/VPC/IAM创建利用Terraform或者cloudformation实现自动化；
• 本次实践为部署在EC2上，后期可以发不到ECS中或者Lambda中。

参考链接

• docs.aws.amazon.com/zh_cn/coded…