YAML en Kubernetes y CI

La mayor parte del dolor de YAML en producción viene de manifiestos de Kubernetes y archivos de workflow de CI — no de ejemplos de juguete.

Manifiestos de Kubernetes

Un Deployment suele combinar:

• Metadatos de API de nivel superior (apiVersion, kind, metadata)
• Una plantilla de pod anidada bajo spec.template
• Arrays de contenedores con puertos, variables de entorno y probes

Los errores de indentación suelen aparecer tres o cuatro niveles de profundidad, por eso las pistas de línea/columna del parser importan más que mensajes genéricos de «YAML inválido».

Workflows de GitHub Actions

Los archivos de workflow combinan mappings y sequences:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Problemas habituales:

• Indentar mal steps para que un step sea hermano de jobs
• Pegar shell multilínea sin block scalars | o >
• Mezclar colecciones flow al estilo JSON { } dentro de archivos block-style

Docker Compose

Compose enfatiza mapas de servicios y grafos de dependencias. Cadenas de puertos como "8080:80" deben ir entre comillas cuando YAML interpretaría : de forma especial en contextos ambiguos.

Hábitos prácticos

1. Validar antes de aplicar — detecta errores de sintaxis localmente
2. Formatear antes del PR — indentación estable reduce ruido en la revisión
3. Ordenar claves opcionalmente — diffs más limpios cuando el equipo acuerda un orden
4. Mantener secretos fuera de enlaces compartidos — usa placeholders en ejemplos enviados al chat

YAML válido es necesario pero no suficiente: nombres de recursos, namespaces y RBAC siguen necesitando revisión específica del clúster.