Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
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.
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).
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.
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.
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.
-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).
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.
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:
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.
Perfecta para proyectos en donde la infraestructura está separa lógicamente (cuentas separadas de AWS).
Buena cuando no hay necesidad de modificar recursos compartidos entre las diferentes cuentas de AWS (un entorno = una cuenta AWS = un archivo de estado).
Buena cuando no hay necesidad de orquestación de los cambios entre los entornos.
Buena cuando los recursos de infraestructura son diferentes por entorno intencionalmente y no pueden ser generalizados (por ejemplo, algunos recursos están ausentes en un entorno o en algunas regiones).
A medida de que el proyecto crezca, estos entornos serán más difíciles de mantener actualizados al día unos de otros. Considerar utilizar módulos de infraestructura (estándares o propios) para tareas repetibles.
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.
Perfecta para comenzar y refactorizar a medida que avanzas.
Perfecta para módulos de recurso pequeños.
Bueno para un número pequeño de recursos (menos de 20 o 30).
Contar con un sólo archivo de estado para todos los recursos puede hacer lento el proceso de trabajo con Terraform si el número de recursos está creciendo (considerar el uso del argumento -target
para limitar el número de recursos).
Los ejemplos y módulos de Terraform deberían integrar documentación que describa sus funcionalidades y el cómo utilizarlas.
Enlaces en el sitio web del Terraform Registry son relevantes y no funcionarán, así que hacer uso de rutas absolutas en el README.md.
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.
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.
Perfecta para proyectos en donde la infraestructura está separa lógicamente (cuentas separadas de AWS).
Buena cuando no hay necesidad de modificar recursos compartidos entre las diferentes cuentas de AWS (un entorno = una cuenta AWS = un archivo de estado).
Buena cuando no hay necesidad de orquestación de los cambios entre los entornos.
Buena cuando los recursos de infraestructura son diferentes por entorno intencionalmente y no pueden ser generalizados (por ejemplo, algunos recursos están ausentes en un entorno o en algunas regiones).
A medida de que el proyecto crezca, estos entornos serán más difíciles de mantener actualizados al día unos de otros. Considerar utilizar módulos de infraestructura (estándares o propios) para tareas repetibles.
El presente libro es un intento por describir sistemáticamente las mejores prácticas para el uso de Terraform y proveer de recomendaciones a los problemas más comunes que experimentan sus usuarios.
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.
Siempre quiero recibir comentarios y actualizar este libro a medida que la comunidad madura y se implementan y verifican nuevas ideas con el tiempo.
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.
Fuente:
Cada entorno utiliza diferentes versiones del módulo estándar de infraestructura (alb
) proveniente del -Terraform Registry-.
Fuente:
Bueno para módulos de infraestructura pequeños y lineares (por ejemplo, ).
La documentación puede incluir diagramas creados con **** y planos creados con .
Hacer uso de los **** **** para asegurarse de que el código es válido, de que está en el formato adecuado y está documentado adecuadamente antes de que sea pusheado a git y revisado por una persona.\
**** 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 ).
Se recomienda revisar el para la familiarización con el mismo, y con otros repositorios existentes (por ejemplo, ) en donde está siendo utilizado.
1. .
2. .
3. Publicación de blog por .
Fuente:
Cada entorno utiliza diferentes versiones del módulo estándar de infraestructura (alb) proveniente de -Terraform Registry-.
En proyectos grandes como el aquí descrito, los beneficios de utilizar Terragrunt se hace palpable. Revisar .
Este libro tuvo su comienzo un día soleado de Madrid del 2018, y se encuentra disponible de manera gratuita en
Please if you want to become a sponsor.
Contáctame ( o ) si te gustaría traducirlo.
Si estás interesado en ciertos temas, por favor, , o bien, da tu pulgar arriba en aquel te gustaría que cubriéramos más. Si crees que cuentas con contenido para incluir y te gustaría contribuir, escribe un borrador y envía una pull-request (¡no te preocupes por tener que escribir un buen texto!).
Este libro es mantenido por con la ayuda de varios contribuidores y traductores. Su versión al español es traducida por .