YAML no Kubernetes e CI

A maior parte da dor com YAML em produção vem de manifests Kubernetes e arquivos de workflow CI — não de exemplos didáticos.

Manifests Kubernetes

Um Deployment geralmente combina:

• Metadata de API no topo (apiVersion, kind, metadata)
• Um pod template aninhado em spec.template
• Arrays de containers com ports, env vars e probes

Erros de indentação costumam aparecer três ou quatro níveis abaixo, o que faz dicas de linha/coluna do parser importarem mais do que mensagens genéricas de "YAML inválido".

Workflows GitHub Actions

Arquivos de workflow combinam mappings e sequences:

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

Problemas comuns:

• Indentar steps errado, fazendo um step virar irmão de jobs
• Colar shell multilinha sem block scalars | ou >
• Misturar flow collections estilo JSON { } dentro de arquivos block-style

Docker Compose

Compose enfatiza maps de serviços e grafos de dependência. Strings de port como "8080:80" devem ficar entre aspas quando o YAML interpretaria : de forma especial em contextos ambíguos.

Hábitos práticos

1. Valide antes do apply — capture erros de sintaxe localmente
2. Formate antes do PR — indentação estável reduz ruído na review
3. Ordene chaves opcionalmente — diffs mais limpos quando a equipe concorda com a ordenação
4. Mantenha secrets fora de links compartilhados — use placeholders em exemplos enviados no chat

YAML válido é necessário, mas não suficiente: nomes de recursos, namespaces e RBAC ainda precisam de review específica para o cluster.