Empezamos la Parte V: Terraform avanzado. Hasta ahora escribías toda tu infraestructura en archivos sueltos. Funciona para algo pequeño, pero cuando creces, ese enfoque se vuelve repetitivo e inmanejable. La solución son los módulos, la pieza clave para reutilizar y organizar tu código Terraform como un profesional. En este subcapítulo entenderás qué son y cómo se estructuran.

Imagina que necesitas crear la misma infraestructura una y otra vez. Por ejemplo, en tu empresa cada nuevo proyecto necesita una VPC con subredes públicas y privadas, igual que la del Capítulo 12. Sin módulos, tendrías que copiar y pegar todo ese código en cada proyecto:

Esto es un desastre: si encuentras un error o quieres mejorar la VPC, tienes que cambiarlo en todos los sitios. Es justo el problema que la programación resolvió hace décadas con las funciones: escribir algo una vez y reutilizarlo.

Un módulo de Terraform es un conjunto de recursos agrupados y reutilizables, empaquetados como una unidad con una entrada y una salida bien definidas. Es el equivalente a una función en programación: lo defines una vez y lo «llamas» tantas veces como necesites, cambiando solo los detalles.

Analogía: un módulo es como una receta de cocina reutilizable. Escribes una vez la receta de «pizza» indicando qué ingredientes admite (los ingredientes son los parámetros). Luego la usas muchas veces cambiando los ingredientes: una pizza de jamón, otra de champiñones, otra vegetariana. La receta (el módulo) es la misma; los ingredientes (las variables) cambian.

Un módulo es, sencillamente, una carpeta con archivos .tf. Por convención, se organizan en tres archivos principales (recuerda los bloques del Capítulo 10):

Define qué se le puede configurar al módulo desde fuera. Son como los «parámetros» de la receta. Por ejemplo, el rango de la VPC o el nombre del proyecto:

Contiene los recursos que el módulo crea, usando las variables de entrada. Es el «cuerpo» de la receta:

Define qué información devuelve el módulo para que otros puedan usarla (recuerda los outputs del subcapítulo 12.4). Por ejemplo, el ID de la VPC creada:

Lo elegante de un módulo es que funciona como una caja con un «contrato» claro:

Quien usa el módulo no necesita saber cómo está hecho por dentro: solo le da las entradas que necesita y recibe las salidas que le interesan. Esto es abstracción: ocultar la complejidad detrás de una interfaz sencilla. Igual que usas una función sin saber cómo está programada por dentro.

Ejemplo del mundo real: el equipo de plataforma de una empresa crea un módulo red-corporativa que monta una VPC con todas las buenas prácticas de seguridad y conectividad de la empresa. Los demás equipos solo tienen que usar ese módulo dándole un nombre y un rango; obtienen una red perfecta sin ser expertos en redes. Toda la complejidad está encapsulada en el módulo.

• Sin módulos, acabas copiando y pegando el mismo código de infraestructura, lo que es repetitivo e inmantenible (cambiar algo obliga a tocarlo en muchos sitios).
• Un módulo es un conjunto de recursos agrupados y reutilizables, el equivalente a una función en programación: lo defines una vez y lo usas muchas. Como una receta de cocina reutilizable.
• Un módulo es una carpeta con archivos .tf, organizados por convención en tres: variables.tf (entradas), main.tf (recursos) y outputs.tf (salidas).
• Funciona como una caja con un contrato: le das entradas (variables) y recibes salidas (outputs), sin necesidad de saber cómo está hecho por dentro. Eso es abstracción.

En el siguiente subcapítulo profundizaremos en cómo se conecta un módulo con el mundo exterior: sus variables de entrada, sus outputs y cómo se establecen las dependencias entre módulos.