La documentación oficial de Terraform describe todos los aspectos de la configuración a detalle, y se recomienda leerla con atención para comprender el resto de esta sección.

Recurso

Un recurso -resource- es, por ejemplo: aws_vpc, aws_db_instance, entre otros. Los recursos pertenecen a los proveedores, aceptan argumentos, muestran datos de salida de los atributos, tienen ciclos de vida. Estos pueden ser creados, recuperados, actualizados y eliminados.

Módulo de recurso

Un módulo de recurso -terraform module- es una colección de recursos conectados, los cuales en conjunto realizan una acción común (por ejemplo, el crea una VPC, sus subredes, la NAT Gateway, etc.). Este depende de la configuración del proveedor, el cual puede definirlo en sí mismo o a un nivel superior de estructura (como en un módulo de infraestructura).

Módulo de infraestructura

Un módulo de infraestructura -infrastructure module- es una colección de módulos de recurso, los cuales pueden no estar conectados lógicamente pero que en el proyecto, configuración o situación en la que se encuentran, sirven a un mismo propósito.

Por ejemplo, el módulo utiliza módulos de recurso,tales como y , para administrar la infraestructura requerida en la ejecución de sobre .

Otro ejemplo es el módulo , en el cual múltiples módulos de son utilizados de manera conjunta para administrar la infraestructura, así como el uso de recursos de Docker para el compilado, push y despliegue de imágenes de Docker. Todo en uno.

Composición

Una composición -composition- es una colección de módulos de infraestructura, la cual puede abarcar a lo largo de diferentes áreas separadas lógicamente (como Regiones de AWS, varias Cuentas de AWS). La composición es utilizada para describir la totalidad de la infraestructura requerida para todo el proyecto u organización.

La composición consiste de módulos de infraestructura compuestos de módulos de recurso, los cuales implementan recursos individuales.

Fuente de datos

La fuente de datos -data source- realiza operaciones de sólo lectura y depende de la configuración del proveedor. Esta es usada en un módulo de recurso y en un módulo de infraestructura.

La fuente de datos terraform_remote_state actúa como un pegamento para módulos y recursos de más alto nivel.

La fuente de datos permite a un programa externo actuar como fuente de datos, exponiendo arbitrariamente información en cualquier lugar de la configuración de Terraform. Aquí tenemos un ejemplo del , en el cual el nombre del archivo es procesado llamando un script externo de Python.

La fuente de datos realiza una petición HTTP GET al URL dado y exporta la información acerca de la respuesta la cual es útil para obtener información de endpoints en los que no existe un proveedor nativo de Terraform.

Estado remoto

-Remote state- El estado de las composiciones y módulos de infraestructura debe de persistir en una locación remota la cual pueda ser accedida por otros de forma controlada (ACL, versionamiento, logging).

Proveedor, aprovisionador, etc.

Los proveedores -providers-, aprovisionadores -provisioners-, y algunos otros términos son descritos a detalle en la documentación oficial, por lo que no hay necesidad de ser repetidos en la presente. En mi opinión, tienen poco que ver con escribir buenos módulos de Terraform.

¿Por qué es tan difícil?

Mientras que los recursos individuales funcionan como átomos en la infraestructura, los módulos de recursos son moléculas. Un módulo es la unidad versionada más pequeña y compartible. Esta contiene la lista exacta de argumentos e implementa la lógica básica para que dicha unidad realice la función requerida. Por ejemplo, crea los recursos aws_security_group y aws_security_group_rule con base a las entradas -inputs-. Este módulo de recurso puede ser utilizado en conjunto con otros módulos para crear un módulo de infraestructura.

El acceso a la información entre moléculas (módulos de recurso e infraestructura) es realizado mediante el uso de salidas -outputs- y fuentes de datos -data sources-.

El acceso entre composiciones es a menudo realizado utilizando fuentes de datos de estados remotos. Hay .

Cuando disponemos los conceptos descritos anteriormente como pseudorelaciones, pueden lucir a como a continuación se muestran:

Fuente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño pequeño, en donde no son utilizadas dependencias externas.

Terraform es un proyecto relativamente nuevo (como la mayoría de las herramientas DevOps, de hecho) que comenzó en el año 2014.

Terraform es bastante potente (si no es que la herramienta más potente disponible en el mercado actualmente) y una de las herramientas que permiten la administración de infraestructura como código más usadas. Terraform permite a los desarrolladores realizar una gran variedad de cosas pero no los restringe de hacerlas de maneras en las que en un futuro les serán difíciles de integrar o de dar soporte.

Algo de la información descrita tal vez no parezca como parte de las mejores prácticas, lo sé, y para ayudar a los lectores a separar cuáles son las mejores prácticas establecidas y cuáles son sólo otras formas opinadas de hacer las cosas, hago uso de sugerencias para proporcionar algo del contexto e iconos para especificar el nivel de madurez de cada subsección relacionada con las mejores prácticas.

Este libro tuvo su comienzo un día soleado de Madrid del 2018, y se encuentra disponible de manera gratuita en

Estos son los artículos de la presente sección:

There is also a workshop for people who want to practice some of the things described También hay un taller para personas que quieran practicar algunas de las cosas descritas en esta guía.

Puedes encontrar el contenido aquí - https://github.com/antonbabenko/terraform-best-practices-workshop.

Las preguntas relacionas a la estructura del código de Terraform son por mucho las más frecuentes dentro de la comunidad. Probablemente todos en algún punto han pensado acerca de la mejor estructura para el código.

¿Cómo debería de estructurar mis configuraciones de Terraform?

Esta es una de las preguntas en las que existen muchas soluciones y es muy difícil dar un consejo general, así que comencemos por comprender con qué estamos tratando.

• ¿Cuál es la complejidad del proyecto?

  • Número de recursos relacionados.

  • Número de proveedores de Terraform.

• ¿Qué tan seguido cambia la infraestructura?

  • De una vez al mes, semana, día.

  • A continuamente (cada que hay un nuevo commit).

• ¿Cuáles son los iniciadores de cambio del código? ¿Se permite que un servidor CI -continuous integration- actualice el repositorio cuando un nuevo artefacto es compilado?

  • Sólo los desarrolladores pueden pushear al repositorio de infraestructura.

  • Todos pueden proponer cambios mediante una PR -pull request- (incluyendo tareas automatizadas corriendo en un servidor CI)

• ¿Qué plataforma o servicio de despliegue se utiliza?

  • AWS CodeDeploy, Kubernetes y OpenShift requieren planteamientos diferentes.

• ¿Cómo son agrupados los entornos?

  • Por entorno, región, proyecto.

Comenzando con la estructuración de la configuración de Terraform

Poner todo el código en main.tf es una buena idea de cuando estás comenzando o escribiendo un código ejemplo. Para cualquier otro caso será mejor tener varios archivos en una separación lógica como a continuación se presenta:

• main.tf - llama a los módulos, locals y data-sources para crear todos los recursos.

• variables.tf - contiene declaraciones de variables utilizadas en el main.tf.

• outputs.tf - contiene outputs de recursos creados en main.tf.

terraform.tfvars no debe ser utilizado en ningún otro lugar más que en la .

¿Cómo pensar acerca de la estructura de configuración de Terraform?

Recomendaciones generales para estructurar el código

• Es más fácil y rápido trabajar con un menor número de recursos.

• terraform plan y terraform apply realizan llamadas API a la nube para verificar el estatus de los recursos.

• Si tienes toda tu infraestructura en una sola composición, puede tomar varios minutos.

En el presente libro, los ejemplos de proyectos están agrupados por _complejidad -_de pequeñas a muy grandes infraestructuras. Está separación no es restrictiva, así que revisa también por otras infraestructuras.

Orquestación de módulos de infraestructura y composiciones

Tener una infraestructura pequeña significa que también se cuenta con un pequeño número de dependencias así como de recursos. Conforme el proyecto crece, la necesidad de encadenar la ejecución de configuraciones de Terraform, conectando diferentes módulos de infraestructura y pasando valores dentro de una composición, se vuelve visible.

Existen al menos 5 diferentes grupos de soluciones de orquestación que los desarrolladores utilizan:

1. Sólo Terraform - Muy directo, los desarrolladores sólo tienen que saber Terraform para tener el trabajo hecho.

2. Terragrunt - Herramienta de orquestación pura que se puede utilizar para orquestar toda la infraestructura y gestionar las dependencias. Terragrunt opera con módulos y composiciones de infraestructura de manera nativa, lo que reduce la duplicación de código.

3. Scripts propios - A menudo, esto sucede como un punto de partida hacia la orquestación y antes de descubrir Terragrunt.

Con esto en mente, estaremos revisando las primeras dos estructuras de proyectos, sólo y .

https://twitter.com/antonbabenko/lists/terraform-experts - Lista de personas que trabajan activamente con Terraform y que te pueden decir mucho (si les preguntas).

https://github.com/shuaibiyy/awesome-terraform -Lista seleccionada de recursos en Terraform de HashiCorp.

http://bit.ly/terraform-youtube - Canal de YouTube "Your Weekly Dose of Terraform" de Anton Babenko. Transmisiones en vivo con reseñas, entrevistas, preguntas y respuestas, codificación en vivo y algo de hacking con Terraform.

- Boletín semanal de Terraform. Varias noticias en el mundo de Terraform (proyectos, anuncios, debates) por Anton Babenko.

Estructuras de código de Terraform

Estructuras de código de Terraform

Fuente:

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño grande que utiliza:

• 2 cuentas de AWS.

• 2 entornos separados (prod

Uso de locales -locals-** para especificar explícitamente dependencias entre los recursos**

Fuente:

La presente integra código como ejemplo de la estructuración de la configuración para una infraestructura de tamaño mediano que utiliza:

• 2 cuentas de AWS.

• 2 entornos separados (prod

Documentación

Documentación generada automáticamente

**** es un marco de trabajo -framework- para administrar y mantener hooks de precommit multi lenguaje. Está escrito en Python y es una herramienta potente para hacer algo de manera automática en la máquina del desarrollador antes de que el código sea commiteado al repositorio de git. Normalmente, es utilizado para ejecutar linters y formatear código (ver ).

Con las configuraciones de Terraform, el pre-commit puede ser utilizado para formatear y validar código, así como actualizar documentación.

Se recomienda revisar el para la familiarización con el mismo, y con otros repositorios existentes (por ejemplo, ) en donde está siendo utilizado.

@porhacer: Documentar versiones de módulos, liberaciones, GH Actions.

Recursos

1. .

2. .

3. Publicación de blog por .

¿Cuáles son las herramientas que debería tener en cuenta y considerar utilizar?

• Terragrunt - herramienta de orquestación.

• - linter de código.

• - gestor de versiones.

• - automaticación de Pull Request.

• - Colección de hooks de git para Terraform a usar con .

• - Cloud estima los costes de Terraform mediante un sistema de extraccion y trabaja con Terragrunt, Atlantis y pre-commit-terraform

¿Cuál es la solución al -infierno de las dependencias- con los módulos?

Las versiones de los recursos y los módulos de la infraestructura deben ser especificados. Los proveedores deben ser configurados fuera de los módulos, solamente en la composición. Las versiones de los proveedores y Terraform también se pueden bloquear.

No hay una herramienta de gestión de dependencias maestra pero, hay varios tips para hacer el dependency hell menos problemático. Por ejemplo, **** puede ser utilizado para automatizar la actualización de dependencias. Dependabot crea pull requests para mantener las dependencias seguras y actualizadas al día. Dependabot soporta configuraciones de Terraform.

Convenciones generales

1. Utilizar __ _ (guión bajo) en lugar de – (guión) en todo: nombres de recursos, nombres de fuentes de datos -data sources-, nombres de variables, salidas -outputs-, etc.

2. Utilizar preferentemente letras y números en letras pequeñas -lowercased- (incluso si UTF-8 es soportado).

Argumentos de recurso y fuente de datos

1. No repetir el tipo de recurso en el nombre del recurso (ni de manera parcial, ni completa):

2. El nombre del recurso debería ser this si no hay un nombre más descriptivo o general disponible, o si el módulo del recurso crea un recurso único de este tipo (por ejemplo, en el sólo hay un recurso del tipo aws_nat_gateway y multiples recursos del tipo aws_route_table, así que aws_nat_gateway __ debería ser llamado this __ y aws_route_table __ debería tener nombres más descriptivos como private, public, database).

3. Siempre utilizar sustantivos singulares para los nombres.

4. Utilizar – dentro de los valores de los argumentos y en lugares en donde el valor será expuesto a un ser humano (por ejemplo, dentro del nombre del DNS o de una instancia RDS).

5. Incluir el argumento count/for each dentro del bloque de recursos como primer argumento en la parte superior y separarlo por una nueva línea después de este.

6. Incluir el argumento tags __ si es soportado por el recurso como el último argumento real, seguido por depends_on y lifecycle, si es necesario. Todo esto debería ser separado por una sola línea vacía.

7. Cuando se utiliza un condición en el argumento count/for each, utilizar un valor booleano si esto tiene sentido, de otra forma, utilizar length u otra expresión.

Ejemplos del código de recurso

Uso de count / for each

Colocación de tags -etiquetas-

Condicionales en count

Variables

1. No reinventar la rueda en los módulos de recursos: usar los valores de variables name, description y default como se define en la sección “Referencia de Argumentos” para el recurso en el que estás trabajando.

2. El soporte para la validación en variables es bastante limitado (por ejemplo, no se puede acceder a otras variables o realizar búsquedas). Planificar en consecuencia de esto porque en muchos casos esta característica es inútil.

3. Utilizar la forma plural en un nombre de variable cuando el tipo sea list (...) o map(...).

4. Ordenar las claves en un bloque variable como este: description, type, default, validation.

5. Incluir siempre una description de todas las variables, incluso si cree que es obvio (lo necesitará en el futuro).

6. Procurar usar tipos simples (number, string, list(...), map(...), any) sobre tipos específicos como object()a menos que necesite tener restricciones estrictas en cada clave.

7. Utilizar tipos específicos como mapa map(map(string)) si todos los elementos del mapa tienen el mismo tipo (por ejemplo, string) o se pueden convertir a él (por ejemplo, el tipo de number se puede convertir en string).

8. Utilizar el tipo any para deshabilitar la validación de tipos a partir de una cierta profundidad o cuando deban admitirse varios tipos.

9. El valor {} a veces es un mapa, pero a veces un objeto. Usar tomap (...) para hacer un mapa porque no hay forma de hacer un objeto.

Outputs -salidas-

Nombrar las salidas -outputs- es importante para hacerlas consistentes y comprensibles fuera de su alcance (cuando el usuario está utilizando un módulo siempre debería de ser obvio qué tipo y atributo del valor es regresado).

1. El nombre de la salida debe describir la propiedad que contiene y ser menos libre de lo que normalmente desearía.

2. Una buena estructura para el nombre de la salida se parece a {name}_{type}_{attribute} o {nombre}_{tipo}_{atributo} donde:

1. {name} es un recurso o fuente de datos -data sorce- sin un prefijo de proveedor. {name} para aws_subnet es subnet, paraaws_vpc es vpc.

3. Si la salida devuelve un valor con funciones de interpolación y varios recursos, {name} y {type} deben ser lo más genéricos posible (this como prefijo debe omitirse). .

4. Si el valor devuelto es una lista, debe tener un nombre en plural. .

5. Incluir siempre la description de todos las salidas, incluso si se cree que esta es obvia.

6. Evitar establecer argumentos sensibles (sensitive)a menos que controle completamente el uso de dicha salida en todos los lugares de todos los módulos.

7. Preferir el uso de try() (disponible desde Terraform 0.13) sobre element(concat(...)) (enfoque heredado de versiones anteriores a la 0.13).

Ejemplos del código de output -salida-

Devuelve como máximo una ID del grupo de seguridad:

Cuando tenga varios recursos del mismo tipo, this debe omitirse en el nombre de la salida:

Utilizar el nombre en plural si el valor devuelto es una lista