Preguntas más frecuentes: Azure Container Registry

Sí. Esta es una plantilla que puede usar para crear un registro.

Sí. Consulte la documentación de Microsoft Defender para la nube, Twistlock y Aqua.

Consulte la documentación de Kubernetes y los pasos para Azure Kubernetes Service.

Antes de obtener las credenciales de administrador, asegúrese de que el usuario administrador del registro esté habilitado.

Para obtener las credenciales mediante la CLI de Azure:

az acr credential show -n myRegistry

Uso de Azure PowerShell:

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

Antes de obtener las credenciales de administrador, asegúrese de que el usuario administrador del registro esté habilitado.

Para obtener la primera contraseña:

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

Para obtener la segunda contraseña:

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

El error se observa cuando el usuario tiene permisos en un registro pero no tiene permisos a nivel de lector en la suscripción. Para resolver este problema, asigne al usuario los permisos de lector en la suscripción:

az role assignment create --role "Reader" --assignee user@contoso.com --scope /subscriptions/<subscription_id> 

Lleva algún tiempo propagar los cambios en las reglas del firewall. Después de cambiar la configuración del firewall, espere unos minutos antes de comprobar este cambio.

ACR admite Docker Registry HTTP API V2. Se puede acceder a las API en https://<your registry login server>/v2/. Ejemplo: https://mycontainerregistry.azurecr.io/v2/

Si se encuentra en 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@%

Para PowerShell:

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

Para más información, consulte Eliminación de imágenes de contenedor en Azure Container Registry

Esta situación puede ocurrir si otras imágenes de contenedor hacen referencia a las capas subyacentes. Si elimina una imagen sin referencias, el uso del registro se actualiza en unos minutos.

Cree una imagen con una capa de 1 GB mediante el siguiente archivo de Docker. Esto asegura que la imagen tiene una capa que no comparte ninguna otra imagen en el registro.

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

Cree e inserte la imagen en el registro mediante la CLI de Docker.

docker build -t myregistry.azurecr.io/1gb:latest .
docker push myregistry.azurecr.io/1gb:latest

Debería poder ver que el uso del almacenamiento ha aumentado en Azure Portal, o puede consultar el uso mediante la CLI.

az acr show-usage -n myregistry

Elimine la imagen con la CLI o Azure Portal y compruebe el uso actualizado en pocos minutos.

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

Para ejecutar el contenedor de la CLI de Azure, monte el socket de Docker:

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

En el contenedor, instale docker:

apk --update add docker

A continuación, autentíquese con el registro:

az acr login -n MyRegistry

Habilite TLS 1.2 mediante cualquier cliente de Docker reciente (versión 18.03.0 y posterior).

Sí, puede usar las imágenes de confianza en Azure Container Registry, ya que Docker Notary se ha integrado y se puede habilitar. Para más información, consulte Confianza de contenido en Azure Container Registry.

¿Dónde se encuentra el archivo de la huella digital?

En ~/.docker/trust/tuf/myregistry.azurecr.io/myrepository/metadata:

• Las claves públicas y los certificados de todas las funciones (excepto los roles de delegación) se almacenan en root.json.
• Las claves públicas y los certificados del rol de delegación se almacenan en el archivo JSON del rol principal (por ejemplo targets.json para el rol targets/releases).

Se recomienda comprobar esas claves públicas y certificados después de la comprobación TUF general realizada por el cliente de Docker y Notary.

ACR admite los roles personalizados que proporcionan diferentes niveles de permisos. Específicamente, los roles AcrPull y AcrPush permiten a los usuarios extraer o insertar imágenes sin permiso para administrar el recurso del registro en Azure.

• Azure Portal: Su registro -> Control de acceso (IAM) -> Agregar (seleccione AcrPull o AcrPush para el rol).

• CLI de Azure: Busque el identificador del recurso del registro mediante el siguiente comando:

  az acr show -n myRegistry
  

  Después, puede asignar el rol de AcrPull o AcrPush a un usuario (en el ejemplo siguiente se usa AcrPull):

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

  O bien, asigne el rol a una entidad de servicio identificada por su identificador de la aplicación:

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

El usuario asignado es capaz entonces de autenticar y acceder a las imágenes en el registro.

• Para autenticarse en un registro:

  az acr login -n myRegistry 
  

• Para enumerar los repositorios:

  az acr repository list -n myRegistry
  

• Para extraer una imagen:

  docker pull myregistry.azurecr.io/hello-world
  

Con el uso solo del rol AcrPull o AcrPush, el usuario asignado no tiene permiso para administrar el recurso del registro en Azure. Por ejemplo, az acr list o az acr show -n myRegistry no mostrarán el registro.

La cuarentena de imágenes actualmente es una característica de versión preliminar de ACR. Puede habilitar el modo de cuarentena de un registro para que solo las imágenes que han pasado correctamente el análisis de seguridad sean visibles para los usuarios normales. Para más información, consulte el repositorio de GitHub para ACR.

Para más información, consulte el artículo en el que se explica cómo hacer que el contenido del Registro esté disponible públicamente.

Una capa no distribuible de un manifiesto contiene un parámetro de dirección URL en el cual se puede obtener dicho contenido. Algunos casos de uso posibles para habilitar inserciones de capas no redistribuibles son para registros restringidos de red, registros con separación aérea con acceso restringido o para registros sin conectividad a Internet.

Por ejemplo, si tiene reglas de grupo de seguridad de red configuradas para que una máquina virtual pueda extraer imágenes solo de su instancia de Azure Container Registry, Docker extraerá los errores de las capas externa o no distribuibles. Por ejemplo, una imagen de Windows Server básica contendría referencias de capas externas a Azure Container Registry en su manifiesto y no se podría extraer este escenario.

Para habilitar la inserción de capas no redistribuibles:

1. Edite el archivo daemon.json, que se encuentra en el directorio /etc/docker/ en los hosts con Linux y en el arrchivo C:\ProgramData\docker\config\daemon.json en Windows Server. Suponiendo que el archivo estaba vacío anteriormente, agregue el siguiente contenido:

   {
     "allow-nondistributable-artifacts": ["myregistry.azurecr.io"]
   }
   

   Nota

   El valor es una matriz de direcciones de registro, separadas por comas.

2. Guarde y cierre el archivo.

3. Reinicie Docker.

Al insertar imágenes en los registros de la lista, se insertan en el registro sus capas no redistribuibles.

Para solucionar problemas de registro y de entorno comunes, consulte Check the health of an Azure container registry (Comprobación del mantenimiento de un registro de contenedor de Azure).

• Si este error es un problema transitorio, entonces el reintento se realizará correctamente.
• Si docker pull produce un error continuamente, entonces podría haber un problema con el demonio de Docker. Por lo general, el problema se puede mitigar con el reinicio del demonio de Docker.
• Si continúa apareciendo este problema después de reiniciar el demonio de Docker, el problema podría tener que ver con algunos problemas de conectividad de red con la máquina. Para comprobar si la red general de la máquina está en buen estado, ejecute el siguiente comando para probar la conectividad de los puntos de conexión. La versión de az acr mínima que contiene este comando de comprobación de conectividad es 2.2.9. Actualice la CLI de Azure si está usando una versión anterior.

az acr check-health -n myRegistry

• Siempre debe tener un mecanismo de reintento en todas las operaciones del cliente de Docker.

Utilice la herramienta de velocidad para probar la velocidad de descarga de la red de la máquina. Si la red de la máquina es lenta, considere usar la máquina virtual de Azure en la misma región que el registro para mejorar la velocidad.

Utilice la herramienta de velocidad para probar la velocidad de carga de la red de la máquina. Si la red de la máquina es lenta, considere usar la máquina virtual de Azure en la misma región que el registro para mejorar la velocidad.

Este error puede ocurrir con la versión de Red Hat del demonio de Docker, donde --signature-verification está habilitado de forma predeterminada. Puede comprobar las opciones del demonio de Docker para Red Hat Enterprise Linux (RHEL) o Fedora mediante el siguiente comando:

grep OPTIONS /etc/sysconfig/docker

Por ejemplo, el servidor de Fedora 28 tiene las siguientes opciones de demonio de Docker:

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

Con --signature-verification=false que falta, docker pull produce un error similar al siguiente:

Trying to pull repository myregistry.azurecr.io/myimage ...
unauthorized: authentication required

Para resolver el error:

1. Agregue la opción --signature-verification=false al archivo de configuración del demonio de Docker /etc/sysconfig/docker. Por ejemplo:

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

2. Reinicie el servicio del demonio de Docker con el comando siguiente:

   sudo systemctl restart docker.service
   

Para encontrar los detalles de --signature-verification, ejecute man dockerd.

Asegúrese de usar una dirección URL de servidor en minúsculas, por ejemplo, docker push myregistry.azurecr.io/myimage:latest, incluso si el nombre de recurso del registro está en mayúsculas o en mayúsculas y minúsculas, como myRegistry.

Inicie dockerd con la opción debug. En primer lugar, cree el archivo de configuración del demonio de Docker (/etc/docker/daemon.json) si no existe y agregue la opción debug:

{    
    "debug": true    
}

Después, reinicie el demonio. Por ejemplo, con Ubuntu 14.04:

sudo service docker restart

Se puede encontrar más información en la documentación de Docker.

• Los registros se pueden generar en ubicaciones diferentes, dependiendo del sistema. Por ejemplo, para Ubuntu 14.04, es /var/log/upstart/docker.log:
  Consulte la documentación de Docker para obtener más información.

• Par Docker para Windows, los registros se generan en %LOCALAPPDATA%/docker/. Sin embargo, es posible que aún no contenga toda la información de depuración.

  Para acceder al registro completo del demonio, es posible que necesite algunos pasos adicionales:

  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
  

  Ahora tiene acceso a todos los archivos de la máquina virtual que ejecutan dockerd. El registro está en /var/log/docker.log.

Cuando concede nuevos permisos (nuevos roles) a una entidad de servicio, es posible que el cambio no tenga efecto inmediatamente. Hay dos razones posibles:

• Retraso de asignación de roles de Microsoft Entra. Normalmente es rápido, pero puede tardar algunos minutos debido a un retraso de propagación.

• El retraso de permisos en el servidor de tokens de ACR puede tardar hasta 10 minutos. Para mitigarlo, puede docker logout y después autenticarse de nuevo con el mismo usuario después de un minuto:

  docker logout myregistry.azurecr.io
  docker login myregistry.azurecr.io
  

Actualmente ACR no admite la eliminación de la replicación principal por parte de los usuarios. La solución consiste en incluir la réplica principal creada en la plantilla pero omitir su creación al agregar "condition": false como se muestra a continuación:

{
    "name": "[concat(parameters('acrName'), '/', parameters('location'))]",
    "condition": false,
    "type": "Microsoft.ContainerRegistry/registries/replications",
    "apiVersion": "2017-10-01",
    "location": "[parameters('location')]",
    "properties": {},
    "dependsOn": [
        "[concat('Microsoft.ContainerRegistry/registries/', parameters('acrName'))]"
     ]
},

Puede encontrar un error InvalidAuthenticationInfo, especialmente con la herramienta curl con la opción -L, --location (para seguir las redirecciones). Por ejemplo, capturar el blob mediante curl con la opción -L y autenticación básica:

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

puede dar lugar a la siguiente respuesta:

<?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>

La causa principal es que algunas implementaciones curl siguen las redirecciones con encabezados de la solicitud original.

Para resolver el problema, debe seguir las redirecciones manualmente sin los encabezados. Imprima los encabezados de respuesta con la opción -D - de curl y después extraiga el encabezado Location:

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

Si usa el explorador Microsoft Edge o Internet Explorer, puede ver un máximo de 100 repositorios o etiquetas. Si el registro tiene más de 100 repositorios o etiquetas, le recomendamos que utilice el explorador Firefox o Chrome para enumerarlos todos.

Es posible que el explorador no pueda enviar la solicitud para capturar repositorios o etiquetas al servidor. Esto puede deberse a varios motivos, como los siguientes:

• No hay conexión de red
• Firewall
• Uso del portal desde una red pública para un registro que solo permite el acceso privado
• Bloqueadores de publicidad
• Errores de DNS

Póngase en contacto con el administrador de red o compruebe la configuración y la conectividad de la red. Intente ejecutar az acr check-health -n yourRegistry mediante la CLI de Azure para comprobar si el entorno puede conectarse a Azure Container Registry. Además, también puede probar una sesión de incógnito o privada en el explorador para evitar cookies o memoria caché del explorador obsoletas.

Estos son algunos escenarios en los que es posible que no se permitan operaciones:

• Ya no se admiten los registros clásicos. Actualice a un nivel de servicio compatible mediante az acr update o Azure Portal.
• Es posible que la imagen o el repositorio estén bloqueados para que no se puedan eliminar ni actualizar. Puede usar el comando az acr repository show para ver los atributos actuales.
• Algunas operaciones no se permiten si la imagen está en cuarentena. Más información sobre la cuarentena.
• Puede que el registro haya alcanzado su límite de almacenamiento.

Si recibe un error tipo "formato de repositorio no compatible", "formato no válido" o "los datos solicitados no existen" al especificar un nombre de repositorio en las operaciones del repositorio, compruebe la ortografía y las mayúsculas y minúsculas en el nombre. Los nombres de repositorio válidos solo pueden incluir caracteres alfanuméricos en minúscula, puntos, guiones, guiones bajos y barras diagonales.

Requisitos previos

• Habilitar el descifrado de HTTPS en Fiddler.
• Habilitar Docker para usar un proxy mediante la interfaz de usuario de Docker.
• Asegúrese de revertirlo cuando termine. Docker no funcionará con esto habilitado y Fiddler no se ejecutará.

Contenedores de Windows

Configure el proxy de Docker en 127.0.0.1:8888.

Contenedores de Linux

Busque la dirección IP de Docker del conmutador virtual de la máquina virtual de Docker:

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

Configure el proxy de Docker para la salida del comando anterior y el puerto 8888 (por ejemplo 10.0.75.1:8888).

Los siguientes comandos cancelan todas las tareas en ejecución en el registro especificado.

az acr task list-runs -r $myregistry --run-status Running --query '[].runId' -o tsv \
| xargs -I% az acr task cancel-run -r $myregistry --run-id %

Si se pasa una carpeta de origen local al comando az acr build, la carpeta .git se excluye del paquete cargado de forma predeterminada. Puede crear un archivo .dockerignore con la siguiente configuración. Indica al comando que restaure todos los archivos bajo .git en el paquete cargado.

!.git/**

Esta configuración también se aplica al comando az acr run.

Actualmente no se admite GitLab para desencadenadores de origen.

Solución de problemas de mensajes de error de ejecución

Integración de CI/CD

• CircleCI
• Acciones de GitHub

Configure las reglas de firewall correctas en los grupos de seguridad de red existentes o en las rutas definidas por el usuario. Después de la instalación, espere unos minutos para que se apliquen las reglas de firewall.

La siguiente directiva integrada de Azure, cuando se establece en el estado de directiva correspondiente, impedirá que el usuario habilite al usuario administrador en su registro.

Pasos siguientes

• Más información acerca de Azure Container Registry.