This tutorial shows you how to use gateway staging servers in OpenResty Edge to test your gateway configuration changes before releasing them to all your production gateway servers.
We know that Edge Admin manages and distributes configurations to Edge Servers. It could be problematic to distribute significant changes directly to all Edge Servers.
To solve this problem, we mark some Edge Servers as staging servers. First release changes to staging servers, and then release them to all servers after testing. It is our topic today: staging servers.
Let’s go to the OpenResty Edge’s Admin web console. It is our sample deployment of the console. Every user has their local deployment.
First, let’s see how to set up gateway servers as staging servers.
Click the tab Gateway Clusters to enter the page of Gateway Clusters.
Here we have a gateway cluster with two gateway servers.
Now we want to set up these two gateway servers as staging servers. We can achieve this in two ways. The first is to set up the whole gateway cluster as a staging cluster. Let me show you how to do this.
Click to edit this cluster.
Here is a switch to set up whether a cluster is a staging cluster.
This switch is off now.
To make the cluster staging, you need to turn this switch on.
Click to save this change.
Click on the cluster name to enter the server list page.
You can see from the server list page that these two servers are now staging servers.
Go back to the gateway clusters page.
The second way is to directly set up a gateway server as a staging server.
Click on the edit button again.
Turn this switch off.
We see that there are switches under each server to set up whether a server is a staging server.
Turn this switch on.
Click to save this change.
Click on the cluster name.
You can see that the first server is still a staging server.
The second server is not.
We do this just for the convenience of the demonstration. It is not recommended to have a cluster with both staging and non-staging servers. It will cause problems when releasing changes on the cluster level.
Now let’s go back to the applications page and see how to release changes to staging servers.
We use our ongoing sample application for the test-edge.com domain.
Let’s enter this application.
Here we create a new page rule to test the staging release.
Click to create this rule. This rule is to return specific content under a particular URI.
First, we add a condition for this rule.
The variable of the condition remains unchanged as URI.
We choose the string equality operator.
Enter the value
/test to match this URI.
The condition is now complete.
Then for the action part of the rule, we can configure an output response body action. Please note that we chose this action just for demonstration. Staging servers work with any configuration.
We have a lot of actions here.
So better search for the
Select the action “Output response body”.
Select text/plain as the content type.
Enter “Hello World” as the output response body.
Click this option to insert this rule before any other existing rules.
Click the Create button to create this rule.
You can see that the rule is already there.
The last step is to make a new configuration release. It will push out our pending changes to our gateway servers.
Let’s click on this link to make a new release.
Add a comment for this release.
To do a staging release, you need to turn on this button.
All staging servers are listed here.
Now it is fully synchronized.
We still see changes we just made in the list of unreleased changes. This is because changes have not been released to all Edge Nodes but only to staging ones.
In the list of release history, we can see changes we just made.
And we can see that the release type is staging.
Now we go to the gateway clusters list and select the servers for testing.
Note that the server with an IP address ending with 226 is a staging server. Click to copy it.
Use this staging server
send the request
We add an “enter” as output to make the output clear.
You can see Hello World as the response.
Now let’s test with a non-staging server. Click to copy the server with the IP address ending with 213.
Use this non-staging server
You can see 404 as the output. It means that the changes we just made did not affect this server.
OpenResty Edge is a powerful distributed traffic management and private CDN software product based on OpenResty. It provides various features such as page rules, web application firewall (WAF), load balancing, and many more.
If you like this tutorial, please subscribe to this blog site and/or our YouTube channel. Thank you!
Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty®, adopted by more than 40 million global website domains.
OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.
As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.