Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

El servidor “Snowflake” y el desastre de ClickOps

En los viejos tiempos de la cultura SysAdmin, un servidor era una mascota. Lo llamaste “Gandalf” o “Zeus”. Un desarrollador ingresaría SSH al servidor, ejecutaría apt-get install nginx, editaría un archivo de configuración usando vi, reiniciaría el servicio y tal vez modificaría un parámetro del kernel (sysctl.conf) para optimizar el rendimiento de la red. Harían esto durante 5 años. El servidor se convirtió en Copo de nieve. Único. Hermoso. Frágil. Si “Gandalf” moría (fallo de hardware), sobrevenía el pánico. “¿Cómo lo reconstruimos?” “No lo sé, Bob lo creó en 2018 y dejó la empresa”. “¿Cuál era la configuración?” “Estaba en el disco duro que acaba de quemarse”. Esto es ClickOps (configuración a través de Consola/GUI) y administración manual. Es un desastre esperando a suceder. En la era de la nube, los servidores son ganado, no mascotas. Los llama “web-worker-01”, “web-worker-02”. Si uno se enferma, le disparas y generas uno nuevo. Infraestructura como Código (IaC) es la metodología que permite esto. Usted define su infraestructura en archivos de texto (.tf). Los comprometes con Git. Tú los revisas. Los aplica utilizando una CLI. La máquina construye el servidor. Lo ideal sería que ningún ser humano volviera a utilizar SSH en una máquina.

Por qué Maison Code habla de Terraform

En Maison Code, gestionamos la infraestructura para múltiples clientes de alto crecimiento. Un cliente maneja las ventas flash (picos de tráfico de 100 veces). Otro maneja datos médicos (cumplimiento de HIPAA, cifrado estricto). No podemos confiar en la memoria humana para garantizar que estos entornos sean correctos. “¿Habilité el cifrado en ese depósito de S3?” Si confías en la memoria, la respuesta es “Quizás”. Usamos Terraform para asegurarnos de que la respuesta sea “Sí, está en la línea 42 de storage.tf”. Construimos Módulos reutilizables. Contamos con un módulo estándar “Maison Code Safe Bucket” que aplica el cifrado, el registro y el control de versiones. Usamos esto para cada cliente. Esto garantiza la Estandarización y la Seguridad a escala. No solucionamos el mismo problema dos veces. Lo solucionamos una vez en Terraform y lo implementamos en todas partes.

La herramienta: HashiCorp Terraform

Terraform es el estándar de oro porque es agnóstico de la nube. Puede usarlo para administrar AWS, Google Cloud, Azure, Cloudflare, GitHub e incluso su pedido de Domino’s Pizza (sí, hay un proveedor). Compare esto con CloudFormation (solo AWS) o Plantillas ARM (solo Azure). Learning Terraform le brinda un superpoder en toda la industria. Utiliza HCL (lenguaje de configuración de HashiCorp). Es declarativo. Describes el destino, no el viaje. “Quiero 5 servidores”. (Terraform descubre cómo pasar del 2 al 5). En lugar de “Crear 3 servidores”. (Imperativo).

Ejemplo: creación de un depósito S3

proveedor "aws" {
  región = "nosotros-este-1"
}

recurso "aws_s3_bucket" "activos" {
  cubo = "maison-code-assets-prod"
  
  etiquetas = {
    Entorno = "Producción"
    Proyecto = "Casa"
    Gestionado por = "Terraformar"
  }
}

recurso "aws_s3_bucket_public_access_block" "bloquear" {
  depósito = aws_s3_bucket.assets.id
  
  block_public_acls = verdadero
  block_public_policy = verdadero
  ignore_public_acls = verdadero
  restrict_public_buckets = verdadero
}

recurso "aws_s3_bucket_versioning" "control de versiones" {
  depósito = aws_s3_bucket.assets.id
  configuración_de_versiones {
    estado = "Habilitado"
  }
}

Este código es Documentación. Cualquiera que lo lea sabe: “Tenemos un depósito. Es explícitamente privado. El control de versiones está habilitado (para que podamos recuperar archivos eliminados)”. Esto es mejor que un documento de Word de 50 páginas que describe la configuración del servidor (que siempre está desactualizado).

The State File: El cerebro de Terraform

Terraform rastrea lo que creó en un archivo llamado terraform.tfstate. Este es un archivo JSON que asigna sus recursos de código (resource "aws_instance" "app") a identificadores del mundo real (i-0a1b2c3d4e5f). Estado actual versus estado deseado. Cuando ejecuta “terraform plan”, Terraform:

Lee su código (estado deseado).
Lee el archivo de estado (último estado conocido).
Actualiza el estado (comprueba las API de AWS para ver si algo cambió).
Calcula el “Delta” (Diff). Luego te dice: “Planeo agregar 1 recurso, cambiar 2 recursos y destruir 0 recursos”. Peligro: El archivo estatal contiene secretos (contraseñas, claves privadas) en texto sin formato. Mejores prácticas: Nunca envíe terraform.tfstate a Git. Utilice un Backend remoto. Almacene el estado en un depósito S3 con el cifrado del lado del servidor habilitado. Utilice una tabla de DynamoDB para Bloqueo de estado. Esto evita que dos desarrolladores ejecuten “terraform apply” al mismo tiempo y corrompan el estado.

Módulos: El principio de NO REPETIRSE (SECO)

Si copia y pega el bloque aws_instance 10 veces para 10 servidores, lo está haciendo mal. Cree un Módulo.

Definición de módulo (modules/web-server/main.tf):

variable "tamaño" { 
  tipo = cadena
  predeterminado = "t2.micro" 
}
variable "nombre" {tipo = cadena}

recurso "aws_instance" "aplicación" {
  ami = "ami-12345678"
  tipo_instancia = var.tamaño
  etiquetas = {
    Nombre = var.nombre
  }
}

Uso (main.tf):

módulo "interfaz" {
  fuente = "./modules/servidor web"
  tamaño = "t3.pequeño"
  nombre = "Frontal-01"
}

módulo "backend" {
  fuente = "./modules/servidor web"
  tamaño = "m5.grande"
  nombre = "API de backend"
}

Si decide cambiar el ID de AMI (actualizar la versión de Ubuntu), lo cambia en un lugar (el módulo) y actualiza todos los servidores.

Detección de deriva: la verificación de la realidad

¿Qué pasa si un desarrollador deshonesto inicia sesión en la consola de AWS y cambia manualmente el grupo de seguridad para abrir el puerto 22 (SSH) al mundo? Esto es Deriva de configuración. La Realidad ya no coincide con el Código. La próxima vez que ejecute “terraform plan”, Terraform verá esto. “Salida: La regla de ingreso del grupo de seguridad cambió del puerto 22 (0.0.0.0/0) a NULL”. Propondrá arreglar el entorno al estado definido en el código. Esto impone la disciplina. Los cambios de “ClickOps” son temporales y serán eliminados en la próxima implementación.

Espacios de trabajo de Terraform: entornos múltiples

Necesita desarrollo, puesta en escena y producción. No replique estructuras de carpetas (/dev, /prod). Utilice Espacios de trabajo. Nueva puesta en escena del espacio de trabajo Terraform. espacio de trabajo terraform nuevo producto. Utiliza los mismos archivos .tf, pero archivos de estado diferentes (terraform.tfstate.d/staging, terraform.tfstate.d/prod). En tu código, puedes usar la lógica: count = terraform.workspace == "prod"? 5: 1. Prod obtiene 5 servidores. El desarrollador obtiene 1.

Política como código (Sentinel / OPA)

En las organizaciones grandes, es importante evitar que los desarrolladores cometan errores. “Nadie puede crear un depósito S3 público”. “Nadie puede aprovisionar una instancia más grande que grande (demasiado cara)”. Puede utilizar Open Policy Agent (OPA) o HashiCorp Sentinel. Se ejecuta antes de “terraform apply”. Si el plan viola la política, bloquea la implementación. Esto es Gobernanza automatizada.

La visión del escéptico

“Es demasiado repetitivo. Puedo hacer clic en el botón más rápido”. Contrapunto: Hacer clic es más rápido una vez. Pero hay que mantenerlo para siempre. Si necesita replicar el entorno en otra región (recuperación ante desastres), hacer clic lleva días y es propenso a errores. Terraform tarda unos minutos (region = "eu-west-1"). Además, el código de “ClickOps” no se puede revisar. No puedes abrir una solicitud de extracción con un clic del mouse. No puede revertir un clic del mouse (fácilmente). El código es auditable. El código es cordura.

Preguntas frecuentes

P: ¿Terraform vs Ansible? R: Terraform proporciona infraestructura (el hardware: VPC, EC2, RDS). Ansible configura el software (el software: Apache, configuración de MySQL, usuarios). En el mundo moderno de la “infraestructura inmutable” (Docker), Ansible es menos necesario. Incorporamos el software a la imagen de Docker. Terraform implementa el servicio de contenedores (ECS/EKS). Utilice Terraform para la nube. Utilice Ansible para el sistema operativo (si no utiliza contenedores).

P: ¿Qué es main.tf, variables.tf, outputs.tf? R: Es una convención. Terraform lee todos los archivos .tf del directorio.

main.tf: Los recursos.
variables.tf: Argumentos de entrada.
outputs.tf: Qué imprimir al final (por ejemplo, URL del balanceador de carga).

P: ¿Acciones de Terraform Cloud frente a Jenkins/GitHub? R: Terraform Cloud ofrece características interesantes:

Gestión remota del estado (integrada).
Registro de Módulo Privado.
Estimación de costos (“Este cambio aumentará su factura en €50”). Sin embargo, puede ejecutar Terraform CLI dentro de GitHub Actions usando un backend S3 de forma gratuita. Terraform Cloud es de pago (por usuario). Generalmente comenzamos con GitHub Actions y actualizamos si es necesario.

Conclusión

La infraestructura como código convierte “Ops” en “Dev”. Lleva la disciplina de la ingeniería de software (control de versiones, revisión de código, pruebas, CI/CD) al mundo del hardware. Si no está en git, no existe. Deja de construir copos de nieve. Empieza a construir Legos.

¿Hacer clic en los botones manualmente?

Si su infraestructura es un delicado copo de nieve que tiene miedo de tocar, Maison Code puede terraformarlo. Realizamos ingeniería inversa de su configuración “ClickOps” existente y la codificamos en módulos Terraform robustos y reutilizables. Implementamos flujos de trabajo de bloqueo de estado, detección de deriva y recuperación ante desastres.

Contrate a nuestros arquitectos.