[Best Practice] Using OpenNJet to achieve grayscale publishing

In the process of testing and releasing a new version of an application, it is often necessary to use some selected accounts for verification first. After the verification is completed, the business traffic is gradually switched to the new version until all traffic is switched to the new cluster.

The test account can be detected in various ways, such as through the field in the Header , the value in the cookie , or the parameters in the URL .

In the configuration and scenarios in the following chapters, the staffid field in the HTTP Header will be used as the basis for judging the test account, and the account of 7xxxx will be identified as the test account.

initial static configuration

In the initial configuration, two groups of upstreams will be set : backendA and backendB , and the staffid value in the header will be used as the basis for traffic ratio through the split_clients command , and 100% of the traffic will be set to point to the backend backendA .

 split_clients $http_staffid $backend {
     100%    backendA;
     *       backendB;
   }

The complete configuration is as follows:

njet.conf
worker_processes auto;
cluster_name app1;
node_name node1;

error_log logs/error.log info;
load_module modules/njt_http_split_clients_2_module.so;
load_module modules/njt_http_dyn_bwlist_module.so;
load_module modules/njt_http_lua_module.so;
load_module modules/njt_dyn_ssl_module.so;
load_module modules/njt_agent_dynlog_module.so;  
load_module modules/njt_http_location_module.so;
helper ctrl modules/njt_helper_ctrl_module.so njet_ctrl.conf;
helper broker modules/njt_helper_broker_module.so ;

events {
    worker_connections  1024;
}

http {
   split_clients $http_staffid $backend {
     100%    backendA;
     *       backendB;
   }

   upstream backendA {
     server 192.168.1.4:18081;
   } 
   upstream backendB {
     server 192.168.2.4:18081;
   } 

   server {
       listen      18080 ssl; 
       ssl_certificate     cert/server.crt;  
       ssl_certificate_key  cert/server.key; 
       server_name www.test.com;
   
       location / {
         proxy_pass http://${backend};
       }
   }
}
njet_ctrl.conf
load_module modules/njt_http_sendmsg_module.so;
load_module modules/njt_ctrl_config_api_module.so; 
load_module modules/njt_helper_health_check_module.so;
load_module modules/njt_http_upstream_api_module.so; 
load_module modules/njt_http_location_api_module.so;
load_module modules/njt_doc_module.so;
load_module modules/njt_http_vtsd_module.so;

error_log logs/error_ctrl.log error;

events {
    worker_connections  1024;
}
http {
    include mime.types;
    access_log off;
    server {
        listen       8081;
        location / {
            return 200 "njet control panel\n";
        }
        location /hc {
            health_check_api;
        }
        location /api {
             api write=on;
        }
        location /kv {
            dyn_sendmsg_kv;
        }
        location /config {
            config_api;
        } 
        location /doc {
            doc_api;
        }
        location /dyn_loc {
           dyn_location_api;
        }  
        location /metrics {
            vhost_traffic_status_display;
            vhost_traffic_status_display_format html;
        }
    }
}

Grayscale publishing steps

动态添加location

After the new version has been deployed to the backendB cluster, add a conditional location through the API provided by the dynamic location , and set all 7xxxx test job numbers in the location to access backendB . In the conditional expressions provided by Njet , you can use $http_* to get the value in the request header , and the $http_staffid ~* "7.*" expression will match all requests whose staffid is 7xxxx in the header .

Use the test job number to test

After adding the conditional location through the previous step , all non- 7xxxx job numbers will continue to access the cluster backendA, and all 7xxxx as test job numbers will access the cluster backendB .

Delete the expression location

When the test is complete, the conditional location can be removed using the dynamic API .

After deleting the conditional location , all traffic is directed to backendA, including the test worker number of 7xxxx .

Gradually adjust the diversion ratio until 100%

Use the dynamic configuration API provided by the module to gradually adjust the split ratio.

For example , when adjusting to a ratio of 50:50 :

Finally adjusted to a ratio of 0 : 100 , all traffic will point to backendB

At this time, the new version of the application has been deployed and switched (A => B). When the next version is released, the same steps can be used to complete the switch (B => A) .

OpenNJet was originally based on NGINX1.19 basic fork and evolved independently. With the iteration of NGINX version, it absorbed the update of upstream NGINX and has been updated to NGINX1.23.1 version. OpenNJet has the characteristics of high performance, stability and easy expansion, and also solves the NGINX has long-standing problems such as difficulty in dynamic configuration and management functions affecting business.

As the underlying engine, OpenNJet can implement different product forms by using the dynamic loading mechanism, such as API gateway, message proxy, inbound and outbound proxy, load balancing, WAF and so on. In the cloud-native architecture, in addition to providing the north-south communication gateway function, OpenNJet also provides new features such as east-west communication in the service grid, transparent traffic hijacking, circuit breaker, telemetry and fault injection.

Portal: https://gitee.com/njet-rd

[Best Practice] Using OpenNJet to achieve grayscale publishing

Guess you like