Microsoft AZ-204: Soluciones de contenedores de Azure — Guía de estudio
Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.
Descripción general
Azure proporciona un espectro de opciones de contenedores que abarcan desde la ejecución de un solo contenedor y clústeres orquestados, hasta una cadena de suministro de imágenes segura y de nivel empresarial. Azure Container Instances (ACI) es la ruta más rápida para ejecutar contenedores de Linux o Windows sin administrar servidores. Azure Kubernetes Service (AKS) es un plano de control de Kubernetes administrado que escala microservicios con programación avanzada, redes, seguridad e integraciones de DevOps. Azure Container Registry (ACR) es el registro privado con replicación geográfica que ancla sus flujos de compilación, etiquetado, subida/descarga (push/pull) y distribución de Helm. Dominar la construcción de imágenes de Docker y la gestión de su ciclo de vida es fundamental para realizar despliegues fiables en cualquiera de estas plataformas. Esta sección establece una visión práctica y centrada en el desarrollador de cómo encajan las piezas, incluyendo despliegues basados en YAML, empaquetado con Helm, exposición de servicios y patrones de identidad/seguridad.
Docker y Azure Container Registry (ACR)
La entrega fiable de contenedores comienza con sólidos fundamentos de Docker. Cada imagen se compone de capas formadas por instrucciones del Dockerfile; la reutilización de capas y los aciertos de caché son críticos para compilaciones rápidas.
- Instrucciones comunes de Dockerfile y recomendaciones:
- FROM define la imagen base. Prefiera imágenes mínimas (p. ej., distroless, alpine cuando sea apropiado) para reducir la superficie de ataque y el tamaño.
- RUN ejecuta comandos para instalar dependencias. Combine comandos relacionados para reducir el número de capas, pero evite líneas RUN monolíticas que oculten los fallos.
- COPY y ADD colocan artefactos de la aplicación. Use .dockerignore para evitar inflar los contextos; fije COPY a rutas explícitas.
- WORKDIR establece el directorio de trabajo; úselo en lugar de encadenar cd en RUN.
- EXPOSE documenta los puertos de escucha previstos (no es un firewall).
- ENV y ARG configuran variables de entorno y de tiempo de compilación; promueva el determinismo en la compilación fijando los valores por defecto de ARG o pasando valores explícitos.
- ENTRYPOINT define el ejecutable principal; use CMD para los argumentos por defecto. Prefiera la forma exec (array JSON) para preservar el manejo de señales para un apagado ordenado.
- HEALTHCHECK habilita la evaluación de vitalidad (liveness) para que los orquestadores puedan reaccionar.
- Las compilaciones multi-etapa separan las fases de compilación y de ejecución, copiando solo los artefactos necesarios en una imagen de ejecución limpia, reduciendo drásticamente el tamaño y la huella de CVE. Por ejemplo, compile con el SDK, publique los binarios y luego cópielos en una base de tiempo de ejecución.
- Las capas de la imagen son inmutables y se direccionan por su contenido. Reordenar las instrucciones altera el almacenamiento en caché. Coloque las instrucciones que cambian con frecuencia (p. ej., el origen de COPY) al final del Dockerfile para maximizar los aciertos de caché.
Con ACR, almacene y distribuya imágenes y charts de Helm de forma privada:
- Repositorios y etiquetado: Suba (push) imágenes como
<registry>.azurecr.io/<repo>:<tag>. Prefiera etiquetas semánticas o basadas en Git (p. ej., 1.4.0, SHA de la compilación) y use digests inmutables en despliegues de producción para la repetibilidad. - Subida y descarga (Pushing and pulling):
- Autentíquese en ACR usando
undefined
o
undefined
con un token de Azure AD. Evite habilitar el usuario administrador de ACR en producción.
- Etiquetar y subir (push):
undefined
;
undefined
. Descargue (pull) con
undefined
o mediante referencias de imagen de Kubernetes.
- Importe imágenes de origen (upstream) a ACR para controlar la cadena de suministro:
undefined
.
- ACR Tasks: Compile, pruebe y aplique parches a las imágenes de forma nativa en Azure. Use
undefined
para compilaciones bajo demanda; automatice las actualizaciones con
undefined
para que se activen a partir de commits de Git o actualizaciones de la imagen base, permitiendo la remediación de CVE sin cambiar el código de la aplicación.
- La replicación geográfica (SKU Premium) proporciona localidad de descarga (pull) multirregional y resiliencia. Configure réplicas en regiones cercanas a los clústeres de AKS para reducir la latencia de descarga y el egreso entre regiones.
- Control de acceso:
- Intégrelo con Azure AD y asigne roles integrados como AcrPull a la identidad del kubelet de AKS, y AcrPush a los pipelines de CI. Los permisos con alcance de repositorio están disponibles a través de tokens y mapas de alcance (scope maps) para un control detallado.
- Restrinja el acceso a la red con puntos de conexión privados, puntos de conexión de servicio y reglas de firewall. Prefiera los puntos de conexión privados para producción.
- Adjunte ACR a AKS con
undefined
para simplificar la asignación del rol AcrPull.
Azure Container Instances (ACI)
ACI ejecuta contenedores bajo demanda sin la gestión de un clúster. La unidad principal es un grupo de contenedores, un conjunto de contenedores co-programados que comparten el mismo kernel del sistema operativo anfitrión, ciclo de vida, IP y volúmenes. Use los grupos de contenedores para implementar el patrón sidecar (p. ej., transportadores de logs, proxies) o para combinar un proceso principal con uno auxiliar.
- Los grupos de múltiples contenedores comparten un espacio de nombres de red, lo que permite la comunicación entre contenedores a través de localhost. También comparten volúmenes montados (Azure Files, emptyDir) y el ciclo de vida, lo que los hace adecuados para tareas únicas y cohesivas que requieren un acoplamiento estrecho.
- Las políticas de reinicio controlan la semántica de ejecución:
- Always: reinicia los contenedores cuando finalizan. Es la mejor opción para servicios de larga duración.
- OnFailure: reinicia solo si el código de salida es distinto de cero. Adecuado para tareas por lotes que deben reintentarse en caso de fallo.
- Never: ejecuta los contenedores una vez y nunca los reinicia, ideal para trabajos idempotentes.
- Las integraciones de red incluyen IP pública con una etiqueta DNS, IP privadas en una subred delegada de una VNet de Azure y egreso seguro a través de NAT o firewall. ACI inyectado en una VNet permite el acceso privado a servicios (bases de datos, almacenamiento) sin exposición pública.
- Consideraciones operativas:
- Inyecte secretos usando variables de entorno seguras o montando Azure Files; para una postura más robusta, recupere los secretos en tiempo de ejecución a través de una identidad administrada desde Key Vault.
- Observe con
undefined
y
undefined
; ejecute comandos interactivos con
undefined
.
- La facturación es por segundo para vCPU y GiB de memoria. Los contenedores se inician rápidamente y se ajustan a cargas de trabajo intermitentes (bursty), tareas auxiliares de CI, pruebas de integración y trabajos activados por colas donde la sobrecarga de Kubernetes es innecesaria.
Azure Kubernetes Service (AKS)
AKS proporciona un plano de control gestionado con grupos de nodos, autoescalado y opciones profundas de redes e identidad.
Los grupos de nodos estructuran la capacidad y la ubicación de las cargas de trabajo. Los grupos de nodos de sistema ejecutan servicios centrales; los grupos de nodos de usuario ejecutan los pods de las aplicaciones. Utilice múltiples grupos para segregar las cargas de trabajo según las necesidades de CPU/Memoria/GPU, SO (Linux/Windows), tamaño de VM y zona de disponibilidad. Emplee taints/tolerations para proteger los grupos de sistema, etiquetas para la selección y el cluster autoscaler para añadir/eliminar nodos basándose en los pods pendientes. Considere el maxPods por nodo y la densidad de pods al dimensionar.
La programación de pods se rige por las solicitudes/límites de recursos, las clases de QoS (Guaranteed/Burstable/BestEffort) y las restricciones. Use nodeSelector/afinidad y anti-afinidad para dirigir los pods a los grupos apropiados y distribuir las réplicas entre zonas y dominios de error. Las restricciones de distribución de topología (Topology spread constraints) mejoran una distribución uniforme. Para servicios críticos, defina PodDisruptionBudgets y PriorityClasses para dar forma a las interrupciones voluntarias y al comportamiento de expropiación. Los DaemonSets colocan agentes por nodo (para logging, monitorización), y los CronJobs programan contenedores para tareas periódicas.
Los despliegues en AKS son declarativos. Los manifiestos YAML definen apiVersion, kind, metadata y spec para Deployments, StatefulSets, Jobs, Services e Ingress. Mantenga los manifiestos en un control de código fuente, parametrice con superposiciones (overlays) de Kustomize para las diferencias entre entornos y aplique con kubectl apply -f. El Server-side apply y el uso adecuado de etiquetas/anotaciones ayudan con la propiedad y la detección de desviaciones (drift). Para empaquetar aplicaciones reutilizables, Helm 3 agrupa plantillas y valores. Aloje los charts de Helm como artefactos OCI en ACR e instale con helm upgrade --install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml. Use archivos de valores (values) por entorno, rastree las versiones de los charts y realice reversiones con helm rollback para una recuperación rápida.
Comandos de kubectl que usará a diario:
- Acceder al contexto del clúster:
az aks get-credentials -g <rg> -n <cluster>fusiona el kubeconfig; usar una máquina unida a Azure AD conkubectles suficiente—no se requiere Docker para desplegar manifiestos. - Inspeccionar y operar:
kubectl get nodes,pods,deploy,svc -A;kubectl describe pod <name>;kubectl logs -f <pod>;kubectl exec -it <pod> -- sh;kubectl rollout status deploy/<name>;kubectl set image deploy/<name> container=<image>:<tag>;kubectl top pods;kubectl cordon/drainnodos para mantenimiento;kubectl auth can-ipara verificar RBAC. - Aplicar/parchear:
kubectl apply -f k8s/; `kubectl patch deploy
← Azure Cosmos DB · Todos los dominios · Autenticación →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →