Azure Container Registry - Getting Started
Solution ·
When we looked at an overview of Container Services in Azure, we took a look at Azure Container Registry (ACR).
A Docker Registry holds Docker images in repositories. Any agent can build & push those images. Nodes running Docker containers can then pull those images.
The main advantages of using Azure Docker Registry (ACR) are
- Network proximity to workloads running Docker Containers (same Azure region)
- Integration with Azure Active Directory (AAD)
- Well defined SLA
- Geo-distribution (opt-in)
- Deployment integration
In the last point, we refer to the ability of deploying ACR with an entire Azure environment.
Docker & Azure CLI integration
Online documentation gives a good quick start which we won’t repeat here. A point we would like to emphasise though is the integration between Azure CLI and Docker CLI.
In the quick start, we do create a registry using Azure CLI. We then log into the registry, still using Azure CLI. That command, i.e. az acr login, actually integrates with the Docker CLI. This is why we are able to use Docker CLI to push images to the registry afterwards.
It is therefore required to have the Docker CLI installed for this command, and later ones, to work. For this reason we cannot do this quick start using Linux subsystem on Windows as we can’t install Docker on it.
For Windows users, the options are
- Run Azure PowerShell SDK with Docker for Windows
- Run a Linux VM in Azure with both Docker & Azure CLI
Identity Integration
Online documentation also cover integration with Azure AD.
Basically, ACR uses Azure AD as its identity backend. The only exception is the Admin account, which is disabled by default.
This is why we can login to the ACR with our own account as described in the last section.
We recommend using a Service Principal for headless agents interacting with ACR. For instance:
- Visual Studio Team Services (VSTS) building and pushing images
- AKS pulling container images
Access Control works as any other Azure resources, i.e. using RBAC. A User or Service Principal can be given different roles on ACR. Those roles define which actions User or Service Principal can perform. For instance, Reader can only pull images. Details on the different roles & associated actions are available in the online documentation.
Web Hooks
ACR support web hooks. We can react to different actions happening in ACR. As of this writing (mid April 2018), push & pull actions are supported.
Using web hooks, we react to an event in ACR using:
- Azure Logic Apps
- Azure Function
- Azure Automation
- Anything able to implement a web hook
Summary
We just covered a lap around ACR.
The online documentation contains Best Practices for ACR which is a good read. The repository namespaces section is especially interesting as a governance inspiration.