Running faster with Source to image

Step 1

change to the correct lab folder

cd openshift-on-aws/modules
mkdir S2i
cd S2i
Step 2

Clone app source code

git clone

In this module you will use Source to Image to build and launch the voting application on OpenShift.

Taking code and moving to containers results in developers writing code for their applications then defining all the parts needed to containerize the application and then further add templates or spec files which are used by orchestrators.

OpenShift attempts to make it easire and faster for developers to get code running on the platform.

Source 2 Image (s2i) does the following:

  • Launches a container from a "builder image" of the matching runtime. In this case that’s a python 2.7 builder image.

  • Executes a build of the application in the running builder container.

  • After a successful build, s2i commits a new image containing the built application and pushes it into the internal registry of OpenShift.

  • The container is launched because a new image has been created. If the container is already running from a previous build, the container will be re-deployed.

    Step 3

    Connect to the OpenShift cluster using the cli

Connect to your Cloud 9 dev ui if you have not already done so.
Connect to the workshop student landing page: [Student landing page]
Find and expand your student number
Follow the instructions to connect to your Cloud 9 developer IDE

./oc login
provide the username and password for the

"oc new-app" is the command that initializes an application in various ways on OpenShift. You will use it to get your source code running on OpenShift.

Step 4

perform a source to image dry run

We will make use of the new-app command with the --dry-run

  1. looks into the current working directory ".", detects python source code and determines its associated GitHub repository.

  2. creates a build object called a build configuration (BC). The build configuration knows:

    • the location of the repository which holds the python builder image

    • where to fetch the source code from, e.g. the GitHub repository

    • knows the name of the output image which will be pushed into the internal container registry (vote-app)

  3. creates an image streams (IS) (a.k.a. OpenShift image objects) to track the builder and the final application image

    • these image streams are able to detect when images are updated and trigger a rebuild or a re-deployment of the application

  4. creates a deployment object called a deployment configuration (DC). The deployment configuration knows:

    • how to re-deploy the application should the image be updated

  5. creates a service object to enable discovery and access to one or more running application containers.

If there are no warnings or errors and all looks well, execute the command without the --dry-run option:

Step 5

Deploying an application using S2i

oc new-app python:3.6~. --name blog-django --dry-run
  • Note: Normally the "new-app" command would automatically select a matching builder image based on the source code but since our code specifically requires Python version 2.7 to function properly we explicitly provide the name and version of the builder image we want to use (python:2.7).

Now that we dry run is complete and we are not seeing issues we can run the new-app command to generate all these builing blocks from the application code and save us time and effort.

oc new-app python:3.6~. --name blog-django

This command will have listed out all the OpenShift objects that were created.

<!-- - Note: Should the build configuration already exists from a previous invocation, start the build again with the following command:

oc start-build blog-django


You can follow the build process in the console and also on the command line, like this:

oc logs bc/blog-django --follow

To view the output of the build in the console, click on the build (vote-app-1) and then on the Logs tab:

Wait for the build to finish before continuing.

Note, the build takes a few minutes, especially the Copying blob…​ and the Storing signatures operations can be slow.

What happens during the build?

  1. the source code is cloned.

  2. the python builder image is launched and the code copied into it.

  3. the s2i assemble script is executed. It knows how to build a python application.

  4. the python dependencies are installed

  5. the running container is committed and a new image is created

  6. the image is then pushed into OpenShift’s internal container registry

After the build has completed, the image is automatically launched and a container in a pod is created.

Step 6

Expose the application for testing

By default, the application is not accessible from outside of OpenShift. Now, expose the application to the external network so it can be tested:

oc expose svc blog-django

The above command creates a route object. An OpenShift Container Platform route exposes a service at a host name, like, so that external clients can reach it by name.

Check the route object:

oc get route

You should see the hostname to use to access the application.

Step 7

Test the application

Copy the URL from the route and open that in a browser.