In the empty project, select the Add to Project button in the centre of the page.

You should be presented with the catalog browser.

If applications had previously been deployed to the project, or you were not on the project Overview page, you can use the Add to Project link in the menu bar.

In this course you are going to deploy a web application which is implemented using the Python programming language.

Select the Python category from the catalog browser. Any options for deploying applications which are related to Python will be displayed.

In the environment used for this course, the only option presented will be that for the Python Source-to-Image (S2I) builder.

For this exercise leave the version as latest, which in this environment maps to Python 3.5.

Click on Select to bring up the deployment options for the Python S2I builder.

For the Name to be given to resources, enter:

blog

For the Git Repository URL enter:

https://github.com/openshift-katacoda/blog-django-py

When you are ready, at the bottom of the page click on Create. This will take you to a splash page confirming the application has been created.

Click on Continue to overview and you will be returned to the Overview page, where you can view the details of the application created and monitor progress as it is built and deployed.

The build may take a moment to start running if the environment needs to update the S2I builder being used due to a newer version being available.

To view the output of the build as it is running, click on View Full Log. This will bring you to the Logs tab of the Pod for the build which is running.

If the build details are not visible, you can access build logs by selecting the Builds menu and then selecting Builds.

This will bring up a list of builds which are currently running, as well as builds which have completed.

Select on the build number of the last build to bring up the details for the build.

Select on the Logs tab to bring up the log output for the build.

Once the build of the application image has completed, it will be deployed, the Overview page showing the details. Click on the arrow to the left of the deployment summary to expose all the details available for the application on the overview page.

When you deploy an application from application source code using the web console, a Route will be automatically created for the application and it will be exposed outside of the cluster. The URL which can be used to access the application from a web browser will be displayed in the Overview page.

With the build and deployment completed, click on the URL and you can view the web application.

Instead of deploying the application from the web console, you can use the command line. Before we do that, lets delete the application we have already deployed.

To do this from the web console you could visit each resource type created and delete them one at a time. The simpler way to delete an application is from the command line using the oc program.

To see a list of all the resources that have been created in the project so far, you can run the command:

oc get all -o name

This will display output similar to:

buildconfigs/blog
builds/blog-1
imagestreams/blog
deploymentconfigs/blog
replicationcontrollers/blog-1
routes/blog
services/blog
pods/blog-1-build
pods/blog-1-fibfy

You have only created one application, so you would know that all the resources listed will relate to it. When you have multiple applications deployed, you need to identify those which are specific to the application you may want to delete. You can do this by applying a command to a subset of resources using a label selector.

To determine what labels may have been added to the resources, select one and display the details on it. To look at the Route which was created, you can run the command:

oc describe route/blog

This should display output similar to:

Name:                   blog
Namespace:              myproject
Created:                4 minutes ago
Labels:                 app=blog
Annotations:            openshift.io/generated-by=OpenShiftWebConsole
                        openshift.io/host.generated=true
Requested Host:         blog-myproject.2886795287-80-ollie02.environments.katacoda.com
                          exposed on router router 4 minutes ago
Path:                   <none>
TLS Termination:        <none>
Insecure Policy:        <none>
Endpoint Port:          8080-tcp

Service:        blog
Weight:         100 (100%)
Endpoints:      172.18.0.3:8080

In this case when deploying the application via the OpenShift web console, OpenShift has applied automatically to all resources the label app=blog. You can confirm this by running the command:

oc get all --selector app=blog -o name

This should display the same list of resources as when oc get all -o name was run. To double check that this is doing what is being described, run instead:

oc get all --selector app=forum -o name

In this case, because there are no resources with the label app=forum, the result will be No resources found.

Having a way of selecting just the resources for the one application, you can now schedule them for deletion by running the command:

oc delete all --selector app=blog

To confirm that the resources have been deleted, run again the command:

oc get all -o name

If you do still see any resources listed, keep running this command until it shows they have all been deleted. You can find that resources may not be deleted immediately as you only scheduled them for deletion and how quickly they can be deleted will depend on how quickly the application can be shutdown.

Although label selectors can be used to qualify what resources are to be queried, or deleted, do be aware that it may not always be the app label that you need to use. When an application is created from a template, the labels applied and their names are dictated by the template. As a result, a template may use a different labelling convention. Always use oc describe to verify what labels have been applied and use oc get all --selector to verify what resources are matched before deleting any resources.

You now have a clean project again, so lets deploy the same web application, but this time using the oc command line program.

The URL of the Git repository containing the web application is:

https://github.com/openshift-katacoda/blog-django-py

We want to deploy it using the S2I builder for the latest version of Python provided by the platform. To do this run the command:

oc new-app python:latest~https://github.com/openshift-katacoda/blog-django-py --name blog

This should display output similar to:

--> Found image 1101339 (18 hours old) in image stream "openshift/python" under tag "latest" for "python:latest"

    Python 3.5
    ----------
    ...

    Tags: builder, python, python35, rh-python35

    * A source build using source code from https://github.com/openshift-katacoda/blog-django-py will be created
      * The resulting image will be pushed to image stream "blog:latest"
      * Use 'start-build' to trigger a new build
    * This image will be deployed in deployment config "blog"
    * Port 8080/tcp will be load balanced by service "blog"
      * Other containers can access this service through the hostname "blog"

--> Creating resources ...
    imagestream "blog" created
    buildconfig "blog" created
    deploymentconfig "blog" created
    service "blog" created
--> Success
    Build scheduled, use 'oc logs -f bc/blog' to track its progress.
    Run 'oc status' to view your app.

OpenShift will assign a default name for the application created based on the name of the Git repository. In this case that would have been blog-django-py. By supplying the --name option along with the name you wish to use as an argument, as we did here, you can override the name used.

To monitor the log output from the build as it is running, run the command:

oc logs bc/blog --follow

This command will exit once the build has completed. You can also interrupt the command by typing CTRL-C in the terminal window.

To view the status of any applications deployed to the project you can run the command:

oc status

Once the build and deployment of the application has completed you should see output similar to:

In project myproject on server https://172.17.0.23:8443

svc/blog - 172.30.35.238:8080
  dc/blog deploys istag/blog:latest <-
    bc/blog source builds https://github.com/openshift-katacoda/blog-django-py on openshift/python:latest
    deployment #1 deployed 4 minutes ago - 1 pod

View details with 'oc describe <resource>/<name>' or list everything with 'oc get all'.

Unlike the case of deploying the application from the web console, the application is not exposed outside of the OpenShift cluster by default. To expose the application created so it is available outside of the OpenShift cluster, you can run the command:

oc expose service/blog

Switch to the OpenShift web console by selecting on Dashboard to verify that the application has been deployed. Select on the URL displayed on the Overview page for the project to visit the application.

Alternatively, to view the hostname assigned to the route created from the command line, you can run the command:

oc get route/blog

The source code for an application isn't going to be static, so a way to trigger a new build after making any changes is required.

To do this from the command line using oc, run the command:

oc start-build blog

This should display:

build "blog-2" started

A new build could also have been triggered from the web console by going to the build configuration for the application and clicking on Start Build.

As before you can use oc logs to monitor the log output as the build runs. You can also monitor the progress of any builds in a project by running the command:

oc get builds --watch

As the build progresses, this should display output similar to:

NAME      TYPE      FROM          STATUS     STARTED         DURATION
blog-1    Source    [email protected]   Complete   2 minutes ago   1m2s
blog-2    Source    [email protected]   Running   3 seconds ago   3s
blog-2    Source    [email protected]   Complete   About a minute ago   1m9s

To exit the command when the build has completed, type CTRL-C in the terminal window.

To display information about the build configuration for the application you can run:

oc describe bc/blog

This will display output similar to:

Name:           blog
Namespace:      myproject
Created:        5 minutes ago
Labels:         app=blog
Annotations:    openshift.io/generated-by=OpenShiftNewApp
Latest Version: 2

Strategy:       Source
URL:            https://github.com/openshift-katacoda/blog-django-py
From Image:     ImageStreamTag openshift/python:latest
Output to:      ImageStreamTag blog:latest

Build Run Policy:       Serial
Triggered by:           Config, ImageChange
Webhook GitHub:
        URL:    https://172.17.0.18:8443/oapi/v1/namespaces/myproject/buildconfigs/blog/webhooks/wrmDd4vYVA9J0NWB0Eaw/github
Webhook Generic:
        URL:            https://172.17.0.18:8443/oapi/v1/namespaces/myproject/buildconfigs/blog/webhooks/TjJ9AP7__NbNVaqC7vIk/generic
        AllowEnv:       false

Build   Status          Duration        Creation Time
blog-2  complete        1m9s            2017-06-01 02:07:15 +0000 UTC
blog-1  complete        1m2s            2017-06-01 02:05:11 +0000 UTC

...

You can see details of the Git repository being used as the source for any build.

You will also see listed a Webhook URL that can be configured into a Git hosting service to trigger a new build automatically when changes are committed and pushed up to a Git repository. As you are using a Git repository on GitHub that you don't own this can not be done for this exercise, but if you had forked the Git repository into your own account, or this was your own application, it could have been configured.

The typical workflow followed when developing an application, is to work on your application source code on your own local machine. When you are happy with changes and they are ready to be made live, commit the changes and push them up to the hosted Git repository linked to the build configuration. If a webhook has been configured, a new build and deployment would be triggered automatically, otherwise you can trigger a new build manually.

In the case of where you are rapidly iterating on changes to test ideas and don't want to have to commit every change and push it back up to the hosted Git repository, you can use what is called a binary input build.

To demonstrate this, clone the Git repository for the application by running:

git clone https://github.com/openshift-katacoda/blog-django-py

This will create a sub directory blog-django-py containing the source code for the application:

Cloning into 'blog-django-py'...
remote: Counting objects: 125, done.
remote: Total 125 (delta 0), reused 0 (delta 0), pack-reused 125
Receiving objects: 100% (125/125), 22.59 KiB | 0 bytes/s, done.
Resolving deltas: 100% (45/45), done.

Change into the sub directory.

cd blog-django-py

To show how a build can be triggered from the local copy of the application source code, without needing to commit changes back to the Git repository, first run the command:

echo 'BLOG_BANNER_COLOR=blue' >> .s2i/environment

This command will update an environment variable setting file used by S2I to determine what environment variables are baked into the application image created.

Start a new build by running the command:

oc start-build blog --from-dir=. --wait

This is similar to what you ran before, with the exception that the option --from-dir=. is also passed to the command, indicating that source code should be uploaded from the directory on the host where you are running the command, rather than it being pulled down from the hosted Git repository.

The output from running the command should start with:

Uploading directory "." as binary input for the build ...

indicating that the source code is being uploaded.

The --wait option is also supplied to indicate that the command should only return when the build has completed. This option can be useful if integrating it into a script and you need to ensure the build has completed before running a subsequent command.

While the build command is running and the application is being deployed, switch to the web console to monitor progress.

Once the build and deployment is finished, if you visit the web application once more, you will see that the banner colour has been changed to blue.

When you use the --from-dir=. option with oc start-build, the contents from the current working directory will only be used for that one build. If you wanted to run further builds with source code from your local directory, you would need to supply --from-dir=. each time.

To return back to using the source code from the hosted Git repository, run:

oc start-build blog

This should output:

build "blog-4" started

If for some reason a build was wrongly started, or you realised it would fail anyway, you can cancel the build by running oc cancel-build and supplying the name of the build.

oc cancel-build blog-4

This should show the build has been cancelled.

build "blog-4" cancelled

You can confirm this by also looking at the list of all builds run.

oc get builds

This should display output similar to:

NAME      TYPE      FROM             STATUS      STARTED          DURATION
blog-1    Source    [email protected]      Complete    12 minutes ago   2m36s
blog-2    Source    [email protected]      Complete    8 minutes ago    1m9s
blog-3    Source    [email protected]   Complete    6 minutes ago    1m10s
blog-4    Source    [email protected]      Cancelled   18 seconds ago   10s

Note that starting a build using source code from a local directory on your own machine can only be done from the command line. There is no way to trigger such a build from the web console.