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!
Über den Autor
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit