Fotolia
How to manage microservices with a container registry
Container registries will help to compile and store images. Get a better understanding of popular registry products and services.
Containers form the foundation for a growing number of cloud-native applications. However, by themselves, containers are little more than a clever packaging exercise that promises the multi-tenant isolation of a virtual machine and efficiency of a user-space application. To be useful, containers require an ecosystem of supporting services that automate various steps of the application development and deployment toolchain. One of these is a container registry that stores and catalogs compiled images.
Understanding the importance of container registries requires some context regarding cloud-native application design and development methodologies. The availability of cloud infrastructure and platform services that can be rapidly instantiated and controlled via public APIs has reshaped how developers think about building, deploying and updating applications.
The 12-factor methodology, promulgated five years ago by the developers of Heroku, is the original and still-popular codification of a set of design rules that outlines how best to build language-agnostic, cloud-native, software-as-a-service applications. Among its core goals, the methodology seeks to "minimize divergence between development and production, enabling continuous deployment for maximum agility and scale up without significant changes to tooling, architecture or development practices." Although it doesn't prescribe any particular technology, by enabling application code to be encapsulated in modular, reusable and easily distributed chunks, containers have emerged as a preferred technique for achieving these goals.
Following the 12-factor technique to build a container-based microservice starts by designing applications with considerable granularity, then packaging code modules into container images. Using a container registry to manage a large image portfolio can improve developer efficiency by facilitating image reuse across multiple applications and reducing redundancy.
Basics of container registries
Container registries typically incorporate both an image repository and means of image or microservice search and discovery. A container repository is analogous to a source code control system for container images. Indeed, source code control systems like Git, Bitbucket or Mercurial can automatically trigger the assembly of an updated image after new code is checked in and built. The repository provides a central location for publishing, storing, finding, downloading and managing container images.
Like an SCCS, a container repository also provides image version control and a searchable database of image descriptions and metadata that can reduce the accumulation of nearly identical image versions used for different applications. Thus, the registry is more than just an image repository, but a searchable database of images and actively running instances that allows for container discovery. Indeed, registries can be the foundation for container marketplaces that are the microservice version of a mobile app store for the acquisition of third-party commercial or open source images that can be assembled into custom applications built from microservice components.
Registries can use meta-images, such as Dockerfile, to specify the components of a container and enable the automatic rebuilding and assembly of images whenever new versions of code for a particular module are submitted. Registries often include domain-name-system services that provide a unique name and virtual IP for each image, and thus simplify finding and connecting to specific microservices in a container cluster. Indeed, complex, microservice-based applications can be automatically assembled on the fly by an orchestration system, like Kubernetes or Docker Compose, by using descriptions of image dependencies.
Thus, container registries can automate the first two stages of the 12-factor process -- namely the process of using a single codebase that is managed using a revision control system and declaring dependencies that can be automatically resolved by integration software. Orchestration, aka cluster management systems, can automate factors three (config) and five (build, release, run).
Popular registries
Registries are rarely stand-alone pieces of software, but part of a container platform, such as Docker, or a cloud service, like Amazon Web Services (AWS). The following are summaries of widely used container registry products and services:
- Docker Registry and Compose. Perhaps the most popular container platform and the product that ignited interest in containers as a new application deployment option, Docker is both an open source project and software suite that contains the key elements of a container ecosystem. The Docker Registry combines both image storage and delivery that can be integrated with other steps in a DevOps toolchain. The Docker documentation illustrates a typical workflow in which "a commit to your source revision control system would trigger a build on your CI system [continuous integration product, such as Jenkins], which would then push a new image to your Registry if the build is successful. A notification from the Registry would then trigger a deployment on a staging environment, or notify other systems that a new image is available."
- CoreOS Quay is a registry from the makers of the popular Linux distribution that is available as either a cloud service or on-premises software. It provides automatic replication across data centers and support for CI processes, such as automatically building new images from Dockerfiles and scanning uploaded or compiled images for security vulnerabilities.
- Rancher is an amalgamation of open source technologies into a complete container ecosystem, and it includes modules for infrastructure and container orchestration and scheduling, user and policy management, and an application catalog. Rancher supports both Docker and CoreOS Quay registries.
- AWS EC2 Container Service (ECS) is a Docker-compatible container service that uses Elastic Compute Cloud instances as container hosts and includes a managed Docker registry, EC2 Container Registry. ECR automatically encrypts stored images and is integrated with AWS Identity and Access Management to enable access controls. Container workflow can be automated using the Docker command-line interface to push images from a code repository to ECR and ECS to automatically deploy and scale containers as needed.
- Azure Container Service is another Docker-compatible offering that supports a variety of orchestration engines, including Swarm, Marathon (Mesos) and soon, Kubernetes. The Azure Container Registry, currently in beta, is based on the open source Docker Registry version 2 that supports both Linux and Windows images. The service integrates with Visual Studio Team Services, allowing developers to automate the container deployment process from code compilation to image registration.
- Google Container Registry -- part of Google Container Engine -- is also a registry based on Docker version 2 that integrates with a variety of continuous integration and deployment tools like Jenkins and CircleCI. The service uses Google Cloud storage, with options for regional replication of repositories to improve response time, and it allows searching for images by name or metadata tags.
Recommendations
The Docker image format and repository APIs have become the de facto standard for most container platforms, including the three major cloud services -- although CoreOS Quay is a strong contender, given its automation support, such as build triggers and Git integration. The key decision organizations must make is between a private registry or cloud service.
If the former, the registry will typically come with whatever container management product -- e.g., Docker, CoreOS Tectonic or Joyent Triton, among others -- one selects, although some like Rancher support both Docker and CoreOS registries. Given its broad support by both packaged software and cloud services, it makes sense to use a Docker registry unless you run into integration problems when building a CI/CD automation pipeline.
