Representar la infraestructura como código en un formato de texto repetible es una práctica recomendada sencilla para sistemas que no requieren jugar con ratones. Esta práctica tiene un nombre... , y hasta ahora existen dos herramientas populares para implementarlo, especialmente en AWS: и .
Comparación de experiencias con Terraform y CloudFormation
antes de venir a (Aka ) Yo trabajé y usé Terraform durante tres años. En el nuevo lugar, también usé Terraform con todas mis fuerzas, y luego la compañía impulsó la transición a todo a la Amazon, incluido CloudFormation. He desarrollado diligentemente las mejores prácticas para ambos y he utilizado ambas herramientas en flujos de trabajo muy complejos en toda la organización. Más tarde, después de sopesar cuidadosamente las implicaciones de migrar de Terraform a CloudFormation, me convencí de que Terraform era probablemente la mejor opción para la organización.
Terraformar horrible
software beta
Terraform aún no ha lanzado la versión 1.0, lo cual es una buena razón para no utilizarla. Ha cambiado mucho desde que lo probé por primera vez, pero en aquel entonces terraform apply A menudo se estropeaba después de varias actualizaciones o simplemente después de un par de años de uso. Yo diría que “ahora todo es diferente”, pero… eso es lo que todo el mundo parece decir, ¿no? Hay cambios que son incompatibles con versiones anteriores, aunque son apropiados, e incluso parece que la sintaxis y las abstracciones de los almacenes de recursos son ahora lo que necesitamos. El instrumento parece haber mejorado mucho, pero... :-0
Por otro lado, AWS ha hecho un buen trabajo manteniendo la compatibilidad con versiones anteriores. Probablemente esto se deba a que sus servicios a menudo se prueban exhaustivamente dentro de la organización y solo después se publican, se les cambia el nombre. Así que “se esforzaron mucho” es quedarse corto. Mantener la compatibilidad con versiones anteriores de las API para un sistema tan variado y complejo como AWS es increíblemente difícil. Cualquiera que haya tenido que mantener API públicas tan utilizadas debería comprender lo difícil que es hacerlo durante tantos años. Pero el comportamiento de CloudFormation, en mi memoria, nunca ha cambiado a lo largo de los años.
Conoce la pierna... es una bala
Hasta donde yo sé, elimina el recurso. forastero La pila de CloudFormation desde su pila CF no es posible. Lo mismo ocurre con Terraform. Le permite importar recursos existentes a su pila. Se puede decir que la función es asombrosa, pero un gran poder conlleva una gran responsabilidad. Solo necesita agregar un recurso a la pila y, mientras trabaja con su pila, no puede eliminar ni cambiar este recurso. Un día le salió el tiro por la culata. Un día en Twitch, alguien importó accidentalmente el grupo de seguridad AWS de otra persona a su propia pila de Terraform sin hacer ninguna travesura. Ingresé varios comandos y... el grupo de seguridad (junto con el tráfico entrante) desapareció.
Terraformar genial
Recuperación de estados incompletos
A veces, CloudFormation no logra realizar la transición completa de un estado a otro. Al mismo tiempo, intentará volver al anterior. Es una pena que esto no siempre sea factible. Puede ser bastante aterrador depurar lo que sucedió después; nunca se sabe si CloudFormation estará feliz de que lo estén pirateando, incluso solo para arreglarlo. Si será posible o no volver al estado anterior, realmente no sabe cómo determinarlo y, por defecto, se queda colgado durante horas esperando un milagro.
Terraform, por otro lado, tiende a recuperarse de transiciones fallidas con mucha más gracia y ofrece herramientas de depuración avanzadas.
Cambios más claros en el estado del documento
“Está bien, equilibrador de carga, estás cambiando. ¿Pero cómo?"
—ingeniero ansioso, listo para presionar el botón “aceptar”.
A veces necesito realizar algunas manipulaciones con el equilibrador de carga en la pila de CloudFormation, como agregar un número de puerto o cambiar un grupo de seguridad. ClouFormation muestra mal los cambios. Yo, con alfileres y agujas, verifico dos veces el archivo yaml diez veces para asegurarme de que no he borrado nada necesario y no he agregado nada innecesario.
Terraform es mucho más transparente a este respecto. A veces es incluso demasiado transparente (léase: aburrido). Afortunadamente, la última versión incluye una visualización mejorada de los cambios para que ahora puedas ver exactamente qué está cambiando.
Flexibilidad
Escribir software al revés.
Para decirlo sin rodeos, la característica más importante del software de larga duración es la capacidad de adaptarse al cambio. Escribe cualquier software al revés. La mayoría de las veces cometí errores al tomar un servicio "simple" y luego comenzar a agruparlo todo en una sola pila de CloudFormation o Terraform. Y, por supuesto, meses después se reveló que había entendido todo mal y que el servicio en realidad no fue sencillo. Y ahora necesito de alguna manera dividir una pila grande en componentes pequeños. Cuando trabajas con CloudFormation, esto solo se puede hacer recreando primero la pila existente, y yo no hago esto con mis bases de datos. Terraform, por otro lado, hizo posible diseccionar la pila y dividirla en partes más pequeñas y más comprensibles.
Módulos en git
Compartir código de Terraform en varias pilas es mucho más fácil que compartir código de CloudFormation. Con Terraform, puedes poner tu código en un repositorio git y acceder a él mediante el control de versiones semántico. Cualquiera que tenga acceso a este repositorio puede reutilizar el código compartido. El equivalente de CloudFormation es S3, pero no tiene los mismos beneficios y no hay ninguna razón por la que debamos abandonar git en favor de S3.
La organización creció y la capacidad de compartir pilas comunes alcanzó un nivel crítico. Terraform hace que todo esto sea fácil y natural, mientras que CloudFormation te hará pasar por obstáculos antes de que puedas hacer que algo como esto funcione.
Operaciones como código
"Escribámoslo y está bien".
—un ingeniero 3 años antes de inventar la bicicleta Terraform.
Cuando se trata de desarrollo de software, Go o un programa Java no es sólo código.
Código como código
También está la infraestructura sobre la que funciona.
Infraestructura como Código
¿Pero de dónde es ella? ¿Cómo monitorearlo? ¿Dónde vive tu código? ¿Los desarrolladores necesitan permiso de acceso?
Operaciones como código
Ser desarrollador de software no significa sólo escribir código.
AWS no es el único: probablemente utilices otros proveedores. SignalFx, PagerDuty o Github. Tal vez tenga un servidor Jenkins interno para CI/CD o un panel interno de Grafana para monitoreo. Infra as Code se elige por diferentes motivos, y cada uno es igualmente importante para todo lo relacionado con el software.
Cuando trabajaba en Twitch, aceleramos los servicios dentro de los sistemas mixtos integrados y AWS de Amazon. Desarrollamos y respaldamos muchos microservicios, lo que aumentó los costos operativos. Las discusiones fueron más o menos así:
- Я: Maldita sea, son muchos gestos para overclockear un microservicio. Tendré que usar esta basura para crear una cuenta de AWS (fuimos a 2 cuentas en microservicio), luego este para configurar alertas, este para un repositorio de código, y este para una lista de correo electrónico, y luego este...
- Dirigir: Escribámoslo y está bien.
- Я: Está bien, pero el guión en sí cambiará. Necesitaremos una forma de comprobar que todos estos artilugios integrados de Amazon estén actualizados.
- Dirigir: Suena bien. Y escribiremos un guión para esto.
- Я: ¡Excelente! Y es probable que el script aún necesite establecer parámetros. ¿Los aceptará?
- Dirigir: ¡Déjalo llevar a donde vaya!
- Я: El proceso puede cambiar y se perderá la compatibilidad con versiones anteriores. Se requerirá algún tipo de control de versiones semántico.
- Dirigir: ¡Gran idea!
- Я: Las herramientas se pueden cambiar manualmente, dentro de la interfaz de usuario. Necesitaremos una forma de comprobar y solucionar este problema.
…3 años después:
- Dirigir: Y tenemos terraformación.
La moraleja de la historia es: incluso si perdidamente enamorado de todo lo de Amazon, todavía estás usando algo que no es de AWS y estos servicios tienen un estado que usa un lenguaje de configuración para mantener ese estado sincronizado.
CloudFormation lambda vs git módulos terraform
lambda es la solución de CloudFormation al problema de la lógica personalizada. Con lambda puedes o . Este enfoque introduce complejidades adicionales que no están presentes en el control de versiones semántico de los módulos git de Terraform. Para mí, el problema más urgente fue administrar los permisos para todas estas lambdas de usuario (y son docenas de cuentas de AWS). Otro problema importante fue el de “¿qué fue primero, el huevo o la gallina?”: estaba relacionado con el código lambda. Esta función en sí misma es infraestructura y código, y ella misma necesita monitoreo y actualizaciones. El último clavo en el ataúd fue la dificultad para actualizar semánticamente los cambios del código lambda; También teníamos que asegurarnos de que las acciones de la pila sin un comando directo no cambiaran entre ejecuciones.
Recuerdo que una vez quise crear una implementación canary para el entorno Elastic Beanstalk con un equilibrador de carga clásico. Lo más fácil sería realizar una segunda implementación para EB junto al entorno de producción, yendo un paso más allá: combinando el grupo de implementación canary de escalamiento automático con la implementación LB en el entorno de producción. Y dado que Terraform utiliza , esto requerirá 4 líneas adicionales de código en Terraform. Cuando pregunté si había una solución comparable en CloudFormation, me señalaron un repositorio git completo con un canal de implementación y todo, todo por algo que 4 líneas pobres de código Terraform podrían hacer.
Detecta mejor la deriva
Asegúrese de que la realidad coincida con las expectativas.
Es una característica de operaciones como código muy poderosa porque ayuda a garantizar que la realidad coincida con las expectativas. Está disponible tanto con CloudFormation como con Terraform. Pero a medida que la pila de producción creció, la búsqueda de derivas en CloudFormation produjo cada vez más detecciones falsas.
Con Terraform tienes ganchos de ciclo de vida mucho más avanzados para la detección de deriva. Por ejemplo, ingresa el comando directamente en la definición de tarea de ECS si desea ignorar los cambios en una definición de tarea específica sin ignorar los cambios en toda su implementación de ECS.
CDK y el futuro de CloudFormation
CloudFormation es difícil de gestionar a gran escala entre infraestructuras. Muchas de estas dificultades se reconocen y la herramienta necesita cosas como , un marco para definir la infraestructura de la nube en código y ejecutarla a través de AWS CloudFormation. Será interesante ver qué le depara el futuro a aws-cdk, pero le resultará difícil competir con las otras fortalezas de Terraform; Para actualizar CloudFormation, se requerirán cambios globales.
Para que Terraform no decepcione
Se trata de “infraestructura como código”, y no “como texto”.
Mi primera impresión de Terraform fue bastante mala. Creo que simplemente no entendí el enfoque. Casi todos los ingenieros lo perciben involuntariamente como un formato de texto que debe convertirse en la infraestructura deseada. NO LO HAGAS DE ESTA MANERA.
Las perogrulladas del buen desarrollo de software también se aplican a Terraform.
He visto muchas prácticas adoptadas para crear un buen código que se ignoran en Terraform. Has estudiado durante años para convertirte en un buen programador. No renuncies a esta experiencia sólo porque estás trabajando con Terraform. Las perogrulladas del buen desarrollo de software se aplican a Terraform.
¿Cómo no se puede documentar el código?
He visto enormes pilas de Terraform sin ninguna documentación. ¿Cómo se puede escribir código en páginas sin ninguna documentación? Agregue documentación que explique su código Terraform (énfasis en la palabra "código"), por qué esta sección es tan importante y qué hace.
¿Cómo podemos implementar servicios que alguna vez fueron una gran función principal ()?
He visto pilas de Terraform muy complejas presentadas como un solo módulo. ¿Por qué no implementamos software de esta manera? ¿Por qué dividimos funciones grandes en otras más pequeñas? Las mismas respuestas se aplican a Terraform. Si su módulo es demasiado grande, deberá dividirlo en módulos más pequeños.
¿Su empresa no utiliza bibliotecas?
He visto cómo los ingenieros, al poner en marcha un nuevo proyecto usando Terraform, copiaban y pegaban estúpidamente grandes fragmentos de otros proyectos en los suyos propios y luego jugueteaban con ellos hasta que empezó a funcionar. ¿Trabajarías así con código “de combate” en tu empresa? No solo utilizamos bibliotecas. Sí, Pero, ¿dónde estamos en principio sin bibliotecas compartidas?
¿No estás usando PEP8 o gofmt?
La mayoría de los idiomas tienen un esquema de formato estándar aceptado. En Python esto es PEP8. En Go - gofmt. Terraform tiene el suyo propio: terraform fmt. ¡Disfrútalo por tu salud!
¿Usarás React sin saber JavaScript?
Los módulos de Terraform pueden simplificar alguna parte de la compleja infraestructura que usted crea, pero esto no significa que no pueda modificarla en absoluto. ¿Quiere utilizar Terraform correctamente sin comprender los recursos? Estás condenado: el tiempo pasará y nunca dominarás Terraform.
¿Estás codificando con singletons o inyección de dependencia?
La inyección de dependencia es una de las mejores prácticas reconocidas para el desarrollo de software y se prefiere a los singletons. ¿Cómo es esto útil en Terraform? He visto módulos Terraform que dependen del estado remoto. En lugar de escribir módulos que recuperen estados remotos, escriba un módulo que tome parámetros. Y luego pase estos parámetros al módulo.
¿Sus bibliotecas hacen diez cosas bien o una cosa genial?
Las bibliotecas que funcionan mejor son aquellas que se centran en una tarea que hacen muy bien. En lugar de escribir grandes módulos Terraform que intenten hacer todo a la vez, cree partes de ellos que hagan una cosa bien. Y luego combínalos según sea necesario.
¿Cómo se realizan cambios en bibliotecas sin compatibilidad con versiones anteriores?
Un módulo Terraform común, como una biblioteca normal, necesita comunicar de alguna manera los cambios a los usuarios sin ser compatible con versiones anteriores. Es molesto cuando estos cambios ocurren en las bibliotecas, y es igualmente molesto cuando se realizan cambios no compatibles con versiones anteriores en los módulos de Terraform. Se recomienda utilizar etiquetas git y semver cuando se utilizan módulos Terraform.
¿Su servicio de producción se ejecuta en su computadora portátil o en un centro de datos?
Hashicorp cuenta con herramientas como para ejecutar tu terraforma. Estos servicios centralizados facilitan la gestión, auditoría y aprobación de cambios de terraform.
¿No escribes exámenes?
Los ingenieros reconocen que es necesario probar el código, pero ellos mismos a menudo se olvidan de probarlo cuando trabajan con Terraform. Para la infraestructura, esto está plagado de momentos traicioneros. Mi consejo es "probar" o "crear pilas de ejemplo" utilizando módulos que se puedan implementar correctamente para realizar pruebas durante CI/CD.
Terraform y microservicios
La vida o la muerte de las empresas de microservicios depende de la velocidad, la innovación y la disrupción de las nuevas pilas de trabajo de microservicios.
El aspecto negativo más común asociado a las arquitecturas de microservicios, y que no se puede eliminar, está relacionado con el trabajo, no con el código. Si piensa en Terraform simplemente como una forma de automatizar únicamente el lado de la infraestructura de una arquitectura de microservicios, entonces se está perdiendo los verdaderos beneficios del sistema. ahora ya esta .
Fuente: habr.com