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-streamoption.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!
저자 소개
유사한 검색 결과
Red Hat and Sylva unify the future for telco cloud
NetApp’s certified OpenShift operator for Trident
Edge computing covered and diced | Technically Speaking
SREs on a plane | Technically Speaking
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래