Frequently asked questions - Azure Container Registry on Azure Stack Hub

Yes. Here is a template that you can use to create a registry. This template is for the Azure public cloud. To use this template against Azure Stack Hub, modify the API version to 2019-05-01, otherwise it fails to deploy.

No. There is currently no integration with Azure Security Center for registries deployed on Azure Stack Hub. There are 3rd party and open source options that can be leveraged to fill this need for connected or disconnected Azure Stack Hub deployments.

See the documentation for Kubernetes and steps for Azure Kubernetes Service.

Before getting admin credentials, make sure the registry's admin user is enabled.

To get credentials using the Azure CLI:

az acr credential show -n myRegistry

Using Azure PowerShell:

Invoke-AzureRmResourceAction -Action listCredentials -ResourceType Microsoft.ContainerRegistry/registries -ResourceGroupName myResourceGroup -ResourceName myRegistry

Before getting admin credentials, make sure the registry's admin user is enabled.

To get the first password:

{
    "password": "[listCredentials(resourceId('Microsoft.ContainerRegistry/registries', 'myRegistry'), '2017-10-01').passwords[0].value]"
}

To get the second password:

{
    "password": "[listCredentials(resourceId('Microsoft.ContainerRegistry/registries', 'myRegistry'), '2017-10-01').passwords[1].value]"
}

You can perform a machine-to-machine image transfer over a local network from a machine that already has the required container image(s). To do this:

1. First, retrieve the required container image(s) using a machine with Internet connectivity by using the docker CLI and docker pull command. See Import container images to a container registry for more information.

2. After you have the required image(s) imported, transport the machine to the location of the disconnected Azure Hub instance.

3. Use the docker tag and docker push commands to tag and push the image to the local Azure Container Registry on the Azure Stack Hub repository.

Azure Container Registry supports Docker Registry HTTP API V2. The APIs can be accessed at https://<your registry login server>/v2/. Example: https://mycontainerregistry.azsacr.<regionname>.<fqdn>/v2/

If you are on bash:

az acr manifest list-metadata --name myRepository --registry myRegistry --query "[?tags[0]==null].digest" --output tsv  | xargs -I% az acr repository delete --name myRegistry --image myRepository@%

For PowerShell:

az acr manifest list-metadata --name myRepository --registry myRegistry --query "[?tags[0]==null].digest" --output tsv | %{ az acr repository delete --name myRegistry --image myRepository@$_ }

For more information, see Delete container images in Azure Container Registry.

This situation can happen if the underlying layers are still being referenced by other container images. If you delete an image with no references, the registry usage updates in a few minutes.

Create an image with a 1GB layer using the following docker file. This ensures that the image has a layer that is not shared by any other image in the registry.

FROM alpine
RUN dd if=/dev/urandom of=1GB.bin  bs=32M  count=32
RUN ls -lh 1GB.bin

Build and push the image to your registry using the docker CLI.

docker build -t myregistry.azsacr.<regionname>.<fqdn>/1gb:latest .
docker push myregistry.azsacr.<regionname>.<fqdn>/1gb:latest

You should be able to see that the storage usage has increased in the Azure Stack Hub portal, or you can query usage using the CLI.

az acr show-usage -n myregistry

Delete the image using the Azure CLI or portal and check the updated usage in a few minutes.

az acr repository delete -n myregistry --image 1gb

You need to run the Azure CLI container by mounting the Docker socket:

docker run -it -v /var/run/docker.sock:/var/run/docker.sock azuresdk/azure-cli-python:dev

In the container, install docker:

apk --update add docker

Then authenticate with your registry:

az acr login -n MyRegistry

Enable TLS 1.2 by using any recent docker client (version 18.03.0 and above).

No, the current release of Azure container registry on Azure Stack Hub only supports the "Standard" SKU and does not support Content Trust.

Azure Container Registry supports custom roles that provide different levels of permissions. Specifically, AcrPull and AcrPush roles allow users to pull and/or push images without the permission to manage the registry resource in Azure.

• Azure Stack Hub portal: Your registry -> Access Control (IAM) -> Add (Select AcrPull or AcrPush for the Role).

• Azure CLI: Find the resource ID of the registry by running the following command:

  az acr show -n myRegistry
  

  Then you can assign the AcrPull or AcrPush role to a user (the following example uses AcrPull):

  az role assignment create --scope resource_id --role AcrPull --assignee user@example.com
  

  Or, assign the role to a service principal identified by its application ID:

  az role assignment create --scope resource_id --role AcrPull --assignee 00000000-0000-0000-0000-000000000000
  

The assignee is then able to authenticate and access images in the registry.

• To authenticate to a registry:

  az acr login -n myRegistry 
  

• To list repositories:

  az acr repository list -n myRegistry
  

• To pull an image:

  docker pull myregistry.azsacr.<regionname>.<fqdn>/hello-world
  

With the use of only the AcrPull or AcrPush role, the assignee doesn't have the permission to manage the registry resource in Azure. For example, az acr list or az acr show -n myRegistry won't show the registry.

A non-distributable layer in a manifest contains a URL parameter that content may be fetched from. Some possible use cases for enabling non-distributable layer pushes are for network restricted registries, air-gapped registries with restricted access, or for registries with no internet connectivity.

For example, if you have NSG rules set up so that a VM can pull images only from your Azure container registry, Docker will pull failures for foreign/non-distributable layers. For example, a Windows Server Core image would contain foreign layer references to Azure container registry in its manifest and would fail to pull in this scenario.

To enable pushing of non-distributable layers:

1. Edit the daemon.json file, which is located in /etc/docker/ on Linux hosts and at C:\ProgramData\docker\config\daemon.json on Windows Server. Assuming the file was previously empty, add the following contents:

   {
     "allow-nondistributable-artifacts": ["myregistry.azsacr.<regionname>.<fqdn>"]
   }
   

   Note

   The value is an array of registry addresses, separated by commas.

2. Save and exit the file.

3. Restart Docker.

When you push images to the registries in the list, their non-distributable layers are pushed to the registry.

To troubleshoot common environment and registry issues, see Check the health of an Azure container registry.

• If this error is a transient issue, then retry will succeed.
• If docker pull fails continuously, then there could be a problem with the Docker daemon. The problem can generally be mitigated by restarting the Docker daemon.
• If you continue to see this issue after restarting Docker daemon, then the problem could be some network connectivity issues with the machine. To check if general network on the machine is healthy, run the following command to test endpoint connectivity. The minimum az acr version that contains this connectivity check command is 2.2.9. Upgrade your Azure CLI if you are using an older version.

az acr check-health -n myRegistry

• You should always have a retry mechanism on all Docker client operations.

Use this tool to test your machine network download speed.

Use this tool to test your machine network upload speed.

This error can happen with the Red Hat version of the Docker daemon, where --signature-verification is enabled by default. You can check the Docker daemon options for Red Hat Enterprise Linux (RHEL) or Fedora by running the following command:

grep OPTIONS /etc/sysconfig/docker

For instance, Fedora 28 Server has the following docker daemon options:

OPTIONS='--selinux-enabled --log-driver=journald --live-restore'

With --signature-verification=false missing, docker pull fails with an error similar to:

Trying to pull repository myregistry.azsacr.<regionname>.<fqdn>/myimage ...
unauthorized: authentication required

To resolve the error:

1. Add the option --signature-verification=false to the Docker daemon configuration file /etc/sysconfig/docker. For example:

   OPTIONS='--selinux-enabled --log-driver=journald --live-restore --signature-verification=false'

2. Restart the Docker daemon service by running the following command:

   sudo systemctl restart docker.service
   

Details of --signature-verification can be found by running man dockerd.

Make sure you use an all lowercase server URL, for example, docker push myregistry.azsacr.<regionname>.<fqdn>/myimage:latest, even if the registry resource name is uppercase or mixed case, like myRegistry.

Start dockerd with the debug option. First, create the Docker daemon configuration file (/etc/docker/daemon.json) if it doesn't exist, and add the debug option:

{    
    "debug": true    
}

Then, restart the daemon. For example, with Ubuntu 14.04:

sudo service docker restart

Details can be found in the Docker documentation.

• The logs may be generated at different locations, depending on your system. For example, for Ubuntu 14.04, it's /var/log/upstart/docker.log.
  See Docker documentation for details.

• For Docker for Windows, the logs are generated under %LOCALAPPDATA%/docker/. However it may not contain all the debug information yet.

  In order to access the full daemon log, you may need some extra steps:

  docker run --privileged -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /usr/local/bin/docker:/usr/local/bin/docker alpine sh
  
  docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh
  chroot /host
  

  Now you have access to all the files of the VM running dockerd. The log is at /var/log/docker.log.

When you grant new permissions (new roles) to a service principal, the change might not take effect immediately. There are two possible reasons:

• Microsoft Entra role assignment delay. Normally it's fast, but it could take minutes due to propagation delay.

• Permission delay on Azure Container Registry token server. This could take up to 10 minutes. To mitigate, you can docker logout and then authenticate again with the same user after 1 minute:

  docker logout myregistry.azsacr.<regionname>.<fqdn>
  docker login myregistry.azsacr.<regionname>.<fqdn>
  

You may encounter an InvalidAuthenticationInfo error, especially using the curl tool with the option -L, --location (to follow redirects). For example, fetching the blob using curl with -L option and basic authentication:

curl -L -H "Authorization: basic $credential" https://$registry.azurecr.io/v2/$repository/blobs/$digest

may result in the following response:

<?xml version="1.0" encoding="utf-8"?>
<Error><Code>InvalidAuthenticationInfo</Code><Message>Authentication information is not given in the correct format. Check the value of Authorization header.
RequestId:00000000-0000-0000-0000-000000000000
Time:2019-01-01T00:00:00.0000000Z</Message></Error>

The root cause is that some curl implementations follow redirects with headers from the original request.

To resolve the problem, you need to follow redirects manually without the headers. Print the response headers with the -D - option of curl and then extract: the Location header:

redirect_url=$(curl -s -D - -H "Authorization: basic $credential" https://$registry.azurecr.io/v2/$repository/blobs/$digest | grep "^Location: " | cut -d " " -f2 | tr -d '\r')
curl $redirect_url

If you are using the Microsoft Edge/IE browser, you can see at most 100 repositories or tags. If your registry has more than 100 repositories or tags, we recommend that you use either the Firefox or Chrome browser to list them all.

The browser might not be able to send the request for fetching repositories or tags to the server. There could be various reasons such as:

• Lack of network connectivity
• Firewall
• Using the portal from a public network for a registry that allows only private access
• Ad blockers
• DNS errors

Please contact your network administrator or check your network configuration and connectivity. Try running az acr check-health -n yourRegistry using your Azure CLI to check if your environment is able to connect to the Container Registry. In addition, you could also try an incognito or private session in your browser to avoid any stale browser cache or cookies.

Here are some scenarios where operations may be disallowed:

• The image or repository maybe locked so that it can't be deleted or updated. You can use the az acr show repository command to view current attributes.
• Some operations are disallowed if the image is in quarantine. Learn more about quarantine.
• Your registry may have reached its storage limit.

If you see an error such as "unsupported repository format", "invalid format", or "the requested data does not exist" when specifying a repository name in repository operations, check the spelling and case of the name. Valid repository names can only include lowercase alphanumeric characters, periods, dashes, underscores, and forward slashes.

Prerequisites

• Enable decrypting https in fiddler: https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS
• Enable Docker to use a proxy through the Docker ui: https://docs.docker.com/docker-for-windows/#proxies
• Be sure to revert when complete. Docker won't work with this enabled and fiddler not running.

Windows containers

Configure Docker proxy to 127.0.0.1:8888

Linux containers

Find the ip of the Docker vm virtual switch:

(Get-NetIPAddress -InterfaceAlias "*Docker*" -AddressFamily IPv4).IPAddress

Configure the Docker proxy to output of the previous command and the port 8888 (for example 10.0.75.1:8888)

Next steps

• Learn more about Azure Container Registry.