Understanding Azure Container Registry

When you get to the end of a devops build pipeline you’re left with a set of artifacts: binaries, configuration files, Web pages, even virtual machines and containers. They’re the components that go together to construct a modern application. Wrapping as many of those components as possible into a container makes a lot of sense, giving you a simpler deployment model. But that leaves a new set of questions: How do you manage those containers and how do you deploy them across a global-scale cloud application?

Services such as GitHub offer private and public registries for your build artifacts, using open standards and open source code. Azure has done the same, using the open source Docker Registry 2.0 as the basis for its own container registry, compliant with Open Container Initiative. It’s not intended to be only for containers; with the increasing importance of Kubernetes-based cloud-native applications, it’s meant to be a one-stop repository for all your OCI-compliant build artifacts. That now includes Helm charts, so you can use Azure’s Container Registry (ACR) as the deployment hub for your applications, using Helm 3.0 for delivery to Kubernetes instances.

Getting started with ACR

Tools such as Azure Container Registry are best thought of as private registries. Only you and your team and services have access to your registry, automating delivery to Azure services that use containers. Familiar tools such as Azure DevOps and Jenkins can be configured to use the Registry as a build end point, so you can go straight from merging a pull request to a container on Azure, ready to deploy.

Microsoft currently offers three versions of ACR: Basic, Standard, and Premium, at three different price points. They all work with Web hooks, use Azure Active Directory for authentication, and have the capability to delete images. Basic has the lowest capacity; Premium includes support for replication across regions and adds image signing support. You’re most likely to use Standard, which gives you 100GB of storage, 60MBps download bandwidth, and supports as many as 10 Web hooks. Pricing is per registry per day, with additional network costs and a separate charge for CPU usage when building new container images.

Creating a new container registry is relatively easy, using either the Azure CLI or Portal. ACR instances are tied to resource groups, so you can have a separate registry for each application you run on Azure. Once a registry has been created, you’re given the URL of a log-in server. This is the end point for integration with devops tools or your developers’ desktop Docker instances.

Interacting with an ACR registry

The Azure CLI’s acr command is probably the most useful way to interact with a registry. Log in and you can start pushing container images to it. It’s a good idea to start from the desktop to get a feel for how it works, tagging a local Docker image with the ACR log-in server name and then using the docker push command to send the image to the ACR registry, automatically creating the appropriate repository in Azure. Once an image is in an ACR repository, use the command line tools to list files, remove them, and even use Docker commands to run them.

Automating ACR can reduce your workload considerably, using ACR Tasks. Tasks bundle up what would have been a set of Azure CLI scripts into simple workflows that manage common operations. For example, they offer a series of triggers that automate building new images when changes happen in your build pipeline or in your continuous integration/continuous delivery (CI/CD) system.

One option, the quick task, wraps all the stages used to build a set of files into a container into a single command. All you need is a working directory with your files and an existing ACR registry and a Dockerfile. A single command takes those files and uses the Dockerfile to create an image, automatically storing it in an ACR repository. Another quick task runs the image on your chosen host.

Put them together and you have a basic set of tools for testing container images. More complex deployments will need more complex scripts—for example deploying a container to a managed Kubernetes instance using AKS. Alternatively, you can automate the entire process, creating a task that monitors a GitHub repo for changes in a deployment branch, building a new image when you merge a pull request into the branch or make a commit.

Securing containers in ACR

There are security benefits to working with ACR. One of the big problems facing anyone building modern applications is understanding and managing your dependency tree. How do you know if a new version of a key library or an obfuscated component is safe to use? You need to be able to trust your containers, and ACR offers two ways to ensure you always deploy trusted code.

Firstly, it provides signed container images, so your Kubernetes cluster can verify that the code it’s running is the code you pushed to your registry from your build system. Signed images ensure that no one has tampered with a container’s contents while it’s being deployed. Secondly, ACR can integrate with Azure’s Security Center. This allows you to scan images as they’re stored in the registry, checking not only for vulnerabilities in your code and in the base image, but also in any dependencies that are included or are referred from the image file. Using Qualys’s scanner, Security Center reports will help you identify vulnerabilities with recommendations for fixes.

Things get interesting when you start using your ACR instances for more than containers. OCI has begun opening up the registry standard to artifacts, with Helm, the de facto tool for Kubernetes application deployment, using it in the latest release. The industry has seen a proliferation of registries and repositories, and it makes sense to standardize on one for all your application components, especially when they’re all part of the same cloud-native application.

ACR now supports OCI Registry As Storage (ORAS). Using an ORAS tool you can push and pull all your artifacts from the same ACR repository. Install ORAS on your developer machines or add support to your build pipeline. Once signed in to your registry with an Azure Active Directory service principal that has push rights, use the ORAS command line tool to push new artifacts to the registry.

Using a command line tool in the Azure CLI gives you the flexibility to build ORAS push into your choice of build tools, as a script that can be called as and when needed. The same command line tool can pull artifacts, and you can build it into your deployment scripts so all the components that make up your applications can automatically deploy when a new build pushes to your ACR repositories.

Private code needs private repositories, and keeping your containers and other build artifacts in Azure puts them where they’re needed. A complete devops build process should go from code commit to running application with no human intervention, making tools such as Azure Container Registry and its associated task automation essential components in any Azure-targeted pipeline. Not only is code automatically stored and deployed on a global scale, it’s scanned for security risks every time there’s a change.