Mucha gente conoce y utiliza Terraform en su trabajo diario, pero aún no se han formado las mejores prácticas al respecto. Cada equipo tiene que inventar sus propios enfoques y métodos.
Es casi seguro que su infraestructura comienza de manera simple: algunos recursos + algunos desarrolladores. Con el tiempo, crece en todo tipo de direcciones. ¿Encuentra formas de agrupar recursos en módulos de Terraform, organizar el código en carpetas y qué más puede salir mal? (últimas palabras famosas)
Pasa el tiempo y sientes que tu infraestructura es tu nueva mascota, pero ¿por qué? Le preocupan los cambios inexplicables en la infraestructura, tiene miedo de tocar la infraestructura y el código; como resultado, retrasa la nueva funcionalidad o reduce la calidad...
Después de tres años de administrar una colección de módulos comunitarios de Terraform para AWS en Github y de mantener Terraform en producción a largo plazo, Anton Babenko está listo para compartir su experiencia: cómo escribir módulos TF para que no duela en el futuro.
Al final de la charla, los participantes estarán más familiarizados con los principios de gestión de recursos en Terraform, las mejores prácticas asociadas con los módulos de Terraform y algunos principios de integración continua asociados con la gestión de infraestructura.
Cláusula de exención de responsabilidades: Observo que este informe tiene fecha de noviembre de 2018; ya han pasado 2 años. La versión de Terraform 0.11 comentada en el informe ya no es compatible. Durante los últimos 2 años, se han lanzado 2 nuevas versiones que contienen muchas innovaciones, mejoras y cambios. Preste atención a esto y consulte la documentación.
Enlaces:
- +
- — código y documentación de formato automático
- — generador de módulos Terraform (WIP)
- — Generador de código Terraform a partir de diagramas visuales (WIP)
- www.terraform-best-practices.com
- (Las nuevas publicaciones están en mi sitio web personal www.antonbabenko.com/)
- @antonbabenko - Twitter y un montón de Slacks diferentes
Mi nombre es Antón Babenko. Algunos de ustedes probablemente usaron el código que escribí. Ahora hablaré de esto con más confianza que nunca, porque tengo acceso a las estadísticas.
Trabajo en Terraform y he sido un participante y colaborador activo en una gran cantidad de proyectos de código abierto relacionados con Terraform y Amazon desde 2015.
Desde entonces, he escrito suficiente código para expresarlo de una manera interesante. E intentaré contarte sobre esto ahora.
Hablaré sobre las complejidades y los detalles de trabajar con Terraform. Pero ese no es realmente el tema de HighLoad. Y ahora entenderás por qué.
Con el tiempo, comencé a escribir módulos Terraform. Los usuarios escribieron preguntas, yo las reescribí. Luego escribí varias utilidades para formatear el código usando un gancho de confirmación previa, etc.
Hubo muchos proyectos interesantes. Me gusta la generación de código porque me gusta que la computadora haga cada vez más trabajo para mí y el programador, por eso actualmente estoy trabajando en un generador de código Terraform a partir de diagramas visuales. Quizás algunos de ustedes los hayan visto. Estas son hermosas cajas con flechas. Y creo que sería genial si pudieras hacer clic en el botón "Exportar" y obtenerlo todo como código.
Soy de Ucrania. He vivido en Noruega durante muchos años.
Además, la información para este informe fue recopilada de personas que conocen mi nombre y me encuentran en las redes sociales. Casi siempre tengo el mismo apodo.
Como mencioné, soy el mantenedor principal de los módulos de Terraform AWS, que es uno de los repositorios más grandes en GitHub donde alojamos módulos para las tareas más comunes: VPC, Autoscaling, RDS.
Y lo que escuchaste ahora es lo más básico. Si duda de entender qué es Terraform, entonces es mejor pasar el tiempo en otro lugar. Habrá muchos términos técnicos aquí. Y no dudé en declarar que el nivel del informe es el más alto. Esto significa que puedo hablar usando todos los términos posibles sin mucha explicación.
Terraform apareció en 2014 como una utilidad que permitía escribir, planificar y gestionar infraestructura como código. El concepto clave aquí es "infraestructura como código".
Toda la documentación, como dije, está escrita en . Espero que la mayoría de la gente conozca este sitio y haya leído la documentación. Si es así, entonces estás en el lugar correcto.
Así es como se ve un archivo de configuración normal de Terraform, donde primero definimos algunas variables.
En este caso definimos "aws_region".
Luego describimos qué recursos queremos crear.
Ejecutamos algunos comandos, en particular "terraform init" para cargar dependencias y proveedores.
Y ejecutamos el comando "terraform apply" para verificar si la configuración especificada coincide con los recursos que creamos. Como no hemos creado nada antes, Terraform nos solicita que creemos estos recursos.
Lo confirmamos. Así creamos un cubo llamado seasnail.
También existen varias utilidades similares. Muchos de los que utilizan Amazon conocen AWS CloudFormation, Google Cloud Deployment Manager o Azure Resource Manager. Cada uno de ellos tiene su propia implementación de algún tipo para administrar recursos dentro de cada uno de estos proveedores de nube pública. Terraform es especialmente útil porque le permite gestionar más de 100 proveedores. (Más detalles )
Los objetivos que Terraform ha perseguido desde el principio:
- Terraform proporciona una vista única de los recursos.
- Le permite admitir todas las plataformas modernas.
- Y Terraform fue diseñado desde el principio como una utilidad que le permite cambiar la infraestructura de forma segura y predecible.
En 2014, la palabra “predecible” sonaba muy inusual en este contexto.
Terraform es una utilidad universal. Si tienes una API, entonces puedes controlar absolutamente todo:
- Podrás utilizar más de 120 proveedores para gestionar todo lo que quieras.
- Por ejemplo, puedes usar Terraform para describir el acceso a los repositorios de GitHub.
- Incluso puedes crear y cerrar errores en Jira.
- Puede gestionar las métricas de New Relic.
- Incluso puedes crear archivos en Dropbox si realmente lo deseas.
Todo esto se logra utilizando proveedores de Terraform, que tienen una API abierta que se puede describir en Go.
Digamos que comenzamos a usar Terraform, leímos documentación en el sitio, miramos algunos videos y comenzamos a escribir main.tf, como mostré en las diapositivas anteriores.
Y todo genial, tienes un archivo que crea una VPC.
Si desea crear una VPC, especifique aproximadamente estas 12 líneas. Describe en qué región deseas crear, qué cidr_block de direcciones IP usar. Eso es todo.
Naturalmente, el proyecto irá creciendo poco a poco.
Y agregará un montón de cosas nuevas allí: recursos, fuentes de datos, se integrará con nuevos proveedores, de repente querrá usar Terraform para administrar usuarios en su cuenta de GitHub, etc. Es posible que desee usar diferentes Proveedores de DNS, cruzan todo. Terraform lo hace fácil.
Veamos el siguiente ejemplo.
Agrega gradualmente internet_gateway porque desea que los recursos de su VPC tengan acceso a Internet. Esta es una buena idea.
El resultado es este main.tf:
Esta es la parte superior de main.tf.
Esta es la parte inferior de main.tf.
Luego agregas la subred. Para cuando desee agregar puertas de enlace NAT, rutas, tablas de enrutamiento y muchas otras subredes, no tendrá 38 líneas, sino aproximadamente 200-300 líneas.
Es decir, su archivo main.tf está creciendo gradualmente. Y muy a menudo la gente pone todo en un solo archivo. Aparecen entre 10 y 20 Kb en main.tf. Imagine que entre 10 y 20 Kb son contenidos de texto. Y todo está conectado con todo. Poco a poco se está volviendo difícil trabajar con esto. 10-20 Kb es un buen caso de usuario, a veces más. Y la gente no siempre piensa que esto es malo.
Como en la programación normal, es decir, no en la infraestructura como código, estamos acostumbrados a usar un montón de clases, paquetes, módulos y agrupaciones diferentes. Terraform te permite hacer prácticamente lo mismo.
- El código está creciendo.
- Las dependencias entre recursos también están creciendo.
Y tenemos una gran, gran necesidad. Entendemos que ya no podemos vivir así. Nuestro código se está volviendo inmenso. Por supuesto, 10-20 Kb no es muy grande, pero estamos hablando solo de la pila de red, es decir, solo ha agregado recursos de red. No estamos hablando de Application Load Balancer, implementación de clúster ES, Kubernetes, etc., donde se pueden incorporar fácilmente 100 Kb. Si escribe todo esto, muy pronto aprenderá que Terraform proporciona módulos Terraform.
Los módulos de Terraform son una configuración de Terraform autónoma que se gestiona como un grupo. Eso es todo lo que necesitas saber sobre los módulos Terraform. No son nada inteligentes, no te permiten realizar conexiones complejas dependiendo de algo. Todo esto recae sobre los hombros de los desarrolladores. Es decir, esto es solo algún tipo de configuración de Terraform que ya ha escrito. Y simplemente puedes llamarlo como grupo.
Así que estamos tratando de entender cómo optimizaremos nuestros 10-20-30 Kb de código. Poco a poco nos vamos dando cuenta de que necesitamos utilizar algunos módulos.
El primer tipo de módulos que encontrará son los módulos de recursos. No entienden de qué se trata su infraestructura, de qué se trata su negocio, dónde y cuáles son las condiciones. Estos son exactamente los módulos que yo, junto con la comunidad de código abierto, administro y que presentamos como los componentes iniciales de su infraestructura.
Un ejemplo de un módulo de recursos.
Cuando llamamos a un módulo de recursos, especificamos desde qué ruta debemos cargar su contenido.
Indicamos qué versión queremos descargar.
Pasamos un montón de argumentos allí. Eso es todo. Eso es todo lo que necesitamos saber cuando usamos este módulo.
Mucha gente piensa que si utilizan la última versión todo será estable. Pero no. La infraestructura debe estar versionada, debemos responder claramente en qué versión se implementó tal o cual componente.
Aquí está el código que se encuentra dentro de este módulo. Módulo de grupo de seguridad. Aquí el pergamino va a la línea 640. Crear un recurso de grupo de seguridad en Amazon en todas las configuraciones posibles no es una tarea trivial. No basta con crear un grupo de seguridad y decirle qué reglas pasarle. Sería muy sencillo. Hay un millón de restricciones diferentes dentro de Amazon. Por ejemplo, si usas Punto final de VPC, lista de prefijos, varias API e intenta combinar todo esto con todo lo demás, entonces Terraform no le permite hacer esto. Y la API de Amazon tampoco lo permite. Por lo tanto, necesitamos ocultar toda esta terrible lógica en un módulo y darle al usuario un código que se parece a este.
El usuario no necesita saber cómo se fabrica por dentro.
El segundo tipo de módulos, que consta de módulos de recursos, ya resuelve problemas que son más aplicables a su negocio. A menudo, este es un lugar que es una extensión de Terraform y establece algunos valores rígidos para las etiquetas, para los estándares de la empresa. También puede agregar allí funciones que Terraform no le permite usar actualmente. Esto es ahora mismo. Ahora la versión 0.11, que está a punto de convertirse en cosa del pasado. Pero aún así, los preprocesadores, jsonnet, cookiecutter y muchas otras cosas son el mecanismo auxiliar que debe usarse para un trabajo completo.
A continuación mostraré algunos ejemplos de esto.
El módulo de infraestructura se llama exactamente de la misma manera.
Se indica la fuente desde donde descargar el contenido.
Se pasan un montón de valores a este módulo.
A continuación, dentro de este módulo, se llama a un conjunto de módulos de recursos para crear una VPC o un balanceador de carga de aplicaciones, o para crear un grupo de seguridad o para un clúster de Elastic Container Service.
Hay dos tipos de módulos. Es importante comprender esto porque la mayor parte de la información que he agrupado en este informe no está escrita en la documentación.
Y la documentación en Terraform en este momento es bastante problemática porque simplemente dice que existen estas características, que puedes usarlas. Pero ella no dice cómo usar estas funciones, ni por qué es mejor usarlas. Por lo tanto, un gran número de personas escriben algo con lo que no pueden vivir.
A continuación, echemos un vistazo a cómo escribir estos módulos. Luego veremos cómo llamarlos y cómo trabajar con el código.
Registro Terraform -
El consejo número 0 es no escribir módulos de recursos. La mayoría de estos módulos ya están escritos para usted. Como dije, son de código abierto, no contienen ninguna lógica de negocios, no tienen valores codificados para direcciones IP, contraseñas, etc. El módulo es muy flexible. Y lo más probable es que ya esté escrito. Hay muchos módulos de recursos de Amazon. Unos 650. Y la mayoría son de buena calidad.
En este ejemplo, alguien se acercó a usted y le dijo: “Quiero poder administrar una base de datos. Crear un módulo para que pueda crear una base de datos." La persona no conoce los detalles de implementación de Amazon o Terraform. Simplemente dice: "Quiero administrar MSSQL". Es decir, queremos decir que llamará a nuestro módulo, pasará allí el tipo de motor e indicará la zona horaria.
Y una persona no debe saber que crearemos dos recursos diferentes dentro de este módulo: uno para MSSQL, el segundo para todo lo demás, solo porque en Terraform 0.11 no se pueden especificar valores de zona horaria como opcionales.
Y al salir de este módulo, una persona podrá simplemente recibir una dirección. No sabrá desde qué base de datos, desde qué recurso estamos creando todo esto internamente. Este es un elemento de ocultación muy importante. Y esto se aplica no sólo a aquellos módulos que son públicos en código abierto, sino también a aquellos módulos que escribirás dentro de tus proyectos y equipos.
Este es el segundo argumento, que es bastante importante si has estado usando Terraform por un tiempo. Tienes un repositorio en el que pones todos los módulos de Terraform para tu empresa. Y es bastante normal que con el tiempo este proyecto crezca hasta alcanzar un tamaño de uno o dos megas. Esto esta bien.
Pero el problema es cómo Terraform llama a estos módulos. Por ejemplo, si llama a un módulo para crear cada usuario individual, Terraform primero cargará todo el repositorio y luego navegará a la carpeta donde se encuentra ese módulo específico. De esta forma descargarás un megabyte cada vez. Si administra 100 o 200 usuarios, descargará 100 o 200 megabytes y luego irá a esa carpeta. Entonces, naturalmente, no querrás descargar un montón de cosas cada vez que presiones "Terraform init".
Hay dos soluciones para este problema. La primera es utilizar rutas relativas. De esta forma indicas en el código que la carpeta es local (./). Y antes de iniciar cualquier cosa, realiza una clonación Git de este repositorio localmente. De esta manera lo haces una vez.
Por supuesto, hay muchas desventajas. Por ejemplo, no puedes usar el control de versiones. Y a veces es difícil vivir con esto.
Segunda solución. Si tiene muchos submódulos y ya tiene algún tipo de canalización establecida, entonces está el proyecto MBT, que le permite recopilar muchos paquetes diferentes de un monorepositorio y cargarlos en S3. Esta es una muy buena manera. Así, el archivo iam-user-1.0.0.zip pesará sólo 1 Kb, porque el código para crear este recurso es muy pequeño. Y funcionará mucho más rápido.
Hablemos de lo que no se puede usar en los módulos.
¿Por qué ocurre este mal en los módulos? Lo peor es asumir usuario. Supongamos que el usuario es una opción de autenticación del proveedor que pueden utilizar diferentes personas. Por ejemplo, todos asimilaremos el rol. Esto significa que Terraform asumirá este papel. Y luego con este rol realizará otras acciones.
Y lo malo es que si a Vasya le gusta conectarse a Amazon de una manera, por ejemplo, usando la variable de entorno predeterminada, y a Petya le gusta usar su clave compartida, que tiene en un lugar secreto, entonces no puedes especificar ambas en Terraformar. Y para que no experimenten sufrimiento, no es necesario indicar este bloque en el módulo. Esto debe indicarse a un nivel superior. Es decir, tenemos un módulo de recursos, un módulo de infraestructura y una composición encima. Y esto debería indicarse en algún lugar más alto.
El segundo mal es el aprovisionador. Aquí el mal no es tan trivial, porque si escribes código y te funciona, entonces puedes pensar que si funciona, entonces para qué cambiarlo.
El problema es que, en primer lugar, no siempre se controla cuándo se lanzará este aprovisionador. Y en segundo lugar, usted no controla lo que significa aws ec2, es decir, ahora estamos hablando de Linux o Windows. Por lo tanto, no se puede escribir algo que funcione igual en diferentes sistemas operativos o para diferentes casos de usuario.
El ejemplo más común, que también se indica en la documentación oficial, es que si escribe aws_instance y especifica un montón de argumentos, entonces no hay nada de malo en eso si especifica el aprovisionador "local-exec" allí y ejecuta su ansible- libro de jugadas.
De hecho, sí, no hay nada de malo en eso. Pero, literalmente, pronto te darás cuenta de que esta cosa de ejecución local no existe, por ejemplo, en launch_configuration.
Y cuando usa launch_configuration y desea crear un grupo de escalado automático a partir de una instancia, en launch_configuration no existe el concepto de "aprovisionador". Existe el concepto de “datos de usuario”.
Por tanto, una solución más universal es utilizar los datos del usuario. Y se iniciará en la instancia misma, cuando la instancia esté activada, o en los mismos datos de usuario, cuando el grupo de escalado automático use esta configuración de lanzamiento.
Si aún desea ejecutar el aprovisionador, porque es un componente de pegado, cuando se crea un recurso, en ese momento necesita ejecutar su aprovisionador, su comando. Hay muchas situaciones de este tipo.
Y el recurso más correcto para esto se llama null_resource. Null_resource es un recurso ficticio que en realidad nunca se crea. No toca nada, ni API, ni escalado automático. Pero te permite controlar cuándo ejecutar el comando. En este caso, el comando se ejecuta durante la creación.
Enlace
Hay varias señales. No entraré en todos los signos en gran detalle. Hay un artículo sobre esto. Pero si ha trabajado con Terraform o ha utilizado módulos de otras personas, a menudo habrá notado que muchos módulos, como la mayor parte del código de código abierto, están escritos por personas para sus propias necesidades. Un hombre lo escribió y resolvió su problema. Lo guardé en GitHub, lo dejé vivir. Vivirá, pero si no hay documentación ni ejemplos allí, nadie lo usará. Y si no existe una funcionalidad que te permita resolver un poco más que su tarea específica, entonces nadie la utilizará tampoco. Hay tantas formas de perder usuarios.
Si quieres escribir algo para que la gente lo use, te recomiendo seguir estas señales.
Son los siguientes:
- Documentación y ejemplos.
- Funcionalidad completa.
- Valores predeterminados razonables.
- Código limpio.
- Pruebas.
Las pruebas son una situación diferente porque son bastante difíciles de escribir. Creo más en la documentación y los ejemplos.
Entonces, vimos cómo escribir módulos. Hay dos argumentos. La primera, que es la más importante, es no escribir si puedes, porque mucha gente ya ha hecho estas tareas antes que tú. Y en segundo lugar, si aún así lo decide, intente no utilizar proveedores en módulos y aprovisionadores.
Esta es la parte gris de la documentación. Quizás ahora estés pensando: “Algo no está claro. No convencido." Pero ya veremos en seis meses.
Ahora hablemos de cómo llamar a estos módulos.
Entendemos que nuestro código crece con el tiempo. Ya no tenemos un archivo, ya tenemos 20 archivos. Están todos en una carpeta. O tal vez en cinco carpetas. Quizás estemos empezando a desglosarlos de alguna manera por región, por algunos componentes. Entonces entendemos que ahora tenemos algunos rudimentos de sincronización y orquestación. Es decir, debemos entender qué debemos hacer si cambiamos los recursos de la red, qué debemos hacer con el resto de nuestros recursos, cómo provocar estas dependencias, etc.
Hay dos extremos. El primer extremo es todo en uno. Tenemos un archivo maestro. Por el momento, esta era la mejor práctica oficial en el sitio web de Terraform.
Pero ahora está escrito como obsoleto y eliminado. Con el tiempo, la comunidad de Terraform se dio cuenta de que esto estaba lejos de ser la mejor práctica, porque la gente comenzó a utilizar el proyecto de diferentes maneras. Y hay problemas. Por ejemplo, cuando enumeramos todas las dependencias en un solo lugar. Hay situaciones en las que hacemos clic en “Plan Terraform” y hasta que Terraform actualice los estados de todos los recursos, puede pasar mucho tiempo.
Mucho tiempo son, por ejemplo, 5 minutos. Para algunos esto es mucho tiempo. He visto casos en los que tomó 15 minutos. La API de AWS pasó 15 minutos intentando descubrir qué estaba pasando con el estado de cada recurso. Ésta es un área muy grande.
Y, naturalmente, aparecerá un problema relacionado cuando quieras cambiar algo en un lugar, luego esperas 15 minutos y te da un panorama de algunos cambios. Escupiste, escribiste "Sí" y algo salió mal. Este es un ejemplo muy real. Terraform no intenta protegerte de los problemas. Es decir, escribe lo que quieras. Habrá problemas, tus problemas. Si bien Terraform 0.11 no intenta ayudarlo de ninguna manera. Hay ciertos lugares interesantes en 0.12 que te permiten decir: "Vasya, realmente quieres esto, ¿puedes entrar en razón?"
La segunda forma es reducir esta área, es decir, las llamadas de un lugar pueden estar menos conectadas desde otro lugar.
El único problema es que necesita escribir más código, es decir, necesita describir variables en una gran cantidad de archivos y actualizarlo. A algunas personas no les gusta. Esto es normal para mí. Y algunas personas piensan: "¿Por qué escribir esto en diferentes lugares? Lo pondré todo en un solo lugar". Esto es posible, pero es el segundo extremo.
¿Quién tiene todo esto viviendo en un solo lugar? Una, dos, tres personas, es decir, alguien lo está usando.
¿Y quién llama a un determinado componente, a un bloque o a un módulo de infraestructura? De cinco a siete personas. Esto es genial.
La respuesta más común está en algún punto intermedio. Si el proyecto es grande, a menudo se encontrará con una situación en la que ninguna solución es adecuada y no todo funciona, por lo que terminará con una mezcla. No hay nada de malo en esto, siempre y cuando comprendas que ambos tienen ventajas.
Si algo cambió en la VPC de pila y deseaba aplicar estos cambios a EC2, es decir, deseaba actualizar el grupo de escalado automático porque tenía una nueva subred, entonces llamo a este tipo de orquestación de dependencia. Hay algunas soluciones: ¿quién usa qué?
Puedo sugerir qué soluciones hay. Puedes usar Terraform para hacer la magia, o puedes usar archivos MAKE para usar Terraform. Y vea si algo ha cambiado allí, puede iniciarlo aquí.
¿Qué te parece esta decisión? ¿Alguien cree que esta es una buena solución? Veo una sonrisa, aparentemente han surgido dudas.
Por supuesto, no intentes esto en casa. Terraform nunca fue diseñado para ejecutarse desde Terraform.
En un informe me dijeron: “No, esto no funcionará”. El caso es que no debería funcionar. Aunque parece tan impresionante cuando puedes iniciar Terraform desde Terraform y luego Terraform, no deberías hacerlo. Terraform siempre debería iniciarse muy fácilmente.
Si necesita orquestación de llamadas cuando algo ha cambiado en un lugar, entonces está Terragrunt.
Terragrunt es una utilidad, un complemento de Terraform, que le permite coordinar y orquestar llamadas a módulos de infraestructura.
Un archivo de configuración típico de Terraform tiene este aspecto.
Usted especifica qué módulo específico desea llamar.
¿Qué dependencias tiene el módulo?
Y qué argumentos acepta este módulo. Eso es todo lo que hay que saber sobre Terragrunt.
La documentación está ahí y hay 1 estrellas en GitHub. Pero en la mayoría de los casos esto es lo que necesita saber. Y esto es muy fácil de implementar en empresas que recién comienzan a trabajar con Terraform.
Entonces la orquestación es Terragrunt. Hay otras opciones.
Ahora hablemos de cómo trabajar con el código.
Si necesita agregar nuevas funciones a su código, en la mayoría de los casos esto es fácil. Estás escribiendo un nuevo recurso, todo es sencillo.
Si tiene algún recurso que creó con anticipación, por ejemplo, conoció Terraform después de abrir una cuenta de AWS y desea utilizar los recursos que ya tiene, entonces sería apropiado ampliar su módulo de esta manera, para que apoya el uso de los recursos existentes.
Y apoyó la creación de nuevos recursos utilizando el recurso de bloque.
En la salida siempre devolvemos la identificación de salida dependiendo de lo que se usó.
El segundo problema muy importante de Terraform 0.11 es el trabajo con listas.
La dificultad es que si tenemos esa lista de usuarios.
Y cuando creamos estos usuarios usando recursos de bloque, todo va bien. Repasamos toda la lista, creando un archivo para cada uno. Todo esta bien. Y luego, por ejemplo, el usuario3, que está en el medio, debe eliminarse de aquí, luego todos los recursos que se crearon después de él se recrearán porque el índice cambiará.
Trabajar con listas en un entorno con estado. ¿Qué es un entorno con estado? Esta es la situación en la que se crea un nuevo valor cuando se crea este recurso. Por ejemplo, AWS Access Key o AWS Secret Key, es decir, cuando creamos un usuario, recibimos una nueva Clave de Acceso o Secreta. Y cada vez que eliminemos un usuario, este usuario tendrá una nueva clave. Pero esto no es feng shui, porque el usuario no querrá ser nuestro amigo si le creamos un nuevo usuario cada vez que alguien deja el equipo.
Esta es la solución. Este es un código escrito en Jsonnet. Jsonnet es un lenguaje de plantillas de Google.
Este comando le permite aceptar esta plantilla y como salida devuelve un archivo json creado de acuerdo con su plantilla.
La plantilla se ve así.
Terraform te permite trabajar con HCL y Json de la misma manera, por lo que si tienes la capacidad de generar Json, puedes introducirlo en Terraform. El archivo con la extensión .tf.json se descargará correctamente.
Y luego trabajamos con él como siempre: terraform init, terramorm apply. Y creamos dos usuarios.
Ahora no tenemos miedo si alguien deja el equipo. Simplemente editaremos el archivo json. Vasya Pupkin se fue, Petia Pyatochkin se quedó. Petya Pyatochkin no recibirá una nueva clave.
Integrar Terraform con otras herramientas no es realmente trabajo de Terraform. Terraform fue creado como una plataforma para crear recursos y eso es todo. Y todo lo que surja después no es asunto de Terraform. Y no es necesario tejerlo allí. Está Ansible, que hace todo lo que necesitas.
Pero surgen situaciones en las que queremos extender Terraform y llamar a algún comando después de que algo se haya completado.
Primera manera. Creamos una salida donde escribimos este comando.
Y luego llamamos a este comando desde la salida de terraform del shell y especificamos el valor que queremos. Así, el comando se ejecuta con todos los valores sustituidos. Es muy cómodo.
Segunda vía. Este es el uso de null_resource dependiendo de los cambios en nuestra infraestructura. Podemos llamar al mismo exe local tan pronto como cambie el ID de algún recurso.
Naturalmente, todo esto es sencillo sobre el papel, porque Amazon, como todos los demás proveedores públicos, tiene muchos de sus propios casos extremos.
El caso extremo más común es que cuando abre una cuenta de AWS, importa qué regiones utilice; ¿Está habilitada esta función allí? tal vez lo abriste después de diciembre de 2013; tal vez esté utilizando el valor predeterminado en VPC, etc. Hay muchas restricciones. Y Amazon los dispersó por toda la documentación.
Hay algunas cosas que recomiendo evitar.
Para empezar, evite todos los argumentos que no sean secretos dentro del plan Terraform o la CLI de Terraform. Todo esto se puede poner en un archivo tfvars o en una variable de entorno.
Pero no es necesario que memorices toda esta orden mágica. Plan Terraform – var y listo. La primera variable es var, la segunda variable es var, la tercera, la cuarta. El principio más importante de la infraestructura como código que uso con más frecuencia es que con solo mirar el código, debería tener una comprensión clara de lo que se implementa allí, en qué estado y con qué valores. Y así no tengo que leer la documentación ni preguntarle a Vasya qué parámetros utilizó para crear nuestro clúster. Solo necesito abrir un archivo con la extensión tfvars, que a menudo coincide con el entorno, y mirar todo lo que hay allí.
Además, no utilice argumentos de destino para reducir el alcance. Para ello es mucho más fácil utilizar pequeños módulos de infraestructura.
Además, no es necesario limitar ni aumentar el paralelismo. Si tengo 150 recursos y quiero aumentar el paralelismo de Amazon del valor predeterminado de 10 a 100, lo más probable es que algo salga mal. O podría ir bien ahora, pero cuando Amazon diga que estás haciendo demasiadas llamadas, estarás en problemas.
Terraform intentará reiniciar la mayoría de estos problemas, pero no logrará casi nada. Paralelismo=1 es algo importante que puedes usar si encuentras algún error dentro de la API de AWS o dentro del proveedor Terraform. Y luego debe especificar: paralelismo = 1 y esperar hasta que Terraform finalice una llamada, luego la segunda y luego la tercera. Los lanzará uno por uno.
La gente suele preguntarme: "¿Por qué creo que los espacios de trabajo de Terraform son malos?" Creo que el principio de la infraestructura como código es ver qué infraestructura se ha creado y con qué valores.
Los espacios de trabajo no fueron creados por los usuarios. Esto no significa que los usuarios escribieran en GitHub cuestiones de que no podemos vivir sin los espacios de trabajo de Terraform. No, no así. Terraform Enterprise es una solución comercial. Terraform de HashiCorp decidió que necesitábamos espacios de trabajo, así que los archivamos. Me resulta mucho más fácil ponerlo en una carpeta separada. Luego habrá un poco más de archivos, pero quedará más claro.
¿Cómo trabajar con el código? De hecho, trabajar con listas es la única molestia. Y tome Terraform más fácilmente. Esto no es lo que hará todo genial por ti. No es necesario guardar allí todo lo que está escrito en la documentación.
El tema del informe fue escrito "para el futuro". Hablaré de esto muy brevemente. Para el futuro, esto significa que pronto se lanzará la versión 0.12.
0.12 es un montón de cosas nuevas. Si viene de la programación habitual, se perderá todo tipo de bloques dinámicos, bucles, operaciones de comparación correctas y condicionales, donde los lados izquierdo y derecho no se calculan simultáneamente, sino según la situación. Lo extrañas mucho, así que 0.12 lo resolverá por ti.
¡Pero! Si escribe cada vez de forma más sencilla, utilizando módulos ya preparados y soluciones de terceros, no tendrá que esperar a que llegue 0.12 y solucione todo por usted.
¡Gracias por el informe! Hablaste de infraestructura como código y literalmente dijiste una palabra sobre pruebas. ¿Se necesitan pruebas en los módulos? ¿De quién es esta responsabilidad? ¿Necesito escribirlo yo mismo o es responsabilidad de los módulos?
El próximo año estará lleno de informes de que hemos decidido probarlo todo. Qué probar es la pregunta más importante. Hay muchas dependencias, muchas restricciones de diferentes proveedores. Cuando tú y yo estamos hablando y dices: "Necesito pruebas", entonces te pregunto: "¿Qué vas a probar?". Dices que harás la prueba en tu región. Entonces digo que esto no funciona en mi región. Es decir, ni siquiera podremos ponernos de acuerdo en esto. Sin mencionar que hay muchos problemas técnicos. Es decir, cómo escribir estas pruebas para que sean las adecuadas.
Estoy investigando activamente este tema, es decir, cómo generar pruebas automáticamente en función de la infraestructura que usted escribió. Es decir, si escribiste este código, entonces necesito ejecutarlo, en base a esto puedo crear pruebas.
es una de las bibliotecas mencionadas con más frecuencia que le permite escribir pruebas de integración para Terraform. Esta es una de las utilidades. Prefiero el tipo DSL, por ejemplo, rspec.
Antón, gracias por el informe! Mi nombre es Valéry. Déjame hacerte una pequeña pregunta filosófica. Hay, condicionalmente, aprovisionamiento, hay despliegue. El aprovisionamiento crea mi infraestructura, en la implementación la llenamos con algo útil, por ejemplo, servidores, aplicaciones, etc. Y está en mi cabeza que Terraform es más para el aprovisionamiento y Ansible es más para la implementación, porque Ansible también es para la infraestructura física. le permite instalar nginx, Postgres. Pero al mismo tiempo, Ansible parece permitir el aprovisionamiento, por ejemplo, de recursos de Amazon o Google. Pero Terraform también le permite implementar algún software utilizando sus módulos. Desde su punto de vista, ¿existe algún tipo de frontera entre Terraform y Ansible, dónde y qué es mejor usar? ¿O por ejemplo crees que Ansible ya es basura, deberías intentar usar Terraform para todo?
Buena pregunta, Valéry. Creo que Terraform no ha cambiado en términos de propósito desde 2014. Fue creado para la infraestructura y murió por la infraestructura. Todavía teníamos y tendremos la necesidad de gestionar la configuración de Ansible. El desafío es que hay datos de usuario dentro de launch_configuration. Y ahí tiras Ansible, etc. Esta es la distinción estándar que más me gusta.
Si hablamos de una hermosa infraestructura, entonces existen utilidades como Packer que recopilan esta imagen. Y luego Terraform usa la fuente de datos para encontrar esta imagen y actualizar su configuración de lanzamiento. Es decir, de esta manera la canalización es que primero extraemos Tracker y luego extraemos Terraform. Y si se produce una compilación, se produce un nuevo cambio.
¡Hola! ¡Gracias por el informe! Mi nombre es Misha, empresa RBS. Puede llamar a Ansible a través del aprovisionador al crear un recurso. Ansible también tiene un tema llamado inventario dinámico. Y primero puede llamar a Terraform y luego a Ansible, que tomará recursos del estado y los ejecutará. ¿Que es mejor?
La gente usa ambos con igual éxito. Me parece que el inventario dinámico en Ansible es algo conveniente, si no estamos hablando de un grupo de escalado automático. Porque en el grupo de ajuste de escala automático ya tenemos nuestro propio conjunto de herramientas, que se llama launch_configuration. En launch_configuration registramos todo lo que debe iniciarse cuando creamos un nuevo recurso. Por lo tanto, con Amazon, usar inventario dinámico y leer el archivo Terraform ts, en mi opinión, es excesivo. Y si usa otras herramientas donde no existe el concepto de "grupo de escala automática", por ejemplo, usa DigitalOcean o algún otro proveedor donde no hay un grupo de escala automática, entonces tendrá que extraer manualmente la API, buscar direcciones IP, crear un archivo de inventario dinámico y Ansible ya lo revisará. Es decir, para Amazon existe launch_configuration y para todo lo demás existe inventario dinámico.
Fuente: habr.com