Solución de problemas habituales de Azure Container Instances

  • Artículo

En este artículo se muestra cómo solucionar problemas habituales al administrar o implementar contenedores en Azure Container Instances. Consulte también las preguntas más frecuentes.

Si necesita soporte adicional, vea las opciones disponibles de Ayuda y soporte técnico en Azure Portal.

Problemas durante la implementación del grupo de contenedores

Convenciones de nomenclatura

Al definir la especificación de contenedor, ciertos parámetros requieren tener en cuenta las restricciones de nomenclatura. A continuación se muestra una tabla con requisitos específicos para las propiedades del grupo de contenedores. Para obtener más información, consulte Convenciones de nomenclatura en el Centro de arquitectura de Azure y Reglas y restricciones de nomenclatura para los recursos de Azure.

Ámbito Length Uso de mayúsculas y minúsculas Caracteres válidos Patrón sugerido Ejemplo
Nombre de contenedor1 1-63 Minúsculas Caracteres alfanuméricos y guion en cualquier lugar, excepto el primer o último carácter <name>-<role>-container<number> web-batch-container1
Puertos del contenedor Entre 1 y 65 535 Entero Un número entero comprendido entre 1 y 65 535 <port-number> 443
Etiqueta de nombre DNS 5-63 No distingue mayúsculas de minúsculas Caracteres alfanuméricos y guion en cualquier lugar, excepto el primer o último carácter <name> frontend-site1
Variable de entorno 1-63 No distingue mayúsculas de minúsculas Caracteres alfanuméricos y guion bajo (_) en cualquier lugar, excepto el primer o último carácter <name> MY_VARIABLE
Nombre del volumen 5-63 Minúsculas Caracteres alfanuméricos y guiones en cualquier lugar, excepto el primer o último carácter. No puede contener dos guiones consecutivos. <name> batch-output-volume

1 La restricción también incluye nombres de grupos de contenedores cuando no se especifican independientemente de las instancias de contenedor, por ejemplo, con implementaciones del comando az container create.

Versión del sistema operativo de imagen no admitida

Si se especifica una imagen que Azure Container Instances no admite, se devuelve un error OsVersionNotSupported. El error es similar a la siguiente, donde {0} es el nombre de la imagen que intentó implementar:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

Este error se suele encontrar con más frecuencia al implementar imágenes de Windows basadas en una versión de canal semianual (SAC) 1709 o 1803, que no se admiten. Para obtener imágenes de Windows admitidas en Azure Container Instances, consulte las preguntas más frecuentes.

No se puede extraer la imagen

Si inicialmente Azure Container Instances no puede extraer su imagen, lo reintenta durante un periodo de tiempo. Si la operación de extracción de imágenes sigue generando errores, ACI acaba por no realizar la implementación y se muestra un error Failed to pull image.

Para resolver este problema, elimine la instancia de contenedor y vuelva a intentar la implementación. Asegúrese de que existe la imagen en el registro y de que ha escrito correctamente el nombre de imagen.

Si no se puede extraer la imagen, se muestran eventos similares al siguiente en la salida de az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

Error de recurso no disponible

Debido a la carga variable de recursos regionales en Azure, podría recibir el siguiente error al intentar implementar una instancia del contenedor:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

Este error indica que, debido a una carga elevada en la región en la que está intentando la implementación, no se pueden asignar los recursos especificados para el contenedor en ese momento. Utilice uno o varios de los siguientes pasos de mitigación para ayudar a resolver el problema.

  • Compruebe que la configuración de implementación del contenedor se encuentra dentro de los parámetros definidos en Region availability for Azure Container Instances (Disponibilidad de regiones en instancias de Azure Container)
  • Especifique la configuración de CPU y memoria más baja para el contenedor
  • Implemente en una región distinta de Azure
  • Implemente en un momento posterior

Problemas durante el tiempo de ejecución del grupo de contenedores

El contenedor tenía un reinicio aislado sin la entrada explícita del usuario

Hay dos categorías generales por las que un grupo de contenedores puede reiniciarse sin una entrada de usuario explícita. En primer lugar, los contenedores pueden experimentar reinicios causados por un bloqueo del proceso de aplicación. El servicio ACI recomienda aplicar soluciones de observabilidad como el SDK de Application Insights, métricas de grupo de contenedores y registros de grupos de contenedores para determinar la razón de las incidencias ocurridas. En segundo lugar, los clientes pueden experimentar reinicios provocados por la infraestructura de ACI debido a eventos de mantenimiento. Para aumentar la disponibilidad de la aplicación, ejecute varios grupos de contenedores detrás de un componente de entrada, como un Application Gateway o Traffic Manager.

El contenedor se cierra y se reinicia continuamente (sin proceso de ejecución prolongada)

Los grupos de contenedores tienen una directiva de reinicio establecida en Always (Siempre) de forma predeterminada, por lo que los contenedores del grupo de contenedores siempre se reinician después de ejecutarse hasta su finalización. Es posible que deba cambiar este valor a OnFailure (En caso de error) o Never (Nunca) si va a ejecutar contenedores basados en tareas. Si especifica OnFailure y sigue observando reinicios continuos, podría haber un problema con la aplicación o el script que se ejecuta en el contenedor.

Al ejecutar grupos de contenedores sin procesos de ejecución prolongada, es posible que vea cierres y reinicios repetidos con imágenes como Ubuntu o Alpine. La conexión mediante EXEC no funcionará porque el contenedor no tiene ningún proceso que lo mantenga activo. Para resolver este problema, incluya un comando de inicio similar al siguiente con la implementación del grupo de contenedores para mantener el contenedor en ejecución.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

La API de Container Instances y Azure Portal incluyen una propiedad restartCount. Para comprobar el número de reinicios de un contenedor, puede usar el comando az container show de la CLI de Azure. En la siguiente salida de ejemplo (que se ha truncado por razones de brevedad), puede ver la propiedad restartCount al final de la salida.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

Nota

La mayoría de las imágenes de contenedor para las distribuciones de Linux establecen una shell, como bash, como el comando predeterminado. Puesto que un shell por sí mismo no es un servicio de ejecución prolongada, estos contenedores se cierran inmediatamente y caen en un bucle de reinicio cuando se configuran con la directiva de reinicio predeterminada Always.

El contenedor tarda mucho tiempo en iniciar

Los tres factores principales que contribuyen al tiempo de inicio del contenedor en Azure Container Instances son:

Las imágenes de Windows tienen consideraciones adicionales.

Tamaño de las imágenes

Si el contenedor tarda mucho tiempo en iniciar, pero al final se realiza correctamente, comience por mirar el tamaño de la imagen del contenedor. Como Azure Container Instances extrae la imagen del contenedor a petición, el tiempo de inicio está directamente relacionado con su tamaño.

Puede ver el tamaño de la imagen del contenedor mediante el comando docker images en la CLI de Docker:

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

La clave para mantener tamaños de imagen pequeños es asegurarse de que la imagen final no contiene nada que no sea necesario en tiempo de ejecución. Una manera de hacerlo es con compilaciones en varias etapas. Las compilaciones en varias etapas hacen más sencillo asegurarse de que la imagen final contiene solo los artefactos necesarios para la aplicación y no los del contenido extra que se requiere en tiempo de compilación.

Ubicación de las imágenes

Otra forma de reducir el impacto de la extracción de la imagen en el tiempo de inicio del contenedor es hospedar la imagen del contenedor con Azure Container Registry en la misma región en la que van a implementar las instancias de contenedor. Esto reduce la ruta de acceso de red que debe recorrer la imagen del contenedor, lo que reduce significativamente el tiempo de descarga.

Imágenes en caché

Azure Container Instances usa un mecanismo de almacenamiento en caché para acelerar el tiempo de inicio del contenedor para las imágenes creadas con imágenes de base de Windows, incluidas nanoserver:1809, servercore:ltsc2019 y servercore:1809. También se almacenan en caché las imágenes de Linux usadas comúnmente, como ubuntu:1604 y alpine:3.6. En el caso de las imágenes de Windows y Linux, evite usar la etiqueta latest. Revise los procedimientos recomendados de etiquetas de imágenes de Container Registry para obtener instrucciones. Para obtener una lista actualizada de imágenes y etiquetas en caché, use la API List Cached Images.

Nota

El uso de imágenes basadas en Windows Server 2019 en Azure Container Instances está en versión preliminar.

Preparación para la red lenta de contenedores de Windows

Durante la creación inicial, los contenedores de Windows pueden no tener conectividad de entrada o salida hasta un máximo de 30 segundos (o, en raras ocasiones, incluso más). Si la aplicación contenedora necesita una conexión a Internet, agregue una lógica de retraso y reintento para dejar 30 segundos para el establecimiento de la conectividad de Internet. Después de la instalación inicial, las redes de contenedores se deben reanudar adecuadamente.

No se puede conectar a la API de Docker subyacente ni ejecutar contenedores con privilegios

Azure Container Instances no expone acceso directo a la infraestructura subyacente que hospeda los grupos de contenedores. Esto incluye el acceso al entorno de ejecución del contenedor, la tecnología de orquestación y la ejecución de operaciones de contenedor con privilegios. Para ver qué operaciones admite ACI, consulte la documentación de referencia de REST. Si falta algo, envíe una solicitud en los foro de comentarios de ACI.

Las direcciones IP del grupo de contenedores pueden no estar accesibles debido a que los puertos no coinciden

Azure Container Instances no admite aún la asignación de puertos con la configuración normal de Docker. Si encuentra una dirección IP de grupo de contenedores no accesible y cree que debería serlo, asegúrese de que ha configurado la imagen de contenedor para que escuche a los mismos puertos que expone en el grupo de contenedores con la propiedad ports.

Si desea confirmar que Azure Container Instances escucha en el puerto que configuró en la imagen de contenedor, pruebe una implementación de la imagen aci-helloworld que expone el puerto. Ejecute también la aplicación aci-helloworld para que escuche en el puerto. aci-helloworld acepta una variable de entorno opcional PORT para invalidar el puerto 80 predeterminado en el que escucha. Por ejemplo, para probar el puerto 9000, establezca la variable de entorno al crear el grupo de contenedores:

  1. Configure el grupo de contenedores para que exponga el puerto 9000 y pase el número de puerto como el valor de la variable de entorno. El ejemplo tiene el formato adecuado para el shell de Bash. Si prefiere otro shell como PowerShell o el símbolo del sistema, deberá ajustar la asignación de variables según corresponda.

    az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'

  2. Busque la dirección IP del grupo de contenedores en la salida del comando de az container create. Busque el valor de ip.

  3. Una vez aprovisionado el contenedor correctamente, vaya a la dirección IP y al puerto de la aplicación contenedora en el explorador, por ejemplo, 192.0.2.0:9000.

    Debería ver el mensaje "Le damos la bienvenida a Azure Container Instances" que se muestra en la aplicación web.

  4. Cuando haya terminado con el contenedor, elimínelo con el comando az container delete:

    az container delete --resource-group myResourceGroup --name mycontainer

Incidencias durante las implementaciones de grupos de contenedores confidenciales

Errores de directiva al usar una directiva de CCE personalizada

Las directivas de CCE personalizadas deben generarse en la extensión confcom de la CLI de Azure. Antes de generar la directiva, asegúrese de que todas las propiedades especificadas en la plantilla de ARM sean válidas y coincidan con lo que espera que se represente en una directiva de computación confidencial. Entre las propiedades a validar se incluyen la imagen de contenedor, las variables de entorno, los montajes de volumen y los comandos de contenedor.

Falta el hash de la directiva

La extensión confcom de la CLI de Azure usará imágenes almacenadas en caché en el equipo local que pueden no coincidir con las que están disponibles de forma remota, lo que puede dar lugar a una discrepancia en las capas al validar la directiva. Asegúrese de quitar las imágenes antiguas e incorporar las imágenes de contenedor más recientes en el entorno local. Una vez que esté seguro de que tiene el SHA más reciente, debe volver a generar la directiva de CCE.

El contenedor o proceso finalizó con el código de salida: 139

Este código de salida se produce debido a limitaciones con la imagen base de Ubuntu, versión 22.04. Se recomienda usar una imagen base diferente para resolver este problema.

Pasos siguientes

Obtenga información sobre cómo recuperar eventos y registros de contenedor para ayudar a depurar los contenedores.