Using stateful junction together with the priority attribute in WebSEAL’s junctions, we can provide a Blue-green deployment mechanism using WebSEAL (or IBM Appliation Gateway (IAG), for that matter)

Blue-green deployments

So Blue-green deployment is a release management technique that reduces risk and minimizes downtime. It uses two production environments, known as Blue and Green, to provide reliable testing, continuous no-outage upgrades, and instant rollbacks.

In other words, instead of upgrading your current production environment (‘Blue’) that is currently handling production load and that may cause downtime, you spin up a new separate production environment with your new version (‘Green’).

WebSEAL Stateful junctions

Stateful junctions are not exactly new in WebSEAL (See https://www.ibm.com/docs/en/sva/10.0.8?topic=junctions-stateful-junction-concepts)

When making a junction stateful, WebSEAL sets a cookie (the PD_STATEFUL cookie) so that subsequent requests will always be sent to the same backend server.

However, in ISVA version 10.0.2, a priority option has been added to junctions that connect to multiple backends. The priority has been added as a way to define a hot-standby server to a junction, opposed to having multiple servers that would be selected based on a ‘least-used’ algoritm.

The current version (‘Blue’) uses a higher priority (eg. 9), and you add a new backend server to the junction, pointing to you new version (‘Green’) with a lower priority (eg. 1)

Bring it together

So the implementation of this, is pretty simple :

define a stateful junction with (at least) 2 backend servers
use priorities to define the ‘Blue’ server (the server that will serve normal requests)
override the PD_STATEFUL_ cookie , to point to the alternative backend server that has lower priority, allowing you to do a verification in production of your new system.

After testing, you can simply change the priority on the backends , or stop the ‘Blue’ server to bring the new system ‘Green’ live.

Preparation

To test this, I’m starting 2 webservers that simply show a Green or Blue page. In this case, I’m using Python’s http.server module:

python -m http.server 9008 --directory ./blue &
python -m http.server 9009 --directory ./green &

The actual config is here : https://github.com/Bozzie4/blog_assets/tree/main/bluegreen

In the 2 directories (blue and green), I just put a simple html file that has the corresponding background color.

I start these simple servers, and make them available.

Stateful junction

I create a standard (transparent path) stateful junction.

The important option here is Stateful Junction

Create 2 backend servers

As part of the junction creation, you need to switch to the Servers tab, and here we can add 2 backends.

This first server (‘Blue’) has Priority 9, meaning that it is the default backend that will be used .

The second server (‘Green’) gets priority 1, so it’s not going to be used unless the primary server becomes unavailable.

UUID

When you’ve saved the junction, the 2 servers will receive a UUID. The UUID will be used as part of the name of the PD_STATEFUL_ cookie.

Demo

Now we just access the WebSEAL instance, using the junction that we defined (/bluegreen). I login using any user (this is not relevant for this example)

We see the Blue page, coming from the Blue backend server. This has the highest priority.

Now we can look at the cookies, and we see that we have a PD_STATEFUL_xxx cookie, that contains the uuid of the Blue backend server. Notice that the cookie contains the path of the junction in this case.

Switch to the Green server

Our servers are both up and running, normal users would login and use the Blue backend. We can now verify that our new server (Green) is ready to use.

To do this, we can edit the name of the PD_STATEFUL_xxx cookie. I had copied the UUID of the Green backend server earlier, and I simply replace the UUID part in the cookies name.

Now we can simply refresh the page, and we get a response from the Green backend server.

The nice thing here is that you can simply continue in your WebSEAL session (I was already logged in). Depending on the way you pass credential information to the backend, the Green server simply logs you in and you can start working . A good approach here is using a JWT junction.

Conclusion and next steps

Using the stateful junction cookie provides a simple way to do Blue-Green deployments.

A downside is that it’s not trivial for your testers to get and use the UUID of the backend junction. Testers typically would not be able to access your ISVA configuration !

So in a next blog, we’ll add a http transformation rule to set the cookies for your testers.