Getting into container development but unsure about where to store your images? Perhaps your team is moving to a containerized workflow and you are determining the best cloud architecture to suit your needs. Or perhaps you have images you use for work and some you use for personal projects and aren’t sure how best to store and manage them.
Whatever the case, the choices for where to store your container images have gotten more varied and complex in recent years with the rapid growth in container technology.
For the uninitiated, container images are stored in a container registry (opens new window). That registry houses container images (i.e., the files, instructions, and other components used to create a single container instance). Developers and CI/CD processes push and pull images to and from the registry prior to performing other actions such as build, run, or scan.
Registries also provide access control functionality that dictates how images can be accessed, pulled, or updated by users, as well as what metadata is available to various audiences.
While Docker Hub is the most well-known container registry, there are plenty of options to choose from, each with their own set of features and functionality.
# Public vs. Private Registries
Most commonly, you'll hear container registries described as "public" or "private". The notion of public or private is a bit of a misnomer, as the line between public and private can be fuzzy depending on the platform. Case in point: Docker Hub has both public and private registry offerings.
Public registries are generally free and, as the name implies, open to the general public.
Public registries are often used by open source maintainers who want the general public to use their images for projects. The NodeJS Docker team (opens new window) and Rocker (opens new window) are examples of popular maintainer communities.
Public registries are also used by individual developers who don’t mind that their images can be found and used by others and just want a free place to put images for later.
Often, those using public registries will add a cryptographic signature to preserve the integrity of the original code and prevent copy-cats or abuse (which has become increasingly common in the cryptocurrency mining world).
Private registries, on the other hand, typically require a paid subscription, and are often used by companies or private parties working on projects that they don’t want others to use. They sometimes have the option to make a container or project public, but generally aren’t set up with public search functionality and all that goes along with it.
Whether a registry is public or private, the owner of the registry maintains the ability to control how users access their assets. For example, some registries choose to control access at the account level, which grants users the ability to download anything stored on a particular registry, while others grant access at the image level. Think of this as the difference between sharing an entire Google Drive with a member of your team versus sharing an individual file.
# SaaS vs. Hosted Registries
Another delineation between registry types is whether they are part of a software-as-a-service offering or hosted.
Developers are most familiar with the SaaS offerings that come from Docker, AWS, Google Cloud, and Azure. These services let you push and pull images from the command line and manage images and related metadata using a web interface, all living in the cloud and managed by the provider. They often have a public side and a paid private offering for teams or companies.
Self-hosted options — Docker Registry and Harbor being among the more popular options — are container registries managed by the user or their team. They can be run on-prem or in the cloud. These are most often used in larger organizations who value security and privacy, and have the DevOps resources to build and maintain such systems. However, some avid container enthusiasts roll their own registries for the increased flexibility, cost savings, or for the sheer challenge of the task.
# Popular Registries
There are many different types of container registries out there, with new features and functionality coming every day, so you’ll want to ensure that you look for one that meets your needs in terms of price, access, controls, and use-case.
Docker Hub (opens new window) calls itself “the world’s leading service for finding and sharing container images with your team and the Docker community.” Much like other hosting platforms, Docker hosts both public and private images. Users can gain access to free repositories by sharing their own work, or they can pay for a subscription plan. As the longest standing repository for container work, Docker has the largest variety of offerings (opens new window) in the registry space.
Although Docker Hub is often synonymous with “container registry”, it’s not the only one. In fact, DataDog's 2020 container report (opens new window) showed that almost 50-percent of containers exist in a container registry outside of Docker Hub.
Quay (opens new window) (managed by Red Hat) soon followed Docker Hub, boasting secure container storage through automatic scanning and a healthy carousel of integrations to ensure ease of use for everyone. If you’re looking for something simple to use, with an emphasis on security, Quay may be a good option for you.
The major cloud platforms also offer their own registry solutions:
Amazon ECR (opens new window), long a favorite with companies who wanted a private registry close to the rest of their cloud infrastructure, recently launched a public side, replete with all of the security features they had previously maintained on their private side. There are two key features to take into account here: immutable image tags and image scanning (opens new window). Immutable image tags ensure that nobody can override an image once it has been added to the repository, while scanning continually checks for vulnerabilities.
Google Container Registry (opens new window) features an expanded number of integrations and security features, including the ability to automatically lock risky images from being deployed. While some argue that Google Container Registry is completely private, that’s not entirely the case. According to Google (opens new window), a “container registry is publicly accessible if the host location’s underlying storage bucket is publicly accessible. Within a project, all images in each host location are either public or not.” In other words, it is not possible to give access to a particular image within a private project; images that you want to be public must be within their own, publicly accessible project.
We’d be negligent if we mentioned two of the big three without including their Microsoft counterpart. The Azure Container Registry (opens new window) offers geo-replication to manage a single registry across regions, automated container building, and integrated security.
The JFrog Container Registry (opens new window) is a hybrid registry for Docker and Helm, with options to run on-prem, in the cloud, or both. While Docker relies on Kubernetes as an orchestration system, Helm serves as a package manager for Kubernetes. JFrog targets those who want a more direct connection to the k8s clusters without having to go through Docker Hub.
And last but certainly not least, for devs who want to roll their own registries, the Harbor open source project has been around since 2018 and is a Cloud Native Computing Foundation Graduated project. It comes with all the glories and tradeoffs that most open-source projects do, but has a huge community behind it and is backed by several large companies, including VMWare, Rancher, and Aqua.
And finally, the major DevOps platforms like GitHub and GitLab have also gotten in the container registry game with directly integrated options. If you already use one of these for CI or source code management, continuing use of that same platform for your registry needs can ensure efficiency throughout your project, as you never need to package and migrate your work.
# The Future of Registries
It’s hard to deny that Docker is here to stay. With easy replication for backups and scalability, a high level of portability, and clear use cases for developers, Docker is used broadly throughout the tech industry.
Nearly 84-percent of companies using containers in production, and more than half of those environments being orchestrated. Orchestrated containers churn twelve times faster, meaning faster iteration cycles that allow for more rapid expansion. Containers will continue to drive software development at scale.
Registry providers like those listed above are the current norm, but developers often find the push/pull requirement of registries to be a pain point or a costly addition to their cloud bill, and there are innovative thinkers on the edge considering different solutions.
While completely self-built options are still a niche use case, the proliferation of monorepos and open-source projects like Nix (opens new window) could lead to innovation in how teams think about registries and their value in the future.
# Use Slim.AI to Streamline Your Use of Registries
Our goal at Slim.AI is to make container management easy and painless. The Slim Developer Platform (opens new window) allows users to search across major public container registries — including DockerHub, Quay, and Amazon ECR — and lets you connect to private registries on AWS or GCR, with more connections coming each week. This allows users to take advantage of our visualization and optimization tools across their entire container pipeline with ease.
Connecting your registries and container repositories to the Slim.AI platform or using it to start your search for the perfect container lets you take advantage of our advanced visualization tools that let you inspect, compare, and diff images.
The platform is currently in closed beta. If it’s something you’d like to see for yourself, register for an invitation to our closed beta today and join a rapidly growing community of developers looking to collaborate on tools that can shift the digital landscape.