Perform in-place Kubernetes updates with a Blue/Green Deployment

Because Red Hat OpenShift is built on Kubernetes, it allows you to perform in-place updates of existing running applications. This feature means you can spin up a different version of an application—newer or older—and have the traffic automatically routed to that version. When done correctly, this can be used to create a zero-downtime deployment.

Put more succinctly: Kubernetes (and OpenShift) allow you to update an application with one simple command.

This OpenShift Developer Sandbox activity will guide you through the process of deploying an application, actively using the application, and then initiating a Blue/Green Deployment to switch to version 2 of that application. Immediately following that update, you will quickly switch back to version 1 of the application. Following that switch, you will again switch to version 2.

This immediate back-and-forth switching between versions is facilitated by the Blue/Green Deployment pattern. In this pattern, both versions of the application are running at the same time, with only one version being accessed at any given moment. The Blue/Green pattern allows you to introduce a new version while keeping the old version running. After both versions are up and running, traffic is very rapidly moved from the older version to the newer version. Monitoring, metrics, and log inspections are then used to determine if the newer version is working properly. If it is, you are finished with the deployment and you can stop and remove the older version. If the newer version is not meeting expectations, you can immediately revert to the older version.

Expected time to completion: 15 minutes

Prerequisites

1. An OpenShift Sandbox account
2. The OpenShift command line interface (CLI) installed on your local PC

Working environment for this activity

• This activity will require you to work at the command line, using either Bash or PowerShell.
• You will need access to a web browser in order to obtain your OpenShift login token.

What you'll be doing

1. Log in to your OpenShift Sandbox at the command line
2. Spin up an application (gethostname-v1, version 1)
3. Run a curl command loop to view the application output
4. Spin up version 2 of the application (gethostname-v2)
5. Patch the route to switch from version 1 to version 2
6. Observe the results
7. Patch the route to switch back to version 1

Part 0: Log in to your OpenShift Sandbox at the command line

Step 0.1

Log in to your OpenShift Sandbox by following these instructions.

Part 1: Spin up version 1 of the application (gethostname-v1)

Step 1.1

Run the following command to create our application:

oc new-app quay.io/rhdevelopers/gethostname:v1 --name gethostname-v1

Step 1.2

Run the following command to create a route to the service:

oc expose service/gethostname-v1 --name gethostname-microservice

This allows the application to be reached from outside of the OpenShift cluster.

Part 2: Run a curl command loop to view the application output

Step 2.1

Run the following command to see the URL of the application:

oc get routes

You will see output similar to the following:

NAME                                                              HOST/PORT                                                                                     
PATH             SERVICES            PORT               TERMINATION           WILDCARD
gethostname-microservice   gethostname-microservice-rhn-engineering-foo-dev.apps.sandbox.x8i5.p1.openshiftapps.com          gethostname-v1   8080-tcp                
​​​​​​​None

We will use this URL in our curl command loop in the next step.

Step 2.2

Run a curl loop against the URL to see the application output. Replace the URL in the following command with the result you got from the previous command (oc get routes) and run the command at a command line:

If you are using Bash:

for ((i=1;i<=10000;i++)); do curl http://gethostname-microservice-rhn-engineering-foo-dev.apps.sandbox.x8i5.p1.openshiftapps.com/hostname; echo -e; sleep .01; done;

If you are using PowerShell:

while ($true) { (curl gethostname-microservice-rhn-engineering-foo-dev.apps.sandbox.x8i5.p1.openshiftapps.com/hostname).content;start-sleep -Milliseconds 200; }

Figure 1 is an example of the kind of output you can expect:

 

Part 3: Spin up version 2 of the application (gethostname-v2)

Step 3.1

Run the following command to create version 2 of our application:

oc new-app quay.io/rhdevelopers/gethostname:v2 --name gethostname-v2

At this point, both versions of gethostname are running in your OpenShift Sandbox cluster. However, the route (gethostname-microservice) is only accessing version 1.

Part 4: Patch the route to switch from version 1 to version 2

Now we'll roll out the Blue/Green deployment. By patching the route, you immediately switch access from version 1 to version 2. Remember: Both versions are running, so switching between them happens very rapidly when you switch the route.

Step 4.1

Run the following command to alter the route to point to version 2:

If you are using Bash:

oc patch route/gethostname-microservice -p '{"spec": {"to": {"name": "gethostname-v2" }}}'

If you are using PowerShell:

oc patch route/gethostname-microservice -p '{\"spec\": {\"to\": {\"name\": \"gethostname-v2\" }}}'

Part 5: Observe results

As the command in step 4.1 is processed, you will see the output of the curl loop change. This is a result of the rolling update.

Part 6: Patch the route to switch back to version 1

Run the following command to alter the route to point to version 1:

If you are using Bash:

oc patch route/gethostname-microservice -p '{"spec": {"to": {"name": "gethostname-v1" }}}'

If you are using PowerShell:

oc patch route/gethostname-microservice -p '{\"spec\": {\"to\": {\"name\": \"gethostname-v1\" }}}'

Conclusion

You've now put the Blue/Green Deployment pattern into action. As you've seen, you can switch between versions very rapidly. Running both versions at the same time enables you to recover immediately in the event that the new version is faulty.

Once you have determined which version you want to use, you can remove the other version and continue normal operations.