Terraform en OCI: el proveedor, Resource Manager y si montar tu propio pipeline

El proveedor oci de Terraform es completo y está bien mantenido — casi todas las funciones de OCI llegan rápido y los nombres de recurso mapean limpiamente sobre la API. La decisión interesante no es si usar Terraform sino dónde ejecutarlo, porque OCI es la única nube que incluye un servicio gestionado de Terraform realmente usable.

Resource Manager, y cuándo es la respuesta correcta

OCI Resource Manager ejecuta Terraform por ti: guarda el estado, ejecuta planes y applies, mantiene las variables y se integra con el IAM de OCI, de modo que una pila es un recurso con políticas como cualquier otro.

Tómalo cuando:

• No tengas ya una plataforma de CI/CD con la que estés contento. Resource Manager elimina el bucket de backend, el bloqueo, el runner y el problema de credenciales de golpe.
• Tu infraestructura sea solo OCI. No hay ventaja en un servicio gestionado para una nube si la mitad de tu infraestructura está en otra parte.
• Quieras acceso privado a recursos de una VCN durante el apply. Los endpoints privados de Resource Manager permiten que una pila alcance una API de Kubernetes privada o una base de datos sin un runner en la VCN.
• Quieras que el histórico de planes y applies sea un recurso auditable de OCI en lugar de un log de CI que rota.

Monta tu propio pipeline cuando:

• Gestiones otros proveedores junto a OCI — DNS, GitHub, otra nube. Repartir Terraform entre dos modelos de ejecución para un mismo entorno cuesta más de lo que ahorra.
• Quieras comprobaciones de política (checkov, conftest), pruebas propias o la salida del plan publicada en un pull request como parte de la revisión. El flujo de Resource Manager está orientado a pilas y no a pull requests, y ese desajuste es el motivo más común por el que los equipos se salen de él.

En cualquier caso, el reparto del estado sigue el mismo principio que en todas partes: un estado por compartimento y capa, separado por radio de explosión y ritmo de cambio, como en el artículo de Terraform en AWS. Si montas el tuyo, usa Object Storage como backend con versionado activado.

Autenticación, sin claves de API

El patrón al que apuntar: ninguna clave de firma de API en un fichero de configuración en ningún sitio.

• Resource Manager se autentica como el principal de la propia pila. Concédeselo con una política acotada al compartimento que gestiona.
• Un runner propio en una instancia de cómputo de OCI usa un principal de instancia mediante un grupo dinámico. Configura el proveedor con auth = "InstancePrincipal" y no hay ninguna clave.
• Un runner fuera de OCI — GitHub Actions, GitLab — usa un usuario de OCI con clave de API, que es el caso donde una clave sigue siendo inevitable. Acota ese usuario con firmeza, rótalo en un calendario que cumplas de verdad y guárdalo en el almacén de secretos de tu CI.
• Los humanos usan oci session authenticate para una sesión basada en token en lugar de una clave de larga vida en su portátil.

Es el mismo argumento que las políticas y grupos dinámicos de OCI: la clave de larga vida es la credencial que se filtra, así que el objetivo es tener las menos posibles.

Particularidades del proveedor que pillan a la gente

• OCID por todas partes. Casi toda referencia a un recurso es un OCID, y son largos, opacos y fáciles de pegar mal. Usa data sources y salidas en lugar de codificarlos, y no copies nunca un OCID entre entornos.
• El compartment_id en casi todos los recursos. Pásalo como variable por capa en lugar de repetirlo, y recuerda que mover un recurso entre compartimentos es una actualización en unos servicios y una recreación en otros.
• Las etiquetas definidas necesitan que el espacio de nombres exista antes. Crea el espacio de nombres y los valores por defecto en una capa temprana, o cada apply posterior fallará por un espacio de nombres inexistente.
• Los nombres de dominio de disponibilidad son específicos de la tenancy. AD-1 en la tuya no es el mismo AD físico que en la de otro. Búscalos siempre con el data source oci_identity_availability_domains en lugar de codificarlos.
• Los límites de servicio son por compartimento y región y subirlos es una petición de soporte con plazo. Un apply que falla por un límite durante un fin de semana de migración se evita comprobándolo antes.
• Algunos recursos tardan mucho. Los adjuntos de DRG, FastConnect y el aprovisionamiento de bases de datos son minutos, no segundos. Pon timeouts generosos en lugar de suponer que se ha colgado.

La forma del pipeline

Elijas el runner que elijas: formato y validación, un escaneo de seguridad del plan, plan revisado por un humano, apply desde el plan guardado y ningún humano con acceso de escritura a producción fuera de una vía de emergencia. Añade un plan de deriva programado — un plan semanal que informe de diferencias no vacías es cómo encuentras los recursos que alguien cambió en la consola, que todo entorno tiene.

Montamos esto junto a la estructura de compartimentos al inicio de un proyecto de OCI, porque las políticas y los espacios de nombres de etiquetas tienen que existir antes de que empiecen a aterrizar cargas.

Qué hacer esta semana

Busca en tus repositorios y configuración de CI claves de firma de API de OCI — un fichero .pem o una entrada key_file en una configuración. Cada una es una credencial sin caducidad. Las que usan runners dentro de OCI se pueden sustituir por un principal de instancia esta misma tarde.