Contenedores en Azure Container Apps
Azure Container Apps le administra los detalles de Kubernetes y las orquestaciones de contenedores. Los contenedores de Azure Container Apps pueden usar cualquier runtime, lenguaje de programación o pila de desarrollo de su elección.
Azure Container Apps admite:
- Cualquier imagen de contenedor x86-64 (
linux/amd64
) basada en Linux - Contenedores de cualquier registro de contenedor público o privado
- Contenedores sidecar e init opcionales
Las características también incluyen:
- Las aplicaciones usan la sección de configuración de
template
para definir la imagen de contenedor y otras opciones de configuración. Los cambios en la sección de configuracióntemplate
desencadenan una nueva revisión de aplicación de contenedor. - Si un contenedor se bloquea, se reinicia automáticamente.
Entre las características de los trabajos se incluyen:
- Las ejecuciones de trabajos usan la sección de configuración de
template
para definir la imagen de contenedor y otros valores cuando se inicia cada ejecución. - Si un contenedor sale con un código de salida distinto de cero, la ejecución del trabajo se marca como errónea. Puede configurar un trabajo para reintentar ejecuciones con errores.
Configuración
La mayoría de las aplicaciones de contenedor tienen un único contenedor. En escenarios avanzados, una aplicación también puede tener contenedores sidecar y de inicialización. En una definición de aplicación de contenedor, la aplicación principal y sus contenedores sidecar se muestran en la matriz containers
de la sección properties.template
y los contenedores de inicialización se muestran en la matriz initContainers
. El siguiente extracto muestra las opciones de configuración disponibles al configurar los contenedores de una aplicación.
{
"properties": {
"template": {
"containers": [
{
"name": "main",
"image": "[parameters('container_image')]",
"env": [
{
"name": "HTTP_PORT",
"value": "80"
},
{
"name": "SECRET_VAL",
"secretRef": "mysecret"
}
],
"resources": {
"cpu": 0.5,
"memory": "1Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
],
"probes": [
{
"type": "liveness",
"httpGet": {
"path": "/health",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "liveness probe"
}
]
},
"initialDelaySeconds": 7,
"periodSeconds": 3
},
{
"type": "readiness",
"tcpSocket": {
"port": 8081
},
"initialDelaySeconds": 10,
"periodSeconds": 3
},
{
"type": "startup",
"httpGet": {
"path": "/startup",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "startup probe"
}
]
},
"initialDelaySeconds": 3,
"periodSeconds": 3
}
]
}
]
},
"initContainers": [
{
"name": "init",
"image": "[parameters('init_container_image')]",
"resources": {
"cpu": 0.25,
"memory": "0.5Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
]
}
]
...
}
...
}
Configuración | Descripción | Comentarios |
---|---|---|
image |
Nombre de la imagen de contenedor para la aplicación de contenedor. | Este valor toma la forma de repository/<IMAGE_NAME>:<TAG> . |
name |
Nombre descriptivo del contenedor. | Se usa para la identificación y los informes. |
command |
Comando de inicio del contenedor. | Equivalente al campo de punto de entrada de Docker. |
args |
Argumentos del comando de inicio. | Las entradas de la matriz se unen para crear una lista de parámetros que se pasa al comando de inicio. |
env |
Matriz de pares nombre-valor que definen variables de entorno. | Utilice secretRef en lugar del campo value para hacer referencia a un secreto. |
resources.cpu |
Número de CPU asignadas al contenedor. | Consulte Requisitos de asignación de memoria y vCPU |
resources.memory |
Cantidad de RAM asignada al contenedor. | Consulte Requisitos de asignación de memoria y vCPU |
volumeMounts |
Una matriz de definiciones de montaje de volumen. | Puede definir volúmenes de almacenamiento temporales o permanentes para el contenedor. Para obtener más información sobre los volúmenes de almacenamiento, consulte Uso de montajes de almacenamiento en Azure Container Apps. |
probes |
Una matriz de sondeos de estado habilitados en el contenedor. | Para más información sobre la configuración de sondeos, consulte Sondeos de estado en Azure Container Apps. |
Requisitos de asignación de memoria y vCPU
Al usar el plan de consumo, el total de CPU y memoria asignados a todos los contenedores de una aplicación de contenedor debe agregar una de las siguientes combinaciones.
vCPU (núcleos) | Memoria |
---|---|
0.25 |
0.5Gi |
0.5 |
1.0Gi |
0.75 |
1.5Gi |
1.0 |
2.0Gi |
1.25 |
2.5Gi |
1.5 |
3.0Gi |
1.75 |
3.5Gi |
2.0 |
4.0Gi |
2.25 |
4.5Gi |
2.5 |
5.0Gi |
2.75 |
5.5Gi |
3.0 |
6.0Gi |
3.25 |
6.5Gi |
3.5 |
7.0Gi |
3.75 |
7.5Gi |
4.0 |
8.0Gi |
Nota:
Las aplicaciones que usan el plan de consumo en un entorno de Solo consumo se limitan a un máximo de 2 núcleos y 4Gi de memoria.
Varios contenedores
En escenarios avanzados, puede ejecutar varios contenedores en una sola aplicación de contenedor. Use este patrón solo en instancias específicas en las que los contenedores estén estrechamente acoplados.
Para la mayoría de los escenarios de microservicio, el procedimiento recomendado es implementar cada servicio como una aplicación de contenedor independiente.
Varios contenedores de la misma aplicación de contenedor comparten recursos de disco duro y red y experimentan el mismo ciclo de vida de la aplicación.
Hay dos maneras de ejecutar contenedores adicionales en una aplicación de contenedor: contenedores sidecar y contenedores de inicialización.
Contenedores sidecar
Puede definir varios contenedores en una sola aplicación contenedora para implementar el patrón sidecar.
Algunos ejemplos de contenedores sidecar son los siguientes:
Un agente que lee los registros del contenedor de aplicaciones principal en un volumen compartido y los reenvía a un servicio de registro.
Un proceso en segundo plano que actualiza una memoria caché usada por el contenedor de aplicaciones principal en un volumen compartido.
Estos escenarios son ejemplos y existen otras formas de implementar un sidecar.
Para ejecutar varios contenedores en una aplicación de contenedor, agregue más de un contenedor en la matriz containers
de la plantilla de aplicación contenedora.
Iniciar contenedores
Puede definir uno o varios contenedores de inicialización en una aplicación de contenedor. Los contenedores de inicialización se ejecutan antes del contenedor de aplicación principal y se usan para realizar tareas de inicialización, como descargar datos o preparar el entorno.
Los contenedores de inicialización se definen en la matriz initContainers
de la plantilla de aplicación de contenedor. Los contenedores se ejecutan en el orden en que se definen en la matriz y deben completarse correctamente antes de que se inicie el contenedor de la aplicación principal.
Nota:
Los contenedores de inicialización de aplicaciones que usan el plan dedicado o que se ejecutan en un entorno de Solo consumo no pueden acceder a la identidad administrada en tiempo de ejecución.
Registros de contenedor
Puede implementar imágenes hospedadas en registros privados proporcionando credenciales en la configuración de Container Apps.
Para usar un registro de contenedor, defina el registro en la matriz registries
en la sección properties.configuration
de la plantilla de recursos de la aplicación de contenedor. El campo passwordSecretRef
identifica el nombre del secreto en el nombre de la matriz secrets
donde definió la contraseña.
{
...
"registries": [{
"server": "docker.io",
"username": "my-registry-user-name",
"passwordSecretRef": "my-password-secret-name"
}]
}
Las credenciales guardadas se usan para extraer una imagen de contenedor del registro privado a medida que se implementa la aplicación.
En el ejemplo siguiente se muestra cómo configurar las credenciales de Azure Container Registry en una aplicación contenedora.
{
...
"configuration": {
"secrets": [
{
"name": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-password"
}
]
}
}
Nota:
Docker Hub limita el número de descargas de imágenes de Docker. Cuando se alcanza el límite, los contenedores de la aplicación no se iniciarán. Use un registro con límites suficientes, como Azure Container Registry para evitar este problema.
Identidad administrada con Azure Container Registry
Puede usar una identidad administrada de Azure para autenticarse con Azure Container Registry en lugar de usar un nombre de usuario y una contraseña. Para obtener más información, vea Identidades administradas en Azure Container Apps.
Para usar la identidad administrada con un registro, la identidad debe estar habilitada en la aplicación y se debe asignar el rol acrPull
en el registro. Para configurar el registro, use el id. de recurso de identidad administrada para una identidad asignada por el usuario o system
para la identidad asignada por el sistema en la propiedad identity
del registro. No configure un nombre de usuario y una contraseña al usar la identidad administrada.
{
"identity": {
"type": "SystemAssigned,UserAssigned",
"userAssignedIdentities": {
"<IDENTITY1_RESOURCE_ID>": {}
}
}
"properties": {
"configuration": {
"registries": [
{
"server": "myacr1.azurecr.io",
"identity": "<IDENTITY1_RESOURCE_ID>"
},
{
"server": "myacr2.azurecr.io",
"identity": "system"
}]
}
...
}
}
Para obtener más información sobre cómo configurar identidades asignadas por el usuario, consulte Adición de una identidad asignada por el usuario.
Limitaciones
Azure Container Apps tiene las siguientes limitaciones:
Contenedores con privilegios: Azure Container Apps no permite el modo de contenedores con privilegios con acceso a nivel de host.
Sistema operativo: se necesitan imágenes de contenedor basadas en Linux (
linux/amd64
).Tamaño máximo de imagen:
- El perfil de carga de trabajo de consumo admite imágenes de contenedor de hasta 8 GB para cada aplicación o réplica de trabajo.
- Los perfiles de carga de trabajo dedicados admiten imágenes de contenedor más grandes. Dado que un perfil de carga de trabajo dedicado puede ejecutar varias aplicaciones o trabajos, varias imágenes de contenedor comparten el espacio en disco disponible. El tamaño de imagen admitido real varía en función de los recursos consumidos por otras aplicaciones y trabajos.