Ever felt like building a pipeline to help you with your application deployment process? It's not as difficult as you'd think and we are going to show you just how easy it is! In this blog, we will talk about how to set up a super quick code pipeline and get started with Red Hat OpenShift, so that you can be deploying faster than ever before!
This will be an end-to-end walkthrough of setting up a simple application with code hosted on Github that you can deploy into OpenShift yourself to give you a primer on the ease-of-administration when it comes to getting applications from idea to working prototype without a single SSH or FTP session required.
Git 'r Done
Let's start with the simple process and get you moving towards a more app-centric operational process. Many of my IT Ops peers are already using Git for managing some simple projects and this is how we are going to take you from code to production using a very easy example.
This process will be done using a simple setup of OpenShift which you can choose to run wherever you wish.
The Git repository we will use for our example is located here: https://github.com/discoposse/cloud-native-python-example-app
You should fork the code and then clone locally so that you can make changes to the app as part of our process.
Create and Deploy Your OpenShift Project
Your topology view will list out the current projects. This is a nifty way manage and organize the apps you’re running.
Click the create a project so you can have a new app. Name it what you want to be easy to find in your OpenShift console.
You’ll see the options for the project source which we want to use From Git for this example.
Use the URL above in the blog and you’ll see this page on Github which holds our working Python web app for a quick and fun little test of the application lifecycle.
Clicking the green code button brings up the clone URL. Your URL will be slightly different because it will be using your fork of the project.
Head back to your OpenShift console and paste into the URL field.
You’ll see the builder automatically detects it’s a Python application and you’re ready to start your build with one last check to make sure that you have the Advanced Options checked to enable a public route to the application. This is how you’re going to access the containerized app itself from the outside world.
Your app is deploying and it will just be a couple of minutes or so of waiting which you can track by watching the deployment build status.
Once the application deployment is done, click on the Topology view in the left-hand panel and under the Resources section you will find your route URL which you can click to launch the app access.
You’re app is now running live on your OpenShift environment!
That’s exciting enough as it is, but it gets better once we think about lifecycle.
Automatic Deploys Triggered by Code Updates
One of the really easy integrations with your deployment pattern is that OpenShift has webhook integration to allow external triggers to fire a new build.
Click on over to the builds section and you just need to copy the code using the Copy URL with Secret link beside the GitHub webhook.
Head back to your GitHub repository and navigate to Settings | Webhooks and create a new webhook using that copied code as the Payload URL.
NOTE: You also have to change the content type to application/json which is not the default.
Now you’ve got a webhook in GitHub to catch the push event and send it over to OpenShift automatically. That means any code commits will trigger a build with the latest code from the repository.
In the example app you can do this by updating the app.py file with some text changes, add the file using git add app.py followed by a git commit -m "updated content" and then a git push back to the repository.
And as if by magic, the build will complete and you refresh the page to see your updated HTML code live in the public-facing site.
The Value of Code, Commit, Deploy.
This is just a simple example to illustrate the workflow. Now you know that you can do this type of very low-lift lifecycle for the application. Your development team can easily have a dev version of the project for rapid rollouts and easy testing.
Adding simple workflows like pre-checks for container builds and automated code testing is not far because you have the flow already in place to go from idea to working prototype with a simple code commit.
You can try this out yourself using the same steps and expand out with some more intermediate and advanced use-cases now. What's to stop you from building your own test app? Now that we have all the underlying infrastructure and deployment workflow ready, it's a magical world ahead.
The real value comes from reducing the need for hand offs, code copying by FTP, SSH to a machine to deploy, which is the underpinning of many "traditional" deployment processes. As an Ops person myself, I had to build a lot of infrastructure to make this type of workflow using many systems and lots of hand-build deployment scripts.
Say hello to the new world and stay tuned to the blog for more advanced examples!