Presentar la infraestructura como código en formato de texto repetible es una práctica recomendada simple para sistemas con los que no necesita llevar. Esta práctica tiene un nombre: Infraestructura como código , y hasta ahora hay dos herramientas populares para su implementación, especialmente en AWS: Terraform y CloudFormation .
Compare la experiencia con Terraform y CloudFormation
Antes de unirme a Twitch (también conocido como Amazon Jr. ), trabajé en una startup y usé Terraform durante tres años. En un nuevo lugar, también utilicé Terraform con might and main, y luego la compañía impulsó la transición a todo a la Amazonía, incluida CloudFormation. Trabajé duro para desarrollar las mejores prácticas para ambos, y utilicé ambas herramientas en flujos de trabajo muy complejos en toda la organización. Más tarde, después de considerar cuidadosamente las consecuencias de cambiar de Terraform a CloudFormation, me convencí de que Terraform era probablemente la mejor opción para la organización.
Software Beta
Terraform ni siquiera ha lanzado la versión 1.0, y esta es una buena razón para no usarla. Desde que lo probé por primera vez, ha cambiado mucho, pero luego la terraform apply menudo se rompió después de varias actualizaciones o solo después de un par de años de operación. Yo diría que "ahora todo es diferente", pero ... ¿entonces todos parecen decir que no? Hay cambios que son incompatibles con versiones anteriores, aunque son apropiados, e incluso la sensación es que la sintaxis y las abstracciones de almacenamiento de recursos son ahora lo que necesita. La herramienta parecía ser mejor, pero ...: -0
AWS, por otro lado, hizo un buen trabajo al mantener la compatibilidad con versiones anteriores. Todo, probablemente, porque sus servicios a menudo están bien probados dentro de la organización y solo entonces, renombrados, publicados. Así que "se esforzó mucho" todavía se dice débilmente. Mantener la compatibilidad con versiones anteriores de la API para un sistema tan complejo y multivariante como AWS es increíblemente difícil. Cualquiera que haya tenido que soportar API disponibles públicamente que se usan con la misma amplitud debería comprender lo difícil que ha sido durante tantos años. Pero el comportamiento de CloudFormation en mi memoria nunca ha cambiado con los años.
Conoce la pierna ... es una bala
Hasta donde sé, no es posible eliminar un recurso de pila de CloudFormation de terceros de mi pila de CF. La situación es similar con Terraform. Le permite importar recursos existentes en su pila. La función, se podría decir, es impresionante, pero con un gran poder conlleva una gran responsabilidad. Uno solo tiene que poner el recurso en la pila, y mientras trabaja con su pila, no puede eliminar o cambiar este recurso. Una vez que se dio la vuelta. De alguna manera, en un sitio de Twitch, alguien, sin planear nada malo, importó accidentalmente un grupo de seguridad de AWS en su propia pila Terraform. Ingresé varios comandos y ... el grupo de seguridad (junto con el tráfico entrante) desapareció.
Recuperación parcial
A veces, CloudFormation no puede pasar completamente de un estado a otro. Al mismo tiempo, intentará volver a la anterior. Lo sentimos, esto no siempre es factible. Luego, depurar lo que sucedió es aterrador: nunca se sabe si CloudFormation estará encantado de que esté roto, incluso para su reparación. Pero, si tiene éxito o no regresa al estado anterior, realmente no sabe cómo determinarlo y, por defecto, se cuelga durante horas esperando un milagro.
Terraform, por el contrario, tiende a recuperarse de las transiciones fallidas de manera mucho más elegante y ofrece herramientas avanzadas de depuración.
Cambios más claros en el estado del documento.
"Está bien, equilibrador de carga, estás cambiando. ¿Pero cómo?"
—Un ingeniero preocupado listo para presionar el botón aceptar.
A veces necesito hacer algunas manipulaciones con el equilibrador de carga en la pila de CloudFormation, por ejemplo, agregar un número de puerto o cambiar un grupo de seguridad. Los cambios de CloudFormation se muestran débilmente. Yo, como en las agujas, verifico dos veces el archivo yaml diez veces para asegurarme de que no borré todo lo que necesitaba y no agregué demasiado.
Terraform es mucho más transparente a este respecto. A veces es incluso demasiado transparente (léase: lo consigue). Afortunadamente, la última versión incluye una visualización mejorada de los cambios: ahora puede ver claramente lo que está cambiando.
Flexibilidad
Escribir software desde el opuesto.
Para decirlo sin rodeos, la característica distintiva más importante del software de larga duración es su capacidad de adaptarse al cambio. Escribe cualquier software desde el lado opuesto. A menudo me percaté de que tomé un servicio "simple", y luego comencé a insertar todo en una sola pila de CloudFormation o Terraform. Y, por supuesto, meses después se reveló que entendí todo mal, ¡y el servicio en realidad no es simple! Y, por lo tanto, necesito dividir de alguna manera una pila grande en componentes pequeños. Cuando trabaja con CloudFormation, es posible hacer esto solo recreando primero la pila existente, pero no lo hago con mis bases de datos. Terraform, por otro lado, hizo posible diseccionar la pila y dividirla en partes más pequeñas más comprensibles.
Módulos en git
Compartir el código de Terraform en varias pilas es mucho más fácil que compartir el código de CloudFormation. Con Terraform, puede poner código en un repositorio git y acceder a él mediante el control de versión semántico. Cualquier persona con acceso a este repositorio puede reutilizar el código compartido. El equivalente de CloudFormation es S3, pero no tiene las mismas ventajas, y no hay una sola razón por la que debamos abandonar completamente git a favor de S3.
La organización creció y la capacidad de compartir pilas compartidas alcanzó un nivel crítico. Con Terraform, todo esto es fácil y natural, mientras que CloudFormation te hará saltar a través de los anillos antes de obtener algo similar.
Operaciones como código
"Vamos a escribir 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 solo código.
Código como Código
Después de todo, todavía existe la infraestructura en la que funciona.
Infraestructura como código
¿Pero de dónde es ella? ¿Cómo monitorearlo? ¿Dónde reside tu código? ¿Los desarrolladores necesitan permiso para acceder?
Operaciones como código
Ser un desarrollador de software no se trata solo de escribir código.
No AWS One: debe estar utilizando otros proveedores. SignalFx, PagerDuty o Github. Quizás tenga un servidor Jenkins interno para CI / CD o un panel de control interno de Grafana para el monitoreo. Infra as Code se elige por varias razones, y cualquiera es igualmente importante para todo lo relacionado con el software.
Cuando trabajaba en Twitch, aceleramos los servicios dentro de los sistemas integrados mixtos de Amazon y los sistemas AWS. Estampamos y respaldamos muchos microservicios, aumentando los costos operativos. Las discusiones se llevaron a cabo aproximadamente en la siguiente línea:
- Yo : Maldición, muchos gestos para dispersar un microservicio. Tendré que usar esta basura para crear una cuenta de AWS (fuimos a 2 cuentas para microservicio ), luego esta para configurar notificaciones, esta para el repositorio de código y esta para la lista de direcciones de correo electrónico, y esta ... .
- Plomo : Vamos a guiar y está bien.
- Yo : Se inquieta, pero el script en sí cambiará. Necesitará una forma de verificar que todos estos artilugios de Amazon incorporados estén actualizados.
- Plomo : Suena bien. Y para esto escribiremos un guión.
- Yo : genial! Y el script probablemente todavía necesite establecer los parámetros. ¿Los aceptará?
- Plomo : Sí, lo hará, ¿a dónde irá?
- Yo : El proceso puede cambiar, se perderá la compatibilidad con versiones anteriores. Tomará un control semántico de la versión.
- Plomo : ¡Gran idea!
- Yo : las herramientas se pueden cambiar manualmente, dentro de la interfaz de usuario. Necesitamos una forma de verificar y solucionar esto.
... 3 años después:
- Plomo : Y tenemos terraform.
La moraleja de la fábula es la siguiente: incluso si está loco por todo Amazon , todavía usa algo que no es de AWS, y estos servicios tienen un estado que el lenguaje usa para la configuración para sincronizar este estado.
lambda es la solución de CloudFormation para problemas de lógica personalizada. Con lambda, puede crear macros o un recurso personalizado . Este enfoque presenta dificultades adicionales que Terraform no tiene en el control de la versión semántica de los módulos git. Para mí, el problema más apremiante fue la administración de permisos para todos estos lambda personalizados (que son docenas de cuentas de AWS). Otro en importancia era un problema como "¿qué sucedió antes: una gallina o un huevo?": Estaba asociado con el código lambda. Esta función en sí misma es infraestructura y código, y en sí misma necesita monitoreo y actualizaciones. Lo último destacado en el ataúd fue la dificultad de actualizar semánticamente los cambios en el código lambda; También era necesario asegurarse de que las acciones de la pila sin un comando directo no cambien entre los inicios.
Recuerdo que de alguna manera quería crear una implementación canaria para el entorno Elastic Beanstalk con un equilibrador de carga clásico. La forma más fácil sería hacer una segunda implementación para EB junto al entorno de producción, dando otro paso: combinando el grupo de implementación canario escalable automáticamente con el LB de implementación en el entorno de producción. Y dado que Terraform usa el beantalk ASG como salida , requerirá 4 líneas de código adicionales en Terraform. Cuando pregunté si había una solución comparable en CloudFormation, me señalaron a un repositorio completo en git con una tubería de implementación y más: todo por el bien de lo que podían hacer las desafortunadas 4 líneas de código Terraform.
Él detecta mejor la deriva
Asegúrese de que la realidad cumpla con las expectativas.
La detección de deriva es una operación muy poderosa como código, porque ayuda a garantizar que la realidad cumpla con las expectativas. Está disponible con CloudFormation y Terraform. Pero a medida que la pila de trabajo creció, la búsqueda de deriva de CloudFormation arrojó más y más falsos positivos.
Con Terraform, tiene ganchos de ciclo de vida mucho más avanzados para la detección de deriva. Por ejemplo, ingrese el comando ignore_changes directamente en la definición de una tarea ECS si desea ignorar los cambios en la definición de una tarea específica sin ignorar los cambios en toda la implementación de ECS.
CloudFormation es difícil de administrar en una escala grande de infraestructura cruzada. Se reconocen muchas de estas dificultades, y la herramienta necesita cosas como aws-cdk , un marco para definir una infraestructura de nube en código y pasarla a través de AWS CloudFormation. Tendrá curiosidad por ver qué tendrá aws-cdk en el futuro, pero le será difícil competir con los otros beneficios de Terraform; para ajustar CloudFormation, se requerirán cambios globales.
Esto es "infraestructura como CÓDIGO", no "como texto".
Mi primera impresión de Terraform fue bastante mala. Creo que simplemente no entendí el enfoque. Casi todos los ingenieros al principio lo perciben involuntariamente como un formato de texto que debe convertirse en la infraestructura deseada. No lo hagas.
He visto cuántas prácticas adoptadas para crear un buen código se ignoran en Terraform. Estudiaste durante años para convertirte en un buen programador. No renuncies a esta experiencia simplemente porque trabajas con Terraform. Las verdades comunes del buen desarrollo de software también se aplican a Terraform.
¿Cómo no se puede documentar el código?
Encontré enormes montones de Terraform sin ninguna documentación. ¿Cómo puedo escribir código en páginas, completamente sin documentación? Agregue documentación que explique su código Terraform (el énfasis aquí en la palabra "código"), por qué esta sección es tan importante y qué hace.
¿Cómo puede implementar servicios que alguna vez fueron una gran función main ()?
Conocí pilas de Terraform muy complejas, presentadas como un solo módulo. ¿Por qué no implementamos software como este? ¿Por qué dividir las funciones grandes en otras más pequeñas? Las mismas respuestas se aplican a Terraform. Si su módulo es demasiado grande, debe dividirlo en módulos más pequeños.
¿Su empresa no utiliza bibliotecas?
Vi cómo los ingenieros, haciendo girar un nuevo proyecto usando Terraform, copian y pegan estúpidamente grandes piezas de otros proyectos en su propio proyecto, y luego los recogen hasta que comienza a funcionar. Entonces, ¿trabajarías en tu empresa con el código de "combate"? No solo usamos bibliotecas. Sí, no todo debería ser una biblioteca, pero ¿dónde estamos sin bibliotecas compartidas en principio?
¿No usas 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 su propio: terraform fmt . Uso para la salud!
¿Usarás React sin saber JavaScript?
Los módulos Terraform pueden simplificar parte de la compleja infraestructura que está creando, pero esto no significa que pueda omitirla. ¿Desea usar Terraform correctamente sin comprender los recursos? Estás condenado: el tiempo se irá, pero no dominarás Terraform.
¿Codifica singletones o introduce dependencias?
La inyección de dependencia es la mejor práctica reconocida para el desarrollo de software, que es preferida por singletones. ¿Cómo es esto útil en Terraform? Conocí módulos de Terraform dependiendo de un estado remoto. En lugar de escribir módulos que se extraen de un estado remoto, escriba un módulo que acepte parámetros. Y luego pasar estos parámetros al módulo.
¿Sus bibliotecas hacen bien diez cosas o una excelente?
Las bibliotecas que se centran en una sola tarea que funcionan bien funcionan mejor. En lugar de escribir grandes módulos de Terraform que intenten hacer todo de una vez, haga partes de ellos que hagan una cosa bien. Y luego combínalos como quieras.
¿Cómo se realizan cambios en las bibliotecas sin compatibilidad con versiones anteriores?
El módulo general de Terraform, como una biblioteca normal, debe informar de alguna manera a los usuarios sobre los cambios sin compatibilidad con versiones anteriores. Cuando tales cambios ocurren en las bibliotecas, es molesto, e igual de molesto cuando se realizan cambios sin compatibilidad con versiones anteriores en los módulos de Terraform. Se recomienda usar etiquetas git y semver cuando se usan módulos Terraform.
¿Se inicia el servicio de producción en su computadora portátil o en un centro de datos?
Hashicorp tiene herramientas como terraform cloud para lanzar tu terraform. Estos servicios centralizados facilitan la gestión, auditoría y aprobación de los cambios de terraforma.
¿No escribes pruebas?
Los ingenieros admiten que el código necesita ser probado, pero ellos mismos a menudo critican cuando trabajan con Terraform. Para la infraestructura, esto está lleno de momentos insidiosos. Le aconsejo que "pruebe" o "cree ejemplos" de pilas utilizando módulos que pueden implementarse adecuadamente para la verificación durante CI / CD.
La vida y muerte de las empresas de microservicios depende de la velocidad, la actualización y la destrucción de nuevas pilas de trabajo de microservicios.
El punto negativo más común relacionado con las arquitecturas de microservicios y que no se puede eliminar de ninguna manera está relacionado con el trabajo, y no con el código. Si toma Terraform, solo como una forma de automatizar solo el lado de la infraestructura de la arquitectura de microservicios, entonces se está privando de las verdaderas ventajas de este sistema. Ahora todo es como el código .