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
