Cuando hablamos de Terraform, muchas veces la primera reacción es: ¿Otra herramienta más para configurar servidores?
No exactamente.
Terraform intenta resolver un problema bastante más interesante: ¿cómo podemos definir, versionar y reproducir nuestra infraestructura de la misma manera que hacemos con nuestro código?
Imaginemos que tenemos que desplegar una aplicación.
Necesitamos:
- una máquina virtual;
- una base de datos;
- una red;
- algunos permisos;
- un almacenamiento;
- quizás un balanceador.
Una forma de hacerlo es entrar a la consola de nuestro proveedor cloud y empezar a crear recursos.
- Hacemos clic.
- Configuramos una opción.
- Creamos una red.
- Después una máquina virtual.
- Después cambiamos una configuración.
- Y finalmente tenemos nuestra infraestructura funcionando.
El problema aparece unos meses después.
Queremos crear exactamente el mismo ambiente para testing.
¿Recordamos todos los pasos?
¿Todas las opciones?
¿Todas las reglas de firewall?
¿Todas las dependencias?
Probablemente no.
Y aunque recordemos todo, aparece otro problema: ¿cómo sabemos exactamente qué cambió entre producción y testing?
Ahí aparece una idea importante: Infrastructure as Code
Infrastructure as Code, o IaC, consiste en tratar la infraestructura como código.
En lugar de decir: Entrá a esta consola y creá una máquina con estas opciones, podemos escribir algo que describa nuestra infraestructura:
resource "..." "..." {
...
}
Ese archivo puede:
- guardarse en Git;
- revisarse mediante Pull Requests;
- versionarse;
- reutilizarse;
- automatizarse;
- compartirlo con otros desarrolladores.
Nuestra infraestructura deja de estar solamente en una consola y pasa a estar también descrita en código.
HashiCorp Terraform es una herramienta de Infrastructure as Code desarrollada originalmente por HashiCorp.
La idea fundamental es bastante sencilla: Describimos el estado que queremos y Terraform se encarga de realizar los cambios necesarios para llegar a ese estado.
Esto es importante porque Terraform utiliza un enfoque declarativo.
No necesitamos describir paso por paso cómo crear la infraestructura.
Describimos qué queremos tener.
Por ejemplo:
resource "local_file" "hello" {
filename = "hello.txt"
content = "Hola desde Terraform!"
}
Estamos diciendo: Quiero un recurso local_file llamado hello cuyo archivo sea hello.txt y cuyo contenido sea Hola desde Terraform!.
Terraform se ocupa del resto.
Para empezar no necesitamos AWS, Azure ni Google Cloud.
Podemos utilizar un provider que trabaja con archivos locales.
Nuestro primer ejemplo completo puede ser:
terraform {
required_providers {
local = {
source = "hashicorp/local"
}
}
}
provider "local" {}
resource "local_file" "hello" {
filename = "hello.txt"
content = "Hola desde Terraform!"
}
Guardamos el archivo como:
main.tf
Y ejecutamos:
terraform init
Terraform descarga y configura el provider que necesitamos.
Después podemos preguntarle qué va a hacer:
terraform plan
Terraform nos muestra un plan de ejecución.
Finalmente:
terraform apply
Terraform aplica los cambios.
Y ahora tenemos:
hello.txt
con el contenido:
Hola desde Terraform!
¿Por qué plan es interesante?
Este es uno de los conceptos más importantes de Terraform.
Antes de modificar nuestra infraestructura podemos ejecutar:
terraform plan
Terraform analiza la configuración y el estado actual y nos muestra qué cambios pretende realizar.
Por ejemplo:
Plan: 1 to add, 0 to change, 0 to destroy.
Esto nos permite revisar los cambios antes de aplicarlos.
En una infraestructura real esto es extremadamente importante.
Imaginemos que alguien modifica un archivo Terraform y, sin revisar nada, ejecuta directamente la aplicación de los cambios.
Podría terminar eliminando un recurso que no debía eliminarse.
Con plan, podemos ver qué piensa hacer Terraform antes de hacerlo.
Terraform no es un script. Esta diferencia merece una explicación.
No hay comentarios.:
Publicar un comentario