Deploying an application from source

Often as a team supporting applications on OpenShift the decision of which deployment method to use will be out of your hands instead be determined by the vendor, organisation or team producing the application in question.

However, for an interesting scenario let's explore the possibility of what we could do if there is no existing deployment tooling in place and all we are given is a codebase in a git repository.

This is where the concept of Source to Image or "s2i" comes in. OpenShift has built in support for building container images using source code from an existing repository. This is accomplished using the source-to-image project.

OpenShift runs the S2I process inside a special Pod, called a Build Pod, and thus builds are subject to quotas, limits, resource scheduling, and other aspects of OpenShift. A full discussion of S2I is beyond the scope of this class, but you can find more information about it in the OpenShift S2I documentation.

6.1 - Starting a source to image build

Deploying an application via an Source to Image is straightforward. Let's try it out.

Start in the +Add view of the Developer perspective.

Click Import from Git under the Git Repository tile.

Source to Image supports a number of popular programming languages as the source. For this example we will use Python.

Enter https://github.com/openshift-roadshow/nationalparks-py.git for the Git Repo URL.

OpenShift will automatically guess the git server type and the programming language used by the source code. You will be now asked to select an Import Strategy. You have three options:

• Devfile: this will use Devfile v2 spec to create an application stack. The repo has to contain a file named devfile.yaml in the Devfile v2 format.

• Dockerfile: this will create a Container image from an existing Dockerfile.

• Builder Image: this will use a mechanism called Source-to-Image to create automatically a container image directly from the source code.

Select Builder Image strategy as we are going to create the container image directly from the source code.

Select Python as the Builder Image type and Python 3.8-ubi8 as the Builder Image Version.

Scroll down and under the General header click the Application drop down and select Create application entering workshop as the name.

Scroll down reviewing the other options then click Create.

6.2 - Monitoring the build

To see the build logs, in Topology view of the Developer perspective, click the nationalparks python icon, then click on View Logs in the Builds section of the Resources tab.

Based on the application’s language, the build process will be different. However, the initial build will take a few minutes as the dependencies are downloaded. You can see all of this happening in real time!

From the oc command line utility, you can also see Builds, let's open our Web Terminal back up and take a look:

oc get builds

You will see output similar to the example below:

NAME                     TYPE     FROM          STATUS     STARTED         DURATION
nationalparks-py-git-1   Source   Git@f87895b   Complete   7 minutes ago   48s

Let's also take a look at the logs from the oc command line with:

oc logs -f builds/nationalparks-py-git-1

After the build has completed and successfully:

• The S2I process will push the resulting image to the internal OpenShift image registry.

• The Deployment (D) will detect that the image has changed, and this will cause a new deployment to happen.

• A ReplicaSet (RS) will be spawned for this new deployment.

• The ReplicaSet will detect no Pods are running and will cause one to be deployed, as our default replica count is just 1.

To conclude, when issuing the oc get pods command, you will see that the build Pod has finished (exited) and that an application Pod is in a ready and running state.

6.3 - Bonus objective: Podman

If you have time, take a while to understand how Podman can be used to build container images on your device outside of an OpenShift cluster.

Awesome you've finished exercise 6! 🎉