Representar a infraestrutura como código nun formato de texto repetible é unha boa práctica sinxela para sistemas que non precisan xogar cos ratos. Esta práctica ten un nome - , e ata agora hai dúas ferramentas populares para implementalo, especialmente en AWS: и .
Comparando a experiencia con Terraform e CloudFormation
Antes de vir (el ) Traballei e utilizou Terraform durante tres anos. No novo lugar, tamén usei Terraform con todas as miñas forzas e, a continuación, a empresa impulsou a transición a todo o que é a Amazon, incluído CloudFormation. Desenvolvín con dilixencia as mellores prácticas para ambos e usei ambas ferramentas en fluxos de traballo moi complexos para toda a organización. Máis tarde, despois de sopesar coidadosamente as implicacións da migración de Terraform a CloudFormation, convencínme de que Terraform era probablemente a mellor opción para a organización.
Terraform Horrible
Software beta
Terraform aínda non lanzou a versión 1.0, o que é unha boa razón para non usala. Cambiou moito desde que o probei eu, pero daquela terraform apply moitas veces avariaba despois de varias actualizacións ou simplemente despois dun par de anos de uso. Eu diría que "agora todo é diferente", pero... iso é o que parecen dicir todos, non? Hai cambios que son incompatibles coas versións anteriores, aínda que son apropiados, e mesmo parece que a sintaxe e as abstraccións dos almacéns de recursos son agora o que necesitamos. O instrumento parece que mellorou moito, pero... :-0
Por outra banda, AWS fixo un bo traballo mantendo a compatibilidade con versións anteriores. Probablemente isto débese a que os seus servizos adoitan ser probados exhaustivamente dentro da organización e só entón, renombrados, publícanse. Entón, "esforzaron moito" é un eufemismo. Manter a compatibilidade con APIs para un sistema tan variado e complexo como AWS é incriblemente difícil. Calquera persoa que tivese que manter API públicas que se usan tan amplamente como son debería entender o difícil que é facelo durante tantos anos. Pero o comportamento de CloudFormation, na miña memoria, nunca cambiou ao longo dos anos.
Coñece a perna... é unha bala
Polo que sei, elimina o recurso alleo A pila de CloudFormation da túa pila CF non é posible. O mesmo ocorre con Terraform. Permítelle importar recursos existentes na súa pila. Pódese dicir que a función é incrible, pero cun gran poder vén unha gran responsabilidade. Só tes que engadir un recurso á pila e, mentres estás a traballar coa túa pila, non podes eliminar nin cambiar este recurso. Un día foi contraproducente. Un día en Twitch, alguén importou accidentalmente o grupo de seguridade de AWS doutra persoa na súa propia pila de Terraform sen facer ningunha travesura. Introducín varios comandos e... o grupo de seguridade (xunto co tráfico entrante) desapareceu.
Terraform Genial
Recuperación de estados incompletos
Ás veces, CloudFormation non logra a transición completa dun estado a outro. Ao mesmo tempo, tentará volver ao anterior. É unha mágoa que isto non sempre sexa viable. Pode dar moito medo depurar o que pasou máis tarde (nunca se sabe se CloudFormation estará feliz de que o pirateen), incluso só para solucionalo. Se poderá volver ao estado anterior ou non, realmente non sabe como determinalo e, por defecto, garda horas esperando un milagre.
Terraform, por outra banda, tende a recuperarse das transicións fallidas con moita máis gracia e ofrece ferramentas de depuración avanzadas.
Cambios máis claros no estado do documento
"Está ben, equilibrador de carga, estás a cambiar. Pero como?"
—Enxeñeiro ansioso, listo para premer o botón "aceptar".
Ás veces teño que facer algunhas manipulacións co equilibrador de carga na pila de CloudFormation, como engadir un número de porto ou cambiar un grupo de seguridade. ClouFormation mostra mal os cambios. Eu, con alfinetes e agullas, comprobo o ficheiro yaml dez veces para asegurarme de que non borrei nada necesario e non engadín nada innecesario.
Terraform é moito máis transparente neste sentido. Ás veces mesmo é demasiado transparente (léase: molesto). Afortunadamente, a última versión inclúe unha visualización mellorada dos cambios para que agora poidas ver exactamente o que está a cambiar.
Flexibilidade
Escribir software ao revés.
Para dicilo sen rodeos, a característica máis importante do software de longa duración é a capacidade de adaptarse ao cambio. Escribe calquera software ao revés. A maioría das veces cometín erros tomando un servizo "simple" e despois comecei a agrupar todo nunha única pila de CloudFormation ou Terraform. E, por suposto, meses despois revelouse que entendín todo mal, e que o servizo non era sinxelo! E agora teño que romper dalgún xeito unha pila grande en pequenos compoñentes. Cando traballas con CloudFormation, isto só se pode facer recreando primeiro a pila existente, e non o fago coas miñas bases de datos. Terraform, por outra banda, permitiu diseccionar a pila e dividila en partes máis pequenas máis comprensibles.
Módulos en git
Compartir código de Terraform en varias pilas é moito máis sinxelo que compartir código de CloudFormation. Con Terraform, podes poñer o teu código nun repositorio git e acceder a el mediante o control de versións semántica. Calquera persoa con acceso a este repositorio pode reutilizar o código compartido. O equivalente de CloudFormation é S3, pero non ten os mesmos beneficios, e non hai ningunha razón para que abandonemos git en favor de S3.
A organización creceu e a capacidade de compartir pilas comúns alcanzou un nivel crítico. Terraform fai que todo isto sexa sinxelo e natural, mentres que CloudFormation fará que salte entre os aros antes de que poidas conseguir que algo así funcione.
Operacións como código
"Imos escribir o guión e está ben".
—un enxeñeiro 3 anos antes de inventar a bicicleta Terraform.
Cando se trata de desenvolvemento de software, Go ou un programa Java non é só código.
Código como Código
Tamén está a infraestrutura na que traballa.
A infraestrutura como código
Pero de onde é ela? Como supervisalo? Onde vive o teu código? Os desenvolvedores necesitan permiso de acceso?
Operacións como Código
Ser un programador de software non significa só escribir código.
AWS non é o único: probablemente use outros provedores. SignalFx, PagerDuty ou Github. Quizais teñas un servidor interno de Jenkins para CI/CD ou un panel interno de Grafana para supervisar. Infra as Code elíxese por diferentes motivos, e cada un é igualmente importante para todo o relacionado co software.
Cando traballaba en Twitch, aceleramos os servizos dentro dos sistemas mixtos integrados e AWS de Amazon. Producimos e admitimos moitos microservizos, aumentando os custos operativos. As discusións foron algo así:
- Я: Caramba, son moitos xestos para facer overclock nun microservizo. Terei que usar este lixo para crear unha conta de AWS (foimos a 2 contas microservizo), despois esta para configurar alertas, esta para un repositorio de código, e esta para unha lista de correo electrónico, e despois esta...
- Chumbo: Imos escribir o guión e vale.
- Я: Está ben, pero o guión en si cambiará. Necesitaremos un xeito de comprobar que todos estes aparellos de Amazon integrados estean actualizados.
- Chumbo: Parece ben. E escribiremos un guión para iso.
- Я: Xenial! E probablemente o script aínda teña que establecer parámetros. Os aceptará?
- Chumbo: Que leve a onde vai!
- Я: O proceso pode cambiar e perderase a compatibilidade con versións anteriores. Será necesario algún tipo de control de versión semántico.
- Chumbo: Boa idea!
- Я: As ferramentas pódense cambiar manualmente, dentro da interface de usuario. Necesitaremos un xeito de comprobar e solucionar isto.
… 3 anos despois:
- Chumbo: E temos terraform.
A moralexa da historia é: aínda que ti de cabeza en todo Amazon, aínda estás usando algo que non é de AWS e estes servizos teñen un estado que usa unha linguaxe de configuración para manter ese estado sincronizado.
CloudFormation lambda vs módulos git terraform
lambda é a solución de CloudFormation para o problema de lóxica personalizada. Con lambda podes ou . Este enfoque introduce complexidades adicionais que non están presentes na versión semántica dos módulos git de Terraform. Para min, o problema máis urxente foi xestionar os permisos de todas estas lambdas de usuarios (e son ducias de contas de AWS). Outro problema importante foi o problema do "que foi primeiro, a galiña ou o ovo?": estaba relacionado co código lambda. Esta función en si é infraestrutura e código, e precisa de seguimento e actualizacións. O cravo final no cadaleito foi a dificultade para actualizar semanticamente os cambios de código lambda; tamén tivemos que asegurarnos de que as accións de pila sen un comando directo non cambiasen entre execucións.
Recordo que unha vez quixen crear unha implementación canaria para o ambiente Elastic Beanstalk cun equilibrador de carga clásico. O máis sinxelo sería facer unha segunda implementación para o EB xunto ao ambiente de produción, dando un paso máis aló: combinando o grupo de despregamento canario de escalado automático coa implementación LB no ambiente de produción. E xa que Terraform usa , isto requirirá 4 liñas de código adicionais en Terraform. Cando preguntei se había unha solución comparable en CloudFormation, apuntáronme a un repositorio git completo cunha canalización de implantación e todo, todo por algo que poderían facer as malas liñas 4 de código Terraform.
Detecta mellor a deriva
Asegúrate de que a realidade coincida coas expectativas.
é unha función de operacións moi poderosa como código porque axuda a garantir que a realidade coincida coas expectativas. Está dispoñible tanto con CloudFormation como con Terraform. Pero a medida que creceu a pila de produción, a busca de deriva en CloudFormation produciu cada vez máis deteccións falsas.
Con Terraform tes ganchos de ciclo de vida moito máis avanzados para a detección de deriva. Por exemplo, introduce o comando directamente na definición de tarefa ECS se quere ignorar os cambios nunha definición de tarefa específica sen ignorar os cambios en toda a súa implementación ECS.
CDK e o futuro de CloudFormation
CloudFormation é difícil de xestionar a grandes escalas de infraestruturas cruzadas. Recoñécense moitas destas dificultades e a ferramenta necesita cousas como , un marco para definir a infraestrutura de nube en código e executalo a través de AWS CloudFormation. Será interesante ver o que lle depara o futuro a aws-cdk, pero terá dificultades para competir coas outras fortalezas de Terraform; para actualizar CloudFormation, serán necesarios cambios globais.
Para que Terraform non defrauda
Trátase de "infraestrutura como código" e non "como texto".
A miña primeira impresión de Terraform foi bastante mala. Creo que non entendín o enfoque. Case todos os enxeñeiros percíbeno involuntariamente como un formato de texto que hai que converter na infraestrutura desexada. NON O FAGAS DESTA FORMA.
Os truismos do bo desenvolvemento de software tamén se aplican a Terraform.
Vin moitas prácticas adoptadas para crear un bo código ignoradas en Terraform. Levaches anos estudando para ser un bo programador. Non abandones esta experiencia só porque estás a traballar con Terraform. Os truismos do bo desenvolvemento de software aplícanse a Terraform.
Como non se pode documentar o código?
Vin enormes pilas de Terraform sen absolutamente ningunha documentación. Como podes escribir código en páxinas, sen absolutamente ningunha documentación? Engade documentación que explique o teu código Terraform (énfase na palabra "código"), por que esta sección é tan importante e que fas.
Como podemos implementar servizos que antes foron unha gran función main()?
Vin pilas de Terraform moi complexas presentadas como un único módulo. Por que non implementamos o software deste xeito? Por que dividimos as funcións grandes noutras máis pequenas? As mesmas respostas aplícanse a Terraform. Se o teu módulo é demasiado grande, debes dividilo en módulos máis pequenos.
A túa empresa non usa bibliotecas?
Vin como enxeñeiros, elaborando un novo proxecto usando Terraform, copiaban estúpidamente anacos enormes doutros proxectos nos seus propios e, despois, retocaban con eles ata que comezou a funcionar. Traballarías así con código de "combate" na túa empresa? Non só usamos bibliotecas. Si, pero onde estamos sen bibliotecas compartidas en principio?!
Non estás usando PEP8 ou gofmt?
A maioría das linguas teñen un esquema de formato estándar e aceptado. En Python isto é PEP8. En Go - gofmt. Terraform ten o seu propio: terraform fmt. Disfrútao pola túa saúde!
Usarás React sen coñecer JavaScript?
Os módulos Terraform poden simplificar algunha parte da complexa infraestrutura que creas, pero isto non significa que non poidas xogar con ela en absoluto. Queres usar Terraform correctamente sen comprender os recursos? Estás condenado: o tempo pasará e nunca dominarás Terraform.
Estás codificando con singletons ou inxección de dependencias?
A inxección de dependencias é unha boa práctica recoñecida para o desenvolvemento de software e prefírese aos singletons. Como é útil isto en Terraform? Vin módulos de Terraform que dependen do estado remoto. En lugar de escribir módulos que recuperen o estado remoto, escriba un módulo que tome parámetros. E despois pase estes parámetros ao módulo.
As túas bibliotecas fan ben dez cousas ou unha cousa xenial?
As bibliotecas que mellor funcionan son aquelas que se centran nunha tarefa que fan moi ben. En lugar de escribir grandes módulos de Terraform que tentan facer todo á vez, constrúe partes deles que fagan ben unha cousa. E despois combínaos segundo sexa necesario.
Como facer cambios nas bibliotecas sen compatibilidade con versións anteriores?
Un módulo común de Terraform, como unha biblioteca normal, precisa dalgunha maneira comunicar os cambios aos usuarios sen ser compatible con versións anteriores. É molesto cando se producen estes cambios nas bibliotecas, e igual de molesto cando se fan cambios non compatibles con versións anteriores nos módulos de Terraform. Recoméndase usar etiquetas git e semver cando se usan módulos Terraform.
O teu servizo de produción funciona no teu portátil ou nun centro de datos?
Hashicorp ten ferramentas como para executar o teu terraform. Estes servizos centralizados facilitan a xestión, auditoría e aprobación dos cambios de terraform.
Non escribes probas?
Os enxeñeiros recoñecen que o código debe ser probado, pero eles mesmos adoitan esquecerse das probas cando traballan con Terraform. Para as infraestruturas, isto está cheo de momentos traizoeiros. O meu consello é "probar" ou "crear pilas de exemplo" utilizando módulos que se poidan implementar correctamente para probar durante CI/CD.
Terraform e microservizos
A vida e a morte das empresas de microservizos dependen da velocidade, a innovación e a interrupción das novas pilas de traballo de microservizos.
O aspecto negativo máis común asociado ás arquitecturas de microservizos, e que non se pode eliminar, está relacionado co traballo, non co código. Se pensas en Terraform só como unha forma de automatizar só o lado da infraestrutura dunha arquitectura de microservizos, estás perdendo os verdadeiros beneficios do sistema. Agora xa está .
Fonte: www.habr.com