Workflow · init → plan → apply
El ciclo de trabajo con OpenTofu se reduce a tres comandos. Cada uno tiene un propósito claro y un momento específico en el que se ejecuta. Entender este flujo es entender cómo funciona la infraestructura como código declarativa.
Los Tres Comandos
Tres comandos cubren el 90% del trabajo diario con OpenTofu. El orden es fijo: init una vez, plan cada vez que se modifica código, apply para materializar los cambios.
tofu init
Primera vez o al cambiar providersDescarga los providers declarados en el bloque required_providers. Crea el directorio .terraform/ con los binarios y un lock file (.terraform.lock.hcl) que fija las versiones exactas. Solo se ejecuta una vez al clonar el repo o al agregar un provider nuevo.
tofu init tofu plan
Cada vez que se modifican archivos .tfCompara el estado deseado (archivos .tf) con el estado real (terraform.tfstate). Muestra un diff legible de qué recursos se van a crear (+), modificar (~) o destruir (-). El plan es de solo lectura — no modifica nada. Es la oportunidad de revisar cambios antes de aplicarlos.
tofu plan tofu apply
Después de revisar el planAplica el plan generado por tofu plan. Pide confirmación interactiva (yes). Crea, modifica o destruye recursos para que el estado real del cluster coincida con el declarado en los archivos .tf. Actualiza terraform.tfstate con los IDs y metadata de los recursos creados.
tofu apply Paso 1: tofu init
El primer comando que se ejecuta en un proyecto OpenTofu. Descarga los providers, crea el directorio de trabajo y genera el lock file. Sin init, ningún otro comando funciona.
Paso 2: tofu plan
El comando más importante del workflow. Compara el estado deseado contra el real y muestra exactamente qué va a cambiar. Ejecutar plan antes de apply no es opcional — es la práctica que evita destruir recursos por error.
Paso 3: tofu apply
El comando que materializa los cambios. Pide confirmación explícita (escribir "yes") y luego crea, modifica o destruye los recursos necesarios para alinear el estado real con el deseado.
Comandos Adicionales
Más allá de init → plan → apply, hay tres comandos útiles para el día a día. No se usan en cada ciclo, pero son esenciales cuando se necesitan.
tofu destroy
Para limpiar el cluster completamenteEl inverso de apply. Destruye todos los recursos gestionados por este stack de OpenTofu. Útil para limpiar el cluster sin dejar recursos huérfanos. Pide confirmación interactiva.
tofu destroy tofu state list
Para inspeccionar el estado actualLista todos los recursos que OpenTofu está gestionando actualmente según el state file. Útil para verificar qué recursos existen sin tener que aplicar cambios.
tofu state list tofu output
Después de apply, para obtener valores generadosMuestra los valores de los outputs definidos en outputs.tf. Después de un apply, permite consultar nombres de recursos, IPs, OCIDs sin necesidad de abrir la consola de Kubernetes o OCI.
tofu output Archivos Generados por OpenTofu
OpenTofu crea y mantiene varios archivos en el directorio de trabajo. Cada uno tiene un propósito específico y reglas claras sobre si se commitea o se ignora.
.terraform/ Contiene los binarios de los providers descargados. Se ignora en .gitignore — no se commitea.
.terraform.lock.hcl Fija las versiones exactas de los providers y sus checksums. Se commitea para garantizar builds reproducibles entre máquinas.
terraform.tfstate Mapeo entre recursos declarados en .tf y recursos reales en el provider. Contiene IDs, metadata y dependencias. Sin este archivo, OpenTofu no sabe qué recursos gestiona.
terraform.tfstate.backup Copia del state anterior. OpenTofu lo crea automáticamente antes de cada apply. Si algo sale mal, se puede restaurar.
Mismo Workflow, Distinto Provider
El workflow init → plan → apply es idéntico para el provider de OCI. La única diferencia es el directorio de trabajo y que las variables sensibles (tenancy_ocid, fingerprint) se pasan via terraform.tfvars o variables de entorno.
cd tofu tofu init tofu plan tofu apply cd tofu/oracle tofu init tofu plan tofu apply Los dos stacks son independientes. Cada uno tiene su propio state file, sus propios providers y sus propias variables. Se pueden aplicar en cualquier orden — no hay dependencia entre ellos. El stack local se usa en el lab, el stack OCI se usa en la Fase 9 para la migración a Oracle Cloud.
Siguiente: IaC vs Config Management
Con el workflow dominado, la última página de la Fase 2 profundiza en la diferencia conceptual entre Infrastructure as Code (OpenTofu) y Configuration Management (Ansible) — y por qué el proyecto usa ambos.