This post will cover how to deploy an application using a container image stored in the internal OpenShift image registry. The first part of the series covered deploying from the web console UI and an external image registry. The second part covered deploying with the oc command line tool.

Importing Application Images

When you deploy an existing container image which resides on an external image registry, the image will be pulled down and stored within the internal OpenShift image registry. The image will then be copied to any node in the OpenShift cluster where an instance of the application is run.

In order to track the image that is pulled down, an Image Stream resource will be created. You can list what image stream resources have been created within a project by running the command:

oc get imagestream -o name

This should yield the output:

imagestream/blog-django-py

To show further details about the image stream source, run this command:

oc describe imagestream/blog-django-py

This should yield output similar to this:

Name:               blog-django-py

Namespace:          myproject

Created:            4 minutes ago

Labels:             app=blog-django-py

Annotations:        openshift.io/generated-by=OpenShiftNewApp openshift.io/image.dockerRepositoryCheck=2017-03-20T02:51:09Z

Docker Pull Spec:   172.30.125.109:5000/myproject/blog-django-py

Image Lookup:       local=false

Unique Images:      1

Tags:               1
latest
 tagged from openshiftkatacoda/blog-django-py

* openshiftkatacoda/blog-django-py@sha256:43e78e610a3181a4b710f938598acaf43d511ab38c4e84a98e59f29dbdb62c62
 4 minutes ago
 

In the details of the image stream which was created, you will see that the label app=blog-django-py was applied, identifying the image as relating to this one deployment. Consequently, when the application was deleted by using a label selector with the same value, the image stream was also deleted.

When you are deploying only a single instance of the application from the image, this is reasonable, but if you need to deploy multiple instances of an application from the same image but with different names, you should import the image as a separate step before attempting to deploy the image.

Once more, delete the application which was already deployed.

oc delete all --selector app=blog-django-py

Check that all the resource objects have been deleted by running:

oc get all -o name

Now, import the existing container image explicitly by using this command:

oc import-image openshiftkatacoda/blog-django-py --confirm

This should yield this output:

The import completed successfully.
Name: blog-django-py
 Namespace: myproject
 Created: Less than a second ago
 Labels: <none>
 Annotations: openshift.io/image.dockerRepositoryCheck=2017-03-20T03:2035Z
 Docker Pull Spec: 172.30.235.4.:5000/myproject/blog-django-py
 Image Lookup: local=false
 Unique Images: 1
 Tags: 1
latest
 tagged from openshiftkatacoda/blog-django-py
* openshiftkatacoda/blog-django-py@sha245:43e78e610a3181a4b710f938598acaf43d511ab38c4e84a98e59f29dbdb62c62
 Less than a second ago

...
 

These are the details of the image stream created.

Note that no labels have been applied this time.

Verify that only the image stream has been created, and no other resource objects:

oc get all -o name

To deploy an instance of the application from the image stream which has been created, run this command:

oc new-app blog-django-py --name blog-1

This is using the image stream name, not the full name that identifies the image as being on the Docker Hub Registry.

This should yield output similar to this:

--> Found image d29f1bb (2 days old) in image stream "myproject/blog-django-py" under tag "latest" for "blog-django-py"
 Python 3.5
 ----------
 ...
 Tags: builder, python, python35, rh-python35
 * This image will be deployed in deployment config "blog-1"
 * Port 8080/tcp will be load balanced by service "blog-1"
 * Other containers can access this service through the hostname "blog-1"

--> Creating resources ...
 deploymentconfig "blog-1" created
 service "blog-1" created
 --> successful
 Run 'oc status' to view your app.
 

Jump back to the OpenShift web console, click on Add to Project in the menu bar, then click on Deploy Image.

This time, select Image Stream Tag, and from the drop-down menus, select the project myproject and the image stream blog-django-py with tag latest.

Change the Name to be used for the deployed application to blog-2. Click on Create at the bottom of the page to start the deployment.

From the command line, list all the resources which have been created.

oc get all -o name

This should yield output similar to this:

imagestreams/blog-django-py

deploymentconfigs/blog-1

deploymentconfigs/blog-2

replicationcontrollers/blog-1-1

replicationcontrollers/blog2-1

services/blog-1

services/blog-2

pods/blog-1-1-mzpbf

pods/blog-2-1-d2snt

You will see a deployment config, replication controller, service, and pod for each instance of the application. Only the one image stream exists corresponding to the initial image import that was run.

Delete each application by running:

oc delete all --selector app=blog-1

oc delete all --selector app=blog-2

When the resource objects for each instance of the application have been deleted, you should be left with just the image stream object.

oc get all -o name

Therefore, importing the existing container image beforehand means that it is retained when any application instance using it is deleted. Isn't that helpful?

Summary of Part Three

In this series of posts, we went over deploying an existing container image in OpenShift. We first did this by deploying an image directly from an external image registry with the web console, and then deployed it again using oc in the command line. In this final post, we imported an image into the OpenShift internal image registry, and deployed the application from there.

Here's a summary of the key commands used. To see more information on each oc command, run it with the --help option.

  • oc new-app <image-stream> --name <name>: Deploy an application from a container image found in the internal image registry. If there is any ambiguity as to the source of the image, use the --image-stream option.
  • oc import-image <docker-image> --confirm: Import a container image found on an external image registry, which will cause it to be pulled into the internal image registry.

Would You Like to Learn More?

This post is based on one of OpenShift’s interactive learning scenarios. To try it and our other tutorials without needing to install OpenShift, visit: https://learn.openshift.com

Do you have an OpenShift Online account? There's no reason to wait. Get your applications running in minutes with no installation needed. Sign up for the free trial of OpenShift Online.

What other topics would you like to see in the future on this blog? We're happy to make tutorials about anything that helps you with your OpenShift experience. Comment and let us know!