【nginx】nginx:利用负载均衡原理实现代码的热部署和灰度发布
事情起因很简单,代码的改动量很大。而且刚接手服务器,对原有的代码进行了一定程度的重构。虽然在测试服务器上做了较多的测试工作,但是直接将代码送入生产环境还是不放心,万一配置出问题服务直接崩溃怎么解?万一遇到没有测出来的bug怎么解?so······
nginx负载均衡简介 :
负载均衡 建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 负载均衡,英文名称为Load Balance,其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。
以上是某科的解释,说的简单些就是一件事,按照一定的规则分配给拥有相同配置的机器去完成
服务器的架构:
因为我们生产环境服务器只有一台,所以是在一台机器内完成的。
图片已经把意思说的很明白的,接下来就是do it
Step1:配置nginx的负载均衡
修改nginx的配置文件(我的目录是/etc/nginx/nginx.conf),在http模块中添加:
# 负载均衡配置 upstream balance { # 开启ip_hash保证同一个用户访问到同一台服务器 ip_hash; # 老服务器运行在11000+端口 server 127.0.0.1:11001 weight=1; # 新服务器运行在12000+端口 server 127.0.0.1:12001 weight=1; } # 作为负载均衡的虚拟服务器 server { listen 10001; location / { proxy_pass http://balance; proxy_set_header X-Real-IP $remote_addr; } access_log /data/logs/nginx.balance.access.log; error_log /data/logs/nginx.balance.error.log; }
配置的字段是什么意思,找某度喽···
当然因为有include,可以把这段代码单独拿出来,减少对nginx配置文件的侵入(我放在/etc/nginx/conf.d/nginx_balance.conf)里面
Step2:新代码部署+启动
我是用supervisor管理进程的,用uwsgi启动代码,下面把相关的配置都放出来了
首先要让老代码运行到11001端口:
server { listen 11001; location / { add_header Access-Control-Allow-Origin *; root /data/www/app/; include uwsgi_params; uwsgi_pass 127.0.0.1:30000; uwsgi_read_timeout 360; } location ~/media/{ root /data/static/; } location = /favicon.ico { log_not_found off; } access_log /data/logs/nginx.qianming.access.log; error_log /data/logs/nginx.qianming.error.log; }
其次是新代码的nginx配置,运行在12001端口:
server { listen 12001; location / { add_header Access-Control-Allow-Origin *; root /data/www_new/app/; include uwsgi_params; uwsgi_pass 127.0.0.1:31000; uwsgi_read_timeout 360; } location ~/media/{ root /data/static/; } location = /favicon.ico { log_not_found off; } access_log /data/logs/nginx.qianming.access.log; error_log /data/logs/nginx.qianming.error.log; }
接下来是supervisor的配置:
; 需要将此配置文件软引用到supervisor的配置文件,默认路径:/etc/supervisor/ ; 使用supervisor来管理进程,做到自动启动 [program:qianming_old] directory=/data/www_new/app command=uwsgi --ini confs/uwsgi.ini autostart=true
最后是uwsgi的配置:
[uwsgi] socket = 127.0.0.1:31000 chdir = /data/www_new/app/ wsgi-file = project/wsgi.py processes = 1 threads = 4 chmod-socket = 664 chown-socket = www:www-data
当然要让配置生效,这里不展开讲了
nginx -t测试通过以后直接可以nginx -s reload加载nginx新的配置,新的代码在supervisor里卖直接启动就可以了,这样旧代码运行在11001端口,新代码运行在12001端口,而访问原先的10001端口会根据自定的规则决定返回11001端口或者12001端口的数据,而这个规则就是通过权重进行配置的,在nginx_balance.conf文件中通过weight配置的。
至此,代码的热部署已经完成。
Step3:测试和灰度发布
要想测试,直接访问12001端口就可以了,因为里面是最新的代码
灰度发布也就是控制weight的值,渐渐增大访问新代码的比例就可以了,直到新代码达到100%,老代码就可以正式宣告退役了^_^
- nginx:利用负载均衡原理实现代码的热部署和灰度发布
- 利用Redis+Nginx实现Sping-Boot应用的负载均衡部署
- nginx结合tomcat实现反向代理和负载均衡的部署
- 利用nginx+lua+memcache实现灰度发布
- 利用svn钩子hooks/post-commit实现代码自动部署
- 利用saltstack部署高可用集群及负载均衡(keepalived+haproxy+nginx)
- nginx Win下实现简单的负载均衡(1)nginx搭建部署
- CentOS利用WebHook实现PHP自动部署Git代码
- KeepLived + Nginx 实现高可用 负载均衡 原理
- 利用saltstack部署高可用集群及负载均衡(keepalived+haproxy+nginx)
- Nginx反向代理Tomcat实现现负载均衡(高可用)以及利用redis+Session同步会话共享配置详解
- 利用nginx和docker实现一个简单负载均衡
- 利用svn钩子hooks/post-commit实现代码自动部署
- 在android中利用多线程实现对控件的更新(动态修改文本框中的值)。简述原理并上传代码。
- Nginx部署前端代码实现前后端分离
- 利用nginx和docker实现一个简单负载均衡
- 利用nginx+lua+memcache实现灰度发布
- 利用lvs+keepalived实现高可用负载均衡环境的部署
- 利用nginx+lua+memcache实现灰度发布
- CVE-2014-0038内核漏洞原理与本地提权利用代码实现分析 作者:seteuid0