A container registry is a repository—or collection of repositories—used to store and access container images. Container registries can support container-based application development, often as part of DevOps processes. Container registries can connect directly to container orchestration platforms like Docker and Kubernetes.
Container registries save developers valuable time in the creation and delivery of cloud-native applications, acting as the intermediary for sharing container images between systems.
A container image includes the files and components that make up an application. In contrast to virtual machines (VMs), containers are lightweight packages of software that run on top of the Linux® operating system (OS). Container images can be multiplied to scale as workloads change. They are commonly associated with agile development, DevOps methodology, and continuous integration and continuous delivery (CI/CD).
Container images include system libraries, system tools, and other platform settings that your apps need to run—giving developers the benefits of portability and agility to quickly expand on or create new apps.
An open source tool like Buildah lets you create OCI- and Docker-compatible images—with or without Dockerfiles or an existing container image starting point—taking a lot of guesswork out of the process.
When developing container images, you need somewhere to save, share, and access them as they are created, and that’s where a container registry comes in.
A container registry essentially acts as a place for developers to store container images and share them out via a process of uploading (pushing) to the registry and downloading (pulling) into another system, like aKubernetes cluster.
Once you pull the image, the application within it can be run on that system.
In addition to container images, registries also store application programming interface (API) paths and access control parameters for container-to-container communication. APIs help eliminate unintended coupling that restricts change and is a common source of outages, especially in hybrid cloud environments where applications no longer reside in the same data center.
Container images can also communicate over a service mesh, an infrastructure layer between containerized services that helps with scaling. For cloud-native apps built in a microservices architecture, a service mesh is a way to comprise a large number of discrete services into a functional application.
The Cloud Native Computing Foundation says containers (including container images and registries) and microservices are the foundation for cloud-native app development. Containers and microservices are fully self-contained, making them a powerful tool for creating portable, cloud-native applications.
Containers isolate the application processes, runtime files, and OS dependencies from the rest of the system. They promise greater portability across hybrid cloud environments and can be deployed for much shorter periods of time than virtual machines (VMs). This makes it easier for developers to push to and pull what they need from a container registry, allowing them to focus on building a great product, without the distraction of underlying infrastructure or execution details.
In a DevOps environment, the use of containers—and container images/registries—allow developers to deploy each application service independently, eliminating the need to merge code changes, improving testing, and helping with fault isolation in both testing and production.
There are 2 types of container registries: public and private.
Public registries are commonly used by individuals or small teams that want to get up and running with their registry as quickly as possible. However, as their organizations grow, this can bring more complex security issues like patching, privacy, and access control that can arise.
Private registries provide a way to incorporate security and privacy into enterprise container image storage, either hosted remotely or on-premises. These private registries often come with advanced security features and technical support.
Most cloud providers offer private image registry services:Google offers the Google Container Registry, AWS provides Amazon Elastic Container Registry (ECR), and Microsoft has the Azure Container Registry.
Using a private, internal registry affords the greatest potential for security and configuration, but it requires careful managing and ensuring the registry’s infrastructure and access controls stay within your organization.
Some important things to to consider when choosing a private container registry service for your enterprise include:
Support for multiple authentication systems
Role-based access control management (RBAC) for local images
Vulnerability scanning capabilities for enhanced security and configuration
Ability to record use in auditable logs so that activity can be traced to a single user
Optimized for automation
A private registry’s enterprise-ready features allow organizations to internally access container images in a secure and efficient manner. Multiple authentication systems put measures in place to verify the container image stored in it.
For example, the image must be digitally signed by the person uploading it before it can be pushed to the registry, as well as to enable activity tracking and prevent unauthorized user uploads.
RBAC manages which user actions are allowed based on the individual’s role. A developer would need access to upload to and download from the registry, while a team member or tester would only need access to download. For organizations with a user management system like Active Directory (AD) or lightweight directory access protocol (LDAP), that system can be linked to the container registry directly and used for RBAC.
A company can choose to create and deploy their own container registry, or they can choose a commercially-supported private registry service.
Red Hat® OpenShift® is an enterprise-ready Kubernetes container platform that offers consistency across any cloud infrastructure—managing hybrid cloud, multicloud, and edge deployments. Through Red Hat OpenShift, an environment for a new microservice or application can be provisioned in minutes. In addition to other cloud services like middleware, languages, frameworks, and databases, it already includes a private registry that provides basic functionality to manage your container images.
Private registries can be deployed as part of a Red Hat OpenShift-managed service on a cloud provider from Red Hat’s rich partner ecosystem, offering a seamless experience on Azure, Amazon Web Services (AWS), IBM Cloud, or Google Cloud. Red Hat OpenShift supports integration with other private registries you may already be using, such as JFrog’s Artifactory and Sonatype Nexus.
Red Hat also offers self-managed services that build on its hybrid cloud foundation with enhanced security features and additional software elements you might use in your data center. If you need more advanced security and technical support functionalities,Red Hat Quay is available as a standalone, scalable enterprise registry option.