Sembla que els desenvolupadors de Terraform ofereixen bones pràctiques molt convenients per treballar amb la infraestructura d'AWS. Només hi ha un matís. Amb el temps, el nombre d'entorns augmenta, apareixen característiques en cadascun. Apareix gairebé una còpia de la pila d'aplicacions a la regió veïna. I el codi Terraform s'ha de copiar i editar amb cura segons els nous requisits o per fer un floc de neu.
El meu informe tracta sobre patrons a Terraform per combatre el caos i la rutina manual en projectes grans i llargs.
Vídeo:
Tinc 40 anys, porto 20 en informàtica. Fa 12 anys que treballo a Ixtens. Ens dediquem al desenvolupament impulsat pel comerç electrònic. I he estat practicant pràctiques de DevOps durant 5 anys.
La meva història tractarà de l'experiència en un projecte en una empresa el nom de la qual no diré, amagada darrere d'un acord de confidencialitat.
Els números de la diapositiva es donen per tal d'entendre l'abast del projecte. I tot el que vaig a dir a continuació està relacionat amb Amazon.
Em vaig incorporar a aquest projecte fa 4 anys. I la refactorització d'infraestructures estava en ple apogeu, perquè el projecte havia crescut. I aquells patrons que s'utilitzaven, ja no encaixen. I donat tot el creixement previst del projecte, calia fer alguna cosa nova.
Gràcies a Matvey, que ens va explicar ahir el que va passar a Dodo Pizza. Això és el que ens va passar fa 4 anys.
Els desenvolupadors van venir i van començar a fer codi d'infraestructura.
Les raons més òbvies per les quals es va requerir això va ser el moment del mercat. Calia assegurar-se que l'equip DevOps no era un coll d'ampolla quan es va llançar. I entre altres coses, Terraform i Puppet es van utilitzar al primer nivell.
Terraform és un projecte de codi obert de HashiCorp. I per als que no sàpiguen què és, les properes diapositives.
La infraestructura com a codi significa que podem descriure la nostra infraestructura i demanar a alguns robots que s'assegurin que obtenim els recursos que hem descrit.
Per exemple, necessitem una màquina virtual. Descriurem, afegirem alguns paràmetres necessaris.
Després d'això, configurarem l'accés a Amazon a la consola. I demana el pla Terraform. El pla de Terraform dirà: "D'acord, pel vostre recurs, podem fer aquestes coses". I s'afegirà almenys un recurs. I no s'esperen canvis.
Quan tot us convingui, podeu demanar a Terraform que s'apliqui i Terraform us crearà una instància i obtindreu una màquina virtual al vostre núvol.
A més, el nostre projecte es desenvolupa. Hi estem afegint alguns canvis. Demanem més instàncies, afegim 53 entrades.
I repetim. Si us plau, planifica. Veiem quins canvis es preveuen. Aplicar. I així creix la nostra infraestructura.
Terraform utilitza un fitxer d'estat. És a dir, desa tots els canvis que van a Amazon en un fitxer, on per a cada recurs que has descrit hi ha els corresponents recursos que s'han creat a Amazon. Així, quan es canvia la descripció d'un recurs, Terraform sap exactament què s'ha de canviar a Amazon.
Aquests fitxers d'estat originalment eren només fitxers. I els vam emmagatzemar a Git, cosa que era extremadament incòmode. Contínuament algú s'oblidava de fer canvis, i hi havia molts conflictes.
Ara és possible utilitzar el backend, és a dir, Terraform s'indica en quin cub, amb quina clau s'ha de desar el fitxer d'estat. I Terraform mateix s'encarregarà d'aconseguir aquest fitxer d'estat, de fer tota la màgia i de tornar el resultat final.
La nostra infraestructura està creixent. Aquí teniu el nostre codi. I ara no volem només crear una màquina virtual, volem tenir un entorn de prova.
Terraform us permet fer una cosa com un mòdul, és a dir, descriure el mateix en alguna carpeta.
I, per exemple, a les proves, crida a aquest mòdul i aconsegueix el mateix que si féssim l'aplicació Terraform al mateix mòdul. Aquí teniu el codi per a la prova.
Per a la producció, hi podem enviar alguns canvis, perquè en les proves no necessitem instàncies grans, en producció seran útils les instàncies grans.
I després tornaré al projecte. Va ser una tasca difícil, la infraestructura estava prevista molt gran. I calia col·locar d'alguna manera tot el codi perquè fos convenient per a tothom: per als que fan manteniment d'aquest codi, i per als que fan canvis. I estava previst que qualsevol desenvolupador pogués anar a arreglar la infraestructura segons fos necessari per a la seva part de la plataforma.
Aquest és un arbre de directoris recomanat per HashiCorp si teniu un projecte gran i té sentit dividir tota la infraestructura en algunes peces petites i descriure cada peça en una carpeta separada.
Tenint una biblioteca de recursos extensa, podeu trucar aproximadament el mateix en proves i en producció.
En el nostre cas, això no era del tot adequat, perquè la pila de proves per a desenvolupadors o per a proves s'havia d'obtenir d'alguna manera més senzilla. I no volia passar per les carpetes i aplicar en la seqüència correcta, i preocupar-me que la base s'aixequi, i aleshores la instància que utilitza aquesta base s'aixeca. Per tant, totes les proves es van iniciar des d'una carpeta. S'hi van cridar els mateixos mòduls, però tot va passar d'una sola vegada.
Terraform s'encarrega de totes les dependències. I sempre crea recursos en aquesta seqüència perquè pugueu obtenir una adreça IP, per exemple, a partir d'una instància acabada de crear, i obtenir aquesta adreça IP a l'entrada route53.
A més, la plataforma és molt gran. I executar una pila de proves, encara que sigui durant una hora, encara que sigui durant 8 hores, és un negoci força car.
I hem automatitzat aquest negoci. I la feina de Jenkins va permetre que la pila s'executés. Va ser necessari llançar-hi una sol·licitud d'extracció amb els canvis que el desenvolupador vol provar, especificar totes les opcions, components i mides necessàries. Si vol proves de rendiment, pot prendre més casos. Si només necessita comprovar que s'obre algun formulari, podria començar pel salari mínim. I també indica si cal un clúster o no, etc.
I llavors Jenkins va empènyer un script de shell que va modificar lleugerament el codi a la carpeta Terraform. S'han eliminat els fitxers innecessaris, s'han afegit els fitxers necessaris. I després, amb una aplicació de Terraform, la pila va augmentar.
I després hi havia altres passos que no vull entrar.
Degut al fet que per a les proves necessitàvem una mica més d'opcions que en producció, vam haver de fer còpies dels mòduls per tal que en aquestes còpies poguéssim afegir aquelles característiques que només es necessiten en proves.
I va passar que durant les proves, sembla que voleu provar aquells canvis que finalment aniran a producció. Però, de fet, es va provar una cosa i es va utilitzar una mica diferent a la producció. I hi va haver una petita ruptura en el patró que en producció tots els canvis van ser aplicats per l'equip d'operació. I de vegades va resultar que aquells canvis que havien de passar de les proves a la producció, es quedaven en una altra versió.
A més, hi va haver un problema tal que es va afegir un nou servei, que era lleugerament diferent d'algun dels existents. I en comptes de modificar un mòdul existent, calia fer-ne una còpia i afegir-hi els canvis necessaris.
De fet, Terraform no és un llenguatge real. Això és una declaració. Si hem de declarar alguna cosa, llavors ho declarem. I tot funciona.
En algun moment, quan parlava d'una de les meves sol·licituds d'extracció, un dels meus companys va dir que no calia produir flocs de neu. Em vaig preguntar què volia dir. Hi ha un fet tan científic que al món no hi ha dos flocs de neu idèntics, tots són lleugerament, però diferents. I tan bon punt vaig sentir això, immediatament vaig sentir tot el pes del codi Terraform. Perquè quan calia passar d'una versió a una altra, Terraform requeria un canvi de cadena de ruptura, és a dir, el codi ja no era compatible amb la següent versió. I vaig haver de fer una sol·licitud d'extracció, que cobria gairebé la meitat dels fitxers de la infraestructura, per tal de portar la infraestructura a la següent versió de Terraform.
I després que aparegués un floc de neu així, tot el codi Terraform que havíem convertit en un gran i gran munt de neu.
Per a un desenvolupador extern que està fora de l'operació, no li importa gaire, perquè va fer una sol·licitud d'extracció, va començar el seu recurs. I ja està, no és la seva preocupació. I l'equip de DevOps que s'assegura que tot està bé ha de fer tots aquests canvis. I el cost d'aquests canvis va augmentar molt, molt amb cada floc de neu addicional.
Hi ha una història sobre com un estudiant d'un seminari dibuixa dos cercles perfectes amb guix en una pissarra. I el professor es sorprèn de com va aconseguir dibuixar tan suaument sense brúixola. L'estudiant respon: "És molt senzill, vaig convertir una picadora de carn durant dos anys a l'exèrcit".
I dels quatre anys que porto en aquest projecte, porto uns dos anys fent Terraform. I, per descomptat, tinc alguns trucs, alguns consells sobre com simplificar el codi Terraform, treballar-hi com un llenguatge de programació i reduir la càrrega dels desenvolupadors que han de mantenir aquest codi actualitzat.
El primer que m'agradaria començar són els enllaços simbòlics. Terraform té molt de codi repetitiu. Per exemple, trucar a un proveïdor en gairebé tots els punts en què creem una infraestructura és el mateix. I és lògic posar-ho en un pare a part. I allà on es requereixi que el proveïdor faci enllaços simbòlics a aquest fitxer.
Per exemple, utilitzeu assumir el rol de producció, que us permet obtenir drets d'accés a algun compte extern d'Amazon. I canviant un fitxer, tots els que queden a l'arbre de recursos tindran els drets necessaris perquè Terraform sàpiga a quin segment d'Amazon accedir.
On els enllaços simbòlics no funcionen? Com he dit, Terraform té fitxers estatals. I són molt, molt xulos. Però el fet és que Terraform inicialitza el backend en el primer. I no pot utilitzar cap variable en aquests paràmetres, sempre s'han d'escriure en text.
I com a resultat, quan algú fa un nou recurs, copia part del codi d'altres carpetes. I es pot equivocar amb la clau o amb la galleda. Per exemple, fa una cosa de sorra a partir d'una caixa de sorra i després la fa en producció. I, per tant, pot resultar que la galleda en producció s'utilitzarà des de la caixa de sorra. Per descomptat, ho trobaran ràpidament. Serà possible solucionar-ho d'alguna manera, però tanmateix és una pèrdua de temps i, fins a cert punt, de recursos.
Què podem fer després? Abans de treballar amb Terraform, cal inicialitzar-lo. En el moment de la inicialització, Terraform baixa tots els connectors. En algun moment, van passar d'un monòlit a una arquitectura més microservei. I sempre cal que feu Terraform init perquè tregui tots els mòduls, tots els connectors.
I podeu utilitzar un script de shell, que, en primer lloc, pot obtenir totes les variables. L'script de shell és il·limitat. I, en segon lloc, el camí. Si sempre utilitzem el camí que hi ha al dipòsit com a clau del fitxer d'estat, l'error s'exclourà aquí.
On obtenir dades? Fitxer JSON. Terraform us permet escriure infraestructura no només en hcl (HashiCorp Configuration Language), sinó també en JSON.
JSON és fàcil de llegir des d'un script de shell. En conseqüència, podeu posar un fitxer de configuració amb un cub en algun lloc. I utilitzeu aquest cub tant al codi Terraform com a l'script de l'intèrpret d'ordres per a la inicialització.
Per què és important tenir una galleda Terraform? Perquè hi ha una cosa com els fitxers d'estat remot. És a dir, quan plantejo un recurs, per dir-li a Amazon: "Si us plau, augmenta la instància", he d'especificar molts paràmetres necessaris.
I aquests identificadors s'emmagatzemen en una altra carpeta. I puc agafar-ho i dir: "Terraform, si us plau, córrer al fitxer d'estat d'aquest mateix recurs i obtenir-me aquests identificadors". I així hi ha una mena d'unificació entre diferents regions o entorns.
No sempre és possible utilitzar un fitxer d'estat remot. Per exemple, heu creat manualment un VPC. I el codi de Terraform que crea el VPC crea un VPC tan diferent que triga molt de temps i cal ajustar un a l'altre, de manera que podeu utilitzar el truc següent.
És a dir, fer un mòdul que, per dir-ho, faci VPC i et doni identificadors, però de fet només hi ha un fitxer amb valors codificats que es pot utilitzar per crear la mateixa instància.
No sempre és necessari desar el fitxer d'estat al núvol. Per exemple, quan proveu mòduls, podeu utilitzar la inicialització del backend, quan el fitxer es desarà només al disc en el moment de la prova.
Ara una mica sobre les proves. Què es pot provar a Terraform? Probablement, moltes coses són possibles, però parlaré d'aquestes 4 coses.
HashiCorp entén com formatar el codi Terraform. I Terraform fmt us permet formatar el codi que editeu segons aquesta creença. En conseqüència, les proves han de comprovar necessàriament si el format coincideix amb el que ha llegat HashiCorp, de manera que no haureu de canviar la ubicació dels claudàtors, etc.
El següent és validar Terraform. Fa una mica més que una comprovació de sintaxi: per desgràcia, tots els claudàtors estan emparellats. Què és important aquí? Tenim una infraestructura molt fina. Té moltes carpetes diferents. I en cadascun cal executar Terraform validate.
En conseqüència, per accelerar les proves, executem diversos processos en paral·lel mitjançant paral·lel.
El paral·lel és una cosa molt interessant, utilitzeu-lo.
Però cada vegada que s'inicia Terraform, va a HashiCorp i pregunta: "Quins són els darrers connectors? I el connector que tinc a la memòria cau, és l'únic o no? I es va alentir a cada pas.
Si Terraform us indica on són els connectors, Terraform dirà: "D'acord, probablement això és el més nou que hi ha. No aniré enlloc, començaré a validar el teu codi Terraform de seguida".
Per omplir la carpeta amb els connectors necessaris, tenim un codi Terraform molt senzill que només cal inicialitzar-lo. Aquí, per descomptat, heu d'especificar tots els proveïdors que d'alguna manera participen en el vostre codi, en cas contrari Terraform dirà: "No conec cap proveïdor, perquè no està a la memòria cau".
El següent és el pla Terraform. Com he dit, el desenvolupament és cíclic. Fem codi amb canvis. I després cal esbrinar quins canvis es preveuen per a la infraestructura.
I quan la infraestructura és molt, molt gran, podeu canviar un mòdul, arreglar algun entorn de prova o una regió específica i trencar-ne un veí. Per tant, s'hauria de fer un pla Terraform per a tota la infraestructura i mostrar quins canvis es preveuen.
Ho pots fer de manera intel·ligent. Per exemple, vam escriure un script de Python que resol dependències. I en funció del que s'hagi canviat: un mòdul Terraform o només un component específic, fa plans per a totes les carpetes dependents.
El pla de Terraform s'ha de fer a petició. Almenys això és el que fem.
Les proves, per descomptat, són bones per a cada canvi, per a cada compromís, però els plans són una cosa bastant cara. I diem a la sol·licitud d'extracció: "Si us plau, doneu-me els plans". El robot arrenca. I envia als comentaris o a adjuntar tots els plans que s'esperen dels teus canvis.
El pla és una cosa força cara. Es necessita temps perquè Terraform va a Amazon i pregunta: "Encara existeix aquesta instància? Aquesta escala automàtica té exactament els mateixos paràmetres?”. I per accelerar-ho, podeu utilitzar un paràmetre com ara refresh=false. Això vol dir que Terraform desinflarà l'estat S3. I creurà que l'estat coincidirà exactament amb el que hi ha a Amazon.
Aquest pla de Terraform és molt més ràpid, però l'estat ha de coincidir amb la vostra infraestructura, és a dir, en algun lloc, en algun moment s'ha de començar l'actualització de Terraform. Terraform refresh fa exactament això, de manera que l'estat coincideixi amb el que hi ha a la infraestructura real.
I he de dir sobre la seguretat. Aquí és on hauria d'haver començat. Quan executeu Terraform i Terraform treballa amb la vostra infraestructura, hi ha una vulnerabilitat. És a dir, bàsicament esteu executant codi. I si la sol·licitud d'extracció conté algun tipus de codi maliciós, es pot executar en una infraestructura que tingui massa accés. Per tant, aneu amb compte on inicieu el pla Terraform.
El següent que m'agradaria parlar és de les proves de dades d'usuari.
Què són les dades d'usuari? A Amazon, quan creem una instància, podem enviar algun tipus de carta des de la instància: metadades. Quan s'inicia una instància, normalment el cloud init sempre està present en aquestes instàncies. Cloud init llegeix aquesta carta i diu: "D'acord, avui sóc un equilibrador de càrrega". I d'acord amb aquests preceptes, realitza algunes accions.
Però, malauradament, quan fem un pla de Terraform i apliquem Terraform, les dades de l'usuari es veuen com aquesta massa de números. És a dir, només t'envia un hash. I tot el que podeu veure al pla és si hi haurà canvis o si el hash es mantindrà igual.
I si no feu cas a això, llavors algun fitxer de text derrotat pot anar a Amazon, a la infraestructura real.
Alternativament, podeu especificar no tota la infraestructura durant l'execució, sinó només la plantilla. I al codi, digueu: "Si us plau, mostra aquesta plantilla per a mi". I com a resultat, podeu obtenir una impressió de com seran les vostres dades a Amazon.
Una altra opció és utilitzar un mòdul per generar dades d'usuari. Aplicaràs aquest mòdul. Obteniu el fitxer al disc. Compara-ho amb la referència. I, per tant, si algun jun decideix arreglar una mica de dades d'usuari, les vostres proves diran: "D'acord, hi ha alguns canvis aquí i allà, això és normal".
El següent del que m'agradaria parlar és l'aplicació Automate Terraform.
Per descomptat, fa prou por fer que Terraform s'apliqui en mode automàtic, perquè qui sap quins canvis hi han arribat i com de perjudicials poden ser per a una infraestructura viva.
Per a un entorn de prova, tot està bé. És a dir, un treball que creï un entorn de prova és el que necessiten tots els desenvolupadors. I una expressió com "tot va funcionar per a mi" no és un meme divertit, sinó una prova que una persona es va confondre, va aixecar una pila, va llançar algunes proves en aquesta pila. I es va assegurar que tot anava bé allà i va dir: "D'acord, el codi que he publicat s'ha provat".
En entorns de producció, sandbox i altres que són més crítics per a l'empresa, és segur utilitzar parcialment alguns recursos perquè no provoca la mort de ningú. Aquests són: grups d'escala automàtica, grups de seguretat, rols, ruta53 i allà la llista pot ser força gran. Però estigueu atents al que està passant, llegiu informes d'aplicacions automatitzades.
Quan sigui perillós o espantós utilitzar-los, per exemple, si es tracta d'alguns recursos persistents d'una base de dades, obteniu informes que indiquen que hi ha canvis no aplicats en alguna peça d'infraestructura. I l'enginyer ja està supervisat executant treballs per aplicar-ho o fer-ho des de la seva consola.
Amazon té una cosa com Terminar la protecció. I en alguns casos pot protegir-se de canvis que no us són necessaris. Així que Terraform va anar a Amazon i va dir "Necessito matar aquesta instància per fer-ne una altra". I Amazon diu: "Ho sento, avui no. Tenim la protecció Terminate".
I la cirereta del pastís és l'optimització del codi. Quan treballem amb codi Terraform, hem de passar un nombre molt gran de paràmetres al mòdul. Aquests són els paràmetres necessaris per crear algun tipus de recurs. I el codi es converteix en grans llistes de paràmetres que cal passar de mòdul a mòdul, de mòdul a mòdul, sobretot si els mòduls estan imbricats.
I és molt difícil de llegir. És molt difícil revisar-ho. I molt sovint resulta que s'estan revisant alguns paràmetres i no són del tot els que calen. I costa temps i diners arreglar-ho més tard.
Per tant, us suggereixo que utilitzeu una cosa com un paràmetre complex que inclou un determinat arbre de valors. És a dir, necessiteu algun tipus de carpeta on tingueu tots els valors que us agradaria tenir en algun tipus d'entorn.
I cridant aquest mòdul, podeu obtenir un arbre que es genera en un mòdul comú, és a dir, en un mòdul comú que funcioni igual per a tota la infraestructura.
En aquest mòdul, podeu fer alguns càlculs utilitzant una característica tan nova de Terraform com a locals. I després, en una sortida, emet algun tipus de paràmetre complex, que pot incloure hash, matrius, etc.
En això, totes les millors troballes que he acabat. I m'agradaria explicar una història sobre Colom. Quan buscava diners per a la seva expedició per descobrir l'Índia (com pensava aleshores), ningú s'ho va creure i va creure que era impossible. Llavors va dir: "Assegureu-vos que l'ou no caigui". Tots els banquers, gent molt rica i probablement intel·ligent, van intentar posar l'ou d'alguna manera, i va caure tot el temps. Llavors Colom va agafar l'ou, el va pressionar una mica. La closca es va arruïnar i l'ou va quedar immòbil. Van dir: "Oh, això és massa fàcil!" I Colom va respondre: “Sí, és massa senzill. I quan obri l'Índia, tothom utilitzarà aquesta ruta comercial".
I el que us acabo de dir és probablement coses força senzilles i trivials. I quan aprens sobre ells i comença a utilitzar-los, està en l'ordre de les coses. Així que utilitzeu-lo. I si aquestes són coses bastant normals per a tu, almenys saps com posar un ou perquè no caigui.
Resumim:
- Intenta evitar els flocs de neu. I com menys flocs de neu, menys recursos necessitareu per fer qualsevol canvi a tota la vostra gran infraestructura.
- Canvi constant. És a dir, quan s'han produït alguns canvis al codi, heu d'alinear la vostra infraestructura amb aquests canvis tan aviat com sigui possible. No hauria d'haver una situació en què algú vingui d'aquí a dos o tres mesos a mirar Elasticsearch, faci un pla de Terraform i hi hagi molts canvis que no s'esperava. I es necessita molt de temps per posar-ho tot en ordre.
- Proves i automatització. Com més està cobert el vostre codi amb proves i xips, més confiança teniu que ho feu tot bé. I el lliurament automàtic augmentarà la vostra confiança moltes vegades.
- El codi dels entorns de prova i producció hauria de ser gairebé el mateix. Pràcticament, perquè al cap i a la fi, la producció és una mica diferent i encara hi haurà alguns matisos que aniran més enllà de l'entorn de prova. Però, tanmateix, es pot proporcionar més o menys.
- I si teniu molt de codi Terraform i es necessita molt de temps per mantenir aquest codi actualitzat, mai és massa tard per refactoritzar i posar-lo en bon estat.
- infraestructura immutable. Lliurament d'AMI a l'horari previst.
- Estructura per a route53 quan teniu moltes entrades i voleu que estiguin en un ordre coherent.
- Lluita contra els límits de velocitat de l'API. És quan Amazon diu: "Això és tot, no puc acceptar més sol·licituds, si us plau, espereu". I la meitat de l'oficina està esperant fins que pugui posar en marxa la seva infraestructura.
- instàncies localitzades. Amazon no és un esdeveniment barat i els llocs us permeten estalviar molt. I allà pots explicar-ne tot un reportatge.
- Funcions de seguretat i IAM.
- Busqueu recursos perduts, quan teniu casos d'origen desconegut a Amazone, mengen diners. Fins i tot si les instàncies costen entre 100 i 150 dòlars al mes, són més de 1 dòlars anuals. Trobar aquests recursos és un negoci lucratiu.
- I instàncies reservades.
Això és tot per a mi. Terraform és molt xulo, fes-lo servir. Gràcies!
Les vostres preguntes
Gràcies pel reportatge! Teniu un fitxer d'estat a S3, però com solucioneu el problema que diverses persones poden agafar aquest fitxer d'estat i intentar desplegar-lo?
En primer lloc, no tenim pressa. En segon lloc, hi ha banderes, en què informem que estem treballant en algun fragment de codi. És a dir, malgrat que la infraestructura és molt gran, això no vol dir que algú estigui fent servir alguna cosa constantment. I quan hi havia una fase activa, això era un problema, vam mantenir els fitxers d'estat a Git. Això era important, en cas contrari algú faria un fitxer d'estat i havíem de recollir-los manualment en un munt per continuar més enllà. Ara no hi ha aquest problema. En general, Terraform va resoldre aquest problema. I si alguna cosa està canviant constantment, podeu utilitzar panys que impedeixin el que heu dit.
Esteu utilitzant codi obert o empresa?
Cap empresa, és a dir, tot el que pots anar i descarregar gratis.
Em dic Stanislav. Volia fer un petit afegit. Heu parlat de la funció d'Amazon que us permet fer que una instància no es pugui matar. Això també es troba al mateix Terraform, al bloc Life Second, podeu prescriure una prohibició del canvi o una prohibició de la destrucció.
Estava limitat en el temps. Bon punt.
També volia preguntar dues coses. Primer, heu parlat de les proves. Heu utilitzat alguna eina de prova? He sentit parlar del connector Test Kitchen. Potser hi ha alguna cosa més. I m'agradaria preguntar sobre els valors locals. En què es diferencien bàsicament de les variables d'entrada? I per què no puc parametritzar alguna cosa només mitjançant els valors locals? Vaig intentar tractar aquest tema, però d'alguna manera no ho vaig resoldre jo mateix.
Podem parlar amb més detall darrere d'aquesta sala. Les eines de prova són completament fetes per nosaltres mateixos. No hi ha res per provar. En general, hi ha opcions quan les proves automàtiques eleven la infraestructura en algun lloc, comproveu que està bé i després ho destrueixen tot amb un informe que la vostra infraestructura encara està en bon estat. No ho tenim perquè les piles de proves s'executen cada dia. I amb això n'hi ha prou. I si alguna cosa comença a trencar-se, començarà a trencar-se sense que ho comprovem en un altre lloc.
Pel que fa als valors locals, continuem la conversa fora del públic.
Hola! Gràcies pel reportatge! Molt informatiu. Vas dir que tens molt del mateix tipus de codi per descriure la infraestructura. Has pensat en generar aquest codi?
Gran pregunta, gràcies! La qüestió és que quan fem servir la infraestructura com a codi, suposem que mirem el codi i entenem quin tipus d'infraestructura hi ha darrere d'aquest codi. Si es genera el codi, hem d'imaginar quin codi es generarà per entendre quin tipus d'infraestructura hi haurà. O generem el codi, el confirmem i, de fet, obtenim el mateix. Per tant, hem anat com hem escrit, ho hem aconseguit. A més, els generadors van aparèixer una mica més tard, quan vam començar a fer. I ja era massa tard per canviar.
Heu sentit a parlar de jsonnet?
No
Mira, això és molt xulo. Veig un cas concret on podeu aplicar-lo i generar una estructura de dades.
Els generadors són bons quan els tens, com en l'acudit sobre la màquina d'afaitar. És a dir, la primera vegada la cara és diferent, però després tothom té la mateixa cara. Els generadors són molt xulos. Però, malauradament, les nostres cares són una mica diferents. Això és un problema.
Només mira. Gràcies!
Em dic Maxim, sóc de Sberbank. Vas dir una mica que vas intentar portar Terraform a un llenguatge de programació analògic. No és més fàcil utilitzar Ansible?
Són coses molt diferents. Ansible pot crear recursos i Puppet pot crear recursos a Amazon. Però Terraform està francament afilat.
Només tens Amazon?
No és que només tinguem Amazon. Gairebé només tenim Amazon. Però la característica clau és que Terraform recorda. A Ansible, si dius: "Recolliu-me 5 instàncies", s'aixecarà, i després dieu: "I ara en necessito 3". I Terraform dirà: "D'acord, en mataré 2", i Ansible dirà: "D'acord, aquí en tens 3". Total 8.
Hola! Gràcies pel teu informe! Va ser molt interessant saber parlar de Terraform. Només vull fer un petit comentari sobre el fet que Terraform encara no té una versió estable, així que tingueu molta cura amb Terraform.
Bona cullera per sopar. És a dir, si necessites una solució, a vegades posposes allò que és inestable, etc., però funciona i ens ha ajudat.
La pregunta és. Esteu utilitzant el backend remot, feu servir S 3. Per què no feu servir el backend oficial?
Oficial?
Núvol de Terraform.
Quan va aparèixer?
fa 4 mesos.
Si hagués aparegut fa 4 anys, probablement, hauria respost a la teva pregunta.
Ja hi ha una funció i bloquejos integrats, i podeu emmagatzemar un fitxer d'estat. Intenta-ho. Però tampoc he provat.
Estem en un gran tren que es mou a gran velocitat. I no pots agafar i llençar uns quants cotxes.
Parlaves de flocs de neu, per què no feies servir branca? Per què no va funcionar així?
Tenim un enfocament tal que tota la infraestructura es troba en un sol dipòsit. Terraform, Puppet, tots els scripts que d'alguna manera es relacionen amb això, tots estan en un sol dipòsit. D'aquesta manera podem assegurar-nos que els canvis incrementals es comprovi un per un. Si fos un munt de branques, llavors aquest projecte seria gairebé impossible de mantenir. Passen sis mesos, i divergeixen tant que només és una mena de càstig. Això és del que volia fugir abans de refactoritzar.
és a dir, no funciona?
No funciona gens.
A la branca, he retallat la diapositiva de la carpeta. És a dir, si ho feu per a cada pila de proves, per exemple, l'equip A té el seu propi pare, l'equip B té el seu propi pare, això tampoc no funciona. Hem creat un codi d'entorn de prova unificat que era prou flexible per adaptar-se a tothom. És a dir, vam servir un codi.
Hola! Em dic Yura! Gràcies pel reportatge! Pregunta sobre mòduls. Dius que estàs utilitzant mòduls. Com es resol el problema si es van fer canvis en un mòdul que no són compatibles amb el canvi d'una altra persona? D'alguna manera versionar mòduls o intentar portar un prodigi per complir dos requisits?
Aquest és el gran problema de la pila de neu. Això és el que patim quan algun canvi innòcu pot trencar alguna part de la infraestructura. I només es notarà després d'un temps llarg.
És a dir, encara no s'ha decidit?
Fas mòduls universals. Eviteu els flocs de neu. I tot sortirà. La segona meitat de l'informe tracta sobre com evitar-ho.
Hola! Gràcies pel reportatge! M'agradaria aclarir. Entre bastidors hi havia una gran pila, per la qual vaig venir. Com s'integren la distribució de papers i titelles?
dades d'usuari.
És a dir, només escupi el fitxer i, d'alguna manera, l'executeu?
Les dades d'usuari són una nota, és a dir, quan fem un clon d'imatge, el Daemon s'aixeca allà i intenta esbrinar qui és, llegeix una nota que indica que és un equilibrador de càrrega.
És a dir, és una mena de procés separat que es regala?
No l'hem inventat nosaltres. El fem servir.
Hola! Només tinc una pregunta sobre dades d'usuari. Vas dir que hi ha problemes allà, que algú podria enviar alguna cosa al lloc equivocat. Hi ha alguna manera d'emmagatzemar dades d'usuari al mateix Git, de manera que sempre quedi clar a què es refereixen les dades d'usuari?
Generem dades d'usuari a partir de la plantilla. És a dir, hi recorre un cert nombre de variables. I Terraform genera el resultat final. Per tant, no us podeu limitar a mirar la plantilla i dir què passa, perquè tots els problemes estan relacionats amb el fet que el desenvolupador pensa que està passant una cadena en aquesta variable i després s'utilitza una matriu. I ell - bang i jo - tal i tal, tal i tal, la línia següent, i tot es va trencar. Si es tracta d'un recurs nou i una persona el planteja, veu que alguna cosa no funciona, això es resol ràpidament. I si aquest grup d'escala automàtica s'ha actualitzat, en algun moment es comencen a substituir les instàncies del grup d'escala automàtica. I aplaudim, alguna cosa no funciona. Fa mal.
Resulta que l'única solució és provar?
Sí, veus el problema, hi afegiu passos de prova. És a dir, la sortida també es pot provar. Potser no és tan convenient, però també podeu posar algunes marques: comproveu que les dades de l'usuari estiguin clavades aquí.
Em dic Timur. Està molt bé que hi hagi informes sobre com organitzar correctament Terraform .
Ni tan sols vaig començar.
Crec que a la propera conferència potser n'hi haurà. Tinc una pregunta senzilla. Per què codifiqueu el valor en un mòdul separat en lloc d'utilitzar tfvars, és a dir, un mòdul amb valors és millor que tfvars?
És a dir, hauria d'escriure aquí (diapositiva: Production/environment/settings.tf): domini = variable, domini vpcnetwork, vpcnetwork variable i stvars: obteniu el mateix?
Fem exactament això. Ens referim al mòdul font de configuració, per exemple.
De fet, això és un tfvars. Tfvars és molt útil en un entorn de proves. Tinc tfvars per a instàncies grans, per a petites. I vaig llençar un fitxer a la carpeta. I vaig aconseguir el que volia. Quan vam veure infraestructures, volem poder veure-ho i entendre-ho de seguida. I així resulta que cal mirar aquí i després mirar a tfvars.
Resulta que tot estava en un sol lloc?
Sí, tfvars és quan tens un codi. I s'utilitza en diversos llocs diferents amb diferents matisos. Llavors tiraries tfvars i obtenies els teus matisos. I som una infraestructura com a codi en estat pur. Mirat i entès.
Hola! Us heu trobat amb situacions en què el proveïdor de núvol interfereix amb el que heu fet amb Terraform? Suposem que editem les metadades. Hi ha claus ssh. I Google hi llisca constantment les seves metadades, les seves claus. I Terraform sempre escriu que té canvis. Després de cada execució, encara que no canviï res, sempre diu que actualitzarà aquest camp ara.
Amb claus, però sí, una part de la infraestructura es veu afectada per tal cosa, és a dir, Terraform no pot canviar res. Tampoc podem canviar res amb les nostres mans. Mentre hi convivim.
És a dir, t'has trobat amb això, però no t'ha plantejat res, com ho fa i ho fa ell mateix?
Lamentablement si.
Hola! Em dic Stanislav Starkov. Correu. en Grup. Com es resol el problema de generar una etiqueta a..., com es passa a dins? Segons tinc entès, a través de les dades de l'usuari, per especificar el nom d'amfitrió, incitar Puppet? I la segona part de la pregunta. Com resoleu aquest problema a SG, és a dir, quan genereu SG, cent instàncies del mateix tipus, com anomenar-les correctament?
Aquells casos que són molt importants per a nosaltres, els anomenarem molt bé. Els que no són necessaris, hi ha un postscript que indica que es tracta d'un grup d'escala automàtica. I en teoria es pot clavar i obtenir-ne un de nou.
Pel que fa al problema amb l'etiqueta, no hi ha cap problema, però sí que sí. I fem servir les etiquetes molt, moltíssim, perquè la infraestructura és gran i cara. I hem de mirar en quins diners es gasten, de manera que les etiquetes ens permeten esbrinar què i on van anar. I, en conseqüència, la recerca d'alguna cosa aquí suposa molts diners gastats.
De què més era la pregunta?
Quan SG crea cent instàncies, cal distingir-les d'alguna manera?
No, no. Cada instància té un agent que em diu que tinc un problema. Si l'agent informa, llavors l'agent sap sobre ell i, almenys, la seva adreça IP existeix. Ja pots córrer. En segon lloc, fem servir Consul for Discovery, on no hi ha Kubernetes. I Consul també mostra l'adreça IP de la instància.
És a dir, esteu orientant exactament la IP i no el nom d'amfitrió?
És impossible navegar pel nom d'amfitrió, és a dir, n'hi ha molts. Hi ha identificadors d'instàncies: AE, etc. El podeu trobar en algun lloc, el podeu llançar a la cerca.
Hola! Em vaig adonar que Terraform és una cosa bona, feta a mida dels núvols.
No només.
Aquesta és la pregunta que m'interessa. Si decideixes traslladar-te, per exemple, al Bare Metal en massa amb totes les teves instàncies? Hi haurà problemes? O encara heu d'utilitzar altres productes, per exemple, el mateix Ansible que es va esmentar aquí?
Ansible tracta una mica d'una altra cosa. És a dir, Ansible ja s'està executant quan la instància s'ha iniciat. I Terraform funciona abans que la instància hagi començat. Canviar a Bare Metal no ho és.
Ara no, però vindran negocis i diran: "Vinga".
Canviar a un altre núvol, sí, però aquí hi ha una característica lleugerament diferent. Heu d'escriure el codi Terraform de manera que pugueu canviar a un altre núvol amb menys vessament de sang.
Inicialment, la tasca era que tota la nostra infraestructura fos agnòstica, és a dir, qualsevol núvol hauria d'estar bé, però en algun moment l'empresa es va rendir i va dir: "D'acord, en els propers N anys no anirem enlloc, podeu utilitzar els serveis de Amazon".
Terraform us permet crear treballs de front-end, configurar PagerDuty, documents de dades, etc. Té moltes cues. Pràcticament pot controlar el món sencer.
Gràcies pel reportatge! També porto 4 anys fent girar Terraform. En l'etapa d'una transició fluida a Terraform, a la infraestructura, a una descripció declarativa, ens vam trobar davant d'una situació en què algú feia alguna cosa a mà i tu intentaves fer un pla. I allà vaig tenir algun error. Com s'aborden aquests problemes? Com es troben els recursos perduts que s'han indicat?
Majoritàriament amb les mans i els ulls, si veiem alguna cosa estranya a l'informe, aleshores analitzem què hi passa, o simplement ho matem. En general, les sol·licituds d'extracció són una cosa habitual.
Si hi ha un error, es desfer? Has provat de fer això?
No, aquesta és una decisió d'una persona en el moment en què veu el problema.
Font: www.habr.com