Azure Container Apps

Azure Container Apps (ACA) es un servicio de alojamiento de contenedores sin servidor totalmente administrado, basado en Kubernetes y KEDA (Kubernetes Event-Driven Autoscaling). A diferencia de AKS, no tiene que administrar directamente el plano de control, los grupos de nodos ni los manifiestos de Kubernetes. En su lugar, implementa los contenedores mediante una CLI sencilla o una definición YAML, y Azure se encarga de toda la orquestación. ACA es ideal para microservicios, backends de API, procesos de trabajo basados en eventos y trabajos de procesamiento en segundo plano que necesitan escalar dinámicamente, incluido el escalado a cero.

Un entorno de Container Apps es el límite aislado dentro del cual se ejecutan una o más Container Apps. Todas las aplicaciones de un entorno comparten la misma red virtual y el mismo espacio de trabajo de Log Analytics. Los entornos tienen como ámbito una región y un grupo de recursos. Puede implementar varios entornos para aislar equipos o etapas (producción frente a preparación). Opcionalmente, puede inyectar el entorno en una VNet propia para permitir la comunicación privada entre Container Apps y otros servicios de Azure sin pasar por Internet público.

Para implementar una Container App, especifique la imagen del contenedor (de Azure Container Registry o de cualquier registro público), el número de réplicas y las variables de entorno. La aplicación estará disponible públicamente mediante una URL HTTPS generada automáticamente si habilita la entrada externa. La configuración de entrada incluye el puerto de destino, la división del tráfico para implementaciones blue-green y si se permite únicamente HTTP o HTTPS. ACA extrae la imagen durante la implementación; el entorno debe tener permisos de extracción en el registro.

Container Apps escala mediante escaladores de KEDA que se activan según métricas externas. Los escaladores de KEDA integrados incluyen: tráfico HTTP (solicitudes simultáneas por réplica), profundidad de la cola de Azure Service Bus (mensajes en espera), Azure Storage Queue, Cron (basado en el tiempo) y CPU/Memoria. Cuando la métrica del escalador llega a cero y minReplicas está establecido en 0, Container Apps se escala a cero, lo que no genera costes de proceso hasta que llegan nuevas solicitudes. El escalado a cero es excelente para procesos de trabajo basados en eventos con cargas de trabajo esporádicas.

Dapr (Distributed Application Runtime) es un entorno de ejecución portátil y basado en eventos que simplifica la creación de microservicios. Container Apps ofrece integración nativa con Dapr: se habilita por aplicación con un solo indicador. Dapr proporciona bloques de construcción para la invocación de servicios (con reintentos y mTLS), la mensajería pub/sub (que abstrae Service Bus y Event Hubs), la administración del estado (que abstrae Redis y Cosmos DB) y los enlaces de salida. Con Dapr, los microservicios se comunican mediante el sidecar de Dapr sin conocer los detalles de la infraestructura subyacente.

Cada implementación en una Container App crea una nueva revisión. En el modo de varias revisiones, puede dividir el tráfico entre revisiones para realizar implementaciones blue-green o canary. Por ejemplo, puede enviar el 10 % del tráfico a una revisión nueva y el 90 % a la revisión estable actual. Supervise las tasas de error y la latencia de la nueva revisión antes de aumentar su porcentaje de tráfico al 100 %. Las revisiones antiguas se pueden desactivar, pero se conservan en el historial, lo que permite revertir los cambios al instante volviendo a asignar el porcentaje de tráfico.

Container Apps admite dos formas de inyectar la configuración: variables de entorno (para configuraciones no confidenciales, como indicadores de características o URL de API) y secretos (para valores confidenciales, como cadenas de conexión). Los secretos se almacenan en el nivel de Container App y se referencian mediante variables de entorno o componentes de Dapr. Para obtener la configuración más segura, haga referencia a los secretos de Azure Key Vault mediante una identidad administrada, de modo que el valor del secreto se recupere en tiempo de ejecución y nunca se almacene en el plano de configuración de Container App.

Container Apps Jobs amplía la plataforma para admitir cargas de trabajo que se ejecutan hasta finalizar: contenedores que se inician, realizan su trabajo y terminan. Jobs admite tres tipos de desencadenadores: Manual (se activa mediante la API o la CLI), Programado (expresión cron) y Basado en eventos (los desencadenadores del escalador de KEDA activan cada ejecución). Jobs solo se factura por el tiempo real de ejecución y resulta ideal para el procesamiento por lotes, la generación de informes, las migraciones de bases de datos y las canalizaciones de inferencia de ML que se ejecutan periódicamente o en respuesta a eventos.

Container Apps envía registros del sistema (eventos de la plataforma, como la creación de revisiones y el escalado) y registros de consola (la salida stdout/stderr de su aplicación) al área de trabajo de Log Analytics asociada al entorno. Consulte los registros con KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Las métricas integradas de Azure Monitor incluyen el número de réplicas, el número de solicitudes, la latencia de las solicitudes y la utilización de CPU/memoria por réplica; todas están disponibles en Azure Portal sin configuración adicional.

Para elegir la plataforma de contenedores de Azure adecuada: Container Apps es la mejor opción para microservicios, trabajadores basados en eventos y API cuando desea las ventajas de Kubernetes sin administrar el clúster, especialmente si resulta útil escalar a cero. AKS es la mejor opción cuando necesita control total de Kubernetes, operadores personalizados o configuraciones de nodo específicas (GPU, mucha memoria). App Service es la mejor opción para aplicaciones web y API tradicionales cuando el equipo de desarrollo prefiere un modelo de PaaS sencillo sin la sobrecarga de administrar contenedores. Las tres plataformas admiten contenedores; la diferencia está entre la complejidad de administración y el nivel de control.

Container Apps admite dos modos de entrada: Externa (accesible públicamente mediante un punto de conexión HTTPS con equilibrio de carga y TLS automático) e Interna (accesible únicamente desde el mismo entorno de Container Apps o desde recursos conectados mediante emparejamiento de VNet). La entrada interna se utiliza para servicios de backend que nunca deben exponerse a Internet. Las aplicaciones pueden llamarse entre sí mediante el nombre DNS interno generado automáticamente http://myapi dentro del mismo entorno, lo que permite una comunicación sencilla entre servicios sin implementar una puerta de enlace de API.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que Azure Container Apps proporciona alojamiento de contenedores sin servidor basado en Kubernetes y KEDA, sin necesidad de administrar clústeres; los escaladores de KEDA permiten escalar a cero según la profundidad de la cola, el tráfico HTTP o las programaciones cron; y la integración con Dapr simplifica la comunicación entre microservicios y la administración del estado. A continuación, conectaremos todos estos elementos en un flujo de trabajo de desarrollo completo de extremo a extremo.