平滑发布与灰度发布

前言

本文主要讲述了什么是平滑发布、灰度发布，以及平滑发布和灰度发布之间的联系。灰度发布，又称金丝雀发布。为什么叫金丝雀发布呢？

金丝雀发布这一术语源于煤矿工人把笼养的金丝雀带入矿井的传统。矿工通过金丝雀来了解矿井中一氧化碳的浓度，如果一氧化碳的浓度过高，金丝雀就会中毒，从而使矿工知道应该立刻撤离。 ——《DevOps实践指南》

一、平滑发布

什么叫平滑？所谓的平滑发布就是发布的过程中不影响用户的使用，系统不会因发布而暂停对外服务，不会造成用户短暂性无法访问。

二、灰度发布

什么叫灰度？所谓的灰度发布就是发布后让部分用户使用新版本，其它用户使用旧版本，逐步扩大影响范围，最终达到全部更新的发布方式 。

三、平滑与灰度的联系

灰度发布与平滑发布其实是关联的。当服务器的数量只有一台的时候，不存在灰度发布，一旦发布了就是所有用户都更新了，所以这个时候只有平滑发布。当服务器数量大于一台的时候，只要每台服务器都能达到平滑发布的方式，然后设定好需要发布的服务器占比数量，就可以实现灰度发布了。

四、实施流程

4.1 实施环境

CentOS 7.4

关闭防火墙

关闭SELINUX

Gitlab版本：gitlab-ce-13.5.1

主机	用途
10.20.151.99	Gitlab服务
10.20.151.180	Nginx负载均衡
10.20.151.143	web1（后端应用服务）
10.20.151.200	web2（后端应用服务）

4.2 做负载均衡

[root@proxy ~]# vim /etc/nginx/nginx.conf
[root@proxy ~]# nginx -t
[root@proxy ~]# nginx -s reload

4.3 Clone项目

（1）clone项目到发布目录

这里将项目clone到Nginx对应的网站发布目录/usr/share/nginx/my-rab/html，其目录下的index.html就是我们开发编写的web页面。

为了节约时间，我这里的两台web机器均使用了zhurongsen账户来上传公钥并进行克隆，而在实际生产中，我们必须要先要在Gitlab上创建对应的用户，通过对应的用户来上传对应的公钥，并通过对应的用户clone相关项目。

• web1上传公钥并clone

  [root@web1 ~]# ssh-keygen -C "xxxx@163.com"
  [root@web1 ~]# cat ~/.ssh/id_rsa.pub
  

  

  [root@web1 ~]# cd /usr/share/nginx/
  [root@web1 nginx]# git clone git@10.20.151.99:rab/my-rab.git
  [root@web1 nginx]# ls
  my-rab
  [root@web1 nginx]# nginx -t
  [root@web1 nginx]# nginx -s reload
  

• web2上传公钥并clone

  [root@web2 ~]# ssh-keygen -C "xxxx@163.com"
  [root@web2 ~]# cat ~/.ssh/id_rsa.pub
  

  

[root@web2 ~]# cd /usr/share/nginx/
[root@web2 nginx]# git clone git@10.20.151.99:rab/my-rab.git
[root@web2 nginx]# ls
my-rab
[root@web2 nginx]# nginx -t
[root@web2 nginx]# nginx -s reload

（2）修改Nginx网站发布目录

• web1

  [root@web1 ~]# vim /etc/nginx/conf.d/web1.conf
  

  

• web2

  [root@web2 ~]# vim /etc/nginx/nginx.conf
  

  

（3）浏览器访问

或：

[root@proxy ~]# curl 127.0.0.1

4.4 优化代码

在用户的访问中，web页面出现了乱码，这个时候就需要研发人员去优化代码，而这时为了业务正常线上运行，我们就需要进行平滑升级。

（1）研发人员优化代码

Linux客户端切换到我们的研发人员zhuxiaojie进行代码修改并提交到Gitlab同时进行分支合并。这里的pull操作、代码push操作省略，这些步骤在我前面的博客中有详细的操作。

（2）停掉后端web其中一台（用于平滑升级即重新上线优化的代码）

该操作在我们的负载均衡服务器上进行。

在这个时候要注意的是：此时我们的线上业务并没有暂停，而且我们做的是负载均衡，因此这里我们停掉web2，让web1继续线上运作（也就是说用户访问的还是以前的旧代码）。操作如下：

[root@proxy ~]# vim /etc/nginx/nginx.conf
[root@proxy ~]# nginx -t
[root@proxy ~]# nginx -s reload

（3）我们运维将优化的代码clone到发布目录

这里我们选择停掉了web2，因此我们优化的新代码就要clone到我们的web2机器上，操作如下：

[root@web2 ~]# cd /usr/share/nginx/
[root@web2 nginx]# rm -rf my-rab      # 删除旧代码
[root@web2 nginx]# git clone git@10.20.151.99:rab/my-rab.git   # clone新代码
[root@web2 nginx]# ls
my-rab
[root@web2 nginx]# nginx -t
[root@web2 nginx]# nginx -s reload

此时预先单独测试一下web2优化的效果，在进行上线。

（4）没问题后进行灰度发布

在上图可看出代码基本上没问题，可将负载的web2打开（这里操作简单，不再截图演示），然后再次进行访问（通过负载均衡服务器访问）

（5）继续优化web1

同理，我们的web2已经解决乱码问题，同样我们的web1也要进行同样优化，操作和web2一模一样，down掉web1，接着干掉旧代码，再clone项目到发布目录，这里不再重复演示。

总结

以上就是平滑发布与灰度发布的整个流程，从研发代码修改到项目再次平滑上线，整个过程业务处于不停机的状态，达到了我们的预期效果，也实现了我们的平滑发布与灰度发布。

<点击跳转至开头>