Parece que os desenvolvedores de Terraform ofrecen mellores prácticas bastante convenientes para traballar coa infraestrutura de AWS. Só hai un matiz. Co paso do tempo, o número de ambientes aumenta, cada un coas súas características. Case unha copia da pila de aplicacións aparece na rexión veciña. E o código de Terraform debe ser coidadosamente copiado e editado segundo os novos requisitos ou transformado nun copo de neve.
O meu informe sobre patróns en Terraform para combater o caos e a rutina manual en proxectos grandes e longos.
Vídeo:
Teño 40 anos, levo 20 en informática. Levo 12 anos traballando para Ixtens. Estamos comprometidos no desenvolvemento impulsado polo comercio electrónico. E levo 5 anos practicando prácticas de DevOps.
A miña historia versará sobre a miña experiencia nun proxecto nunha empresa cuxo nome non vou dicir, escondido detrás dun acordo de non divulgación.
Indícanse os números da diapositiva para comprender a escala do proxecto. E todo o que vou dicir a continuación está relacionado con Amazon.
Sumeime a este proxecto hai 4 anos. E a refactorización de infraestruturas estaba en pleno auxe porque o proxecto medraba. E os patróns que se empregaban xa non eran axeitados. E tendo en conta todo o crecemento previsto do proxecto, foi necesario dar con algo novo.
Grazas a Matvey, que onte nos contou o que pasou en Dodo Pizza. Isto é o que pasou aquí hai 4 anos.
Os desenvolvedores viñeron e comezaron a facer código de infraestrutura.
As razóns máis obvias polas que se requiría isto era o tempo de comercialización. Era necesario asegurarse de que o equipo DevOps non fose un pescozo de botella durante o lanzamento. E, entre outras cousas, Terraform e Puppet utilizáronse no primeiro nivel.
Terraform é un proxecto de código aberto de HashiCorp. E para os que nin sequera saben o que é isto, as próximas diapositivas.
A infraestrutura como código significa que podemos describir a nosa infraestrutura e pedirlle a algúns robots que se aseguren de que recibimos os recursos que describimos.
Por exemplo, necesitamos unha máquina virtual. Describiremos e engadiremos varios parámetros necesarios.
Despois diso, configuraremos o acceso a Amazon na consola. E pediremos o plan Terraform. O plan Terraform dirá: "Está ben, podemos facer estas cousas polo teu recurso". E engadirase polo menos un recurso. E non se esperan cambios.
Unha vez que estea satisfeito con todo, pode solicitar a Terraform que solicite e Terraform creará unha instancia para vostede e recibirá unha máquina virtual na súa nube.
Ademais o noso proxecto está a desenvolverse. Estamos engadindo algúns cambios alí. Solicitamos máis instancias, sumamos 53 entradas.
E repetimos. Por favor, planifica. Vemos que cambios están previstos. Aplicamos. E así crece a nosa infraestrutura.
Terraform usa algo chamado ficheiros de estado. É dicir, todos os cambios que van a Amazon gárdanse nun ficheiro onde para cada recurso que describiches hai os correspondentes recursos que foron creados en Amazon. Así, cando a descrición dun recurso cambia, Terraform sabe exactamente o que hai que cambiar en Amazon.
Estes ficheiros de estado orixinalmente eran só ficheiros. E almacenámolos en Git, o que era moi inconveniente. Alguén sempre se esquecía de cometer cambios, e xurdiron moitos conflitos.
Agora é posible usar o backend, é dicir, Terraform especifícase en que depósito e con que clave se debe gardar o ficheiro de estado. E o propio Terraform encargarase de conseguir este ficheiro de estado, facendo toda a maxia e devolvendo o resultado final.
A nosa infraestrutura está a medrar. Aquí está o noso código. E agora non queremos só crear unha máquina virtual, queremos ter un ambiente de proba.
Terraform permítelle crear un módulo, é dicir, describir o mesmo nalgún cartafol.
E, por exemplo, na proba, chama a este módulo e obtén o mesmo que se executaramos Terraform aplica no propio módulo. Para probas haberá este código.
Para a produción, podemos enviar algúns cambios alí, porque nas probas non necesitamos grandes instancias; en produción, as grandes instancias son só útiles.
E entón volverei ao proxecto. Foi unha tarefa difícil, a infraestrutura prevista era moi grande. E foi necesario colocar dalgún xeito todo o código para que fose conveniente para todos: tanto para os que realizan o mantemento deste código como para os que fan cambios. E estaba previsto que calquera desenvolvedor puidese ir arranxar a infraestrutura segundo fose necesario para a súa parte da plataforma.
Esta é unha árbore de directorios recomendada polo propio HashiCorp se tes un proxecto grande e ten sentido dividir toda a infraestrutura nalgúns pequenos anacos e describir cada peza nun cartafol separado.
Tendo unha extensa biblioteca de recursos, pode chamar aproximadamente o mesmo en probas e en produción.
No noso caso, isto non era totalmente axeitado, porque a pila de probas para desenvolvedores ou para probas tiña que obterse dalgún xeito máis sinxelo. Pero non quería percorrer os cartafoles e aplicalos na secuencia requirida e preocuparme de que a base de datos aumentase, e entón a instancia que usa esta base de datos aumentase. Polo tanto, todas as probas lanzáronse desde un cartafol. Alí chamáronse os mesmos módulos, pero facíase todo nunha soa carreira.
Terraform encárgase de todas as dependencias. E sempre crea recursos na secuencia para que poidas obter un enderezo IP, por exemplo, dunha instancia recentemente creada, e obter este enderezo IP no rexistro de route53.
Ademais, a plataforma é moi grande. E lanzar unha pila de probas, aínda que sexa durante unha hora, aínda que sexa durante 8 horas, é unha empresa bastante cara.
E automatizamos este asunto. E o traballo de Jenkins permitiunos executar a pila. Nel, foi necesario lanzar unha solicitude de extracción cos cambios que o desenvolvedor quere probar, especificar todas as opcións, compoñentes e dimensións necesarias. Se quere probas de rendemento, pode tomar máis casos. Se só precisa comprobar que se abre algún formulario, podería comezar co salario mínimo. E tamén indicar se é necesario ou non un clúster, etc.
E entón Jenkins empuxou un script de shell, que modificou lixeiramente o código no cartafol Terraform. Eliminei ficheiros innecesarios e engadín os ficheiros necesarios. E despois, cunha aplicación de Terraform, a pila subiu.
E despois houbo outros pasos nos que non quero entrar.
Debido a que para probar necesitabamos un pouco máis de opcións que na produción, tivemos que facer copias dos módulos para que nestas copias puidésemos engadir aquelas funcionalidades que só eran necesarias para probar.
E ocorreu que nas probas quero probar eses cambios que finalmente entrarán en produción. Pero, de feito, probouse unha cousa e utilizouse outra lixeiramente diferente na produción. E houbo unha pequena ruptura no patrón de que na produción todos os cambios foron aplicados polo equipo operativo. E ás veces resultou que aqueles cambios que debían pasar das probas á produción quedaban noutra versión.
Ademais, houbo tal problema que se engadiu un novo servizo, que era lixeiramente diferente dalgún xa existente. E en lugar de modificar un módulo existente, tivemos que facer unha copia do mesmo e engadir os cambios necesarios.
Esencialmente, Terraform non é unha linguaxe real. Esta é unha declaración. Se necesitamos declarar algo, entón declarámolo. E todo funciona.
Nalgún momento, cando se estaba a discutir unha das miñas solicitudes de extracción, un dos meus compañeiros dixo que non había necesidade de crear copos de neve. Pregunteime que quería dicir. Hai un feito científico de que non hai dous copos de neve idénticos no mundo, todos son lixeiramente diferentes. E en canto escoitei isto, inmediatamente sentín todo o peso do código Terraform. Porque cando era necesario pasar de versión en versión, Terraform requiría romper a cadea de cambios, é dicir, o código xa non era compatible coa seguinte versión. E tivemos que facer un pull request, que cubría case a metade dos ficheiros da infraestrutura, para levar a infraestrutura á seguinte versión de Terraform.
E despois de aparecer tal copo de neve, todo o código Terraform que tiñamos convertido nunha gran, gran morea de neve.
Para un desenvolvedor externo que está fóra da operación, isto non lle importa moito, porque fixo unha solicitude de extracción, comezou o seu recurso. E iso é todo, xa non é a súa preocupación. E o equipo de DevOps, que se asegura de que todo estea ben, debe facer todos estes cambios. E o custo destes cambios aumentou moito, moito con cada copo de neve adicional.
Hai unha historia sobre como un estudante dun seminario debuxa dous círculos perfectos con xiz no encerado. E o profesor sorpréndese de como conseguiu debuxar con tanta fluidez sen compás. O estudante responde: "Moi sinxelo, pasei dous anos no exército facendo un moedor de carne".
E dos catro anos que levo implicado neste proxecto, levo uns dous anos facendo Terraform. E, por suposto, teño algúns trucos, algúns consellos sobre como simplificar o código de Terraform, traballar con el como unha linguaxe de programación e reducir a carga dos desenvolvedores que deben manter este código actualizado.
O primeiro polo que me gustaría comezar son ligazóns simbólicas. Terraform ten moito código repetitivo. Por exemplo, a chamada ao provedor en case todos os puntos onde creamos unha infraestrutura é a mesma. E é lóxico poñelo nun cartafol separado. E sempre que o provedor teña que facer ligazóns simbólicas a este ficheiro.
Por exemplo, na produción usas asumir o rol, o que che permite obter dereitos de acceso a algunha conta externa de Amazon. E tendo cambiado un ficheiro, todos os restantes da árbore de recursos terán os dereitos necesarios para que Terraform saiba a que segmento de Amazon acceder.
Onde fallan as ligazóns simbólicas? Como dixen, Terraform ten ficheiros estatais. E son moi, moi chulos. Pero o caso é que Terraform inicializa o backend en primeiro lugar. E non pode usar ningunha variable nestes parámetros, deben estar sempre escritos en texto.
E como resultado, cando alguén crea un novo recurso, copia parte do código doutros cartafoles. E pode cometer un erro coa chave ou co balde. Por exemplo, fai unha cousa de sandbox a partir de sandbox e despois faino en produción. E por iso pode resultar que o balde en produción será usado desde a caixa de area. Por suposto, atoparano axiña. Será posible arranxar isto dalgún xeito, pero non obstante é unha perda de tempo e, en certa medida, de recursos.
Que podemos facer despois? Antes de traballar con Terraform, cómpre inicializalo. Na inicialización, Terraform descarga todos os complementos. Nalgún momento separáronse dunha arquitectura monolito a unha arquitectura de microservizos. E sempre cómpre facer Terraform init para que tire todos os módulos, todos os complementos.
E pode usar un script de shell, que, en primeiro lugar, pode obter todas as variables. O script de shell non está limitado de ningún xeito. E, en segundo lugar, os camiños. Se sempre usamos o camiño que está no repositorio como clave para o ficheiro de estado, entón, en consecuencia, o erro aquí eliminarase.
Onde podo obter os datos? Ficheiro JSON. Terraform permítelle escribir infraestrutura non só en hcl (HashiCorp Configuration Language), senón tamén en JSON.
JSON é fácil de ler desde un script de shell. En consecuencia, pode poñer o ficheiro de configuración con balde nalgún lugar. E use este balde tanto no código Terraform como no script de shell para a inicialización.
Por que é importante ter un balde para Terraform? Porque hai algo como ficheiros de estado remoto. É dicir, cando plantexo algún recurso, para dicirlle a Amazon: "Por favor, crea unha instancia", teño que especificar moitos parámetros necesarios.
E estes identificadores almacénanse noutro cartafol. E podo dicir: "Terraform, corre ao ficheiro de estado dese mesmo recurso e pídeme estes identificadores". E así aparece unha certa unificación entre rexións ou ambientes diferentes.
Non sempre é posible usar un ficheiro de estado remoto. Por exemplo, creaches un VPC a man. E o código de Terraform que crea o VPC crea VPC tan diferentes que levará moito tempo e terás que axustar un ao outro, polo que podes usar o seguinte truco.
É dicir, facer un módulo que pareza facer un VPC e, por así dicilo, dáche identificadores, pero en realidade simplemente hai un ficheiro con valores codificados que se pode usar para crear a mesma instancia.
Non sempre é necesario gardar o ficheiro de estado na nube. Por exemplo, ao probar módulos, pode usar a inicialización do backend, onde o ficheiro simplemente se gardará no disco no momento da proba.
Agora un pouco sobre probas. Que podes probar en Terraform? Probablemente é posible moito, pero falarei destas 4 cousas.
HashiCorp entende como se debe formatar o código Terraform. E Terraform fmt permítelle formatar o código que edita segundo esta crenza. En consecuencia, as probas deben verificar necesariamente se o formato se corresponde co que legou HashiCorp, para que non sexa necesario cambiar a localización dos corchetes, etc.
O seguinte é Terraform validate. Non fai máis que comprobar a sintaxe - ala, se todos os parénteses están emparellados. Que é importante aquí? A nosa infraestrutura é moi ampla. Hai moitos papás diferentes nel. E en cada un cómpre executar Terraform validate.
En consecuencia, para acelerar as probas, executamos varios procesos en paralelo usando paralelo.
Paralelo é algo moi chulo, utilízao.
Pero cada vez que Terraform se inicia, vai a HashiCorp e pregunta: "Cales son as últimas versións do complemento? E o complemento que teño na caché, é o correcto ou o incorrecto?" E isto diminuíu a cada paso.
Se lle indicas a Terraform onde están os complementos, Terraform dirá: "Está ben, isto é probablemente o último que hai. Non irei a ningún lado, comezarei inmediatamente a validar o teu código Terraform".
Para encher o cartafol cos complementos necesarios, temos un código Terraform moi sinxelo que só precisa inicializar. Aquí, por suposto, debes especificar todos os provedores que dalgún xeito participan no teu código, se non, Terraform dirá: "Non coñezo un determinado provedor porque non está na caché".
O seguinte é o plan Terraform. Como dixen, o desenvolvemento é cíclico. Facemos cambios no código. E entón cómpre descubrir cales son os cambios previstos para a infraestrutura.
E cando a infraestrutura é moi, moi grande, pode cambiar un módulo, arranxar algún ambiente de proba ou algunha rexión específica e romper algún veciño. Polo tanto, deberíase facer o plan Terraform para toda a infraestrutura e mostrar cales son os cambios previstos.
Podes facelo de forma intelixente. Por exemplo, escribimos un script de Python que resolve dependencias. E dependendo do que se modificou: un módulo Terraform ou só un compoñente específico, fai plans para todos os cartafoles dependentes.
Os planos de Terraform deben facerse previa solicitude. Polo menos iso é o que facemos.
Por suposto, é bo facer probas para cada cambio, para cada compromiso, pero os plans son algo bastante caro. E nunha solicitude de extracción dicimos: "Por favor, dáme os plans". O robot comeza. E envía comentarios ou adxunta todos os plans que se esperan dos teus cambios.
Un plan é unha cousa bastante cara. Leva tempo porque Terraform vai a Amazon e pregunta: "Aínda existe esta instancia? Esta escala automática ten exactamente os mesmos parámetros?" E para acelerar isto, podes usar un parámetro como refresh=false. Isto significa que Terraform descargará o estado desde S3. E crerá que o estado coincidirá exactamente co que hai en Amazon.
Tal plan de Terraform vai moito máis rápido, pero o estado debe corresponder á túa infraestrutura, é dicir, nalgún lugar, nalgún momento debe comezar a actualización de Terraform. A actualización de Terraform fai exactamente iso: o estado coincide co que hai na infraestrutura real.
E hai que falar de seguridade. Por aquí tiñamos que comezar. Onde executas Terraform e Terraform funciona na túa infraestrutura hai unha vulnerabilidade. É dicir, esencialmente estás executando o código. E se a solicitude de extracción contén algún tipo de código malicioso, pódese executar nunha infraestrutura que teña demasiado acceso. Polo tanto, teña coidado onde executa o plan Terraform.
O seguinte do que me gustaría falar é das probas de datos do usuario.
Que son os datos do usuario? En Amazon, cando creamos unha instancia, podemos enviar unha determinada carta coa instancia: metadatos. Cando se inicia a instancia, normalmente cloud init está sempre presente nestas instancias. Cloud init le esta carta e di: "OK, hoxe son o equilibrador de carga". E de acordo con estes convenios realiza algunhas accións.
Pero, desafortunadamente, cando creamos o plan Terraform e aplicamos Terraform, os datos do usuario parecen este tipo de masa de números. É dicir, simplemente envíache o hash. E todo o que podes ver no plan é se haberá algún cambio ou se o hash seguirá sendo o mesmo.
E se non prestas atención a isto, entón algún ficheiro de texto roto pode acabar en Amazon, na infraestrutura real.
Alternativamente, ao executar, pode especificar non toda a infraestrutura, senón só o modelo. E no código di: "Mostra este modelo na miña pantalla". E, como resultado, podes obter unha impresión de como serán os teus datos en Amazon.
Outra opción é usar un módulo para xerar datos de usuario. Aplicarás este módulo. Recibes o ficheiro no disco. Compárao co de referencia. E así, se algún rapaz decide corrixir un pouco os datos do usuario, as súas probas dirán: "OK, hai algúns cambios aquí e alí, isto é normal".
O seguinte do que me gustaría falar é a aplicación automatizada de Terraform.
Por suposto, dá bastante medo facer a aplicación de Terraform en modo automático, porque quen sabe que cambios chegaron alí e o destrutivos que poden ser para a infraestrutura viva.
Para un ambiente de proba, todo isto é normal. É dicir, un traballo que cree un ambiente de proba é o que necesitan todos os desenvolvedores. E unha expresión como "todo funcionou para min" non é un meme divertido, senón unha proba de que unha persoa se confundiu, levantou unha pila e realizou algunhas probas nesta pila. E asegurouse de que todo estaba ben alí e dixo: "Está ben, o código que estou a publicar foi probado".
En ambientes de produción, sandbox e outros que son máis críticos para o negocio, podes usar parcialmente algúns recursos de forma bastante segura porque non provoca que ninguén morra. Estes son: grupos de escala automática, grupos de seguridade, roles, ruta53 e a lista pode ser bastante grande. Pero estea atento ao que está a suceder, lea os informes automatizados das aplicacións.
Cando sexa perigoso ou asustado aplicar, por exemplo, se estes son algúns recursos persistentes dunha base de datos, recibirá informes de que hai cambios sen aplicar nalgunha parte da infraestrutura. E o enxeñeiro, baixo supervisión, comeza traballos para aplicar ou faino desde a súa consola.
Amazon ten algo como Terminar protección. E pode protexer nalgúns casos de cambios que non son necesarios para ti. É dicir, Terraform foi a Amazon e dixo: "Necesito matar esta instancia para facer outra". E Amazon di: "Sentímolo, hoxe non. Temos protección Terminate".
E a guinda do pastel é a optimización do código. Cando traballamos con código Terraform, debemos pasar un número moi grande de parámetros ao módulo. Estes son os parámetros necesarios para crear algún tipo de recurso. E o código convértese en grandes listas de parámetros que hai que pasar de módulo en módulo, de módulo en módulo, especialmente se os módulos están aniñados.
E é moi difícil de ler. É moi difícil revisar isto. E moitas veces resulta que algúns parámetros son revisados e non son exactamente o que se necesita. E isto custa tempo e diñeiro para arranxar máis tarde.
Polo tanto, suxiro que use tal cousa como un parámetro complexo que inclúe unha determinada árbore de valores. É dicir, necesitas algún tipo de cartafol onde teñas todos os valores que che gustaría ter nalgún ambiente.
E chamando a este módulo, pódese obter unha árbore que se xera nun módulo común, é dicir, nun módulo común que funcione igual para toda a infraestrutura.
Neste módulo podes facer algúns cálculos usando unha característica tan recente en Terraform como locais. E despois, cunha saída, dá algún parámetro complexo, que pode incluír hash de matriz, etc.
Aquí é onde remataron todos os mellores descubrimentos que teño. E gustaríame contar unha historia sobre Colón. Cando buscaba cartos para a súa expedición para descubrir a India (como el pensaba entón), ninguén o cría e pensaron que era imposible. Entón dixo: "Asegúrese de que o ovo non caia". Todos os banqueiros, xente moi rica e seguramente intelixente, tentaron colocar dalgunha maneira o ovo, e este seguía caendo. Entón Colón colleu o ovo e premeuno un pouco. A casca engurrou e o ovo quedou inmóbil. Eles dixeron: "Oh, iso é moi doado!" E Colón respondeu: “Si, é moi sinxelo. E cando abro a India, todos usarán esta ruta comercial".
E o que che acabo de dicir probablemente sexan cousas bastante sinxelas e triviais. E cando aprendes sobre eles e comezas a utilizalos, está na orde das cousas. Así que aproveita. E se estas son cousas completamente normais para ti, polo menos sabes como colocar o ovo para que non caia.
Resumemos:
- Tenta evitar os copos de neve. E cantos menos copos de neve, menos recursos necesitarás para facer cambios na túa gran infraestrutura.
- Cambios constantes. É dicir, cando se producen algúns cambios no código, cómpre que a súa infraestrutura cumpra con estes cambios o máis rápido posible. Non debería haber unha situación na que alguén veña mirar a Elasticsearch dous ou tres meses despois, faga un plan Terraform e haxa unha morea de cambios que non esperaba. E leva moito tempo poñer todo en orde.
- Probas e automatización. Canto máis estea cuberto de probas e funcións o teu código, máis seguro tes de que estás facendo todo correctamente. E a entrega automática aumentará a túa confianza moitas veces.
- O código para os ambientes de proba e produción debería ser case o mesmo. Practicamente, porque a produción aínda é un pouco diferente e aínda haberá algúns matices que irán máis aló do ambiente de proba. Pero, con todo, máis ou menos, isto pódese garantir.
- E se tes moito código de Terraform e leva moito tempo manter este código actualizado, nunca é tarde para refactorizar e poñelo en boa forma.
- Infraestrutura inmutable. Entrega de AMI a tempo.
- Estrutura para a ruta 53 cando tes moitas entradas e queres que estean nunha orde coherente.
- Loitando contra os límites de taxas da API. É entón cando Amazon di: "Isto é todo, non podo aceptar máis solicitudes, espera". E a metade da oficina está á espera de que poida poñer en marcha a súa infraestrutura.
- Instancias puntuales. Amazon non é un evento barato e os lugares permítenche aforrar moito. E alí podedes contar toda unha reportaxe ao respecto.
- Funcións de seguridade e IAM.
- Buscando recursos perdidos, cando tes casos de orixe descoñecida en Amazone, comen cartos. Aínda que as instancias custan entre 100 e 150 dólares ao mes, isto supón máis de 1 dólares ao ano. Atopar tales recursos é un negocio rendible.
- E instancias reservadas.
Iso é todo para min. Terraform é moi chulo, úsao. Grazas!
preguntas
Grazas polo informe! O teu ficheiro de estado está en S3, pero como solucionas o problema de que varias persoas poidan tomar este ficheiro de estado e tentar expandilo?
En primeiro lugar, non temos présa. En segundo lugar, hai bandeiras, nas que informamos de que estamos a traballar nalgún anaco de código. É dicir, a pesar de que a infraestrutura é moi grande, isto non significa que alguén estea a usar algo constantemente. E cando había unha fase activa, este era un problema; almacenamos ficheiros de estado en Git. Isto era importante, se non, alguén faría un ficheiro de estado, e tiñamos que armalos manualmente para que todo continuase. Agora non hai tal problema. En xeral, Terraform resolveu este problema. E se algo está a cambiar constantemente, podes usar bloqueos, que impiden o que dixeches.
Estás usando código aberto ou empresa?
Sen empresa, é dicir, todo o que podes descargar e descargar gratis.
Chámome Stanislav. Quería facer un pequeno engadido. Falaches dunha función de Amazon que che permite facer que unha instancia non se poida matar. Isto tamén está no propio Terraform; no bloque Life Second podes especificar unha prohibición de cambios ou unha prohibición de destrución.
O tempo era limitado. Bo punto.
Tamén quería preguntarlle dúas cousas. En primeiro lugar, falaches de probas. Usaches algunha ferramenta de proba? Oín falar do complemento Test Kitchen. Quizais haxa algo máis. E tamén me gustaría preguntar polos Valores Locais. En que se diferencian fundamentalmente das variables de entrada? E por que non podo parametrizar algo só a través de Valores locais? Tentei descubrir este tema, pero dalgunha maneira non puiden descifralo eu.
Podemos falar con máis detalle fóra desta sala. As nosas ferramentas de proba son totalmente feitas por si mesmos. Non hai nada que probar. En xeral, hai opcións cando as probas automatizadas recollen a infraestrutura nalgún lugar, comproban que está ben e despois destrúeno todo cun informe de que a túa infraestrutura aínda está en bo estado. Non temos isto porque as pilas de proba execútanse todos os días. E abonda. E se algo comeza a romperse, comezará a romperse sen que o comprobemos noutro lugar.
Respecto dos valores locais, sigamos coa conversa fóra da sala.
Ola! Grazas polo informe! Moi informativo. Dixeches que tes moito do mesmo tipo de código para describir a infraestrutura. Pensaches en xerar este código?
Gran pregunta, grazas! A cuestión é que cando usamos a infraestrutura como código, asumimos que miramos o código e entendemos que infraestrutura hai detrás dese código. Se se xera código, necesitamos imaxinar que código se xerará para comprender que tipo de infraestrutura haberá. Ou xeramos código, commitámolo e, esencialmente, ocorre o mesmo. Así que seguimos o camiño que escribimos, conseguímolo. Os xeradores máis apareceron un pouco máis tarde cando comezamos a fabricalos. E xa era tarde para cambiar.
Escoitaches algo sobre jsonnet?
Non
Mira, isto é moi chulo. Vexo un caso específico no que podes aplicalo e xerar unha estrutura de datos.
Os xeradores son bos cando os tes, como na broma sobre unha máquina de afeitar. É dicir, a primeira vez a cara é diferente, pero despois todos teñen a mesma cara. Os xeradores funcionan moi ben. Pero, por desgraza, as nosas caras son lixeiramente diferentes. Este é un problema.
Só mira. Grazas!
Chámome Maxim, son de Sberbank. Falabas un pouco de como estabas intentando levar Terraform ao equivalente a unha linguaxe de programación. Non é máis doado usar Ansible?
Son cousas moi diferentes. Podes crear recursos en Ansible e Puppet pode crear recursos en Amazon. Pero Terraform está directamente afiado.
Só tes Amazon?
Non é que só teñamos Amazon. Case só temos Amazon. Pero a característica fundamental é que Terraform lembra. En Ansible, se dis: "Dáme 5 instancias", entón aumentará e despois dis: "E agora necesito 3". E Terraform dirá: "Está ben, vou matar a 2", e Ansible dirá: "Está ben, aquí tes 3". Total 8.
Ola! Grazas polo teu informe! Foi moi interesante escoitar sobre Terraform. Gustaríame facer inmediatamente un pequeno comentario sobre o feito de que Terraform aínda non ten unha versión estable, así que trate a Terraform con moita cautela.
Unha boa culler para a cea. É dicir, se necesitas unha solución, ás veces posás o que é inestable, etc., pero funciona e axudounos.
A pregunta é esta. Usas o backend remoto, usas S 3. Por que non usas o backend oficial?
Oficial?
Nube Terraform.
Cando apareceu?
Hai uns 4 meses.
Se aparecera hai 4 anos, probablemente contestaría á túa pregunta.
Xa hai unha función e bloqueos incorporados, e podes almacenar un ficheiro de estado. Inténtalo. Pero tampouco o probei.
Viaxamos nun gran tren que circula a gran velocidade. E non podes coller uns poucos coches e tiralos.
Falabas de copos de neve, por que non usaches rama? Por que non funcionou así?
O noso enfoque é que toda a infraestrutura estea nun só repositorio. Terraform, Puppet, todos os scripts que dalgún xeito están relacionados con isto, están todos nun só repositorio. Deste xeito, podemos asegurarnos de que os cambios incrementais se proban un tras outro. Se fose unha morea de ramas, entón tal proxecto sería case imposible de manter. Pasan seis meses, e diverxen tanto que é só algún tipo de castigo. Isto é do que quería escapar antes de refactorizar.
Entón non funciona?
Isto non funciona en absoluto.
Na rama recorto a diapositiva do cartafol. É dicir, se o fas para cada pila de probas, por exemplo, o equipo A ten o seu propio cartafol, o equipo B ten o seu propio cartafol, entón isto tampouco funciona. Creamos un código de ambiente de proba unificado que era o suficientemente flexible para adaptarse a todos. É dicir, servimos un código.
Ola! Chámome Yura! Grazas polo informe! Pregunta sobre módulos. Vostede di que está a usar módulos. Como se resolve o problema se se fixeron cambios nun módulo que non son compatibles co cambio doutra persoa? Estás versionando os módulos dalgún xeito ou intentas traer un wunderwaffle para cumprir dous requisitos?
Este é un gran problema de acumulación de neve. Isto é o que padecemos cando algún cambio inocuo pode romper algunha parte da infraestrutura. E isto só se notará despois de moito tempo.
É dicir, aínda non se resolveu?
Fai módulos universais. Evita os copos de neve. E todo sairá. A segunda metade do informe trata sobre como evitalo.
Ola! Grazas polo informe! Gustaríame aclarar. Detrás das escenas había unha gran pila pola que vin. Como se integran Puppet e a distribución de roles?
Datos do usuario.
É dicir, só cuspir o ficheiro e execútao dalgún xeito?
Os datos do usuario son unha nota, é dicir, cando facemos un clon da imaxe, Daemon érguese alí e, tentando descubrir quen é, le a nota de que é un equilibrador de carga.
É dicir, é este algún tipo de proceso separado que se regala?
Non o inventamos nós. Usámolo.
Ola! Só teño unha pregunta sobre os datos do usuario. Dixeches que hai problemas alí, que alguén pode enviar algo ao lugar equivocado. Hai algunha maneira de almacenar os datos do usuario no mesmo Git, para que sempre quede claro a que se refiren os datos do usuario?
Xeramos datos de usuario a partir do modelo. É dicir, úsanse alí un certo número de variables. E Terraform xera o resultado final. Polo tanto, non pode simplemente mirar o modelo e dicir o que pasará, porque todos os problemas están relacionados co feito de que o desenvolvedor pensa que está pasando unha cadea nesta variable, pero alí úsase unha matriz. E el - bam e eu - fulano, fulano, a seguinte liña, e todo rompeu. Se este é un recurso novo e unha persoa o recolle e ve que algo non funciona, entón resolvese rapidamente. E se se actualiza este grupo de escala automática, nalgún momento comezan a substituírse as instancias do grupo de escala automática. E ben, algo non funciona. Doe.
Resulta que a única solución é probar?
Si, ves o problema, engades alí pasos de proba. É dicir, a saída tamén se pode probar. Quizais non sexa tan cómodo, pero tamén podes poñer algunhas marcas: comprobe que os datos do usuario estean cravados aquí.
Chámome Timur. Está moi ben que haxa informes sobre como organizar correctamente Terraform.
Nin sequera empecei.
Creo que quizais na próxima conferencia haberá. Teño unha pregunta sinxela. Por que está codificando o valor nun módulo separado en lugar de usar tfvars, é dicir, por que un módulo con valores é mellor que tfvars?
É dicir, debería escribir aquí (diapositiva: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork e stvars: podo obter o mesmo?
Iso é exactamente o que facemos. Referímonos ao módulo fonte de configuración, por exemplo.
Esencialmente, estes son tfvars. Tfvars é moi cómodo nun ambiente de proba. Teño tfvars para grandes instancias, para pequenas. E tirei un ficheiro no cartafol. E conseguín o que quería. Cando estamos recortando infraestruturas, queremos que sexa posible ollar e entender de inmediato todo. E así resulta que cómpre mirar aquí e despois mirar tfvars.
É posible ter todo nun só lugar?
Si, tfvars é cando tes un código. E úsase en varios lugares diferentes con diferentes matices. Despois botarías tfvars e conseguirías os teus matices. E somos infraestrutura como código na súa forma máis pura. Mirei e entendín.
Ola! Encontrou situacións nas que o provedor da nube interfire co que fixeches Terraform? Digamos que editamos os metadatos. Hai claves ssh. E Google pon aí constantemente os seus metadatos e as súas claves. E Terraform sempre escribe que ten cambios. Despois de cada carreira, aínda que nada cambie, sempre di que actualizará este campo agora.
Con chaves, pero si, parte da infraestrutura está afectada por isto, é dicir, Terraform non pode cambiar nada. Tampouco podemos cambiar nada coas nosas mans. Viviremos con iso polo momento.
É dicir, atopouse con algo así, pero non se lle ocorreu nada, como o fai e faino el mesmo?
Por desgraza si.
Ola! Chámome Starkov Stanislav. Correo. ru Grupo. Como se soluciona o problema de xerar unha etiqueta en..., como se pasa por dentro? Segundo teño entendido, a través de User - data para especificar o nome de host, activa Puppet? E a segunda parte da pregunta. Como se soluciona este problema en SG, é dicir, cando xera SG, centos de instancias do mesmo tipo, cal é o nome correcto para elas?
Aqueles casos que son moi importantes para nós, poñémolos moi ben. Os que non son necesarios, hai unha nota de que este é un grupo de escala automática. E, en teoría, podes cravar e conseguir un novo.
En canto ao problema coa etiqueta, non hai tal problema, pero hai tal tarefa. E usamos as etiquetas moi, pero moito, porque a infraestrutura é grande e cara. E temos que mirar cara a onde vai o diñeiro, polo que as etiquetas permítennos desglosar o que foi onde. E, en consecuencia, gástase aquí a procura de algo que signifique moito diñeiro.
De que máis se trataba a pregunta?
Cando SG crea centos de instancias, hai que distinguirlas dalgún xeito?
Non, non. En cada instancia hai un axente que informa de que teño un problema. Se un axente informa, entón o axente sabe sobre el e, como mínimo, existe o seu enderezo IP. Xa podes fuxir. En segundo lugar, usamos Consul for Discovery, onde Kubernetes non está. E Consul tamén mostra o enderezo IP da instancia.
É dicir, estás centrando específicamente na IP e non no nome de host?
É imposible navegar polo nome de host, é dicir, hai moitos. Hai identificadores de instancia: AE, etc. Podes atopalo nalgún lugar, podes botalo na busca.
Ola! Decateime de que Terraform é algo bo, feito a medida para as nubes.
Non só.
Esta é precisamente a pregunta que me interesa. Se decides pasar, por exemplo, ao Bare Metal en masa con todas as túas instancias? Haberá algún problema? Ou aínda terás que usar outros produtos, por exemplo, o mesmo Ansible que se mencionou aquí?
Ansible é un pouco máis. É dicir, Ansible xa funciona cando se iniciou a instancia. E Terraform funciona antes de que se inicie a instancia. Cambiando ao Bare Metal - non.
Agora non, pero os negocios virán e dirán: "Vamos".
Cambiar a outra nube, si, pero aquí hai un truco lixeiramente diferente. Debes escribir código de Terraform de tal xeito que poidas cambiar a outra nube con menos esforzo.
Inicialmente, a tarefa foi fixada en que toda a nosa infraestrutura fose agnóstica, é dicir, calquera nube debería ser axeitada, pero nalgún momento a empresa deuse por vencida e dixo: "Está ben, nos próximos N anos non iremos a ningún lado, podemos utilizar servizos. de Amazon"
Terraform permítelle crear traballos front-end, configurar PagerDuty, documentos de datos, etc. Ten moitas colas. Practicamente pode controlar o mundo enteiro.
Grazas polo informe! Tamén teño 4 anos usando Terraform. Na etapa dunha transición suave a Terraform, á infraestrutura, a unha descrición declarativa, enfrontámonos a unha situación na que alguén facía algo a man e ti intentabas facer un plan. E teño algún tipo de erro alí. Como lides con este tipo de problemas? Como atopa os recursos perdidos que foron listados?
Principalmente coas mans e cos ollos, se vemos algo raro no informe, entón analizamos o que está a pasar alí, ou simplemente matamos. En xeral, as solicitudes de extracción son algo común.
Se hai un erro, retírao? Tentaches facelo?
Non, esta é a decisión dunha persoa no momento en que ve un problema.
Fonte: www.habr.com