Getting Started With Container Registries

The explosion of the use of containers for software development and deployment brings about a need for proper storage and organization of the images these containers are based on. There are multiple container registry solutions available with a variety of feature sets to consider. Some solutions are more comprehensive than others, and it’s important to understand the purpose of container registries, how they function, and ways they can best suit an organization's needs.

Container registries serve as libraries for third-party container images required during the build phase of a software development pipeline, as well as images produced that are intended for deployment to test, staging, and production environments.

Public container registries like Docker Hub play a valuable role in the container ecosystem by providing a way to make container images easily available to developers. Popular images include those for applications and services commonly used in microservices architectures, such as databases (postgres, mysql), messaging solutions (redis), and programming language environments (python, golang, openjdk). While relying solely on Docker Hub for these images is convenient, there are some important reasons to consider storing the container images that your organization relies on in an internal container registry solution.

There are two types of container images you will use in your projects:

1. Images you produce
2. Images that are dependencies of the images you produce

Just like other third-party packages and dependencies your software requires to build and operate successfully, your container images are also essential building blocks that should be organized and managed carefully. Losing a dependency required by your software development and deployment pipelines to run and complete successfully equates to loss of development time and increased risk that your application or service will not function as intended. Also, frequently re-building your code is prone to error — there is no guarantee that you will get a consistent build each time, whereas your binaries are immutable.

Choosing a reliable, secure container registry and integrating it into your pipelines is a critical step to mitigating interruptions of your build processes and will increase your confidence in your deployments.

This is a preview of the Getting Started With Container Registries Refcard. To read the entire Refcard, please download the PDF from the link above.

The following terminology is essential to know when discussing containers and their source images. Also, understanding the concepts around image format and how images are stored on your filesystem will allow you to make better decisions regarding managing the sharing and distribution of your container images.

Container Terminology

Container

A container is the encapsulation of an application and all of its required dependencies and system resources running within an isolated “space” on a host machine. Containers share the host machine’s operating system and kernel, but they utilize low-level features that allow isolation between processes running inside the container and other processes on the same host. Containers enable the portability of an application or service between different computing environments without the risk of changes in behavior because of differing dependency sets.

Container Image

A container image is an immutable, executable binary that provides all of the dependencies and configuration required for creating a container. It encompasses all of the environment configuration and explicitly defines all of the resources to which a container will have access after it is launched. Images can be thought of as a snapshot of a complete filesystem stored as an archive that can be unpacked and run within the context of a collection of root filesystem changes.

Using Docker (which requires the installation of Docker Engine) is a common way of building container images. Building images with Docker also requires a text file called a Dockerfile, a file that serves as the blueprint for a container that explicitly defines the image environment, dependencies, and other configurations. However, there are other options available that use existing Dockerfiles or an equivalent of a Dockerfile to build images. Some examples are buildah, orca-build, img, and kaniko.

Base Image

Images can inherit from other images, and many are built from an initial set of dependencies and configurations that come from a base image. Commonly used base images can describe a base operating system (e.g., ubuntu, alpine, centos) and/or include a specific package or set of dependencies (e.g., java, swift, bash). A base image is not based on any other image and uses the word scratch in the first line of the image’s Dockerfile.

Example: Base Image Dockerfile for alpine

xxxxxxxxxx

FROM scratch

ADD alpine-minirootfs-3.12.1-x86_64.tar.gz /

CMD ["/bin/sh"]

An image that is based on another will specify the image it inherits from, also known as a parent image, in the first line of the Dockerfile. A parent image is not required to be a base image.

xxxxxxxxxx

FROM ubuntu

Image ID

When an image is built, it is assigned a unique ID in the form of an SHA-256 hex digest calculated from the contents of the image.

Image Tag

An image tag is an alias that is used to point to a specific image binary within an image repository. The tag can be set to any text but is generally used to indicate a specific version of a named image. A tag is unique to an image binary; however, an image binary can have multiple tags. This capability is commonly used along with semantic versioning to tag the latest minor and/or patch version as the latest major version available. For example, the latest binary of an image could potentially have the tags :3, :3.2, :3.2.1, and :latest, similar to the figure below:

Figure 1: Image tags

This is a preview of the Getting Started With Container Registries Refcard. To read the entire Refcard, please download the PDF from the link above.

Development Pipelines

If you are using Docker, where you store and access your container images is often an afterthought because of how easy it is to simply use the default settings of Docker Engine. If a container registry is not specified in a Dockerfile, or when requesting or sharing an image (e.g., docker pull <image-name>), then the registry is assumed to be Docker Hub. This is an important fact to remember, especially when setting up your continuous integration and development/deployment (CI/CD) pipelines!

Think about how often developers will pull images from the public registry to build and run an application or service locally. On top of that, every time your application is triggered to build in your Continuous Integration (CI) server, images will potentially be pulled from the registry. As shown in Figure 2, your requests for the images you rely on may not reach the intended remote registry for any number of reasons (e.g., unavailability of the network or of the remote service).

Figure 2: Remote registry requests

Docker has a clever mechanism for caching images locally once they have been pulled. This will save you the bandwidth cost of repeatedly pulling the same image over and over. However, to guarantee build repeatability and to ensure that all dependencies are accounted for, many CI systems are set up to start a build from scratch. Aside from that, any new machine instance that does not have an accessible local Docker cache will be required to pull source images from a registry. This could potentially include new development, test, staging, and production systems.

This is a preview of the Getting Started With Container Registries Refcard. To read the entire Refcard, please download the PDF from the link above.

Set up Your Container Registry

The technical details of setting up a container registry will be different depending on which solution you choose to implement. Regardless of the solution you choose, bear in mind the following guidelines.

Access and Security

Identify any network requirements or security zones that may affect the location of your container registry. Ensure that developers can access the registry from their local machines, other development or deployment environments, and separate tools (e.g., CI server, automated deployment system).

Health

Observe the health of your container registry regularly. A monitoring solution can send alerts when you approach or exceed storage space thresholds and collect data around how often images are pulled and from where. This data will provide insight into whether to plan for scaling or replication of the registry.

This is a preview of the Getting Started With Container Registries Refcard. To read the entire Refcard, please download the PDF from the link above.

Storing and accessing container images responsibly will help mitigate and prevent some of the known complications and missteps learned from experience. Use the information in this Refcard to make an educated decision about your choice of container registry and how your organization manages container images essential to your software projects. The following references will help you stay up to date on important changes and progress made around image formats that may impact your container registry compatibility:

• https://docs.docker.com/
• https://opencontainers.org/

This is a preview of the Getting Started With Container Registries Refcard. To read the entire Refcard, please download the PDF from the link above.