Discover the Azure Container Registry
Use the Azure Container Registry (ACR) service with your existing container development and deployment pipelines, or use Azure Container Registry Tasks to build container images in Azure. Build on demand, or fully automate builds with triggers such as source code commits and base image updates.
Use cases
Pull images from an Azure container registry to various deployment targets:
- Scalable orchestration systems that manage containerized applications across clusters of hosts, including Kubernetes, DC/OS, and Docker Swarm.
- Azure services that support building and running applications at scale, including Azure Kubernetes Service (AKS), App Service, Batch, Service Fabric, and others.
Developers can also push to a container registry as part of a container development workflow. For example, target a container registry from a continuous integration and delivery tool such as Azure Pipelines or Jenkins.
Configure ACR Tasks to automatically rebuild application images when their base images are updated, or automate image builds when your team commits code to a Git repository. Create multi-step tasks to automate building, testing, and patching multiple container images in parallel in the cloud.
Azure Container Registry service tiers
Azure Container Registry is available in multiple service tiers. These tiers provide predictable pricing and several options for aligning to the capacity and usage patterns of your private Docker registry in Azure.
- Basic - A cost-optimized entry point for developers learning about Azure Container Registry. Basic registries have the same programmatic capabilities as Standard and Premium (such as Azure Active Directory authentication integration, image deletion, and webhooks). However, the included storage and image throughput are most appropriate for lower usage scenarios.
- Standard - Standard registries offer the same capabilities as Basic, with increased included storage and image throughput. Standard registries should satisfy the needs of most production scenarios.
- Premium - Premium registries provide the highest amount of included storage and concurrent operations, enabling high-volume scenarios. In addition to higher image throughput, Premium adds features such as geo-replication for managing a single registry across multiple regions, content trust for image tag signing, private link with private endpoints to restrict access to the registry.
Supported images and artifacts
Grouped in a repository, each image is a read-only snapshot of a Docker-compatible container. Azure container registries can include both Windows and Linux images. In addition to Docker container images, Azure Container Registry stores related content formats such as Helm charts and images built to the Open Container Initiative (OCI) Image Format Specification.
Automated image builds
Use Azure Container Registry Tasks (ACR Tasks) to streamline building, testing, pushing, and deploying images in Azure. Configure build tasks to automate your container OS and framework patching pipeline, and build images automatically when your team commits code to source control. Windows VMs have extensions which give your VM additional capabilities through post deployment configuration and automated tasks.
Explore storage capabilities
Every Basic, Standard, and Premium Azure container registry benefits from advanced Azure storage features like encryption-at-rest for image data security and geo-redundancy for image data protection.
- Encryption-at-rest: All container images in your registry are encrypted at rest. Azure automatically encrypts an image before storing it, and decrypts it on-the-fly when you or your applications and services pull the image.
- Regional storage: Azure Container Registry stores data in the region where the registry is created, to help customers meet data residency and compliance requirements. In all regions except Brazil South and Southeast Asia, Azure may also store registry data in a paired region in the same geography. In the Brazil South and Southeast Asia regions, registry data is always confined to the region, to accommodate data residency requirements for those regions.
If a regional outage occurs, the registry data may become unavailable and is not automatically recovered. Customers who wish to have their registry data stored in multiple regions for better performance across different geographies or who wish to have resiliency in the event of a regional outage should enable geo-replication.
- Zone redundancy: A feature of the Premium service tier, zone redundancy uses Azure availability zones to replicate your registry to a minimum of three separate zones in each enabled region.
- Scalable storage: Azure Container Registry allows you to create as many repositories, images, layers, or tags as you need, up to the registry storage limit.
Very high numbers of repositories and tags can impact the performance of your registry. Periodically delete unused repositories, tags, and images as part of your registry maintenance routine. Deleted registry resources like repositories, images, and tags cannot be recovered after deletion.
Build and manage containers with tasks
ACR Tasks is a suite of features within Azure Container Registry. It provides cloud-based container image building for platforms including Linux, Windows, and Azure Resource Manager, and can automate OS and framework patching for your Docker containers. ACR Tasks enables automated builds triggered by source code updates, updates to a container's base image, or timers.
Task scenarios
ACR Tasks supports several scenarios to build and maintain container images and other artifacts.
Quick task - Build and push a single container image to a container registry on-demand, in Azure, without needing a local Docker Engine installation. Think
docker build
,docker push
in the cloud.Automatically triggered tasks - Enable one or more triggers to build an image:
- Trigger on source code update
- Trigger on base image update
Trigger on a schedule
Multi-step task - Extend the single image build-and-push capability of ACR Tasks with multi-step, multi-container-based workflows.
Each ACR Task has an associated source code context - the location of a set of source files used to build a container image or other artifact. Example contexts include a Git repository or a local filesystem.
Explore elements of a Dockerfile
If you want to create a custom container you will need to understand the elements of a Dockerfile. A Dockerfile is a text file that contains the instructions we use to build and run a Docker image. The following aspects of the image are defined:
- The base or parent image we use to create the new image
- Commands to update the base OS and install additional software
- Build artifacts to include, such as a developed application
- Services to expose, such a storage and network configuration
- Command to run when the container is launched
Let's map these aspects to an example Dockerfile. Suppose we're creating a Docker image for an ASP.NET Core website. The Dockerfile may look like the following example.
# Step 1: Specify the parent image for the new image
FROM ubuntu:18.04
# Step 2: Update OS packages and install additional software
RUN apt -y update && apt install -y wget nginx software-properties-common apt-transport-https \
&& wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb \
&& dpkg -i packages-microsoft-prod.deb \
&& add-apt-repository universe \
&& apt -y update \
&& apt install -y dotnet-sdk-3.0
# Step 3: Configure Nginx environment
CMD service nginx start
# Step 4: Configure Nginx environment
COPY ./default /etc/nginx/sites-available/default
# STEP 5: Configure work directory
WORKDIR /app
# STEP 6: Copy website code to container
COPY ./website/. .
# STEP 7: Configure network requirements
EXPOSE 80:8080
# STEP 8: Define the entry point of the process that runs in the container
ENTRYPOINT ["dotnet", "website.dll"]
We're not going to cover the Dockerfile file specification here or the detail of each command in our above example. However, notice that there are several commands in this file that allow us to manipulate the structure of the image.
Each of these steps creates a cached container image as we build the final container image. These temporary images are layered on top of the previous and presented as single image once all steps complete.
Finally, notice the last step, step 8. The ENTRYPOINT
in the file indicates which process will execute once we run a container from an image.
Exercise: Build and run a container image by using Azure Container Registry Tasks
In this exercise you will use ACR Tasks to perform the following actions:
- Create an Azure Container Registry
- Build and push image from a Dockerfile
- Verify the results
- Run the image in the ACR
Prerequisites
- An Azure account with an active subscription. If you don't already have one, follow this instructions.
Login to Azure and start the Cloud Shell
Login to the Azure Portal and open the Cloud Shell.
After the shell opens be sure to select the Bash environment.
Create an Azure Container Registry
Create a resource group for the registry.
az group create --name az204-acr-rg --location eastus
Create a basic container registry. The registry name must be unique within Azure, and contain 5-50 alphanumeric characters. Replace
in the command below with a unique value. az acr create --resource-group az204-acr-rg \ --name <myContainerRegistry> --sku Basic
Note: The command above creates a Basic registry, a cost-optimized option for developers learning about Azure Container Registry.
Build and push image from a Dockerfile
Now use Azure Container Registry to build and push an image based on a local Dockerfile.
Create, or navigate, to a local directory and then use the command below to create the Dockerfile. The Dockerfile will contain a single line that references the
hello-world
image hosted at the Microsoft Container Registry.echo FROM mcr.microsoft.com/hello-world > Dockerfile
Run the az acr build command, which builds the image and, after the image is successfully built, pushes it to your registry. Replace
with the name you used earlier. az acr build --image sample/hello-world:v1 \ --registry <myContainerRegistry> \ --file Dockerfile .
The command above will generate a lot of output, below is shortened sample of that output showing the last few lines with the final results. You can see in the repository
field the sample/hello-word
image is listed.
- image:
registry: <myContainerRegistry>.azurecr.io
repository: sample/hello-world
tag: v1
digest: sha256:92c7f9c92844bbbb5d0a101b22f7c2a7949e40f8ea90c8b3bc396879d95e899a
runtime-dependency:
registry: mcr.microsoft.com
repository: hello-world
tag: latest
digest: sha256:92c7f9c92844bbbb5d0a101b22f7c2a7949e40f8ea90c8b3bc396879d95e899a
git: {}
Run ID: cf1 was successful after 11s
Verify the results
Use the
az acr repository list
command to list the repositories in your registry. Replace<myContainerRegistry>
with the name you used earlier.az acr repository list --name <myContainerRegistry> --output table
Output:
Result ---------------- sample/hello-world
Use the
az acr repository show-tags
command to list the tags on the sample/hello-world repository. Replace<myContainerRegistry>
with the name you used earlier.az acr repository show-tags --name <myContainerRegistry> \ --repository sample/hello-world --output table
Output:
Result -------- v1
Run the image in the ACR
- Run the sample/hello-world:v1 container image from your container registry by using the
az acr run
command. The following example uses$Registry
to specify the registry where you run the command. Replace<myContainerRegistry>
with the name you used earlier.
az acr run --registry <myContainerRegistry> \
--cmd '$Registry/sample/hello-world:v1' /dev/null
The cmd parameter in this example runs the container in its default configuration, but cmd
supports additional docker
run
parameters or even other docker
commands.
Below is shortened sample of the output:
Packing source code into tar to upload...
Uploading archived source code from '/tmp/run_archive_ebf74da7fcb04683867b129e2ccad5e1.tar.gz'...
Sending context (1.855 KiB) to registry: mycontainerre...
Queued a run with ID: cab
Waiting for an agent...
2019/03/19 19:01:53 Using acb_vol_60e9a538-b466-475f-9565-80c5b93eaa15 as the home volume
2019/03/19 19:01:53 Creating Docker network: acb_default_network, driver: 'bridge'
2019/03/19 19:01:53 Successfully set up Docker network: acb_default_network
2019/03/19 19:01:53 Setting up Docker configuration...
2019/03/19 19:01:54 Successfully set up Docker configuration
2019/03/19 19:01:54 Logging in to registry: mycontainerregistry008.azurecr.io
2019/03/19 19:01:55 Successfully logged into mycontainerregistry008.azurecr.io
2019/03/19 19:01:55 Executing step ID: acb_step_0. Working directory: '', Network: 'acb_default_network'
2019/03/19 19:01:55 Launching container with name: acb_step_0
Hello from Docker!
This message shows that your installation appears to be working correctly.
2019/03/19 19:01:56 Successfully executed container: acb_step_0
2019/03/19 19:01:56 Step ID: acb_step_0 marked as successful (elapsed time in seconds: 0.843801)
Run ID: cab was successful after 6s
Clean up resources
When no longer needed, you can use the az group delete
command to remove the resource group, the container registry, and the container images stored there.
az group delete --name az204-acr-rg --no-wait
Note: This operation takes on average 5 - 10 minutes