前言
本文主要讲述了什么是平滑发布、灰度发布,以及平滑发布和灰度发布之间的联系。灰度发布,又称金丝雀发布。为什么叫金丝雀发布呢?
金丝雀发布这一术语源于煤矿工人把笼养的金丝雀带入矿井的传统。矿工通过金丝雀来了解矿井中一氧化碳的浓度,如果一氧化碳的浓度过高,金丝雀就会中毒,从而使矿工知道应该立刻撤离。 ——《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项目到发布目录,这里不再重复演示。
总结
以上就是平滑发布与灰度发布的整个流程,从研发代码修改到项目再次平滑上线,整个过程业务处于不停机的状态,达到了我们的预期效果,也实现了我们的平滑发布与灰度发布。