Solución de problemas habituales de Azure Container Instances
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 del contenedor, determinados parámetros requieren el cumplimiento de las restricciones de nomenclatura. En la tabla siguiente se muestran los 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 suele producirse al implementar imágenes de Windows basadas en la versión 1709 o 1803 del canal semianual, que no se admite. 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 la imagen existe en el Registro y ha escrito correctamente el nombre de la 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 pesada en la región en la que se intenta implementar, los recursos especificados para el contenedor no se pueden asignar 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 salidas repetidas y reinicios con imágenes como Ubuntu o Alpine. La conexión a través de EXEC no funcionará porque el contenedor no tiene ningún proceso que lo mantenga activo. Para resolver este problema, incluya un comando start como el ejemplo 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 salida del ejemplo siguiente, que truncamos para mayor brevedad, 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 más consideraciones.
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 pequeños tamaños de imagen es asegurarse de que la imagen final no contenga 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 el acceso directo a la infraestructura subyacente que hospeda 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 Foros 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 que la dirección IP de un grupo de contenedores no es accesible cuando cree que debe ser, asegúrese de configurar la imagen de contenedor para escuchar 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:
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, debe ajustar la asignación de variables en consecuencia.
az container create --resource-group myResourceGroup \ --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \ --ip-address Public --ports 9000 \ --environment-variables 'PORT'='9000'Busque la dirección IP del grupo de contenedores en la salida del comando de
az container create. Busque el valor de ip.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.
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 usa 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 un error de coincidencia de capas cuando se valida la directiva. Asegúrese de quitar las imágenes antiguas y extraer 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.