INTRODUCTION

The need for a storage solution designed for container images arises as platforms like Kubernetes become the new standard for cloud-native application development. Traditional blob storage doesn’t address layered file systems and other aspects of container image artifacts. Container image storage should be secure, fast and stable at scale, and automation-friendly. This technology overview discusses the features all container registries share and the necessary feature set of an enterprise grade container image registry.

CONTAINER TECHNOLOGY OVERVIEW

Containers allow organizations to run their applications reliably in any computing environment by encapsulating all of an application’s dependencies. This self-contained artifact is referred to as a container image. One or more running container instances can be created from a container image. These images are then run on an orchestration platform like Red Hat^® OpenShift^®. The container image encapsulates everything an application needs, including the code, system tools and libraries, and generic settings.

While hypervisor-isolated virtual machines (VMs) similarly offer portability, containers offer an abstraction between the operating system system and application levels, which consumes fewer resources than a VM. Linux kernel features such as namespaces and cgroups work together to isolate running containers, making it possible to safely share the underlying compute resources. Containers are suitable for automated, highly dynamic scaling, and for automated migration in failure cases, because they decouple applications from individual hosts, often referred to as “compute nodes.” The discrete nature of software containers can help teams decompose complex feature sets into architecturally independent microservices that can be rapidly and independently iterated.

Container adoption has accelerated over the last several years. According to a report by Datadog, container usage increased by 40% between 2016 and 2017. Once an organization begins down the path of containerization, its proliferation often accelerates. The same report found that container adoption quintupled in production in the first 10 months.

To be able to deploy containers, container orchestrators require a registry where images are stored. Consequently, container registries are now a critical part of a modern software deployment pipeline.

CONTAINER REGISTRIES

Container adopters can choose generic blob artifact storage or a container-specific registry solution for storing images. Generic storage solutions typically treat images like binary objects and are severely limited in their ability to inspect inside the container image. However, container images use layered file systems and often come with a manifest that details what is inside. This allows container-native tools to perform more detailed auditing, security scanning, and performance optimization. Image registries are designed specifically for container images, so they provide a more robust, scalable, and better informed solution.

The registry specification was recently made independent via the Open Container Initiative (OCI) Distribution Specification project. All container registries on the market today have the core functionality in this specification: the upload (push) and download (pull) of container images. However, many organizations need a registry with additional features to make it suitable for use within their environments.

ENTERPRISE REGISTRY REQUIREMENTS

An enterprise-ready registry should have security at the center of its design. It should:

• Support multiple authentication systems.
• Come with role-based access control (RBAC) management to ensure fine-grained access control of the registry.
• Use vulnerability scanning capabilities to prevent compromised images from being deployed.
• Record all registry activity in auditable logs so administrators can trace any activity back to a single user.

An enterprise registry must be robust and fast at scale, highly available, geographically replicated, and optimized for automation. Robot accounts and git hooks reduce the possible amount of human error and lag time from the deployment process. Garbage collection should also be automated and require no downtime.