Parecería que los desarrolladores de Terraform ofrecen mejores prácticas bastante convenientes para trabajar con la infraestructura de AWS. Solo hay un matiz. Con el tiempo, aumenta la cantidad de entornos, aparecen características en cada uno. Aparece casi una copia de la pila de aplicaciones en la región vecina. Y el código de Terraform debe copiarse y editarse cuidadosamente de acuerdo con los nuevos requisitos o para hacer un copo de nieve.
Mi informe trata sobre patrones en Terraform para combatir el caos y la rutina manual en proyectos grandes y largos.
Vídeo:
Tengo 40 años, he estado en TI durante 20 años. Trabajo en Ixtens desde hace 12 años. Estamos comprometidos con el desarrollo impulsado por el comercio electrónico. Y he estado practicando prácticas DevOps durante 5 años.
Mi relato versará sobre la experiencia en un proyecto en una empresa cuyo nombre no diré, escondiéndose detrás de un acuerdo de confidencialidad.
Los números en la diapositiva se dan para comprender el alcance del proyecto. Y todo lo que voy a decir a continuación está relacionado con Amazon.
Me uní a este proyecto hace 4 años. Y la refactorización de infraestructura estaba en pleno apogeo, porque el proyecto había crecido. Y esos patrones que se usaban, ya no encajan. Y dado todo el crecimiento planificado del proyecto, era necesario pensar en algo nuevo.
Gracias a Matvey, que ayer nos contó lo que pasó en Dodo Pizza. Esto es lo que nos pasó hace 4 años.
Los desarrolladores llegaron y comenzaron a crear código de infraestructura.
Las razones más obvias por las que esto fue necesario fue el tiempo de comercialización. Era necesario asegurarse de que el equipo de DevOps no fuera un cuello de botella durante el despliegue. Y entre otras cosas, Terraform y Puppet se usaron en el primer nivel.
Terraform es un proyecto de código abierto de HashiCorp. Y para aquellos que no saben lo que es, las siguientes diapositivas.
Infraestructura como código significa que podemos describir nuestra infraestructura y pedirle a algunos robots que se aseguren de obtener los recursos que describimos.
Por ejemplo, necesitamos una máquina virtual. Describiremos, agregaremos algunos parámetros requeridos.
Después de eso, configuraremos el acceso a Amazon en la consola. Y pregunta por el plan Terraform. El plan Terraform dirá: "Ok, para su recurso, podemos hacer estas cosas". Y se agregará al menos un recurso. Y no se esperan cambios.
Después de que todo le convenga, puede solicitar la aplicación de Terraform y Terraform creará una instancia para usted, y obtendrá una máquina virtual en su nube.
Además, nuestro proyecto se desarrolla. Estamos agregando algunos cambios allí. Pedimos más instancias, agregamos 53 entradas.
Y repetimos. Por favor planifique. Vemos qué cambios están previstos. Aplicar. Y así crece nuestra infraestructura.
Terraform usa archivos de estado. Es decir, guarda todos los cambios que van a Amazon en un archivo, donde para cada recurso que describiste, hay recursos correspondientes que se crearon en Amazon. Por lo tanto, al cambiar la descripción de un recurso, Terraform sabe exactamente qué se debe cambiar en Amazon.
Estos archivos de estado originalmente eran solo archivos. Y los almacenamos en Git, lo cual fue extremadamente inconveniente. Constantemente alguien se olvidaba de realizar cambios y había muchos conflictos.
Ahora es posible usar el backend, es decir, Terraform se indica en qué cubo, con qué clave se debe guardar el archivo de estado. Y Terraform mismo se encargará de obtener este archivo de estado, haciendo toda la magia y volviendo a colocar el resultado final.
Nuestra infraestructura está creciendo. Aquí está nuestro código. Y ahora no queremos simplemente crear una máquina virtual, queremos tener un entorno de prueba.
Terraform le permite crear algo como un módulo, es decir, describir lo mismo en alguna carpeta.
Y, por ejemplo, en testing, llamar a este módulo y obtener lo mismo que si estuviéramos haciendo Terraform apply en el propio módulo. Aquí está el código para probar.
Para producción, podemos enviar algunos cambios allí, porque en las pruebas no necesitamos instancias grandes, en producción, las instancias grandes serán útiles.
Y luego volveré al proyecto. Fue una tarea difícil, la infraestructura fue planeada muy grande. Y era necesario colocar de alguna manera todo el código para que fuera conveniente para todos: para quienes realizan el mantenimiento de este código y para quienes realizan cambios. Y se planeó que cualquier desarrollador pudiera ir y arreglar la infraestructura según fuera necesario para su parte de la plataforma.
Este es un árbol de directorios recomendado por HashiCorp si tiene un proyecto grande y tiene sentido dividir toda la infraestructura en algunas partes pequeñas y describir cada parte en una carpeta separada.
Al tener una biblioteca de recursos extensa, puede llamar sobre lo mismo en pruebas y en producción.
En nuestro caso, esto no era del todo adecuado, porque la pila de prueba para desarrolladores o para pruebas debía obtenerse de alguna manera más simple. Y no quería revisar las carpetas y aplicar en la secuencia correcta, y preocuparme de que la base suba, y luego la instancia que usa esta base suba. Por lo tanto, todas las pruebas se iniciaron desde una carpeta. Allí se llamaron los mismos módulos, pero todo pasó de una vez.
Terraform se encarga de todas las dependencias. Y siempre crea recursos en esa secuencia para que pueda obtener una dirección IP, por ejemplo, de una instancia recién creada, y obtener esta dirección IP en la entrada route53.
Además, la plataforma es muy grande. Y ejecutar una pila de prueba, incluso durante una hora, incluso durante 8 horas, es un negocio bastante costoso.
Y hemos automatizado este negocio. Y el trabajo de Jenkins permitió que la pila se ejecutara. Era necesario lanzar una solicitud de extracción en él con los cambios que el desarrollador desea probar, especificar todas las opciones, componentes y dimensiones necesarias. Si quiere pruebas de rendimiento, entonces puede tomar más instancias. Si solo necesita comprobar que se abre algún formulario, podría empezar por el mínimo. Y también indicar si se necesita un clúster o no, etc.
Y luego Jenkins empujó un script de shell que modificó ligeramente el código en la carpeta Terraform. Se eliminaron los archivos innecesarios, se agregaron los archivos necesarios. Y luego, con una aplicación de Terraform, la pila aumentó.
Y luego hubo otros pasos en los que no quiero entrar.
Debido al hecho de que para las pruebas necesitábamos un poco más de opciones que en producción, tuvimos que hacer copias de los módulos para que en estas copias pudiéramos agregar aquellas funciones que se necesitan solo en las pruebas.
Y sucedió que en las pruebas, parece que desea probar esos cambios que eventualmente pasarán a producción. Pero, de hecho, se probó una cosa y se usó un poco diferente en la producción. Y hubo una pequeña ruptura en el patrón de que en producción todos los cambios los aplicaba el equipo de operaciones. Y a veces resultaba que esos cambios que se suponía iban a pasar de testing a producción, se quedaban en otra versión.
Además, hubo tal problema que se agregó un nuevo servicio, que era ligeramente diferente de algunos ya existentes. Y en lugar de modificar un módulo existente, tenía que hacer una copia y agregar los cambios necesarios.
De hecho, Terraform no es un lenguaje real. Esta es una declaración. Si necesitamos declarar algo, entonces lo declaramos. Y todo funciona.
En algún momento, al hablar de una de mis solicitudes de extracción, uno de mis colegas dijo que no es necesario producir copos de nieve. Me pregunté qué quería decir. Existe un hecho tan científico que en el mundo no hay dos copos de nieve idénticos, todos son ligeramente, pero diferentes. Y tan pronto como escuché esto, inmediatamente sentí todo el peso del código Terraform. Porque cuando fue necesario pasar de una versión a otra, Terraform requirió un cambio de cadena de ruptura, es decir, el código ya no era compatible con la siguiente versión. Y tuve que hacer una solicitud de extracción, que cubría casi la mitad de los archivos en la infraestructura, para llevar la infraestructura a la próxima versión de Terraform.
Y después de que apareciera ese copo de nieve, todo el código de Terraform que habíamos convertido en un gran montón de nieve.
Para un desarrollador externo que está fuera de operación, no le importa mucho, porque hizo una solicitud de extracción, comenzó su recurso. Y eso es todo, no es asunto suyo. Y el equipo de DevOps que se asegura de que todo esté bien debe realizar todos estos cambios. Y el costo de estos cambios aumentó muchísimo con cada copo de nieve adicional.
Hay una historia sobre cómo un estudiante en un seminario dibuja dos círculos perfectos con tiza en una pizarra. Y el maestro se sorprende de cómo logró dibujar tan suavemente sin compás. El estudiante responde: "Es muy simple, hice una picadora de carne durante dos años en el ejército".
Y de los cuatro años que he estado en este proyecto, he estado haciendo Terraform durante unos dos años. Y, por supuesto, tengo algunos trucos, algunos consejos sobre cómo simplificar el código de Terraform, trabajar con él como un lenguaje de programación y reducir la carga de los desarrolladores que deben mantener este código actualizado.
Lo primero con lo que me gustaría comenzar son los enlaces simbólicos. Terraform tiene mucho código repetitivo. Por ejemplo, llamar a un proveedor en casi todos los puntos donde creamos una infraestructura es lo mismo. Y es lógico ponerlo en un papi aparte. Y siempre que se requiera que el proveedor haga Symlinks a este archivo.
Por ejemplo, utiliza asumir un rol en producción, lo que le permite obtener derechos de acceso a alguna cuenta externa de Amazon. Y al cambiar un archivo, todos los restantes que están en el árbol de recursos tendrán los derechos necesarios para que Terraform sepa a qué segmento de Amazon acceder.
¿Dónde no funcionan los enlaces simbólicos? Como dije, Terraform tiene archivos de estado. Y son muy, muy geniales. Pero el hecho es que Terraform inicializa el backend en el primero. Y no puede usar ninguna variable en estos parámetros, siempre deben escribirse en texto.
Y como resultado, cuando alguien crea un nuevo recurso, copia parte del código de otras carpetas. Y puede equivocarse con la llave o con el balde. Por ejemplo, hace una caja de arena a partir de una caja de arena y luego la hace en producción. Y entonces puede resultar que el balde en producción se use desde la caja de arena. Por supuesto, lo encontrarán rápidamente. Será posible arreglar esto de alguna manera, pero sin embargo es una pérdida de tiempo y, hasta cierto punto, de recursos.
¿Qué podemos hacer a continuación? Antes de trabajar con Terraform, debe inicializarlo. En el momento de la inicialización, Terraform descarga todos los complementos. En algún momento, pasaron de ser un monolito a una arquitectura de microservicios. Y siempre necesita hacer Terraform init para que abra todos los módulos, todos los complementos.
Y puede usar un script de shell que, en primer lugar, puede obtener todas las variables. Shell script es ilimitado. Y, en segundo lugar, el camino. Si siempre usamos la ruta que está en el repositorio como clave para el archivo de estado, entonces, en consecuencia, el error se excluirá aquí.
¿Dónde obtener datos? archivo JSON. Terraform le permite escribir infraestructura no solo en hcl (lenguaje de configuración de HashiCorp), sino también en JSON.
JSON es fácil de leer desde un script de shell. En consecuencia, puede colocar un archivo de configuración con un depósito en algún lugar. Y use este depósito tanto en el código de Terraform como en el script de shell para la inicialización.
¿Por qué es importante tener un balde Terraform? Porque existen los archivos de estado remoto. Es decir, cuando levanto algún recurso, para decirle a Amazon: "Por favor, levante la instancia", necesito especificar muchos parámetros requeridos.
Y estos identificadores se almacenan en alguna otra carpeta. Y puedo tomarlo y decir: "Terraform, vaya al archivo de estado de ese mismo recurso y consígame estos identificadores". Y así hay una especie de unificación entre diferentes regiones o ambientes.
No siempre es posible utilizar un archivo de estado remoto. Por ejemplo, creó manualmente una VPC. Y el código de Terraform que crea la VPC crea una VPC tan diferente que lleva mucho tiempo y tienes que ajustar una a la otra, así que puedes usar el siguiente truco.
Es decir, hacer un módulo que, por así decirlo, haga VPC y le proporcione identificadores, pero de hecho solo hay un archivo con valores codificados que se pueden usar para crear la misma instancia.
No siempre es necesario guardar el archivo de estado en la nube. Por ejemplo, al probar módulos, puede usar la inicialización de back-end, cuando el archivo se guardará solo en el disco en el momento de la prueba.
Ahora un poco sobre las pruebas. ¿Qué se puede probar en Terraform? Probablemente, mucho es posible, pero hablaré sobre estas 4 cosas.
HashiCorp sabe cómo formatear el código de Terraform. Y Terraform fmt le permite formatear el código que edita de acuerdo con esa creencia. En consecuencia, las pruebas deben verificar necesariamente si el formato coincide con lo que legó HashiCorp, para que no tenga que cambiar la ubicación de los corchetes, etc.
El siguiente es la validación de Terraform. Hace un poco más que una verificación de sintaxis: por desgracia, todos los corchetes están emparejados. ¿Qué es importante aquí? Tenemos una infraestructura muy delgada. Tiene muchas carpetas diferentes. Y en cada uno necesita ejecutar la validación de Terraform.
En consecuencia, para acelerar las pruebas, ejecutamos varios procesos en paralelo usando paralelo.
Parallel es algo muy bueno, úsalo.
Pero cada vez que se inicializa Terraform, va a HashiCorp y pregunta: “¿Cuáles son los complementos más recientes? Y el complemento que tengo en el caché, ¿es el indicado o no? Y se ralentizaba a cada paso.
Si Terraform le dice dónde están los complementos, Terraform dirá: “OK, esto es probablemente lo más nuevo que existe. No iré a ningún lado, comenzaré a validar tu código Terraform de inmediato".
Para llenar la carpeta con los complementos necesarios, tenemos un código Terraform muy simple que solo necesita inicializarse. Aquí, por supuesto, debe especificar todos los proveedores que de alguna manera participan en su código; de lo contrario, Terraform dirá: "No conozco ningún proveedor, porque no está en el caché".
El siguiente es el plan Terraform. Como dije, el desarrollo es cíclico. Hacemos código con cambios. Y luego debe averiguar qué cambios se planean para la infraestructura.
Y cuando la infraestructura es muy, muy grande, puede cambiar un módulo, arreglar algún entorno de prueba o alguna región específica y romper algún vecino. Por lo tanto, se debe hacer un plan Terraform para toda la infraestructura y mostrar qué cambios se planean.
Puedes hacerlo de manera inteligente. Por ejemplo, escribimos un script de Python que resuelve las dependencias. Y dependiendo de lo que se haya cambiado: un módulo de Terraform o simplemente un componente específico, hace planes para todas las carpetas dependientes.
El plan Terraform se debe hacer a pedido. Al menos eso es lo que hacemos.
Las pruebas, por supuesto, son buenas para cada cambio, para cada compromiso, pero los planes son algo bastante costoso. Y decimos en la solicitud de extracción: "Por favor, dame los planos". El robot comienza. Y envía a los comentarios o para adjuntar todos los planos que se esperan de tus cambios.
El plan es algo bastante caro. Lleva tiempo porque Terraform va a Amazon y pregunta: "¿Todavía existe esta instancia? ¿Este escalado automático tiene exactamente los mismos parámetros?”. Y para acelerarlo, puede usar un parámetro como refresh=false. Esto significa que Terraform desinflará el estado S3. Y creerá que el estado coincidirá exactamente con lo que hay en Amazon.
Tal plan de Terraform es mucho más rápido, pero el estado debe coincidir con su infraestructura, es decir, en algún lugar, en algún momento debe comenzar la actualización de Terraform. La actualización de Terraform hace exactamente eso, de modo que el estado se corresponde con lo que hay en la infraestructura real.
Y debo decir sobre la seguridad. Aquí es donde debería haber comenzado. Donde ejecuta Terraform y Terraform funciona con su infraestructura, existe una vulnerabilidad. Es decir, básicamente estás ejecutando código. Y si la solicitud de extracción contiene algún tipo de código malicioso, puede ejecutarse en una infraestructura que tiene demasiado acceso. Por lo tanto, tenga cuidado donde lanza el plan Terraform.
Lo siguiente de lo que me gustaría hablar es sobre las pruebas de datos de usuario.
¿Qué son los datos de usuario? En Amazon, cuando creamos una instancia, podemos enviar algún tipo de carta desde la instancia: metadatos. Cuando se inicia una instancia, por lo general, cloud init siempre está presente en esas instancias. Cloud init lee esta carta y dice: "OK, hoy soy un balanceador de carga". Y de acuerdo con estos preceptos, realiza algunas acciones.
Pero, desafortunadamente, cuando hacemos un plan de Terraform y aplicamos Terraform, los datos de usuario se ven como esta mezcla de números. Es decir, solo te envía un hash. Y todo lo que puede ver en el plan es si habrá algún cambio o si el hash seguirá siendo el mismo.
Y si no presta atención a esto, entonces algún archivo de texto golpeado puede ir a Amazon, a la infraestructura real.
Alternativamente, puede especificar no toda la infraestructura durante la ejecución, sino solo la plantilla. Y en el código, diga: "Por favor, muéstrame esta plantilla". Y como resultado, puede obtener una copia impresa de cómo se verán sus datos en Amazon.
Otra opción es utilizar un módulo para generar datos de usuario. Aplicarás este módulo. Obtener el archivo en el disco. Compáralo con la referencia. Y, por lo tanto, si algún jun decide corregir algunos datos de usuario, sus pruebas dirán: "Está bien, hay algunos cambios aquí y allá, esto es normal".
Lo siguiente de lo que me gustaría hablar es sobre la aplicación automatizada de Terraform.
Por supuesto, es lo suficientemente aterrador aplicar Terraform en modo automático, porque quién sabe qué cambios se han producido allí y cuán perjudiciales pueden ser para una infraestructura viva.
Para un entorno de prueba, todo esto está bien. Es decir, un trabajo que crea un entorno de prueba es lo que necesitan todos los desarrolladores. Y una expresión como "todo funcionó para mí" no es un meme divertido, sino una prueba de que una persona se confundió, levantó una pila y lanzó algunas pruebas en esta pila. Y se aseguró de que todo estaba bien allí y dijo: “OK, el código que libero ha sido probado”.
En producción, sandbox y otros entornos que son más críticos para el negocio, es seguro usar parcialmente algunos recursos porque no causa la muerte de nadie. Estos son: grupos de escalado automático, grupos de seguridad, roles, ruta 53 y allí la lista puede ser bastante grande. Pero esté atento a lo que sucede, lea los informes de las aplicaciones automatizadas.
Cuando sea peligroso o aterrador usarlos, por ejemplo, si se trata de algunos recursos persistentes, de una base de datos, obtenga informes de que hay cambios no aplicados en alguna parte de la infraestructura. Y el ingeniero ya está supervisado ejecutando trabajos para aplicar o haciéndolo desde su consola.
Amazon tiene tal cosa como Terminar la protección. Y puede protegerlo en algunos casos de cambios que no son necesarios para usted. Entonces Terraform fue a Amazon y dice "Necesito eliminar esta instancia para hacer otra". Y Amazon dice: “Lo siento, hoy no. Tenemos la protección Terminar”.
Y la guinda del pastel es la optimización del código. Cuando trabajamos con código Terraform, debemos pasar una gran cantidad de parámetros al módulo. Estos son los parámetros necesarios para crear algún tipo de recurso. Y el código se convierte en grandes listas de parámetros que deben pasarse de un módulo a otro, de un módulo a otro, especialmente si los módulos están anidados.
Y es muy difícil de leer. Es muy difícil revisar esto. Y muy a menudo resulta que algunos parámetros se están revisando y no son exactamente los que se necesitan. Y cuesta tiempo y dinero arreglarlo más tarde.
Por lo tanto, le sugiero que use algo como un parámetro complejo que incluye un cierto árbol de valores. Es decir, necesita algún tipo de carpeta donde tenga todos los valores que le gustaría tener en algún tipo de entorno.
Y al llamar a este módulo, puede obtener un árbol que se genera en un módulo común, es decir, en un módulo común que funciona igual para toda la infraestructura.
En este módulo, puede hacer algunos cálculos utilizando una función tan nueva en Terraform como locales. Y luego, en una salida, emita algún tipo de parámetro complejo, que puede incluir hashes, matrices, etc.
En esto, todos los mejores hallazgos que he terminado. Y me gustaría contar una historia sobre Colón. Cuando buscaba dinero para su expedición a descubrir la India (como pensaba entonces), nadie le creyó y creyó que era imposible. Luego dijo: "Asegúrate de que el huevo no se caiga". Todos los banqueros, gente muy rica y probablemente inteligente, trataron de poner el huevo de alguna manera, y cayó todo el tiempo. Entonces Colón tomó el huevo, lo apretó un poco. La cáscara se arrugó y el huevo permaneció inmóvil. Dijeron: "¡Oh, eso es demasiado fácil!" Y Colón respondió: “Sí, es demasiado simple. Y cuando abra la India, todos usarán esta ruta comercial”.
Y lo que les acabo de decir son probablemente cosas bastante simples y triviales. Y cuando te enteras de ellos y empiezas a usarlos, está en el orden de las cosas. Así que úsalo. Y si estas son cosas bastante normales para ti, entonces al menos sabes cómo poner un huevo para que no se caiga.
En resumen:
- Trate de evitar los copos de nieve. Y cuantos menos copos de nieve, menos recursos necesitará para realizar cambios en toda su gran infraestructura.
- Cambio constante. Es decir, cuando se han producido algunos cambios en el código, debe alinear su infraestructura con estos cambios lo antes posible. No debería haber una situación en la que alguien venga en dos o tres meses a ver Elasticsearch, haga un plan de Terraform y haya muchos cambios que no esperaba. Y se necesita mucho tiempo para volver a poner todo en orden.
- Pruebas y automatización. Cuanto más esté cubierto su código con pruebas y chips, más confianza tendrá de que está haciendo todo bien. Y la entrega automática aumentará su confianza muchas veces.
- El código para los entornos de prueba y producción debería ser casi el mismo. Prácticamente, porque al fin y al cabo, la producción es un poco diferente y aún habrá algunos matices que irán más allá del entorno de pruebas. Sin embargo, se puede proporcionar más o menos.
- Y si tiene una gran cantidad de código de Terraform y lleva mucho tiempo mantenerlo actualizado, entonces nunca es demasiado tarde para refactorizarlo y ponerlo en buen estado.
- infraestructura inmutable. Entrega AMI a tiempo.
- Estructura para route53 cuando tiene muchas entradas y quiere que estén en un orden consistente.
- Lucha contra los límites de tasa de API. Aquí es cuando Amazon dice: "Eso es todo, no puedo aceptar más solicitudes, por favor espere". Y la mitad de la oficina está esperando hasta que pueda lanzar su infraestructura.
- instancias puntuales. Amazon no es un evento barato y los lugares te permiten ahorrar bastante. Y ahí se puede contar todo un reportaje al respecto.
- Roles de seguridad y IAM.
- Busque recursos perdidos, cuando tiene instancias de origen desconocido en Amazone, comen dinero. Incluso si las instancias cuestan entre $100 y $150 por mes, son más de $1 por año. Encontrar tales recursos es un negocio lucrativo.
- E instancias reservadas.
Eso es todo para mí. Terraform es genial, úsalo. ¡Gracias!
preguntas
¡Gracias por el informe! Tiene un archivo de estado en S3, pero ¿cómo resuelve el problema de que varias personas pueden tomar este archivo de estado e intentar implementarlo?
En primer lugar, no tenemos prisa. En segundo lugar, están las banderas, en las que informamos que estamos trabajando en algún código. Es decir, a pesar de que la infraestructura es muy grande, esto no significa que alguien esté usando algo constantemente. Y cuando hubo una fase activa, esto fue un problema, mantuvimos los archivos de estado en Git. Esto era importante, de lo contrario, alguien crearía un archivo de estado y teníamos que recopilarlos manualmente en un montón para continuar. Ahora no hay tal problema. En general, Terraform resolvió este problema. Y si algo cambia constantemente, puede usar bloqueos que eviten lo que dijo.
¿Utiliza código abierto o empresarial?
Sin empresa, es decir, todo lo que puedes ir y descargar gratis.
Mi nombre es Stanislav. Quería hacer una pequeña adición. Usted habló sobre la característica de Amazon que le permite hacer que una instancia no se pueda matar. Esto también está en Terraform, en el bloque Life Second, puede prescribir una prohibición de cambio o una prohibición de destrucción.
Estaba limitado en el tiempo. Buen punto.
También quería preguntar dos cosas. Primero, hablaste de las pruebas. ¿Ha utilizado alguna herramienta de prueba? Escuché sobre el complemento Test Kitchen. Tal vez hay algo más. Y me gustaría preguntar acerca de los valores locales. ¿En qué se diferencian básicamente de las variables de entrada? ¿Y por qué no puedo parametrizar algo solo a través de Valores Locales? Traté de lidiar con este tema, pero de alguna manera no lo descubrí yo mismo.
Podemos hablar con más detalle detrás de esta sala. Las herramientas de prueba son completamente hechas por nosotros mismos. No hay nada allí para probar. En general, hay opciones cuando las pruebas automáticas levantan la infraestructura en alguna parte, comprueban que está bien y luego destruyen todo con un informe de que su infraestructura todavía está en buen estado. No tenemos eso porque las pilas de prueba se ejecutan todos los días. Y eso es suficiente. Y si algo comienza a romperse, entonces comenzará a romperse sin que lo revisemos en otro lugar.
Con respecto a los valores locales, continuemos la conversación fuera de la audiencia.
¡Hola! ¡Gracias por el informe! Muy informativo. Dijiste que tienes mucho del mismo tipo de código para describir la infraestructura. ¿Has considerado generar este código?
¡Gran pregunta, gracias! El punto es que cuando usamos la infraestructura como código, asumimos que miramos el código y entendemos qué tipo de infraestructura se encuentra detrás de este código. Si se genera el código, debemos imaginar qué código se generará para comprender qué tipo de infraestructura habrá. O generamos el código, lo cometemos y, de hecho, obtenemos lo mismo. Por lo tanto, fuimos por el camino que escribimos, lo conseguimos. Además, los generadores aparecieron un poco más tarde, cuando empezamos a fabricar. Y era demasiado tarde para cambiar.
¿Has oído hablar de jsonnet?
Нет.
Mira, esto es realmente genial. Veo un caso específico donde puedes aplicarlo y generar una estructura de datos.
Los generadores son buenos cuando los tienes, como en el chiste sobre la máquina de afeitar. Es decir, la primera vez la cara es diferente, pero luego todos tienen la misma cara. Los generadores son muy buenos. Pero, desafortunadamente, nuestras caras son un poco diferentes. Esto es un problema.
Solo mira. ¡Gracias!
Mi nombre es Maxim, soy de Sberbank. Dijiste un poco que intentaste llevar Terraform a un análogo de un lenguaje de programación. ¿No es más fácil usar Ansible?
Estas son cosas muy diferentes. Ansible puede crear recursos y Puppet puede crear recursos en Amazon. Pero Terraform está francamente afilado.
Solo tienes Amazon?
No es que solo tengamos Amazon. Casi solo tenemos Amazon. Pero la característica clave es que Terraform recuerda. En Ansible, si dice: "Recójame 5 instancias", entonces se elevará y luego dirá: "Y ahora necesito 3". Y Terraform dirá: "Ok, mataré a 2", y Ansible dirá: "Ok, aquí hay 3 para ti". 8 totales.
¡Hola! ¡Gracias por tu informe! Fue muy interesante escuchar acerca de Terraform. Solo quiero hacer un pequeño comentario sobre el hecho de que Terraform aún no tiene una versión estable, así que tenga mucho cuidado con Terraform.
Buena cuchara para la cena. Es decir, si necesita una solución, a veces pospone lo inestable, etc., pero funciona y nos ayudó.
La pregunta es. Está usando el backend remoto, está usando S 3. ¿Por qué no está usando el backend oficial?
¿Oficial?
Nube de terraformación.
¿Cuándo apareció?
Hace unos 4 meses.
Si hubiera aparecido hace 4 años, probablemente habría respondido a su pregunta.
Ya hay una función y bloqueos incorporados, y puede almacenar un archivo de estado. Intentalo. Pero tampoco he probado.
Estamos en un gran tren que se mueve a gran velocidad. Y no puedes simplemente tomar y tirar algunos autos.
Estabas hablando de copos de nieve, ¿por qué no usaste rama? ¿Por qué no funcionó de esa manera?
Tenemos un enfoque tal que toda la infraestructura está en un repositorio. Terraform, Puppet, todos los scripts que de alguna manera se relacionan con esto, están todos en un repositorio. De esta manera podemos asegurarnos de que los cambios incrementales se prueban uno por uno. Si se tratara de un montón de ramas, ese proyecto sería casi imposible de mantener. Pasan seis meses y se separan tanto que es solo una especie de castigo. Esto es de lo que quería huir antes de refactorizar.
es decir, no funciona?
No funciona en absoluto.
En rama, recorté la diapositiva de la carpeta. Es decir, si lo hace para cada pila de prueba, por ejemplo, el equipo A tiene su propio papá, el equipo B tiene su propio papá, entonces esto tampoco funciona. Hicimos un código de entorno de prueba unificado que era lo suficientemente flexible para adaptarse a todos. Es decir, servimos un código.
¡Hola! ¡Mi nombre es Yura! ¡Gracias por el informe! Pregunta sobre módulos. Dices que estás usando módulos. ¿Cómo resuelve el problema si se realizaron cambios en un módulo que no son compatibles con el cambio de otra persona? ¿De alguna manera versionando módulos o tratando de traer un prodigio para cumplir con dos requisitos?
Este es el gran problema de la acumulación de nieve. Esto es lo que sufrimos cuando algún cambio inocuo puede romper alguna parte de la infraestructura. Y se notará solo después de mucho tiempo.
Es decir, ¿todavía no se ha decidido?
Haces módulos universales. Evita los copos de nieve. Y todo saldrá bien. La segunda mitad del informe trata sobre cómo evitarlo.
¡Hola! ¡Gracias por el informe! Me gustaría aclarar. Detrás de escena había una gran pila, por la que vine. ¿Cómo se integran la distribución de marionetas y funciones?
datos del usuario.
Es decir, ¿simplemente escupe el archivo y lo ejecuta de alguna manera?
Los datos de usuario son una nota, es decir, cuando hacemos un clon de imagen, luego Daemon sube allí y, tratando de averiguar quién es, lee una nota que indica que es un equilibrador de carga.
Es decir, ¿es algún tipo de proceso separado el que se regala?
No lo inventamos. lo usamos
¡Hola! Solo tengo una pregunta sobre los datos del usuario. Dijiste que hay problemas allí, que alguien podría enviar algo al lugar equivocado. ¿Hay alguna forma de almacenar los datos del usuario en el mismo Git, de modo que siempre quede claro a qué se refieren los datos del usuario?
Generamos datos de usuario a partir de una plantilla. Es decir, un cierto número de variables recurren allí. Y Terraform genera el resultado final. Por lo tanto, no puede simplemente mirar la plantilla y decir qué sucede, porque todos los problemas están relacionados con el hecho de que el desarrollador piensa que está pasando una cadena en esta variable, y luego se usa una matriz. Y él, bang y yo, fulano de tal, fulano de tal, la siguiente línea, y todo se rompió. Si este es un recurso nuevo y una persona lo plantea, ve que algo no funciona, entonces esto se resuelve rápidamente. Y si este grupo de escalado automático se actualizó, en algún momento las instancias del grupo de escalado automático comienzan a reemplazarse. Y aplaudir, algo no funciona. Duele.
¿Resulta que la única solución es probar?
Sí, ves el problema, agregas pasos de prueba allí. Es decir, la salida también se puede probar. Tal vez no sea tan conveniente, pero también puede poner algunas marcas: verifique que los datos del usuario estén clavados aquí.
Mi nombre es Timur. Es muy bueno que haya informes sobre cómo organizar correctamente Terraform.
Ni siquiera empecé.
Creo que en la próxima conferencia, tal vez la haya. Tengo una pregunta sencilla. ¿Por qué está codificando el valor en un módulo separado en lugar de usar tfvars, es decir, es un módulo con valores mejor que tfvars?
Es decir, debería escribir aquí (diapositiva: Production/environment/settings.tf): dominio = variable, dominio vpcnetwork, vpcnetwork variable y stvars: ¿obtiene lo mismo?
Hacemos exactamente eso. Nos referimos al módulo fuente de configuración, por ejemplo.
De hecho, este es un tfvars. Tfvars es muy útil en un entorno de prueba. Tengo tfvars para instancias grandes, para instancias pequeñas. Y tiré un archivo a la carpeta. Y obtuve lo que quería. Cuando vimos infraestructura, queremos poder ver y entender todo de inmediato. Y resulta que necesitas mirar aquí, luego mirar en tfvars.
¿Resulta que todo estaba en un solo lugar?
Sí, tfvars es cuando tienes un código. Y se utiliza en varios lugares diferentes con diferentes matices. Entonces lanzarías tfvars y obtendrías tus matices. Y somos infraestructura como código en estado puro. Miró y entendió.
¡Hola! ¿Se ha encontrado con situaciones en las que el proveedor de la nube interfiere con lo que ha hecho con Terraform? Digamos que editamos los metadatos. Hay claves ssh. Y Google desliza constantemente sus metadatos, sus claves allí. Y Terraform siempre escribe que tiene cambios. Después de cada ejecución, incluso si nada cambia, siempre dice que actualizará este campo ahora.
Con claves, pero sí, parte de la infraestructura se ve afectada por tal cosa, es decir, Terraform no puede cambiar nada. Tampoco podemos cambiar nada con nuestras manos. Mientras vivamos con ello.
Es decir, te encontraste con esto, pero no se te ocurrió nada, ¿cómo lo hace y lo hace él mismo?
Lamentablemente si.
¡Hola! Mi nombre es Stanislav Starkov. Correo. es Grupo. ¿Cómo solucionas el problema de generar una etiqueta en..., cómo la pasas adentro? Según tengo entendido, a través de los datos del usuario, para especificar el nombre de host, ¿incitar a Puppet? Y la segunda parte de la pregunta. ¿Cómo resuelve este problema en SG, es decir, cuando genera SG, cien instancias del mismo tipo, cómo nombrarlas correctamente?
Aquellas instancias que son muy importantes para nosotros, las nombraremos bellamente. Aquellos que no son necesarios, hay una posdata de que este es un grupo de escalado automático. Y en teoría se puede clavar, y conseguir uno nuevo.
En cuanto al problema con la etiqueta, no existe tal problema, pero existe tal tarea. Y usamos etiquetas muy, muy fuertemente, porque la infraestructura es grande y costosa. Y debemos ver en qué se gasta el dinero, por lo que las etiquetas nos permiten determinar en qué se gastó y a dónde se fue. Y, en consecuencia, la búsqueda de algo aquí es una gran cantidad de dinero gastado.
¿De qué otra cosa era la pregunta?
Cuando SG crea cien instancias, ¿es necesario distinguirlas de alguna manera?
No, no lo hagas. Cada instancia tiene un agente que me dice que tengo un problema. Si el agente informa, entonces el agente sabe sobre él y, al menos, su dirección IP existe. Ya puedes correr. En segundo lugar, usamos Consul para Discovery, donde no hay Kubernetes. Y Consul también muestra la dirección IP de la instancia.
Es decir, ¿está apuntando exactamente a la IP y no al nombre de host?
Es imposible navegar por nombre de host, es decir, hay muchos. Hay identificadores de instancia: AE, etc. Puede encontrarlo en algún lugar, puede incluirlo en la búsqueda.
¡Hola! Me di cuenta de que Terraform es algo bueno, adaptado a las nubes.
No solo
Esta es la pregunta que me interesa. Si decide pasar, digamos, a Bare Metal en masa con todas sus instancias? ¿Habrá algún problema? ¿O todavía tiene que usar otros productos, por ejemplo, el mismo Ansible que se mencionó aquí?
Ansible es un poco sobre otra cosa. Es decir, Ansible ya se está ejecutando cuando se inició la instancia. Y Terraform funciona antes de que se inicie la instancia. Cambiar a Bare Metal no lo es.
Ahora no, pero los negocios vendrán y dirán: "Vamos".
Cambiar a otra nube: sí, pero aquí hay una característica ligeramente diferente. Debe escribir el código de Terraform de tal manera que pueda cambiar a otra nube con menos derramamiento de sangre.
Inicialmente, la tarea era que toda nuestra infraestructura fuera agnóstica, es decir, cualquier nube debería estar bien, pero en algún momento la empresa se dio por vencida y dijo: "Está bien, en los próximos N años no iremos a ninguna parte, puede usar los servicios de Amazonas".
Terraform le permite crear trabajos front-end, configurar PagerDuty, documentos de datos, etc. Tiene muchas colas. Prácticamente puede controlar el mundo entero.
¡Gracias por el informe! También he estado girando Terraform durante 4 años. En la etapa de una transición fluida a Terraform, a la infraestructura, a una descripción declarativa, nos enfrentamos a una situación en la que alguien estaba haciendo algo a mano y tú estabas tratando de hacer un plan. Y tengo un error allí. ¿Cómo lidias con tales problemas? ¿Cómo encuentra los recursos perdidos que se indicaron?
Principalmente con nuestras manos y ojos, si vemos algo extraño en el informe, analizamos lo que está sucediendo allí, o simplemente lo eliminamos. En general, las solicitudes de extracción son algo común.
Si hay un error, ¿hace retroceder? ¿Has intentado hacer esto?
No, esta es una decisión de una persona en el momento en que ve el problema.
Fuente: habr.com