Operar Azure Container Apps con seguridad: revisiones, ciclo de vida, registros, sondeos y escalado

radio_button_uncheckedshort_text1. Operación continua de una carga de IA

Las actualizaciones frecuentes de modelos, prompts, dependencias y enrutamiento hacen que los servicios de IA cambien rápidamente. Imagina una canalización documental con una API HTTP para recibir PDF y un worker para OCR y clasificación. Ambos se ejecutan en Azure Container Apps, y el objetivo es publicar varias veces al día sin enviar usuarios a una revisión defectuosa.

Un flujo fiable conecta identidad del artefacto, estado de revisión, tráfico, registros, sondeos y capacidad. Así, el equipo diagnostica una revisión que nunca está lista mientras la anterior sigue atendiendo, y conserva versiones antiguas solo durante la ventana de rollback y auditoría.

• Actualizar imágenes y administrar activación, desactivación, rollback y limpieza.
• Elegir entre iniciar, detener, reiniciar y reducir a cero.
• Investigar errores mediante registros sin depender del shell.
• Ajustar inicio, preparación y ejecución al calentamiento del modelo.
• Equilibrar CPU y memoria por réplica con límites y reglas de escalado.

Resumen del tema

La fiabilidad posterior al despliegue une versiones, revisiones, observabilidad, sondeos y capacidad en un runbook repetible.

radio_button_uncheckedshort_text2. Etiquetas, resúmenes y actualizaciones que crean revisiones

Una etiqueta es un nombre móvil como dev o staging. El resumen de imagen identifica contenido inmutable. En producción conviene usar el digest para relacionar un incidente con el contenedor y el build de modelo exactos; una etiqueta reutilizada no ofrece la misma trazabilidad.

Los cambios en la plantilla - imagen o configuración de escala - pertenecen a la revisión y producen otra instantánea inmutable. Configuraciones de la aplicación como el tráfico de entrada alcanzan todas las revisiones. Después de actualizar, comprueba la plantilla registrada.

az containerapp update \
  --name ai-document-api \
  --resource-group rg-ai200-aca \
  --image myregistry.azurecr.io/ai-document-api@sha256:<digest>

az containerapp show \
  --name ai-document-api \
  --resource-group rg-ai200-aca \
  --query properties.template.containers

Resumen del tema

Usa resúmenes auditables, distingue qué cambios crean revisiones y valida la plantilla antes de dirigir tráfico.

radio_button_uncheckedshort_text3. Modos de revisión, activación, tráfico y rollback

En modo de revisión única, la versión anterior sigue activa hasta que la sustituta se aprovisiona, alcanza las réplicas esperadas y supera los sondeos de inicio y preparación. Si falla, el tráfico permanece en la anterior. El modo múltiple permite varias revisiones, reparto ponderado, canary, pruebas A/B y despliegue azul-verde.

Activa significa que puede ejecutar y recibir tráfico, no que deba recibirlo todo. Las inactivas preservan historial sin réplicas. Confirma estado y registros antes de modificar pesos y usa una pequeña cuota canary cuando el modelo necesite validación real.

Resumen del tema

El modo único automatiza una transición protegida; el múltiple ofrece activación y reparto para entrega progresiva y rollback rápido.

radio_button_uncheckedshort_text4. Inspeccionar, desactivar y conservar revisiones

Enumera revisiones para localizar la activa y la defectuosa, y compara imagen, entorno, recursos y estado con una versión sana. Desactiva antes de eliminar: se detienen réplicas y tráfico, pero queda la configuración como evidencia y posible rollback.

az containerapp revision list \
  --name ai-document-api --resource-group rg-ai200-aca --all -o table

az containerapp revision show \
  --name ai-document-api --resource-group rg-ai200-aca \
  --revision <revision-name>

az containerapp revision deactivate \
  --name ai-document-api --resource-group rg-ai200-aca \
  --revision <revision-name>

Elimina revisiones obsoletas después del incidente y de la ventana de rollback. Azure Container Apps conserva por defecto hasta 100 revisiones inactivas y purga las más antiguas al superar el límite. Ajusta maxInactiveRevisions según auditoría, recuperación y claridad operativa.

Resumen del tema

Investiga por revisión, desactiva antes de borrar y documenta una ventana de retención para rollback y evidencia.

radio_button_uncheckedshort_text5. Iniciar, detener, reiniciar o reducir a cero

Cada acción resuelve un caso. Reducir a cero es automático y guiado por reglas; detener es una pausa explícita de toda la aplicación que impide nuevas réplicas; reiniciar recicla réplicas para un estado transitorio o un cambio, pero aumenta los inicios en frío cuando se cargan modelos grandes.

Iniciar y detener actúan sobre toda la aplicación; en la CLI de Azure actual, reiniciar apunta a una revisión con nombre. Si falla una sola versión, desactiva o reinicia esa revisión. Acompaña el reinicio con registros y estado porque puede retrasar la próxima falla. El contenedor debe terminar correctamente y guardar estado duradero fuera del disco local.

az containerapp stop --name ai-document-api --resource-group rg-ai200-aca
az containerapp start --name ai-document-api --resource-group rg-ai200-aca
az containerapp revision restart \
  --name ai-document-api --resource-group rg-ai200-aca \
  --revision <revision-name>

az containerapp revision list \
  --name ai-document-api --resource-group rg-ai200-aca \
  --query "[].{name:name,active:properties.active,health:properties.healthState}" \
  -o table

Resumen del tema

Elige la acción más estrecha: cero para inactividad, detener para pausa garantizada, reiniciar para estados transitorios y revisión para una versión defectuosa.

radio_button_uncheckedshort_text6. Lista repetible de comprobación

Empieza por nombrar la revisión con error y comparar su estado de plataforma con los registros. Comprueba capas comunes en orden para no ocultar la causa con reinicios o más recursos.

1. Extracción de imagen: servidor, digest, identidad o credencial y permiso AcrPull.
2. Puerto y entrada: interfaz y puerto reales del proceso.
3. Configuración: variables y referencias de secretos frente a la revisión sana.
4. Sondeos: tipo, protocolo, ruta, puerto, tiempos y respuesta.
5. Recursos: falta de memoria, limitación de CPU, bucle de fallos y calentamiento.
6. Dependencias y código: después de validar la plataforma, revisa excepciones y servicios externos.

Resumen del tema

Identifica la revisión y valida imagen, red, configuración, sondeos, recursos y código en un orden constante.

radio_button_uncheckedshort_text7. Transmitir y conservar los registros correctos

Los registros de consola proceden de stdout y stderr; los del sistema describen plataforma y revisiones; los HTTP opcionales muestran entrada, latencia y respuestas 5xx. La transmisión sirve para reproducir un fallo en tiempo real y Log Analytics conserva historial. Configura el destino del entorno antes de necesitarlo.

az containerapp logs show \
  --name ai-document-api --resource-group rg-ai200-aca \
  --follow --tail 50

az containerapp logs show \
  --name ai-document-api --resource-group rg-ai200-aca \
  --type system --tail 50

Incluye identificador de correlación, revisión o build, etiqueta o digest, versión del modelo, latencia total y tiempos de dependencias. Guarda identificadores y metadatos en lugar de PDF, prompts, credenciales o datos personales sin procesar.

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "ai-document-api"
| where RevisionName_s contains "<revision-name>"
| project TimeGenerated, RevisionName_s, Log_s
| order by TimeGenerated desc

Resumen del tema

Combina consola y sistema en vivo con Azure Monitor histórico y usa registros estructurados sin contenido sensible.

radio_button_uncheckedshort_text8. Diagnosticar un incidente específico de revisión

1. Confirma los nombres de la revisión activa, la más reciente y la defectuosa.
2. Transmite registros mientras inicia o se reproduce la solicitud.
3. Compara imagen, variables, secretos, entrada, sondeos y recursos con una revisión sana.
4. Corrige un único punto; un cambio de plantilla genera otra revisión.
5. Espera aprovisionamiento y sondeos, valida latencia y errores y luego mueve tráfico.
6. Conserva el rollback y limpia cuando venza la política.

Cambiar una variable cada vez conserva causalidad. No borres historial ni aumentes recursos primero si la evidencia señala una variable, un puerto o una ruta.

Resumen del tema

Reduce el alcance, reproduce con registros, compara, corrige un punto y valida la siguiente revisión antes del tráfico.

radio_button_uncheckedshort_text9. Sondeos de inicio, preparación y ejecución

Las API cargan modelos, calientan cachés y conectan dependencias. Preparación solo debe tener éxito al poder atender; ejecución debe detectar bloqueo o proceso irrecuperable, no lentitud externa temporal. Azure Container Apps admite HTTP(S) y TCP, no admite exec y permite un sondeo de cada tipo por contenedor.

properties:
  template:
    containers:
      - name: api
        image: myregistry.azurecr.io/ai-document-api@sha256:<digest>
        probes:
          - type: Startup
            httpGet: { path: /health/startup, port: 8080 }
            periodSeconds: 10
            failureThreshold: 12
          - type: Readiness
            httpGet: { path: /health/ready, port: 8080 }
            initialDelaySeconds: 20
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          - type: Liveness
            httpGet: { path: /health/live, port: 8080 }
            initialDelaySeconds: 60
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

Resumen del tema

Usa inicio para calentamiento, preparación para proteger tráfico y ejecución para reciclar procesos bloqueados según el comportamiento real.

radio_button_uncheckedshort_text10. Solucionar sondeos sin crear bucles de reinicio

Las causas comunes son puerto o ruta incompatibles, endpoint inaccesible, protocolo incorrecto, timeout menor que el calentamiento o dependencia caída. Para HTTP, los códigos 200 a 399 indican éxito.

• Alinea puerto de sondeo, proceso y entrada.
• Usa endpoints ligeros y separados cuando los criterios difieran.
• Ajusta demora, período, timeout y umbral según tiempo medido.
• No hagas depender ejecución de todos los sistemas externos.
• Relaciona hora y tipo con revisión, registros y Diagnosticar y resolver problemas.

Un sondeo de ejecución agresivo reinicia antes de que cargue el modelo; uno de preparación permisivo envía tráfico a una réplica incapaz de responder.

Resumen del tema

Valida alcance y tiempos, evita dependencias transitorias en ejecución y explica cada error con registros y diagnóstico.

radio_button_uncheckedshort_text11. Dimensionar CPU y memoria por réplica

CPU y memoria determinan capacidad y coste unitario. CPU insuficiente crea limitación y latencia; memoria insuficiente provoca terminación, reinicios e inicios en frío. El coste combina tamaño, número y duración de las réplicas.

Mide latencia con concurrencia y rendimiento del worker; observa CPU, memoria, reinicios y preparación. Cambia un límite y repite la carga. Cada modelo puede alterar inicio, memoria y latencia.

az containerapp update \
  --name ai-document-api --resource-group rg-ai200-aca \
  --cpu 1.0 --memory 2Gi

az containerapp update \
  --name ai-document-api --resource-group rg-ai200-aca \
  --min-replicas 1 --max-replicas 10

Resumen del tema

Elige recursos por el cuello medido, repite pruebas representativas y revalida después de cambios de modelo o dependencias.

radio_button_uncheckedshort_text12. Escalar API síncronas y workers de forma distinta

Azure Container Apps usa límites declarativos y reglas KEDA. HTTP reacciona a solicitudes concurrentes; TCP a conexiones; reglas personalizadas pueden usar CPU, memoria, colas, Azure Service Bus, Azure Event Hubs, Apache Kafka, Redis y otras fuentes. Cambiar escala crea revisión.

Una API sensible a latencia puede mantener una réplica mínima y alinear concurrencia con CPU. Un worker de eventos puede llegar a cero si el trabajo es duradero. Sin entrada, define regla o mínimo para poder despertar. Las reglas de CPU o memoria no pueden llegar a cero porque necesitan una réplica para medir.

Sondeos y escala deben coincidir. El mínimo mejora respuesta y eleva coste base; el máximo protege presupuesto y dependencias, pero puede limitar rendimiento.

Resumen del tema

Conserva capacidad caliente para API, permite cero a workers duraderos y ajusta KEDA, límites, recursos y sondeos juntos.

radio_button_uncheckedshort_text13. Laboratorio guiado: diagnosticar una API documental

Usa una suscripción de Azure de pago con permisos, CLI de Azure actual y Visual Studio Code; Python 3.12 es opcional. ACR Tasks puede no funcionar con créditos gratuitos. Trabaja en un grupo desechable y elimínalo al terminar.

1. Implementa una API simulada y registra revisión, FQDN, digest y estado sano.
2. Quita una variable, observa la revisión y corrige el error con registros.
3. Introduce un puerto de entrada incorrecto y compara con el proceso.
4. Configura preparación y distingue calentamiento lento de endpoint erróneo.
5. Consulta Log Analytics por aplicación y revisión y crea una cronología.
6. Aplica la corrección, demuestra preparación, conserva rollback y limpia lo obsoleto.

Reúne estado de revisiones, registros correlacionados, configuración corregida y una comparación antes/después. No uses documentos ni credenciales reales.

Resumen del tema

El laboratorio practica configuración ausente y entrada incorrecta y demuestra la solución con revisión, registros en vivo e historial.

radio_button_uncheckedshort_text14. Repaso de conocimientos

Resumen del tema

El examen favorece identidad inmutable, controles estrechos, diagnóstico por evidencia, endpoints correctos y recursos basados en métricas.

radio_button_uncheckedshort_text15. Lista operativa y referencias de Microsoft

• Antes: fija digest, registra build y modelo, confirma secretos, puerto y sondeos.
• Durante: observa aprovisionamiento, sondeos, registros, réplicas, latencia y errores.
• Incidente: aísla revisión, conserva evidencia, compara y cambia un punto.
• Después: prueba rollback, documenta causa, aplica retención y revisa recursos y escala.

1. Azure Container Apps revisions
2. Application lifecycle management
3. Application logging
4. Health probes
5. Scaling applications
6. Azure CLI - az containerapp

Resumen del tema

El runbook debe explicitar identidad, puertas de salud, evidencia, rollback, limpieza y revisión de capacidad.