Hi, that’s great news!
On our side, we were mainly waiting for the automatic scheduled images import. We have some private base images in external registries, that are either automatically built (dockerhub), or manually (artifactoryonline), so yes, having a scheduled import is a huge win for us because it allows for automatic rebuilds. Vincent > On 18 Jan 2016, at 06:06, Clayton Coleman <[email protected]> wrote: > > In 1.2 we plan to land a number of improvements to how image streams > work that deliver on the original design goals of centralizing and > abstracting how users deal with images in multiple docker registries > in a predictable way. I wanted to provide an abstract on those > changes so people could give feedback based on their use cases today, > and see if there's additional opportunities to streamline workflows on > OpenShift. > > > ## Importing images from V2 Docker registries with authentication > > This feature enables importing images based on the secrets that exist > in the current namespace. If you create an image stream that points to > a remote registry that requires auth, the pull secrets in the current > namespace will be used to authenticate you (you can create a pull > secret with 'oc secrets new-dockercfg NAME ...'). It also streamlines > the API that we use to import images, so you'll see some additional > info show up in your imported images like the size, layer info, and > the ability to selectively import specific tags with the 'oc tag' > command. It prioritizes importing tags from remote repositories based > on semantic versioning - i.e., a tag like "v5" will be imported in > preference to "v5.3.6", and improves the performance of importing in > general. > > Authentication is not currently enabled for V1 Docker registries given > the upcoming removal of support for V1 registries in the Docker > daemon. > > > ## Allow the OpenShift integrated registry to automatically proxy pull > requests to any tagged image > > This feature allows you to 'docker pull' any image that is tagged into > an OpenShift repository and resides in a V2 docker registry. This > leverages the authentication support described above, so as long as > you can authenticate to the OpenShift registry you do *not* need to > have authentication keys to remote repositories. An example: > > oc tag --source=docker mysql:5.6 mysql:latest > docker pull <integratedregistry>/<namespace>/mysql:latest > ... downloads mysql:5.6 > > This pull-through mechanism leverages content-offload, so if you have > S3 or Swift URL downloads (where the registry creates a temporary URL > that downloads directly from S3 or Swift) the OpenShift registry is > only invoked to get the manifest, and the local Docker daemon will > pull directly from your content store. > > This should open the door for centrally managing and referencing > images across the cluster - any instance of OpenShift can pull > metadata centrally but leverage content locally. > > > ## Automatically import images on a scheduled basis > > This feature lets you enable background importing of upstream Docker > image metadata into an image stream. Every X minutes OpenShift will > check to see if your upstream registry tags changed, and then > automatically import the latest metadata from the server, triggering > deployments or builds automatically. This also leverages the > improvements above, allowing you to authenticate to any V2 Docker > registry for import. > > You will be able to enable scheduled import with the tag command: > > oc tag --source=docker mysql:5.6 mysql:latest --schedule > > This will import the image immediately (making the current unique > image reference available for deployments), and then every 15 minutes > by default the Docker Hub will be checked to see if the tag has been > changed. As an administrator, you can change the frequency of these > imports and the rate at which images can be imported to limit the > impact that imports have your other registries. > > Every time OpenShift finds a new tag, the image stream will trigger > any builds or deployments that depend on the tag, which means you can > enable scheduling for your base images (things like RHEL, base images > on the DockerHub, or images built in external systems), and those > images will automatically flow into your OpenShift deployment on a > schedule. This allows production clusters to import and track images > from development clusters automatically. > > > ## Image Policy Control > > In order to give administrators more control about what runs on their > cluster, we plan to introduce policy controls as an admission > controller, with some (or all) of the following options available: > > * Control which images can be used in pods and builds > * Specify a partial match on registry, namespace, or name in either > a blacklist or a whitelist to prevent images from unknown registries > from being used in pods > * Require the image to be fully qualified to an image ID (rather > than a tag) to enforce idempotent pulls > * Require the image to have matching metadata inside of openshift > (i.e. be imported as a tag or pushed to the cluster) > * Require the presence or absence of a specific annotation or label > on the image metadata (so you can write automated processes that scan > / check images before they run on the cluster) > * Prevent images from being tagged into image repositories that don't > already exist on the platforms (for non-administrators) > * Prevent images from being built that aren't in a whitelist > > > There are other features in store - for the list above, we'd > appreciate any feedback on how they fit into your workflow and whether > they make working with images easier on your clusters. > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
