Infraestructura de contenedores con GitHub Copilot

Completado

Tip

Consulte la pestaña Texto e imágenes para obtener más detalles.

La contenedorización ya no es una preocupación independiente de la infraestructura. Cuando la aplicación se ejecuta en Kubernetes, el Dockerfile, los manifiestos de Kubernetes y la infraestructura de Azure subyacente forman parte del mismo patrimonio de IaC. Comparten el mismo control de versiones, la misma canalización de CI/CD y el mismo proceso de revisión.

GitHub Copilot es adecuado para la infraestructura de contenedores porque la sintaxis de Dockerfile y YAML de Kubernetes son altamente estructurados y enriquecidos con patrones. Estas características son precisamente las cualidades que hacen que la generación de Bicep sea eficaz. La mayoría de los patrones de contenerización aparecen con frecuencia en proyectos de código abierto, lo que proporciona a Copilot una sólida cobertura de las mejores prácticas.

Generación de dockerfiles con GitHub Copilot

La anatomía de un buen prompt de Dockerfile

Un mensaje de Dockerfile efectivo especifica el tipo de aplicación, la imagen base, los requisitos de tiempo de ejecución y los requisitos de seguridad. Si falta cualquiera de estos componentes básicos del contenedor, Copilots recurre por defecto a patrones más simples, pero menos seguros.

Una solicitud mínima pero problemática:

Create a Dockerfile for a Node.js app.

Copilot puede producir un Dockerfile de una sola fase que se ejecuta como raíz, incluye dependencias de desarrollo y usa una etiqueta de imagen base desanclada. Cada uno de estos es un problema de seguridad o eficiencia.

Un mensaje mejor:

Generate a production-grade multi-stage Dockerfile for a Node.js Express application.
Requirements:
- Build stage: node:20-alpine, install all dependencies, no build step needed (pure JS)
- Runtime stage: node:20-alpine
- Copy only node_modules and application files to the runtime stage
- Do not include devDependencies in the runtime image
- Create a non-root user with UID 1001 and run the process as that user
- Set NODE_ENV=production
- Expose port 3000
- Add a HEALTHCHECK that polls GET /health every 30 seconds
- Pin the base image to a specific digest for reproducibility

Compilaciones en varias etapas

Un Dockerfile de una sola fase copia todo en la imagen final, incluidas las herramientas de compilación, las dependencias de desarrollo, los archivos de prueba y los mapas de origen. Este enfoque puede inflar el tamaño de la imagen y aumenta la superficie expuesta a ataques. Las compilaciones de varias fases separan el entorno de compilación del entorno de tiempo de ejecución. Solo los artefactos necesarios para ejecutar la aplicación se copian en la imagen final.

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .

# Stage 2: Runtime
FROM node:20-alpine AS runtime
WORKDIR /app

# Create non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup -u 1001

# Copy only what is needed from the build stage
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/package.json ./
COPY --from=builder --chown=appuser:appgroup /app/server.js ./
COPY --from=builder --chown=appuser:appgroup /app/routes ./routes

ENV NODE_ENV=production
USER appuser
EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

CMD ["node", "server.js"]

Uso de Copilot como revisor de seguridad

Después de generar un Dockerfile, pida a Copilot revisarlo:

Review this Dockerfile for security vulnerabilities and best practices.
Check for:
1. Processes running as root
2. Sensitive files or environment variables that might be copied into the image
3. Unpinned or mutable image tags (e.g., "latest")
4. Unnecessary packages or capabilities included in the runtime image
5. Missing HEALTHCHECK instruction
6. Layer caching inefficiencies that could expose secrets in build history

Copilot marca números de línea específicos y explica cada preocupación. Este mensaje de revisión funciona en cualquier Dockerfile, no solo en los generados con Copilot.

Generación de manifiestos de Kubernetes con GitHub Copilot

Qué incluir en un prompt de Kubernetes

Los manifiestos de Kubernetes interactúan con recursos específicos del clúster: controladores de entrada, clases de almacenamiento, espacios de nombres y sistemas de identidad. Un mensaje de Kubernetes correcto especifica lo siguiente:

• Los tipos de recursos necesarios (implementación, servicio, entrada, ConfigMap, etc.)
• El puerto y el protocolo de la aplicación
• Solicitudes y límites de recursos
• Puntos de conexión de sondeo de estado
• Variables de entorno y su origen (ConfigMap, Secreto o valor directo)
• Namespace
• Nombre de la clase de entrada si procede

Generación de una pila de implementación completa

Generate Kubernetes YAML manifests for a Node.js API application on AKS.
Include the following resources separated by ---:

Deployment:
- 3 replicas
- Image: iaclab-api:v1 (from a private ACR registry acr-iaclab.azurecr.io)
- Resource requests: 100m CPU, 128Mi memory
- Resource limits: 500m CPU, 512Mi memory
- Liveness probe: GET /health on port 3000, initialDelaySeconds 10, periodSeconds 15
- Readiness probe: GET /ready on port 3000, initialDelaySeconds 5, periodSeconds 10
- Environment variable APP_ENV sourced from a ConfigMap named "iaclab-config"
- Pod anti-affinity: prefer to spread replicas across different nodes
  (preferredDuringSchedulingIgnoredDuringExecution)

Service:
- ClusterIP type
- Port 80 mapping to container port 3000

Ingress:
- Ingress class: nginx
- Host: iaclab.training.azure.com
- Path: / (prefix)
- TLS: reference a secret named "iaclab-tls"

ConfigMap:
- Name: iaclab-config
- Key APP_ENV with value "staging"

Apply namespace: iaclab to all resources.

Descripción de los sondeos de estado

Kubernetes usa dos tipos de sondeos para administrar el ciclo de vida del contenedor.

La sonda de actividad responde a la pregunta: ¿está vivo este contenedor? Si la sonda de ejecución falla varias veces, Kubernetes finaliza el contenedor e inicia uno nuevo. Úselo para detectar cuándo la aplicación entró en un estado irrecuperable, como un interbloqueo o un bucle de bloqueo.

El sondeo de preparación responde a la pregunta: ¿este contenedor está listo para recibir tráfico? Si falla el sondeo de preparación, Kubernetes elimina el pod de la lista de puntos de conexión de servicio. El tráfico deja de dirigirse a él y no se reanuda hasta que la sonda se recupera. Úselo para indicar cuándo finalizó el inicio de la aplicación o se sobrecarga temporalmente.

Para añadir una sonda de inicio:

Add a startupProbe to the Deployment container spec. The startup probe should
call GET /health on port 3000, with a failureThreshold of 30 and
periodSeconds of 10. This gives the container up to 5 minutes to start before
liveness probes begin checking.

Protección mediante contextos de seguridad

De forma predeterminada, los contenedores de Kubernetes se ejecutan con más privilegios de los necesarios. Un securityContext en el nivel de pod y de contenedor restringe lo que puede hacer el contenedor.

Add security contexts to the Deployment in this manifest:

Pod-level securityContext:
- runAsNonRoot: true
- seccompProfile type: RuntimeDefault

Container-level securityContext:
- runAsUser: 1001
- runAsGroup: 1001
- readOnlyRootFilesystem: true
- allowPrivilegeEscalation: false
- capabilities: drop ALL

Also add an emptyDir volume mounted at /tmp so the application can write
temporary files despite the read-only root filesystem.

Después de Copilot genera el manifiesto actualizado, pídale que explique cada configuración:

Explain each field in the securityContext in plain language.
For each setting, describe what attack or misuse it prevents.

Este patrón funciona bien para el aprendizaje en equipo. Use Copilot para generar y, a continuación, use Copilot para explicar.

Patrones específicos de AKS

AKS presenta conceptos específicos de Azure que los manifiestos estándar de Kubernetes no abordan. Copilot conoce bien estos patrones.

Identidad de carga de trabajo:

Add Azure Workload Identity annotations to the Deployment and ServiceAccount.
The workload should use a managed identity with client ID
"00000000-0000-0000-0000-000000000000".
Add the required azure.workload.identity/client-id annotation to the
ServiceAccount and the azure.workload.identity/use: "true" label to the pod spec.

Volumen persistente de disco de Azure:

Add a PersistentVolumeClaim for 10Gi using the managed-csi storage class
(Azure Disk). Mount it at /data in the container with ReadWriteOnce access mode.

Presupuesto de interrupciones de pods:

Add a PodDisruptionBudget for the Deployment that ensures at least 2 replicas
are always available during voluntary disruptions (node drains, upgrades).

Revisión de manifiestos existentes

Pegue cualquier manifiesto de Kubernetes en Copilot Chat y solicite una revisión:

Review this Kubernetes manifest for:
1. Security issues (missing security context, running as root, privileged containers)
2. Missing resource requests or limits
3. Missing health probes
4. Configurations that would cause problems in a production AKS cluster
5. Any deprecated API versions (e.g., apps/v1beta is deprecated)

For each issue, identify the line, explain the risk, and provide the corrected YAML.

Esta solicitud de revisión es útil para los equipos que acumulan manifiestos a lo largo del tiempo y quieren ponerlos al día a los estándares actuales sin auditar manualmente cada archivo.

Scaffolding de gráfico de Helm

En el caso del empaquetado reutilizable de aplicaciones, Copilot puede aplicar scaffolding a la estructura de gráficos de Helm. Utilice una instrucción que especifique el nombre del gráfico, los recursos que se deben incluir, los valores que se deben parametrizar y cualquier requisito específico de AKS, como la clase de entrada o la identidad de carga de trabajo. Copilot genera Chart.yaml, values.yaml y archivos de plantilla en la estructura de directorios esperada. Revise detenidamente el values.yaml generado para asegurarse de que los valores predeterminados confidenciales no se confirman en el control de código fuente.