Terraform desde cero en 2026: Infrastructure as Code para principiantes

Por qué necesitas Infrastructure as Code en 2026

Si todavía haces clic en una consola web para crear una VM, configurar una red o desplegar un cluster, tu trabajo es lento, repetible solo por ti y casi imposible de auditar. Tres problemas clásicos:

• Drift: la infraestructura real diverge del último cambio manual que hiciste un viernes a las 23h.
• Reproducibilidad rota: tu staging se parece al productivo solo por casualidad.
• Onboarding eterno: cualquier sysadmin nuevo necesita semanas para entender qué existe y por qué.

Terraform —y su fork open source OpenTofu— ataca los tres con un único archivo declarativo: describes el estado final que quieres y la herramienta se encarga de conciliar la realidad con tu intención, una y otra vez, en cualquier proveedor. Esta guía te lleva de cero a un primer terraform apply real sobre DigitalOcean, con comparación honesta de las dos variantes del lenguaje en 2026 y trampas que nadie te cuenta.

El ecosistema en 2026: Terraform, OpenTofu, y por qué hay dos

El 10 de agosto de 2023 HashiCorp relicenció Terraform y el resto de sus productos de Mozilla Public License 2.0 a Business Source License 1.1. La BSL te permite usar Terraform libremente en producción propia, pero prohíbe construir un producto competidor sobre él. Quince días después, una coalición de Spacelift, Harness, Gruntwork, env0 y Scalr publicó el manifiesto que dio origen a OpenTofu, un fork desde la última versión MPL (Terraform 1.5.7).

Cronología verificada:

Fecha	Hito
10 ago 2023	HashiCorp anuncia cambio a BSL 1.1
25 ago 2023	Publicación del manifiesto OpenTF
20 sep 2023	Linux Foundation acepta OpenTofu
10 ene 2024	OpenTofu 1.6.0 GA — primer estable con features propias
27 feb 2025	IBM cierra la adquisición de HashiCorp por USD 6.4B
Abr 2025	OpenTofu aceptado por la CNCF

En la práctica, las dos herramientas comparten el 90% del lenguaje (HCL), el formato del archivo de estado, y la práctica totalidad del ecosistema de providers. Las divergencias en 2026 son cuatro:

Característica	Terraform (IBM)	OpenTofu (CNCF)
Licencia	BSL 1.1 (source-available)	MPL 2.0 (open source)
Versión actual (mid-2026)	1.15.x estable, 1.16.0 en RC	1.12.x estable, 1.13.0 en beta
Cifrado de estado en reposo	Solo a nivel de backend (S3 SSE, etc.)	Nativo cliente-side con KMS, GCP KMS o PBKDF2
Backend dinámico	Limitado	Variables en el bloque terraform {}
Import loopable	No	Sí desde 1.8
Stacks (multi-config)	GA late 2025	No

¿Cuál elegir? Si tu equipo es un usuario final que ejecuta terraform apply contra su propia infra, la BSL no te restringe: cualquiera de las dos sirve. Si te importa que el código sea open source de verdad, o necesitas cifrado de estado cliente-side sin tener que montar KMS propio, OpenTofu es la opción honesta. Si dependes de Terraform Stacks o de HCP Terraform como plataforma gestionada, quédate con Terraform.

Instalación: la trampa de los paquetes viejos

La mayoría de los tutoriales viejos empiezan con apt install terraform. En Debian y Ubuntu ese paquete apunta al HashiCorp APT repository, que a veces se retrasa varias semanas respecto al upstream y nunca te da OpenTofu. Mejor instalar el binario directo del proyecto:

# OpenTofu (recomendado para open source)
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh
tofu --version
# OpenTofu v1.12.3
# on linux_amd64
# Terraform (si lo necesitas por compatibilidad HCP)
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform
terraform --version
# Terraform v1.15.5

Si tienes ambos binarios en el mismo sistema, recuerda que comparten .terraform.lock.hcl y el directorio .terraform/ en cada proyecto. No lances terraform init y tofu init sobre la misma raíz: el segundo comando va a quejarse de un lockfile escrito por la otra herramienta. Una raíz, una herramienta.

Tu primer proyecto: una droplet en DigitalOcean

El caso mínimo útil: una VM Debian 12 en DigitalOcean con tu clave SSH pública, taggeable, reproducible. Crea la carpeta de trabajo y un archivo main.tf:

mkdir ~/iac-demo && cd ~/iac-demo
touch main.tf variables.tf outputs.tf terraform.tfvars

El archivo main.tf declara el provider y el recurso. Nunca hardcodees la API token en el archivo — usa una variable de entorno:

terraform {
  required_version = ">= 1.12.0"
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}
variable "do_token" {
  type      = string
  sensitive = true
}
variable "ssh_key_path" {
  type    = string
  default = "~/.ssh/id_ed25519.pub"
}
provider "digitalocean" {
  token = var.do_token
}
resource "digitalocean_ssh_key" "demo" {
  name       = "iac-demo-key"
  public_key = file(var.ssh_key_path)
}
resource "digitalocean_droplet" "demo" {
  image    = "debian-12-x64"
  name     = "iac-demo-01"
  region   = "nyc3"
  size     = "s-1vcpu-1gb"
  ssh_keys = [digitalocean_ssh_key.demo.id]
  tags = ["iac-demo", "terraform"]
}

variables.tf declara los defaults y outputs.tf expone la IP de la droplet para usarla desde tu shell:

# variables.tf
variable "droplet_name" {
  type    = string
  default = "iac-demo-01"
}
# outputs.tf
output "droplet_ipv4" {
  value       = digitalocean_droplet.demo.ipv4_address
  description = "Dirección IPv4 pública de la droplet"
}
output "ssh_command" {
  value       = "ssh root@${digitalocean_droplet.demo.ipv4_address}"
  description = "Comando para conectar a la droplet"
}

El archivo terraform.tfvars queda casi vacío en local — la API token va por variable de entorno para no filtrarla:

droplet_name = "iac-demo-01"

Genera un token en DigitalOcean → API → Tokens con scope de escritura, expórtalo y lanza el ciclo:

export DIGITALOCEAN_TOKEN="dop_v1_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export TF_VAR_do_token="$DIGITALOCEAN_TOKEN"
tofu init
# Initializing the backend...
# Initializing provider plugins...
# - Reusing previous version of digitalocean/digitalocean from the dependency lock file
# Terraform/OpenTofu has been successfully initialized!
tofu plan
# digitalocean_ssh_key.demo: Refreshing state...
# digitalocean_droplet.demo: Refreshing state...
# Plan: 1 to add, 0 to change, 0 to destroy.
tofu apply
# Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
# Outputs:
# droplet_ipv4 = "138.68.123.45"
# ssh_command = "ssh [email protected]"

En menos de 60 segundos tienes una droplet real, descrita en 30 líneas de HCL, reproducible por cualquier sysadmin con tu mismo token. El comando tofu output en otra terminal te da la IP sin tocar la consola web.

El archivo de estado: lo que nunca debes perder

Cuando tofu apply termina, la herramienta escribe terraform.tfstate en tu directorio. Ese archivo es el mapa vivo de toda tu infraestructura: cada recurso, cada ID en el proveedor, cada dependencia. Perderlo es perder la capacidad de gestionar esa infra con código. La próxima vez que hagas tofu plan verá recursos existentes que no puede conciliar y propondrá destruirlos y recrearlos — exactamente lo contrario de lo que quieres.

Las reglas que aplico a rajatabla:

1. Estado local solo para aprender. En el momento en que dos personas pueden tocar el mismo proyecto, backend remoto obligatorio (S3, GCS, Azure Storage, Consul, etcd, o Terraform Cloud / HCP).
2. Nunca commitear .tfstate a git: contiene secretos en texto plano. Añade *.tfstate y .terraform/ al .gitignore desde el primer commit.
3. Habilita versioning en el bucket de estado. Borrar o sobrescribir el state por accidente deja de ser catastrófico.
4. Bloquea el state con terraform { backend "s3" { ..., dynamodb_table = "tofu-locks" } } si trabajas en equipo. Sin lock, dos apply simultáneos corrompen el archivo.

Ejemplo mínimo para producción con S3 + DynamoDB lock (compatible con OpenTofu y Terraform):

terraform {
  backend "s3" {
    bucket         = "mi-empresa-tofu-state"
    key            = "iac-demo/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tofu-locks"
    encrypt        = true
  }
}

Si trabajas con OpenTofu 1.7+ y manejas secretos sensibles en el state (claves API, passwords de DB), añade el cifrado cliente-side con PBKDF2:

terraform {
  encryption {
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.default
    }
    state {
      method   = method.aes_gcm.default
      enforced = true
    }
  }
}
key_provider "pbkdf2" "default" {
  passphrase = var.state_passphrase
}

Con Terraform de IBM, ese mismo terraform {} devuelve error: el cifrado cliente-side sigue siendo feature exclusiva de OpenTofu en 2026. Si necesitas ese nivel y prefieres quedarte con Terraform, la única salida es cifrar el bucket S3 con SSE-KMS y asumir que quien tenga acceso al bucket ve los secretos en claro.

Errores comunes que cuestan horas

1. Olvidar el -out=tfplan en pipelines. Sin ese flag, el plan que se ejecuta en CI no es exactamente el que aprobó el revisor. En OpenTofu 1.6+ puedes usar tofu plan -out=tfplan && tofu apply -auto-approve tfplan como cinturón de seguridad.

2. Mezclar terraform y tofu en el mismo directorio. Si tu equipo tiene ambos binarios en el $PATH, asegúrate de que el CI y el local usan el mismo. El .terraform.lock.hcl deja una pista de quién escribió el lockfile; si ves "tofu" en los comentarios y tu binario es terraform, vas a obtener errores de checksum.

3. State drift por cambios manuales. Cualquier edición en la consola de DigitalOcean que no esté en main.tf es drift. tofu plan te lo mostrará como "# digitalocean_droplet.demo has been changed" y propondrá sobrescribirlo. La cura es disciplina: si tocas algo por consola, vuelve a main.tf y commitea el cambio. La prevención es tofu plan -detailed-exitcode en CI para abortar el deploy si hay drift no documentado.

4. Providers viejos tras actualizar. terraform init -upgrade (o tofu init -upgrade) descarga la última versión declarada en required_providers. Si un día rompes algo, vuelve al lockfile viejo con terraform init -upgrade=false. Y revisa .terraform.lock.hcl en git: ahí vive la lista exacta de versiones usadas.

5. Recursos huérfanos tras destruir. Si borras un bloque resource de tu HCL y haces apply, la herramienta destruye el recurso en el proveedor — bien. Pero si renombras un bloque (web → web_server), interpreta el cambio como “destruir el viejo, crear el nuevo”, lo que en producción es exactamente lo opuesto a lo que querías. Para renombrar sin destruir: tofu state mv digitalocean_droplet.web digitalocean_droplet.web_server, y luego edita el main.tf.

Cuándo Terraform NO es la herramienta correcta

Terraform no es bala de plata. Tres casos donde conviene mirar otra cosa primero:

• Infraestructura puramente Kubernetes: si todo lo que despliega vive dentro de un cluster, los Helm charts + Kustomize o el API server de Kubernetes suelen ser suficientes. Terraform tiene un provider de Kubernetes, pero es verboso para lo que consigues.
• Cambios imperativos puntuales: si necesitas reiniciar un servicio ahora, ssh + systemctl restart es más rápido que escribir un recurso null_resource con triggers.
• Configuración mutable compleja: Ansible, Chef o Puppet están diseñados para estado final sobre máquinas existentes. Terraform es declarativo pero está pensado para provisionar, no para mantener. La frontera es difusa, pero si pasas más tiempo aplicando local-exec que resource blocks, probablemente estás en territorio Ansible.

Resumen: tu primer commit en menos de 15 minutos

1. Instala OpenTofu o Terraform con el script oficial — evita los paquetes viejos de tu distro.
2. Crea un proyecto nuevo con main.tf, variables.tf, outputs.tf y un .gitignore que excluya *.tfstate y .terraform/.
3. Exporta tu API token como variable de entorno y lánzalo con tofu init && tofu plan && tofu apply.
4. El primer state va en local; el segundo en un backend remoto con lock.
5. Adopta tofu plan -out=tfplan en CI desde el día uno.

Tienes ahora una infraestructura reproducible, auditable en git, y portable a cualquier cloud que tenga provider oficial. El siguiente paso natural es convertir esa droplet en un módulo reusable (module "web" { source = "./modules/web" }) y empezar a parametrizar entornos con workspaces o directorios separados. Esa es la parte divertida.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux