Webhooks and Rollbacks

Build Triggers, Webhooks and Rollbacks - Oh My!

Once you have an app deployed in OpenShift you can take advantage of some continuous capabilities that help to enable DevOps and automate your management process. We will cover some of those in this lab: Build triggers, webhooks, and rollbacks.

Build Trigger / Code Change Webhook

When using S2I there are a few different things that can be used to trigger a rebuild of your source code. The first is a configuration change, the second is an image change, and the last (which we are covering here) is a webhook. A webhook is basically your git source code repository telling OpenShift that the code we care about has changed. Let’s set that up for our project now to see it in action.

The builder template that was used when the webapp was added to the project created a number of resources for you. What we care about right now is the build configuration because that contains the webhooks. Let’s find the URL for the webhook:

CLI Steps

Goto the terminal and type the following:

$ oc describe bc/webapp

You should see the output for the app's build configuration. Look for the text "Webhook".

Copy the Generic webhook to the clipboard

Web Console Steps

Hover over "Builds" and then click on "Builds"

This is going to show basic details for all build configurations in this project

Click the "webapp" build config

You will see the summary of builds using this build config

Click the "Configuration" tab (next to the active Summary tab)

Now you can see the various configuration details including the Github specific and Generic webhook URLs.

Copy the Generic webhook to the clipboard

Now open a webbrowser and navigate to where we manage the source code for this project (http://openshift.example.com:3000/demo/openshiftexamples-nodemongo)

Source Control Repo Steps

Let's put the webhook URL into the repository. At the main page for this repository (the fork), you should see a tab bar with code, issues, commits, releases, wiki, and settings.

Click the "Settings" button

Now you will see a vertical list of settings groups.

Click the "Webhooks" item

Click the "Add webhook" button and select "Gogs"

Paste in the URL you copied

Click the button to "Add webhook"

Good work! Now any "push" to the forked repository will send a webhook that triggers OpenShift to: re-build the code and image using s2i, and then perform a new pod deployment. Let's test that out.

Select the webhook and click the "Test Delivery" button.

Switch back to the OpenShift web console and browse to Builds for the webapp

You should see the new build #2 has been triggered.

Deployment Triggers

In addition to setting up triggers for rebuilding code, we can setup a different type of trigger to deploy pods. Deployment triggers can be due to a configuration change (e.g. environment variables) or due to an image change. This powerful feature will be covered in one of the advanced labs.

Rollbacks

Well, what if something isn’t quite right with the latest version of our app? Let’s say some feature we thought was ready for the world really isn’t - and we didn’t figure that out until after we deployed it. No problem, we can roll it back with the click of a button. Let’s check that out:

CLI Steps

Goto the terminal and type the following:

$ oc rollback webapp-1
$ oc get pods -w

OpenShift has done a graceful removal of the old pod and created a new one using the previous deployment configuration. Open the page for the webapp and refresh it. Notice it is no longer talking to the database. Let's put it back to a working state again:

$ oc rollback webapp-2

Web Console Steps

Hover over "Applications" and then click on "Deployments"

Click the "webapp" deployment config

Toward the bottom of the screen you will see a table of deployments using this deployment config

In the Deployments table click the #1

Click the "Rollback button", accept defaults, and click "Rollback" again

You can go back to the overview page to see your previous deployment spinning down and your new one spinning up. OpenShift has done a graceful removal of the old pod and created a new one using the previous deployment configuration. Open the page for the webapp and refresh it. Notice it is no longer talking to the database.

OK let's put it back to a working state again for the next lab.

Following steps just like above, Click the "Rollback button", for the previously working deployment (should be #2).

The old pod wasn’t killed until the new pod was successfully started and ready to be used. This is so that OpenShift could continue to route traffic to the old pod until the new one was ready.

You can integrate your CI/CD tools to do rollbacks with the REST API.

Summary

In this lab we saw how you can configure a source code repository to trigger builds with webhooks. This webhook could come from Github, Jenkins, Travis-CI, or any tool capable of sending a URL POST. Keep in mind that there are other types of build triggers you can setup. For example: if a new version of the upstream RHEL image changes. We also inspected our deployment history and did a rollback of our running deployment to one based on an older image.