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, . 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 . 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.