手把手教你搭建一个灰度发布环境
DevUI是一支兼具设计视角和工程视角的团队，服务于华为云 DevCloud平台和华为内部数个中后台系统，服务于设计师和前端工程师。
官方网站： devui.design
Ng组件库： ng-devui（欢迎Star）
引言
灰度发布，又称金丝雀发布。html
金丝雀发布这一术语源于煤矿工人把笼养的金丝雀带入矿井的传统。矿工经过金丝雀来了解矿井中一氧化碳的浓度，若是一氧化碳的浓度太高，金丝雀就会中毒，从而使矿工知道应该马上撤离。 ——《DevOps实践指南》
对应到软件开中，则是指在发布新的产品特性时经过少许的用户试点确认新特性没有问题，确保无误后推广到更大的用户使用群体。前端
集成灰度发布的流水线在DevOps中是一个很是重要的工具和高效的实践，然而笔者在入职之前对流水线和灰度发布知之甚少。在了解一个新东西时，先从逻辑上打通全部的关键环节，而后再完成一个最简单的Demo，对于咱们来讲是比较有意思的学习路径，所以便有了这篇文章。java
本文理论内容较少，主要是从零到一的搭建流程实践，适合对工程化感兴趣的初级前端开发者。node
01 服务器准备
获取服务器
上面提到，灰度发布是经过少许的用户试点来验证新功能有没有问题。因此要保证有两批用户能在同一时间体验到不一样的功能。这就要求咱们准备两台服务器，分别部署不一样的代码版本。nginx
若是你已经有了一台服务器，也能够经过在不一样端口部署服务的方式来模拟两台服务器。若是你还一台服务器都没有，那么能够参考这个过程购买两台云服务器，若是是按需购买，完成本文的Demo，大概要花费20块钱。git
获取云服务器教程：https://github.com/TerminatorSd/canaryUI/blob/master/HuaWeiCloudServer.mdgithub
工具安装
Git
首先，确保你的服务器上已经安装了git，若是没有的话使用如下命令进行安装，安装好了之后生成ssh 公钥，放到你的github 里，后面拉取代码的时候会用到。shell
yum install git
Nginx
若是你的服务器没有Nginx，先按照如下操做进行安装，Linux 下安装Nginx很是简单：npm
sudo yum install nginx
安装完了，在终端输入nginx -t检查一下是否安装成功。若是安装成功，它会显示Nginx 配置文件的状态，以及位置。segmentfault
此时nginx尚未启动，在终端中输入nginx 或nginx -s reload 命令便可启动，此时看到的nginx相关进程以下，代表已经启动成功。
在浏览器里访问你的服务器公网IP，若是能看到下面的页面说明Nginx 能够正常工做。
Jenkins (耗时比较久)
第一次接触Jenkins 可能会有不少疑问，Jenkins 是什么？能完成什么事情？我为何要使用Jenkins 等诸如此类。很难讲清楚Jenkins 是什么东西，因此这里简单介绍一下Jenkins 能够作什么。简单来说，你在任何一台服务器上进行的任何操做命令，Jenkins 均可以帮你完成，只要你提早在Jenkins上建立好任务，指定任务内容和触发时机，好比定时触发或者在特定的状况下触发。
（1）安装
Jenkins稳定版本list：http://pkg.jenkins-ci.org/redhat-stable/
// 科学上网会快一些，记得留意网站上java和jenkins版本匹配信息，别下错了 wget http://pkg.jenkins-ci.org/redhat-stable/jenkins-2.204.5-1.1.noarch.rpm rpm -ivh jenkins-2.204.5-1.1.noarch.rpm
修改Jenkins端口，不冲突可不修改
// line 56 JENKINS\_PORT vi /etc/sysconfig/jenkins
（2）启动
启动jenkins
service jenkins start/stop/restart // 密码位置 /var/lib/jenkins/secrets/initialAdminPassword
（3）访问
访问服务器的8080端口，输入从上述位置获取的密码，点击继续
建立一个帐户而后登陆
看到Jenkins 已就绪的页面表示安装已经完成，服务器准备工做到此结束。
02 代码准备
准备两份代码
由于要作灰度部署，因此须要准备两份不同的代码，以验证咱们实施的灰度操做是否生效。这里选择使用Angular 的Angular-CLI 来建立代码。建立的项目并不简洁，可是胜在操做简单。咱们一次性把两份代码准备好，简化开发侧工做。
// 安装angular-cli，前提是已经安装了node，若是没有node真的要去自行百度了... npm install -g @angular/cli // 快速建立一个新项目，一路回车 ng new canaryDemocd canaryDemo // 运行完这个命令后访问http://localhost:4200 查看页面信息 ng serve
访问localhost 的4200 端口查看页面，而后把项目根目录下src 中的index.html 的title 改为A-CanaryDemo，能够看到页面会进行实时地刷新。在这个例子中，咱们用title 来标识灰度发布过程当中两边不一样的服务须要部署的代码。
接下来，咱们进行两次打包，两次打包的title 分别为A-CanaryDemo 和 B-CanaryDemo， 把这两个文件夹放好备用，做为一会灰度发布的新老代码。
ng build --prod
配置Nginx
在上述完成Nginx 的安装操做时，咱们访问服务器的IP 看到的是Nginx 的页面，如今咱们想访问到本身的页面，首先把上面打包获得的A-CanaryDemo 发送到两台服务器上任意位置，这里咱们把它放到/var/canaryDemo。
// 将A-CanaryDemo 文件夹复制到你的公网服务器上，xx部分是你的服务器公网ip scp -r ./dist/A-CanaryDemo root@xx.xx.xx.xx:/var/canaryDemo
去服务器上/var 的位置上看一下，是否已经有了这个文件，若是有了的话，接着到下一步。即修改Nginx 配置把访问该服务器IP 的请求转发到咱们刚刚上传上来的页面上。上面提到过能够经过nginx -t 这个命令来查看Nginx 配置文件的位置，在这一步，咱们要去编辑那个文件。
vi /etc/nginx/nginx.conf
修改47-50行添加下图相关的内容，即将访问到该服务器IP 的流量转发到/var/canaryDemo 下的index.html.
修改完毕，保存退出，重启一下nginx
nginx -s reload
这时候去访问咱们服务器的IP 地址能够看到页面已经变成了刚刚咱们在本地改的页面，并且title 确实是A-CanaryDemo。两台服务器都操做完成后，两边均可以访问到title 为A-CanaryDemo 的页面。此时的状态至关于生产环境已经在提供稳定服务的两台机器。
03 定义灰度策略
接下来，咱们要开始进行灰度发布的部分，在进行相关操做以前，咱们须要定义一个灰度策略，即知足什么状况下的流量会走到灰度边，而其余流量走向正常边。这里为了简单起见，咱们使用名字为canary 的cookie 来区分，若是检测到这个cookie 的值为devui，就访问灰度边机器，不然就访问正常边机器。按照此规则配置Nginx 结果以下，此处分别使用11.11.11.11和22.22.22.22表明两台服务器的IP地址：
# Canary Deployment
map $COOKIE\_canary $group {
# canary account
~\*devui$ server\_canary;
default server\_default;
}
upstream server\_canary {
# 两台机器的IP，第一台设置端口号8000是为了防止nginx转发出现死循环致使页面报错
server 11.11.11.11:8000 weight=1 max\_fails=1 fail\_timeout=30s;
server 22.22.22.22 weight=1 max\_fails=1 fail\_timeout=30s;
}
upstream server\_default {
server 11.11.11.11:8000 weight=2 max\_fails=1 fail\_timeout=30s;
server 22.22.22.22 weight=2 max\_fails=1 fail\_timeout=30s;
}
# 相应地，要配置8000端口的转发规则，8000端口默认不开启访问，须要去云服务器控制台安全组新增8000
server {
listen 8000;
server\_name \_;
root /var/canaryDemo;
# Load configuration files for the default server block.
include /etc/nginx/default.d/\*.conf;
location / {
root /var/canaryDemo;
index index.html;
}
}
server {
listen 80 default\_server;
listen \[::\]:80 default\_server;
server\_name \_;
# root /usr/share/nginx/html;
root /var/canaryDemo;
# Load configuration files for the default server block.
include /etc/nginx/default.d/\*.conf;
location / {
proxy\_pass http://$group;
# root /var/canaryDemo;
# index index.html;
}
error\_page 404 /404.html;
location = /40x.html {
}
error\_page 500 502 503 504 /50x.html;
location = /50x.h
}
此时，灰度流量和正常流量都会随机分配到AB两边的机器。下面，咱们经过创建Jenkins 任务执行Nginx 文件修改的方式实现灰度发布。
04 实现灰度发布
流程梳理
在建立用于实现灰度发布的Jenkins任务以前咱们先梳理一下要达到灰度发布的目标须要哪几个任务，以及每一个任务负责完成什么事情。灰度发布通常遵循这样的流程（假设咱们有AB两台服务器用于提供生产环境的服务，咱们称之为AB边）：
（1）新代码部署到A边
（2）符合灰度策略的小部分流量切到A边，剩余大部分流量仍去往B边
（3）手动验证A边功能是否正常可用
（4）验证无误后，大部分流量转到A边，灰度流量去往B边
（5）手动验证B边功能是否正常可用
（6）验证无误后，流量像往常同样均分到AB边
任务拆解
经过上述的拆解，咱们得出灰度发布的6个步骤，其中（3）和（5）是须要手动验证的环节，因此咱们以这两个任务为分割点，创建三个Jenkins 任务（Jenkins 任务创建在A 边机器上）以下：
（1）Canary_A（灰度测试A），这个任务又包含两个部分，更新A边的代码，而后修改流量分发策略使得灰度流量到达A，其余流量到达B
（2）Canary_AB（上线A灰度测试B），更新B边代码，灰度流量达到B，其余流量到达A
（3）Canary_B（上线B），全部流量均分到AB
建立任务
先按照任务拆解部分的设定建立三个FreeStyle 类型的Jenkins 任务，记得使用英文名字，中文名字后面建文件夹比较麻烦。任务详情信息能够不填，直接保存就好，下一步咱们再来配置每一个任务的具体信息。
配置任务
如今已经建立好了三个任务，先点击进入每个任务进行一次空的构建（不然后面可能致使修改后的构建任务没法启动），而后咱们来对每一个任务进行详细的配置。
现代前端项目都要进行构建打包这一步。可是廉价的云服务器在完成构建方面有些力不从心，CPU 常常爆表。因此咱们在这里把打包出得出的生产包归入git 管理，每次的代码更新会同步最新的生产包到github，所以Jenkins 任务把生产包拉下来，放在指定位置便可完成一次新代码的部署。
这一步操做，其实咱们在以前就已经完成了，咱们在上面打了两份tilte 不同的生产包，此时能够派上用场了。
首先来配置灰度测试A，这个任务内容上面也基本讲清楚了，首先要关联该任务到远程的github 仓库（须要手动建立一个，存放上面打包的B-CanaryDemo，并命名为dist）让它知道能够去哪里拉取最新代码。
执行一次构建任务（在git fetch 那一步耗时不稳定，有时比较久），而后点击本次构建进去查看Console Output，能够肯定执行Jenkins 任务的位置是位于服务器上的/var/lib/jenkins/workspace/Canary_A
继续编辑灰度测试A 任务，添加build shell，也就是每次任务执行时要执行的命令：
（1）先拉取最新的代码
（2）把代码根目录下的dist目录复制到部署代码的位置，这里咱们指定的位置是/var/canaryDemo
（3）修改Nginx 配置使灰度流量到达A边
就步骤（3）而言，修改灰度流量的方式其实就是选择性注释Nginx 配置文件中的内容，注释方式以下便可实现灰度测试A。
upstream server_canary {
# 灰度流量访问A 边
server 11.11.11.11:8080 weight=1 max_fails=1 fail_timeout=30s;
# server 22.22.22.22 weight=1 max_fails=1 fail_timeout=30s;
}
upstream server_default {
# 正常流量访问B 边，为了在修改文件的时候把这段的配置和上面的server_canary 区分开，咱们把这里的weight 设为2
# server 11.11.11.11:8080 weight=2 max_fails=1 fail_timeout=30s;
server 22.22.22.22 weight=2 max_fails=1 fail_timeout=30s;
}
这一步填写的shell 命令在使用jenkins 用户执行时可能会遇到权限问题，能够先用root 用户登陆，把/var 目录的归属改成jenkins 用户，/etc/nginx/ngix.conf也须要新增可写权限。由此，最终获得的shell 命令以下：
git pull rm -rf /var/canaryDemo scp -r dist /var/canaryDemo sed -i 's/server 22.22.22.22 weight=1/# server 22.22.22.22 weight=1/' /etc/nginx/nginx.conf sed -i 's/server 11.11.11.11:8000 weight=2/# server 11.11.11.11:8000 weight=2/' /etc/nginx/nginx.conf nginx -s reload
灰度测试A 任务内容配置完成，接下来依次配置上线A 灰度测试B 和上线B。
灰度测试B 的要执行的任务是把最新的代码拉到A 边（由于咱们的Jenkins 任务都是创建在A 边的），复制dist 下的代码到B 边Nginx 指定访问位置，而后修改A 边Nginx 配置，使灰度流量到达B 边。
git pull rm -rf canaryDemo mv dist canaryDemo scp -r canaryDemo root@xx.xx.xx.xx:/var sed -i 's/# server 22.22.22.22 weight=1/server 22.22.22.22 weight=1/' /etc/nginx/nginx.conf sed -i 's/# server 11.11.11.11:8000 weight=2/server 11.11.11.11:8000 weight=2/' /etc/nginx/nginx.conf sed -i 's/server 22.22.22.22 weight=2/# server 22.22.22.22 weight=2/' /etc/nginx/nginx.conf sed -i 's/server 11.11.11.11:8000 weight=1/# server 11.11.11.11:8000 weight=1/' /etc/nginx/nginx.conf nginx -s reload
这一步的任务内容涉及到从A 边服务器向B 边服务器发送代码，这个过程通常来讲须要输入B 边服务器的密码。咱们想要作到免密发送，所以要经过把A 边机器~/.ssh/id_rsa.pub 中的内容添加到B 边服务器~/.ssh/authorized_keys 中使得A 得到免密像B 发送文件的权限。
上线B 则是经过取消对A 边Nginx 配置的注释使全部流量均分到AB 边.
sed -i 's/# server 22.22.22.22 weight=2/server 22.22.22.22 weight=2/' /etc/nginx/nginx.conf sed -i 's/# server 11.11.11.11:8000 weight=1/server 11.11.11.11:8000 weight=1/' /etc/nginx/nginx.conf nginx -s reload
至此，咱们就从零到一搭建了一个灰度发布环境。在代码更新后，经过手动执行Jenkins 任务的方式实现灰度部署和手工测试，保证新功能平滑上线。
总结
本文从服务器准备、代码准备、灰度策略制定和实现灰度发布四个方面介绍了从零搭建一个灰度发布环境的必备流程。灰度发布的核心其实就是经过对Nginx 文件的修改实现流量的定向分发。内容颇为简单，可是从零到一的整个流程操做下来仍是比较繁琐，但愿各位看官可以有所收获。
另外，这只是一个最简易的Demo，在真正的DevOps 开发过程当中，还须要集成编译构建、代码检查、安全扫描和自动化测试用例等其余操做，期待后续团队的其余成员进行更多的专项扩展！
加入咱们
咱们是DevUI团队，欢迎来这里和咱们一块儿打造优雅高效的人机设计/研发体系。招聘邮箱：muyang2@huawei.com。
文/DevUI 少东
往期文章推荐