This tutorial is part of the Learning path: Deploying Red Hat OpenShift Container Platform 4.x on IBM Power Systems Virtual Servers.
Red Hat® OpenShift® Source-to-Image (S2I) is a framework that makes it easy to write images that take application source code as input and produce a new image that runs the assembled application as output. The main advantage of using S2I for building reproducible container images is the ease of use for developers.
In this tutorial, you’ll learn how to use the OpenShift S2I feature with a cluster deployed on IBM® Power Systems™ Virtual Servers. We’ll use a sample pyFlask (Python-based popular web framework) application hosted on GitHub. Additionally, you’ll learn how to set up GitHub webhook to notify OpenShift of new code push/commit events in GitHub, such that OpenShift will auto-rebuild and auto-redeploy the application using the latest code changes in your GitHub repository.
To enable continuous deployment using the OpenShift S2I feature, make sure that the following prerequisites are fulfilled:
- Access to the OpenShift cluster in Power Virtual Server (we used OpenShift Container Platform version 4.6.9)
- Familiarity with GitHub basic operations (clone/create repo, create and update files in repo, and so on)
To enable continuous deployment using the OpenShift S2I feature as mentioned in this tutorial takes around 30 minutes.
1. Create an OpenShift project to deploy the application.
Click the Projects tab and on the Projects page, click Create Project.
In the Create Project dialog box, enter project details such as name, display name, and description and click Create.
On the Project page, verify that the project is created.
Tip: If there are multiple projects, you can use filters to quickly search for the project.
2. Clone the GitHub repo.
A simple pyFlask app with three API endpoints (root, version, and test) is hosted in the following link:
You need to fork this repository because you will be making changes to the GitHub code as part of this use case which will need owner privileges.
3. Create a new deployment from your GitHub repo.
In the OpenShift GUI, switch to the Developer persona and click +Add to create a new deployment. Then, click the From Git option. Ensure that you have selected the pyflask-demo project we created earlier for this demo.
Fill the Import from Git form with the required details.
Note: Do not forget to add your GitHub repo path in the respective field.
Ignore the Unable to detect builder image message if it appears.
Because OpenShift failed to auto-detect the source code language, we need to select it manually. Click the Python builder image.
Enter a unique name for OpenShift to use for the application and the resources it will create as part of this deployment.
OpenShift in Power Virtual Server by default only supports secure (HTTPS) routes. So you will need to make some config changes. Click Routing, and in the Routing form, select the Secure Route checkbox to enable TLS edge termination.
Retain the default values for the remaining fields and click Create.
In the Topology view, click your application. In the Deployment view, wait for the build to complete and the pod to be in Running state.
What happens here is that OpenShift builds the container image (using the Python builder image and your source code from your GitHub repo), creates a Docker image, uploads the image to the OpenShift internal image registry, and creates a pod using that Docker image.
4. Verify that the pyFlask app is running successfully.
In the Topology view, click the s2i-pyflask application, scroll down to the bottom of the resources page, and click the Routes URL.
The URL opens in your browser and displays the “Hello World….” message as mentioned in the pyFlask application GitHub source code (refer to the
app.py's hello_world()function which maps to the root endpoint).
Note: While opening this URL for the first time, if you encounter a browser security warning, click Advanced and continue to open the URL.
Similarly, open the /version and /test endpoints, and notice that the appropriate message as encoded in the application’s GitHub source code is displayed.
This proves that the pyFlask application that was deployed from the GitHub source is working as expected.
You have now successfully deployed a pod directly from your GitHub repo.
5. Set up GitHub webhook to notify OpenShift of GitHub events and set up auto deployment.
Github webhooks allow external services to be notified when certain GitHub events happen.
Continuous deployment means updates to the GitHub source code must automatically deploy new pods. For this to work, we need to configure our GitHub repo with the webhook that OpenShift provides as part of the BuildConfig attribute.
This is best achieved using the GUI.
On the BuildConfigs page, click your buildconfig entry and scroll down to find the Generic webhook and click Copy URL with Secret.
Navigate to your GitHub repo, and under Settings, click the Webhooks tab and add a new webhook using the copied URL from the previous step.
Enter the copied URL in the Payload URL field, select the application/json option from the Content type list, and click Disable (not recommended) for SSL verification. Retain the default values for the remaining fields and click Add webhook.
If successful, notice that your newly added webhook is displayed on the Webhooks page.
Click your newly added webhook to see details. GitHub generally does a simple ping test as part of adding a new webhook. Scroll down to the Recent Deliveries section and notice that an entry prefixed with a tick mark (indicating that the ping test is successful) is displayed. Click the entry to find more details about the REST API call and the associated response for the ping test.
A successful ping test (Response 200) would mean that GitHub is able to connect with your OpenShift cluster.
You have now successfully set up the GitHub webhook.
6. Change source code in GitHub and verify that pod is auto deployed.
Let’s now make a small change in source code by changing the version to 2.0 in app.py. This should trigger a push event from GitHub to the OpenShift and in turn causes OpenShift to rebuild the Docker image and redeploy our pod using the newly built Docker image.
Open the app.py file and in the
get_version()function, change the version from
Scroll down, add a commit message, and click Commit changes.
Then, switch to your OpenShift GUI, switch to the Developer persona/view, click the s2i-pyflask application, and watch a new build getting triggered automatically.
After this build is complete, a new Pod will be auto deployed using the new Docker image that got created from this build.
Switch to the Administrator persona/view, click Workloads, and then click Pods. Notice that the old pod is being terminated and new pod is being created.
Switch back to the Developer persona/view, click Topology, select the s2i-pyflask application to open the resources window, and scroll down to the Routes section.
Click route URL and access the /version endpoint.
Note that the router URL is unchanged while we moved from version 1 to version 2 of our application. So, if you already have the /version endpoint URL opened (as part of the earlier step), you can just refresh it.
Notice that the container is indeed running the newer version of the application!
If you go to your GitHub webhooks view, you can see a new entry under Recent Deliveries, which maps to the recent notification delivered by GitHub to OpenShift in response to the code change (push/commit) operation (version change) we did.
Click the recent delivery and notice the Response 200 message indicating successful rebuild and redeployment of the pod in our OpenShift cluster.
Congratulations, you have successfully used OpenShift S2I capability on an OpenShift cluster running in Power Virtual Server. In this tutorial you learnt how to deploy an application in OpenShift cluster directly from a GitHub-hosted source code, set up the connection between OpenShift and GitHub using webhooks, and ensure that the new code changes to source code repository results in a new version of the application being deployed automatically in an OpenShift cluster.