Choosing a Registry for OpenShift

2016 年 9 月 2 日Dan McPherson3 分 (読了時間の目安)

When deploying OpenShift, everyone has to pick whether they want to use OpenShift's integrated registry or bring their own. Let's break down the differences with each option.

Automated Updates

OpenShift provides a feature known as Image Change Triggers which are applicable to builds and deployments. This feature is really the core of what makes containers consumable. I say that because containers, for all the benefits they entail, bring along a major problem in image maintenance.

Namely, every time a package/library needs an update, every image containing that package/library has to be rebuilt and redeployed.

If that package/library is introduced a lower level image layer, an update could require hundreds or even thousands of rebuilds and subsequent redeploys. Image Change Triggers are what handle the grunt work of triggering builds and deployments all the way up every dependency chain. That, tied together with liveness/readiness checks and OpenShift's built-in CI/CD capabilities, makes it possible to maintain your image catalog and capitalize on all the promised benefits of containers.

OpenShift's support of Image Change Triggers, however, does vary between internal and external registries. The internal registry has near instant response times because the triggering logic is built into the registry. So it's able to push out notifications as soon as an image update occurs. With external registries, OpenShift is limited to polling for when an image changes. The polling interval is controlled by the scheduledImageImportMinimumIntervalSeconds setting in the master config and defaults to 15 mins. For general maintenance, such as security updates, this interval is probably good enough. But for active development, waiting up to 15 mins for a build or deployment to be kicked off will get annoying quickly.

Authentication/Authorization

One of the biggest reasons OpenShift is able to offer a great experience is because it provides an entirely integrated compute environment. Two of those integrated features that make a big difference with the registry experience are management of authentication and authorization.

Namely, if you are pushing or pulling from Image Streams located in an OpenShift project, users and service accounts within the project will automatically have the appropriate permissions to access the images.

It's also possible to access the OpenShift registry from the outside with the docker client and perform direct pushes and pulls. And while accessible within the project is the default, it's also possible to share Image Streams across projects. For example, if you wanted to promote an image from qe to stage, you would give the stage project's service account access to pull images from the qe project:

<span>oc policy add-role-to-group system:image-puller system:serviceaccounts:stage -n qe</span>

And you would probably want to tag the appropriate Image Stream to pull:

<span>oc tag qe/myapp:promote &lt;image_stream_id&gt;</span>

With external registries, the registry owns its own authentication and authorization which takes most of the magic away. Namely, the automated connection between users of an OpenShift project and the access they have to a particular set of images in the external registry is no longer applicable. OpenShift does still allow you to use images from external registries with Image Pull Secrets. For example, you can:

Create an image pull secret. Note: Other mechanisms to specify the secret are available.

oc secrets new &lt;pull_secret_name&gt; .dockercfg=&lt;path/to/.dockercfg&gt;

Then link that secret to the default service account. Note: There is a separate link action required for builds.

oc secrets link default &lt;pull_secret_name&gt; --for=pull

Manually import the tag and image metadata. Note: It's also possible to query external registries at a scheduled interval.

oc import-image &lt;image_stream_name&gt;[:&lt;tag&gt;] --from=&lt;registry:port&gt; --confirm

And you can now reference this Image Stream as you would one that used OpenShift's built-in registry.

Image Pruning

Another big advantage of using OpenShift's integrated registry is image pruning. OpenShift has the ability to prune images based on lack of references (including individual image layers), age, and size. This feature might not be super critical if you are only using containers as a production deployment mechanism because you might not mind keeping every version ever published. But for most pre-production use cases, especially development scenarios, automated pruning is probably a requirement.

User Interface

Obviously every registry interface is going to have its own advantages. But UI was probably the biggest weakness for the OpenShift registry before OCP 3.3. OpenShift previously took the approach of providing a registry but not really highlighting it. That's all changing with 3.3 as the image details, including helpful hints about how to interact with images directly, are being exposed.

What to Choose?

If you haven't already picked a registry, there are a lot of reasons to use the one provided by OpenShift. Even if you already have another registry for production use cases, it might still make sense to use the OpenShift registry for all your pre-production, or at least pre-stage, scenarios. Any environment with a large number of users or projects under active development will certainly benefit greatly from the tight integration.

執筆者紹介

Dan McPherson

類似検索

ブログ投稿

チャンネル別に見る

すべてのチャンネルを見る

Choosing a Registry for OpenShift

Automated Updates

Authentication/Authorization

Image Pruning

User Interface

What to Choose?

執筆者紹介

Dan McPherson

類似検索

チャンネル別に見る

プラットフォーム

ツール

試用、購入、販売

コミュニケーション

Red Hat について

Change page language

Red Hat legal and privacy links

Red Hat legal and privacy links