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.
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. 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. 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]> 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]> Date: Friday, March 4, 2016 at 10:29 AM To: skotaru <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: Private registry : unable to pull On Thu, Mar 3, 2016 at 11:03 PM, Srinivas Naga Kotaru (skotaru) < [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=<****> --docker-email= > [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] > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > -- Ben Parees | OpenShift
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
