cd openshift-on-aws/modules mkdir S2i cd S2i
change to the correct lab folder
cd openshift-on-aws/modules mkdir S2i cd S2i
Clone app source code
git clone https://github.com/openshift-katacoda/blog-django-py
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.
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: https://lab2-ignitionbucket-137e1h7z6m6h0.s3-us-west-2.amazonaws.com/workshop.html [Student landing page] Find and expand your student number Follow the instructions to connect to your Cloud 9 developer IDE ./oc login api.apps.lab3-student0.egrsolutions.co.za:6443 provide the username and password for the https://lab2-ignitionbucket-137e1h7z6m6h0.s3-us-west-2.amazonaws.com/workshop.html
"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.
perform a source to image dry run
We will make use of the
new-app command with the
looks into the current working directory ".", detects python source code and determines its associated GitHub repository.
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 (
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
creates a deployment object called a
deployment configuration (DC). The deployment configuration knows:
how to re-deploy the application should the image be updated
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
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
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?
the source code is cloned.
the python builder image is launched and the code copied into it.
assemble script is executed. It knows how to build a python application.
the python dependencies are installed
the running container is committed and a new image is created
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.
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 www.example.com, 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.
Test the application
Copy the URL from the route and open that in a browser.