The Red Hat OpenShift Container Platform allows you to perform rolling updates of existing running applications. This feature, which is native to Kubernetes, means you can spin up a different version of an application—newer or older—than the current one, and have the traffic automatically routed to it. 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 that application, and then initiating a rolling update to version 2 of the application.

Expected time to completion: 15 minutes

Prerequisites

1. An OpenShift Sandbox account
2. The OpenShift command line interface (CLI) installed on your local PC
3. git installed on your local PC
4. The code editor of your choice; you’ll need it to create a few files 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

0. Log in to your OpenShift Sandbox at the command line
1. Spin up an application (“myboot”, version 1)
2. Run a curl command loop to view the application output
3. Change deployment image to version 2
4. Observe rolling deployment results

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 an application (“myboot”, version 1)

Step 1.1

Create a file on your local PC named myboot-deployment.yml with the following contents:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myboot
  name: myboot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myboot
  template:
    metadata:
      labels:
        app: myboot
    spec:
      containers:
      - name: myboot
        image: quay.io/rhdevelopers/myboot:v1
        ports:
          - containerPort: 8080

Notice that the Deployment object references the image quay.io/rhdevelopers/myboot:v1.

Step 1.2

Run the following command, using the file you just created, to create the Deployment object and get the application running in your cluster:

oc create -f myboot-deployment.yml

Step 1.3

Create a file on your local PC named myboot-service.yml with the following contents:

apiVersion: v1
kind: Service
metadata:
  name: myboot
  labels:
    app: myboot
spec:
  ports:
  - name: http
    port: 8080
  selector:
    app: myboot
  type: LoadBalancer

Step 1.4

Run the following command, using the file you just created, to create a Service object that references the myboot Deployment:

oc create -f myboot-service.yml

Step 1.5

Run the following command to create a route to the service. This allows the application to be reached from outside of the OpenShift cluster:

oc expose service/myboot

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. We will use this URL in the following curl command loop:

oc get routes

You will see output similar to the following:

NAME     HOST/PORT                                                                    PATH   SERVICES   PORT   TERMINATION   WILDCARD
myboot   myboot-rhn-engineering-dschenck-dev.apps.sandbox.x8i5.p1.openshiftapps.com          myboot     http                 None

Step 2.2

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

If you are using Bash:

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

If you are using PowerShell:

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

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

 

Part 3: Change deployment image to version 2

Step 3.1

Run the following command to switch to the version 2 image for the “myboot” application:

oc set image deploy/myboot myboot=quay.io/rhdevelopers/myboot:v2

Part 4: Observe rolling deployment results

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

You will most likely see some output that is the result of your pods being in a “not ready” state. This behavior is not optimal and can easily be prevented by adding a readiness probe to your deployment.

Figure 2 illustrates both the rolling update and the error associated with not using a readiness probe:

1. The sections labeled with a 1 show the results before and after the rolling update. Notice that the host name has changed, demonstrating that a new pod has replaced the old one.
2. The section labeled with a 2 is an example of the error that may occur in the time during which the old pod has been removed from service and the new pod is not ready. This situation can be avoided by using a readiness probe.

 

Next step

Proceed to the next sandbox activity in this series, "Guarantee application availability with OpenShift readiness probes," to go through the process of setting up a readiness probe to ensure that your rolling updates are error-free.