参考文章：使用 Nginx 实现灰度发布
什么是灰度发布
- 【百度百科】灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。 在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
- 除了AB test灰度发布另一种思想是，只发布给一小部分用户，如：App在发布之前，针对性的给一小批用户测试下新版本，用小流量发布的方式来检验新版会不会有问题。
- 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
Openshift上实现蓝绿部署
image.png
在openshift上的部署两个版本的Service：service01, service02。在创建Route的时候，可以非常简单地指定同一个Route流量访问两个service的百分比service01（25%流量）, service02（75%流量）。所有请求该Route的流量会被按指定的比例访问后service。
配置发布75%-25%.png
Route详情展示.png
对应的Route yaml配置文件如下：
apiVersion: route.openshift.io/v1
kind: Route
metadata:
labels:
app: grey-test
name: grey-test
namespace: grey
spec:
alternateBackends:
- kind: Service
name: service_v2
weight: 75
host: grey-test.sample.com
port:
targetPort: web
to:
kind: Service
name: service_v1
weight: 25
wildcardPolicy: None
金丝雀发布的不足
- openshift中Route自带的金丝雀发布配置非常简单，也很实用。但是它没办法对请求的流量进行定义控制。
- 例如根据IP，指定IP为'202.38.12.10'的用户访问service_v2,那么Openshift中Route自带的分流就无法实现。
- 所以必须对特定用户访问特定版本的问题，我们需要寻求其它办法。使用传统的方法，Nginx是一个比较常见的选择。在openshift的灰度方案中，我们也尝试使用Nginx来实现对特定用户的灰度发布。
Nginx配置实现灰度发布
- 创建两个upstream
- 针对remote_addr进行分流，默认访问default的upstream，如果ip为'202.38.12.10'，则访问api_v2的upstream。
无需多解释，直接上配置。
upstream default{
server 172.30.198.194:8080 max_fails=1 fail_timeout=60;
}
upstream api_v2{
server 172.30.198.194:8080 max_fails=1 fail_timeout=60;
}
server {
listen 80;
server_name _;
set $group default;
if ($remote_addr ~ "202.38.12.10") {
set $group api_v2;
}
location / {
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}
对配置作进一步优化
怎么获取客户端IP？
- 如果直接访问Nginx服务的话，在Nginx上通过 $remote_addr 能够获得客户端IP，但是我们知道在Openshift高可用部署中，我们使用了负载均衡器。通过负载均衡器转发后，Nginx webserver获得的$remote_addr其实是负载均衡器的IP，而不是客户端真实IP。
-
为了能在Nginx webserver中获得客户端IP，需要在附加HTTP头字段开启客户端真实IP。同时在Nginx的配置中使用$http_x_forwarded_for来检查客户端IP.
IaaS上创建负载均衡器.png - 新的配置如下
upstream default{
server 172.30.198.194:8080 max_fails=1 fail_timeout=60;
}
upstream api_v2{
server 172.30.198.194:8080 max_fails=1 fail_timeout=60;
}
server {
listen 80;
server_name _;
set $group default;
if ($http_x_forwarded_for ~ "202.38.12.10") {
set $group api_v2;
}
location / {
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}
如何实现高可用？
这个非常简单，只需要在Openshift上将为Nginx的DeploymentConfig增加Pod数增就可以了。
我要有多个IP加入白名单，有没有更方便的配置方法？
Nginx有map函数，能将IP与访问的后台服务。
map $http_x_forwarded_for $group {
default 172.30.198.194:8080;
~202.38.12.10 172.30.198.194:8080;
}
server{
listen 8080;
server_name _;
location /{
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}
明明有域名为啥只能是IP？
- Openshift对于Service除了有固定的IP外，还有固定的域名，一般域名形式为：servername-projectname.svc。我们能否用域名代替IP,让这个配置的可读性更高，什么IP访问什么服务一目了然。
- 但是直接将IP更改为对应Service的域名，在启动Nginx时会报无法解析域名的错误。
- Nginx需要在map配置中解析域名需要指定dns。
- 最终配置如下（172.30.0.1为Openshif集群默认的内部DNS，可在master的配置文件中查看）：
resolver 172.30.0.1;
map $http_x_forwarded_for $group {
default api_v1.server.svc:8080;
~202.38.12.10 api_v2.server.svc:8080;
}
server{
listen 8080;
server_name _;
location /{
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}
Openshift中对于443端口的负载均衡器使用的是TCP协议，无法转发X_forward_for，那https服务要怎么弄？
如何应用请求为Https，无法直接使用TCP负载均衡器，而Openshift部署时是通过TCP负载均衡器来作443端口的负载的。
- 这就需要创建一个Https负载均衡器， 后台Openshift Nginx的Route设置为正常的Http。其它配置一样。既能将clientIP传给后台webserver，同时又满足了该业务请求为Http协议。
-
最终的流程图如下：
Nginx作负载均衡器图.png
拓展思考
- 是否一定要在Openshift上部署呢?【必然不需要】
- Nginx实现灰度发布除了支持ip还支持啥？【对Header头信息等】
- 除了对页面HTTP请求实现这种灰度，那么对于TCP服务呢，比如说数据库？【也是OK的】
