--
Srinivas Kotaru

From: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Friday, March 4, 2016 at 11:37 AM
To: skotaru <[email protected]<mailto:[email protected]>>
Cc: Ben Parees <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: Private registry : unable to pull

If you are using Openshift primarily for Devops workflows, we do not recommend 
building workflows that depend on an external registry, primarily because you 
lose fast image change triggering.  If you are looking to centralize your 
images, we recommend that you do that through global shared file storage 
backing the registry, rather than multiple registries in multiple regions.

<< We are planning to have a central global corporate repo with shared storage 
with access to all regions and zones.  Looking for a solution which has  good 
control at operations side to both apps & infra teams. Our platform is mostly 
towards running mission critical apps.   >>

Also, administrative policies around images and what can be deployed in the 
cluster will depend on that registry integration, which means if you choose an 
external registry you will be unable to centrally control image policy (like 
limiting what images can be run on the cluster, image signing, or image 
scanning and approval processes).  The upcoming atomic registry work will build 
on top of that cluster.

Future CI/CD workflow integration into OpenShift will utilize the registry to 
drive promotion of images across clusters as well as providing unified pipeline 
and test concepts.

<<I am interested to know more about approach. Where shall I get more details 
about bigger picture or what it looks like? >>

We do enable building outside the cluster and pushing in, which it sounds like 
you are describing, which allows you to control the operational pieces 
centrally.

<<Yes right>>

There are a number of techniques that can improve how the registry can scale to 
meet your operational needs - the most common is to have your core cluster 
(Devops) be the "central registry", and have the satellite clusters tag images 
from the central location.  If you are backing the registry with object storage 
(our recommendation) the content offload feature should allow nodes to pull 
from the global object store directly (which means if your object store is geo 
replicated you can pull from anywhere).


On Mar 4, 2016, at 2:23 PM, Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>> wrote:

As I said, if I toggle image to public, was able to create app.

Since we have multiple clusters, we are exploring using a single corporate 
repository to host all images. It include openshift specific and other 
certified images in our environment.  Want to avoid multiple internal repo’s 
associated with each cluster for easy operations and maintenance purpose.

We also exploring to build and deployment outside of openshift using CI/CD tool 
chain and copy final  images  central repo rather openshift repo.

That is the idea of this exercise.  We don’t want to expose all images to 
everyone and limit them to private. A special secret will be added to all 
projects and CI/CD Jenkins bot which has access to push and pull to this 
corporate repo.

--
Srinivas Kotaru

From: Ben Parees <[email protected]<mailto:[email protected]>>
Date: Friday, March 4, 2016 at 10:29 AM
To: skotaru <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: Private registry : unable to pull



On Thu, Mar 3, 2016 at 11:03 PM, Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>> wrote:
Am trying to create an app using an image from corporate private registry.

>>>>>>>>>>
# oc new-app --docker-image=myrepo/skotaru/ruby-22-rhel7 --name quayapp1

I0303 19:55:15.769901   88132 componentresolvers.go:126] Errors occurred during 
resolution: []error{(*errors.errorString)(0xc208546d00)}
F0303 19:55:15.770051   88132 helpers.go:96] error: no match for 
“myrepo/skotaru/ruby-22-rhel7", specify --allow-missing-images to use this 
image name.

<<<<<<<<<<

It is failing to create app. If I changed image type to public, am able to 
create the app.

created a secret and added it to default service account.

# oc secrets new-dockercfg repo-login --docker-server=myrepo 
--docker-username=skotaru --docker-password=<****> 
[email protected]<mailto:[email protected]>
# oc secrets add serviceaccount/default secrets/repo-login --for=pull

Am I missing anything here? Why unable to create app if image type is private?

​oc new-app now goes through the openshift internal registry to pull all 
images, so the question is how to ensure the openshift registry has the 
necessary credentials to access your private registry.  The answer to that is 
you need to create an imagestream that points to your private registry, and 
includes your credentials.

Then you can invoke new-app w/ the imagestream name.

Alternatively, if you're confident you've setup your service account 
credentials correctly, you can go ahead and use the "--allow-missing-images" 
flag and new-app will construct the DeploymentConfig despite not being able to 
confirm the image exists.

Adding Clayton in case there are more details to the registry pull-through 
feature.

​



--
Srinivas Kotaru

_______________________________________________
users mailing list
[email protected]<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users




--
Ben Parees | OpenShift

_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to