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

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 módulo de VPC de AWS de Terraform 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 terraform-aws-atlantis utiliza módulos de recurso,tales como terraform-aws-vpc y terraform-aws-security-group, para administrar la infraestructura requerida en la ejecución de Atlantis sobre AWS Fargate.

Otro ejemplo es el módulo terraform-aws-cloudquery, en el cual múltiples módulos de terraform-aws-modules 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 externa 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 módulo terraform-aws-lambda, en el cual el nombre del archivo es procesado llamando un script externo de Python.

La fuente de datos http 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, terraform-aws-security-group 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 múltiples formas de compartir información entre configuraciones.

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

composition-1 { 
  infrastructure-module-1 { 
    data-source-1 => d
  
    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }
}

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 y stage, los cuales no comparten nada). Cada entorno vive en una cuenta separada de AWS.

• Cada entorno hace uso de la misma versión del módulo interno modules/network dado que es procedente de un directorio local.

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.

Documentación

Documentación generada automáticamente

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

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

Recursos

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 y stage, los cuales no comparten nada). Cada entorno vive en cuentas separadas de AWS.

• Cada entorno hace uso de la misma versión del módulo interno modules/network dado que es procedente de un directorio local.

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.

Años después, ha sido actualizado incluyendo a más de las mejores prácticas disponibles para Terraform 1.0. Eventualmente, este libro debería contener la mayoría de las mejores prácticas y recomendaciones indiscutibles para los usuarios de Terraform.

Patrocinadores

Traducciones

Contribuciones

Siempre quiero recibir comentarios y actualizar este libro a medida que la comunidad madura y se implementan y verifican nuevas ideas con el tiempo.

Autores

Licencia

El presente trabajo es licenciado bajo la Licencia Apache 2. Ver LICENCIA para detalles completos.

Los autores y contribuidores de este contenido no garantizan la validez de la información aquí encontrada. Favor de asegurarse de que se sobreentiende que la información proveída se provee de manera gratuita, y no es creado ningún tipo de acuerdo o contrato entre usted y las personas asociadas con el contenido de este proyecto. Los autores y contribuidores no asumen y, por la presente, renuncian a cualquier responsabilidad ante cualquier parte por cualquier pérdida, daño o interrupción causada por errores u omisiones en la información contenida, asociada o vinculada a este contenido, ya sea que dichos errores u omisiones sean el resultado de negligencia, accidente ocualquier otra causa.

Derechos de autor © 2018-2023 Anton Babenko.