Operar la IDP: Docker, kind, OpenTofu, Crossplane, observabilidad

Objetivos del capítulo
  • Componer la IDP en local con Docker Compose y kind.

  • Aprovisionar infra reproducible con OpenTofu y Crossplane.

  • Monitorizar y observar la IDP.

  • Preparar disaster recovery y plan de upgrades.

  • Aplicar multi-tenant y aislamiento.

Operar la cocina: del dev al cluster

Una IDP no es un experimento: hay que servirla todos los días, con la misma fiabilidad que el plato del mediodía. Este capítulo es el que te enseña a llevar el restaurante: neveras (Docker), hornos (Kubernetes), pedidos al proveedor (IaC), bandejas de control de calidad (observabilidad) y el plan anti-incendios (backup + DR).

Stack local con Docker Compose

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/compose/docker-compose.yml[tag=compose-stack]
Healthcheck obligatorio

El :code:`healthcheck` de Postgres evita que Backstage arranque antes de que la DB esté lista. Sin él verás crashes intermitentes al levantar el compose.

Cluster local con kind

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/k8s/kind-config.yaml[tag=kind-config]
kind no es para producción

kind usa contenedores Docker como nodos. Sirve para CI y desarrollo local. Para producción usa EKS, AKS, GKE o tu distribución on-prem preferida. Los YAMLs son los mismos; cambian los manifiestos del cluster (CNI, ingress, RBAC).

IaC con OpenTofu

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/infra/tofu/backend.tf[tag=tofu-s3-backend]
Nunca :code:`tofu apply` directo en CI

El flujo correcto es: PR con plan, revisión humana, merge, apply desde CI con OIDC. Si aplicas sin revisión, todo cambio queda fuera del audit trail. Ver :apéndice C sobre buenas prácticas de IaC.

Crossplane: CRDs como infra

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/crossplane/provider.yaml[tag=crossplane-provider]
Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/crossplane/xrd.yaml[tag=crossplane-xrd]
Arquitectura cloud: OpenTofu + Crossplane
Failed to generate image: Could not find the 'mmdc' executable in PATH; add it to the PATH or specify its location using the 'mmdc' document attribute
flowchart TB
  Tofu[OpenTofu] --> Cluster[EKS/AKS/GKE]
  Crossplane[Crossplane] --> RDS[(AWS RDS)]
  Crossplane --> S3[(S3 buckets)]
  Crossplane --> DNS[(Route53)]
  BS[Backstage] --> Crossplane
  BS --> Tofu

Desplegar Backstage en Kubernetes

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/k8s/backstage/deployment.yaml[tag=backstage-deployment]
Helm vs YAMLs pelados

Los YAMLs sirven para entender; Helm sirve para operar. El chart oficial backstage en https://backstage.github.io/charts parametriza imágenes, secrets, ingress, y RBAC. En producción usa Helm.

Observabilidad: métricas, logs y traces

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/k8s/monitoring/servicemonitor.yaml[tag=prometheus-servicemonitor]
Stack de observabilidad
Failed to generate image: Could not find the 'mmdc' executable in PATH; add it to the PATH or specify its location using the 'mmdc' document attribute
flowchart LR
  BS[Backstage] --> Prom[Prometheus]
  BS --> OTel[OpenTelemetry Collector]
  OTel --> Tempo[Tempo]
  OTel --> Loki[Loki]
  Prom --> Graf[Grafana]
  Loki --> Graf
  Tempo --> Graf
SLOs recomendados
  • Disponibilidad: 99.5% mensual (Backstage no es crítico, pero no debe estar caído).

  • Latencia p95: < 500 ms en /catalog, < 1.5 s en scaffolder (incluye clonado de repo).

  • Tasa de error: < 1% en endpoints del catalog.

Logs y alertas

Logging stack

Loki + Promtail para logs. Fluent Bit si ya tienes ELK. El plugin @backstage/plugin-search-backend puede indexar logs por entityRef.

Alertas que importan
  • Caída de Backstage (up == 0).

  • Latencia p95 > 2 s sostenida.

  • Errores 5xx > 1% en 5 min.

  • Postgres: connections > 80% del pool, replication lag > 30 s.

Las alertas deben ser actionable: cada alerta tiene un runbook.

Backup y disaster recovery

Unresolved directive in chapters/cap-15-operaciones-iac-observabilidad.adoc - include::../../chapters/chapter-15-ops/scripts/backup.sh[tag=backup-script]
3-2-1

3 copias, 2 medios distintos, 1 off-site. En la nube: S3 + Glacier + cross-region. En on-prem: NAS + cinta +异地复制. Testea el restore mensualmente; un backup no testeado es un backup inexistente.

Upgrades: el baile de versiones

Codemods y cadence
  • Backstage publica codemods (scripts JS) que migran APIs deprecadas.

  • Cadencia: actualizar dentro de 2 versiones de cada release. Si vas 6 versiones atrás, el upgrade es doloroso.

  • Estrategia: branch dedicado + runbook + ventana de mantenimiento + rollback automático.

Multi-tenant: aislamiento por namespace

Multi-tenant con namespaces, Systems y Domains
Failed to generate image: Could not find the 'mmdc' executable in PATH; add it to the PATH or specify its location using the 'mmdc' document attribute
flowchart TB
  NS1[backstage-prod] --> Sys1[sazon-restaurant]
  NS2[backstage-staging] --> Sys2[sazon-staging]
  Sys1 --> Dom1[restaurant]
  Sys2 --> Dom1
Sistemas vs Dominios
  • System = unidad de producto (sazon-restaurant).

  • Domain = área de negocio (restaurant, payments).

  • Namespace = aislamiento físico (prod, staging, dev).

Multi-tenant = combina las tres para evitar que dos equipos pisen entidades comunes.

Plugins extra útiles

El ecosistema crece rápido
  • TechDocs: docs-as-code desde el repo.

  • ArgoCD: vista de deployments GitOps.

  • Kubernetes: vista de workloads + logs.

  • Cost Insights: costes de cloud por equipo.

Evalúa plugins con criterios: maintenance status, versiones soportadas, contributor count. Un plugin abandonado es una trampa.

Example 15. Receta del capítulo
  1. Levanta el stack local con docker compose up.

  2. Crea un cluster kind create cluster --config kind-config.yaml.

  3. Aplica el Deployment y el Service de Backstage.

  4. Configura OpenTofu con backend S3 + DynamoDB lock.

  5. Instala Crossplane con un provider de tu cloud.

  6. Configura ServiceMonitor + Prometheus + Grafana.

  7. Programa el backup y testea el restore.

Resumen

  • Compose y kind valen para dev; Kubernetes gestionado vale para producción.

  • OpenTofu + S3 backend + DynamoDB lock = state compartido con concurrencia segura.

  • Crossplane da CRDs para AWS RDS, S3, etc., con self-service.

  • Observabilidad: Prometheus para métricas, Loki para logs, OpenTelemetry para traces.

  • Backup con 3-2-1 + restore testeado mensualmente.

  • Upgrades: codemods + cadence (dentro de 2 versiones).

Glosario del capítulo

Docker Compose

Herramienta para correr multi-contenedor en un solo host.

kind

Kubernetes-in-Docker. Cluster K8s en contenedores Docker locales.

OpenTofu

Fork open source de Terraform, mantenido por la Linux Foundation.

Crossplane

Plataforma K8s que expone recursos cloud como CRDs.

ServiceMonitor

CRD de Prometheus Operator para descubrir métricas.

SLO

Service Level Objective. Objetivo medible (latencia, disponibilidad).

Codemod

Script automatizado que reescribe código entre versiones.

Próximo capítulo

Backstage vs Port vs Compass vs Cortex: guía de compra —comparativa honesta y argumentario para una CTO.

Parte VI: Parte 6 — Comparativa y cierre

Backstage contra Port, Compass y Cortex. Métricas de adopción, ROI y guía de decisión para CTOs.