Moltes persones coneixen i utilitzen Terraform en el seu treball diari, però encara no s'han format les millors pràctiques per a això. Cada equip ha d'inventar els seus propis enfocaments i mètodes.
La vostra infraestructura gairebé segur que comença senzill: uns quants recursos + uns quants desenvolupadors. Amb el temps, creix en tot tipus de direccions. Trobeu maneres d'agrupar recursos en mòduls de Terraform, organitzar el codi en carpetes i què més pot sortir malament? (últimes paraules famoses)
El temps passa i sents que la teva infraestructura és la teva nova mascota, però per què? Estàs preocupat pels canvis inexplicables a la infraestructura, tens por de tocar la infraestructura i el codi; com a resultat, retardes noves funcionalitats o redueixes la qualitat...
Després de tres anys de gestionar una col·lecció de mòduls de la comunitat Terraform per a AWS a Github i el manteniment a llarg termini de Terraform en producció, Anton Babenko està preparat per compartir la seva experiència: com escriure mòduls TF perquè no faci mal en el futur.
Al final de la xerrada, els participants estaran més familiaritzats amb els principis de gestió de recursos a Terraform, les millors pràctiques associades amb els mòduls de Terraform i alguns principis d'integració contínua associats a la gestió d'infraestructures.
Exempció de responsabilitat: Tinc nota que aquest informe té la data de novembre de 2018; ja han passat 2 anys. La versió de Terraform 0.11 que es parla a l'informe ja no és compatible. Durant els últims 2 anys, s'han llançat 2 nous llançaments, que contenen moltes innovacions, millores i canvis. Si us plau, presteu atenció a això i comproveu la documentació.
Enllaços:
- +
- — Codi de format automàtic i documentació
- — generador de mòduls Terraform (WIP)
- - Generador de codi Terraform a partir de diagrames visuals (WIP)
- www.terraform-best-practices.com
- (Les publicacions noves es troben al meu lloc web personal www.antonbabenko.com/)
- @antonbabenko: Twitter i un munt de Slacks diferents
Em dic Anton Babenko. Alguns de vosaltres probablement heu utilitzat el codi que vaig escriure. Ara parlaré d'això amb més confiança que mai, perquè tinc accés a les estadístiques.
Treballo a Terraform i he estat un participant i col·laborador actiu en un gran nombre de projectes de codi obert relacionats amb Terraform i Amazon des del 2015.
Des de llavors he escrit prou codi per posar-lo d'una manera interessant. I ara intentaré explicar-te això.
Parlaré de les complexitats i les especificitats de treballar amb Terraform. Però aquest no és realment el tema de HighLoad. I ara entendreu per què.
Amb el temps, vaig començar a escriure mòduls Terraform. Els usuaris van escriure preguntes, jo les vaig reescriure. A continuació, vaig escriure diverses utilitats per formatar el codi mitjançant un ganxo de precommit, etc.
Hi havia molts projectes interessants. M'agrada la generació de codi perquè m'agrada que l'ordinador faci cada cop més feina per a mi i el programador, així que actualment estic treballant en un generador de codi Terraform a partir de diagrames visuals. Potser alguns de vosaltres els heu vist. Són boniques caixes amb fletxes. I crec que és fantàstic fer clic al botó "Exporta" i obtenir-ho tot com a codi.
Sóc d'Ucraïna. Fa molts anys que visc a Noruega.
També s'ha recopilat informació per a aquest informe de persones que coneixen el meu nom i em troben a les xarxes socials. Gairebé sempre tinc el mateix sobrenom.
Com he comentat, sóc el principal mantenidor dels mòduls Terraform AWS, que és un dels dipòsits més grans de GitHub on allotgem mòduls per a les tasques més habituals: VPC, Autoscaling, RDS.
I el que has sentit ara és el més bàsic. Si dubteu que entengueu què és Terraform, és millor passar el temps en un altre lloc. Aquí hi haurà molts termes tècnics. I no vaig dubtar a declarar el nivell de l'informe com el més alt. Això vol dir que puc parlar fent servir tots els termes possibles sense gaire explicació.
Terraform va aparèixer el 2014 com una utilitat que us permetia escriure, planificar i gestionar la infraestructura com a codi. El concepte clau aquí és "infraestructura com a codi".
Tota la documentació, com he dit, està escrita . Espero que la majoria de la gent conegui aquest lloc i hagi llegit la documentació. Si és així, estàs al lloc correcte.
Així és un fitxer de configuració normal de Terraform, on primer definim algunes variables.
En aquest cas definim "aws_region".
Després descrivim quins recursos volem crear.
Executem algunes ordres, en particular "terraform init" per carregar dependències i proveïdors.
I executem l'ordre "terraform apply" per comprovar si la configuració especificada coincideix amb els recursos que hem creat. Com que no hem creat res abans, Terraform ens demana que creem aquests recursos.
Ho confirmem. Així creem una galleda anomenada caragol de mar.
També hi ha diverses utilitats similars. Molts de vosaltres que feu servir Amazon coneixeu AWS CloudFormation o Google Cloud Deployment Manager o Azure Resource Manager. Cadascun d'ells té la seva pròpia implementació d'algun tipus per gestionar els recursos dins de cadascun d'aquests proveïdors de núvols públics. Terraform és especialment útil perquè us permet gestionar més de 100 proveïdors. (Més detalls )
Els objectius que Terraform ha perseguit des del principi:
- Terraform ofereix una visió única dels recursos.
- Li permet donar suport a totes les plataformes modernes.
- I Terraform es va dissenyar des del principi com una utilitat que us permet canviar la infraestructura de manera segura i previsible.
El 2014, la paraula "previsible" sonava molt inusual en aquest context.
Terraform és una utilitat universal. Si teniu una API, podeu controlar absolutament tot:
- Podeu utilitzar més de 120 proveïdors per gestionar tot el que vulgueu.
- Per exemple, podeu utilitzar Terraform per descriure l'accés als repositoris de GitHub.
- Fins i tot podeu crear i tancar errors a Jira.
- Podeu gestionar les mètriques de New Relic.
- Fins i tot podeu crear fitxers a Dropbox si realment ho voleu.
Tot això s'aconsegueix mitjançant proveïdors de Terraform, que tenen una API oberta que es pot descriure a Go.
Suposem que vam començar a utilitzar Terraform, vam llegir una mica de documentació al lloc, vam veure un vídeo i vam començar a escriure main.tf, tal com vaig mostrar a les diapositives anteriors.
I tot és genial, tens un fitxer que crea un VPC.
Si voleu crear un VPC, especifiqueu aproximadament aquestes 12 línies. Descriu en quina regió voleu crear, quin cidr_block d'adreces IP utilitzareu. Això és tot.
Naturalment, el projecte anirà creixent progressivament.
I hi afegireu un munt de coses noves: recursos, fonts de dades, us integrareu amb nous proveïdors, de sobte voldreu utilitzar Terraform per gestionar els usuaris del vostre compte de GitHub, etc. És possible que vulgueu utilitzar-lo. diferents proveïdors de DNS, creueu-ho tot. Terraform ho facilita.
Vegem l'exemple següent.
Afegiu internet_gateway a poc a poc perquè voleu que els recursos del vostre VPC tinguin accés a Internet. Aquesta és una bona idea.
El resultat és aquest main.tf:
Aquesta és la part superior de main.tf.
Aquesta és la part inferior de main.tf.
A continuació, afegiu una subxarxa. Quan vulgueu afegir passarel·les NAT, rutes, taules d'encaminament i un munt d'altres subxarxes, no tindreu 38 línies, sinó aproximadament 200-300 línies.
És a dir, el vostre fitxer main.tf està creixent gradualment. I molt sovint la gent ho posa tot en un sol fitxer. 10-20 Kb apareix a main.tf. Imagineu que 10-20 Kb són contingut de text. I tot està connectat amb tot. A poc a poc es fa difícil treballar amb això. 10-20 Kb és un bon cas d'usuari, de vegades més. I la gent no sempre pensa que això sigui dolent.
Com en la programació normal, és a dir, no la infraestructura com a codi, estem acostumats a utilitzar un munt de classes, paquets, mòduls i agrupacions diferents. Terraform us permet fer gairebé el mateix.
- El codi està creixent.
- També creixen les dependències entre recursos.
I tenim una gran, gran necessitat. Entenem que ja no podem viure així. El nostre codi s'està convertint en immens. 10-20 Kb, per descomptat, no és molt gran, però estem parlant només de la pila de xarxa, és a dir, només heu afegit recursos de xarxa. No estem parlant d'Application Load Balancer, clúster ES de desplegament, Kubernetes, etc., on es poden teixir fàcilment 100 Kb. Si anoteu tot això, molt aviat sabreu que Terraform ofereix mòduls de Terraform.
Els mòduls Terraform són una configuració de Terraform autònoma que es gestiona com a grup. Això és tot el que necessiteu saber sobre els mòduls de Terraform. No són gens intel·ligents, no et permeten fer cap connexió complexa en funció d'alguna cosa. Tot això recau sobre les espatlles dels desenvolupadors. És a dir, això és només una mena de configuració de Terraform que ja heu escrit. I simplement podeu trucar-lo com a grup.
Per tant, estem intentant entendre com optimitzarem els nostres 10-20-30 Kb de codi. A poc a poc ens anem adonant que necessitem utilitzar alguns mòduls.
El primer tipus de mòduls que trobeu són mòduls de recursos. No entenen de què tracta la vostra infraestructura, de què tracta el vostre negoci, on i quines són les condicions. Aquests són exactament els mòduls que jo, juntament amb la comunitat de codi obert, administro i que proposem com a pilars inicials de la vostra infraestructura.
Un exemple de mòdul de recursos.
Quan anomenem un mòdul de recursos, especifiquem des de quina ruta hem de carregar el seu contingut.
Indiquem quina versió volem descarregar.
Hi passem un munt d'arguments. Això és tot. Això és tot el que necessitem saber quan fem servir aquest mòdul.
Molta gent pensa que si utilitzen l'última versió, tot serà estable. Però no. S'ha de versionar la infraestructura; hem de respondre clarament a quina versió s'ha desplegat aquest o aquell component.
Aquí teniu el codi que hi ha dins d'aquest mòdul. Mòdul de grup de seguretat. Aquí el desplaçament va a la línia 640. Crear un recurs de grup de seguretat a Amazon en totes les configuracions possibles és una tasca molt no trivial. No n'hi ha prou amb crear un grup de seguretat i dir-li quines regles li han de passar. Seria molt senzill. Hi ha un milió de restriccions diferents a Amazon. Per exemple, si feu servir Punt final de VPC, llista de prefixos, diverses API i intenta combinar tot això amb tota la resta, llavors Terraform no et permet fer això. I l'API d'Amazon tampoc ho permet. Per tant, hem d'amagar tota aquesta lògica terrible en un mòdul i donar el codi d'usuari que sembla així.
L'usuari no necessita saber com es fa a l'interior.
El segon tipus de mòduls, que consta de mòduls de recursos, ja resol problemes que són més aplicables al teu negoci. Sovint, aquest és un lloc que és una extensió per a Terraform i estableix uns valors rígids per a les etiquetes, per als estàndards de l'empresa. També podeu afegir-hi funcionalitats que Terraform no us permet utilitzar actualment. Això és ara mateix. Ara la versió 0.11, que està a punt de convertir-se en cosa del passat. Però tot i així, els preprocessadors, jsonnet, cookiecutter i un munt d'altres coses són el mecanisme auxiliar que s'ha d'utilitzar per a un treball complet.
A continuació, mostraré alguns exemples d'això.
El mòdul d'infraestructura s'anomena exactament de la mateixa manera.
S'indica la font des d'on descarregar el contingut.
Es passen un munt de valors i es passen a aquest mòdul.
A continuació, dins d'aquest mòdul, es criden un munt de mòduls de recursos per crear un VPC o un equilibrador de càrrega d'aplicacions, o per crear un grup de seguretat o per a un clúster Elastic Container Service.
Hi ha dos tipus de mòduls. Això és important entendre-ho perquè la majoria de la informació que he agrupat en aquest informe no està escrita a la documentació.
I la documentació de Terraform ara mateix és bastant problemàtica perquè només diu que hi ha aquestes funcions, que les podeu utilitzar. Però ella no diu com utilitzar aquestes funcions, per què és millor utilitzar-les. Per tant, un nombre molt gran de persones escriuen alguna cosa amb la qual no poden viure.
A continuació, fem una ullada a com escriure aquests mòduls. A continuació, veurem com cridar-los i com treballar amb el codi.
Registre Terraform -
El consell número 0 és no escriure mòduls de recursos. La majoria d'aquests mòduls ja estan escrits per a tu. Com he dit, són de codi obert, no contenen cap lògica de negoci, no tenen valors codificats per a adreces IP, contrasenyes, etc. El mòdul és molt flexible. I molt probablement ja s'ha escrit. Hi ha molts mòduls per a recursos d'Amazon. Uns 650. I la majoria són de bona qualitat.
En aquest exemple, algú us va dir: "Vull poder gestionar una base de dades. Creeu un mòdul perquè pugui crear una base de dades". La persona no coneix els detalls d'implementació ni d'Amazon ni de Terraform. Simplement diu: "Vull gestionar MSSQL". És a dir, volem dir que trucarà al nostre mòdul, hi passarà el tipus de motor i indicarà la zona horària.
I una persona no hauria de saber que crearem dos recursos diferents dins d'aquest mòdul: un per a MSSQL, el segon per a tota la resta, només perquè a Terraform 0.11 no podeu especificar els valors de la zona horària com a opcionals.
I a la sortida d'aquest mòdul, una persona podrà rebre simplement una adreça. No sabrà a partir de quina base de dades, a partir de quin recurs estem creant tot això internament. Aquest és un element molt important d'ocultació. I això s'aplica no només als mòduls que són públics en codi obert, sinó també als mòduls que escriureu dins dels vostres projectes i equips.
Aquest és el segon argument, que és força important si fa temps que feu servir Terraform. Disposes d'un repositori on col·loca tots els mòduls de Terraform per a la teva empresa. I és força normal que amb el temps aquest projecte creixi fins a una mida d'un o dos megabytes. Això està bé.
Però el problema és com Terraform anomena aquests mòduls. Per exemple, si truqueu a un mòdul per crear cada usuari individual, Terraform carregarà primer tot el repositori i després navegarà a la carpeta on es troba aquest mòdul específic. D'aquesta manera us descarregareu un megabyte cada vegada. Si gestioneu 100 o 200 usuaris, baixareu 100 o 200 megabytes i, a continuació, aneu a aquesta carpeta. Així que, naturalment, no voldreu descarregar un munt de coses cada vegada que premeu "Terraform init".
Hi ha dues solucions a aquest problema. El primer és utilitzar camins relatius. D'aquesta manera indiqueu al codi que la carpeta és local (./). I abans de llançar qualsevol cosa, feu un clon Git d'aquest dipòsit localment. D'aquesta manera ho fas una vegada.
Hi ha, és clar, molts inconvenients. Per exemple, no podeu utilitzar versions. I això de vegades és difícil de conviure.
Segona solució. Si teniu molts submòduls i ja teniu algun tipus de pipeline establert, aleshores hi ha el projecte MBT, que us permet recollir molts paquets diferents d'un monorepositori i pujar-los a S3. Aquesta és una molt bona manera. Així, el fitxer iam-user-1.0.0.zip només pesarà 1 Kb, perquè el codi per crear aquest recurs és molt petit. I funcionarà molt més ràpid.
Parlem del que no es pot utilitzar en mòduls.
Per què hi ha aquest mal als mòduls? El pitjor és suposar usuari. Suposem que l'usuari és una opció d'autenticació del proveïdor que poden utilitzar diferents persones. Per exemple, tots assimilarem el rol. Això vol dir que Terraform assumirà aquest paper. I després amb aquest paper realitzarà altres accions.
I el mal és que si a Vasya li agrada connectar-se a Amazon d'una manera, per exemple, utilitzant la variable d'entorn predeterminada, i a Petya li agrada utilitzar la seva clau compartida, que té en un lloc secret, no podeu especificar totes dues a Terraform. I perquè no experimentin patiment, no cal indicar aquest bloc al mòdul. Això s'ha d'indicar a un nivell superior. És a dir, tenim un mòdul de recursos, un mòdul d'infraestructura i una composició al damunt. I això s'hauria d'indicar en algun lloc més alt.
El segon mal és el subministrador. Aquí el mal no és tan trivial, perquè si escriviu codi i us funciona, potser penseu que si funciona, per què canviar-lo.
El mal és que no sempre controleu quan es posarà en marxa aquest subministrador, en primer lloc. I en segon lloc, no controleu el que significa aws ec2, és a dir, estem parlant de Linux o Windows ara. Per tant, no podeu escriure res que funcioni igual en diferents sistemes operatius o per a diferents casos d'usuari.
L'exemple més comú, que també s'indica a la documentació oficial, és que si escriviu aws_instance i especifiqueu un munt d'arguments, no hi ha res de dolent amb això si especifiqueu el proveïdor "local-exec" allà i executeu el vostre ansible- llibre de jugades.
De fet, sí, no hi ha res dolent en això. Però, literalment, aviat us adonareu que aquesta cosa de l'executiu local no existeix, per exemple, a launch_configuration.
I quan utilitzeu launch_configuration i voleu crear un grup d'escala automàtica a partir d'una instància, llavors a launch_configuration no hi ha cap concepte de "provisionador". Hi ha el concepte de "dades d'usuari".
Per tant, una solució més universal és utilitzar les dades dels usuaris. I s'iniciarà a la pròpia instància, quan la instància estigui activada, o a les mateixes dades d'usuari, quan el grup d'escalat automàtic utilitzi aquesta launch_configuration.
Si encara voleu executar l'aprovisionador, perquè és un component d'enganxament, quan es crea un recurs, en aquest moment haureu d'executar l'aprovisionador, la vostra comanda. Hi ha moltes situacions d'aquest tipus.
I el recurs més correcte per a això s'anomena null_resource. Null_resource és un recurs fictici que mai es crea realment. No toca res, ni API, ni autoscaling. Però us permet controlar quan executar l'ordre. En aquest cas, l'ordre s'executa durant la creació.
Enllaç
Hi ha diversos senyals. No entraré en tots els rètols amb gran detall. Hi ha un article sobre això. Però si heu treballat amb Terraform o heu utilitzat mòduls d'altres persones, sovint us heu adonat que molts mòduls, com la majoria del codi en codi obert, són escrits per persones per a les seves pròpies necessitats. Un home ho va escriure i va resoldre el seu problema. El vaig enganxar a GitHub, el vaig deixar viure. Viurà, però si no hi ha documentació i exemples allà, ningú l'utilitzarà. I si no hi ha cap funcionalitat que us permeti resoldre una mica més que la seva tasca específica, tampoc no l'utilitzarà ningú. Hi ha moltes maneres de perdre usuaris.
Si voleu escriure alguna cosa perquè la gent l'utilitzi, us recomano seguir aquests signes.
Són els següents:
- Documentació i exemples.
- Funcionalitat completa.
- Valors predeterminats raonables.
- Codi net.
- Proves.
Les proves són una situació diferent perquè són força difícils d'escriure. Crec més en la documentació i en els exemples.
Per tant, vam mirar com escriure mòduls. Hi ha dos arguments. El primer, que és el més important, és no escriure si pots, perquè una colla de gent ja ha fet aquestes tasques abans que tu. I en segon lloc, si encara us decidiu, intenteu no utilitzar proveïdors en mòduls i proveïdors.
Aquesta és la part grisa de la documentació. Potser ara penseu: "Alguna cosa no està clara. No està convençut". Però en sis mesos ho veurem.
Ara parlem de com cridar aquests mòduls.
Entenem que el nostre codi creix amb el temps. Ja no tenim un fitxer, ja tenim 20 fitxers. Estan tots en una carpeta. O potser cinc carpetes. Potser estem començant a desglossar-los d'alguna manera per regió, per alguns components. Llavors entenem que ara tenim alguns rudiments de sincronització i orquestració. És a dir, hem d'entendre què hem de fer si canviem els recursos de la xarxa, què hem de fer amb la resta dels nostres recursos, com provocar aquestes dependències, etc.
Hi ha dos extrems. El primer extrem està tot en un. Tenim un fitxer mestre. De moment, aquesta era la millor pràctica oficial al lloc web de Terraform.
Però ara està escrit com a obsolet i eliminat. Amb el temps, la comunitat de Terraform es va adonar que això estava lluny de ser la millor pràctica, perquè la gent va començar a utilitzar el projecte de diferents maneres. I hi ha problemes. Per exemple, quan enumerem totes les dependències en un sol lloc. Hi ha situacions en què fem clic a "Pla Terraform" i fins que Terraform actualitzi els estats de tots els recursos, pot passar molt de temps.
Molt de temps és, per exemple, 5 minuts. Per a alguns això és molt de temps. He vist casos en què van trigar 15 minuts. L'API d'AWS va passar 15 minuts intentant esbrinar què passava amb l'estat de cada recurs. Aquesta és una zona molt gran.
I, naturalment, apareixerà un problema relacionat quan vulgueu canviar alguna cosa en un sol lloc, després espereu 15 minuts i us ofereix un llenç d'alguns canvis. Vas escopir, vas escriure "Sí" i alguna cosa va sortir malament. Aquest és un exemple molt real. Terraform no intenta protegir-te dels problemes. És a dir, escriu el que vulguis. Hi haurà problemes, els vostres problemes. Tot i que Terraform 0.11 no intenta ajudar-te de cap manera. Hi ha certs llocs interessants a 0.12 que et permeten dir: "Vasya, realment vols això, pots recuperar el teu sentit?"
La segona manera és reduir aquesta àrea, és a dir, les trucades d'un lloc poden estar menys connectades des d'un altre lloc.
L'únic problema és que cal escriure més codi, és a dir, cal descriure variables en un gran nombre de fitxers i actualitzar-lo. A algunes persones no els agrada. Això és normal per a mi. I algunes persones pensen: "Per què escriure això en diferents llocs, ho posaré tot en un sol lloc". Això és possible, però aquest és el segon extrem.
Qui té tot això vivint en un sol lloc? Una, dues, tres persones, és a dir, algú l'està utilitzant.
I qui anomena un component concret, un bloc o un mòdul d'infraestructura? De cinc a set persones. Això mola.
La resposta més habitual es troba en algun lloc del mig. Si el projecte és gran, sovint tindreu una situació en què cap solució és adequada i no tot funciona, de manera que acabeu amb una barreja. No hi ha res dolent en això, sempre que entenguis que tots dos tenen avantatges.
Si alguna cosa ha canviat a la VPC de pila i voleu aplicar aquests canvis a EC2, és a dir, voleu actualitzar el grup d'escala automàtica perquè teníeu una subxarxa nova, anomeno aquest tipus d'orquestració de dependències. Hi ha algunes solucions: qui fa servir què?
Puc suggerir quines solucions hi ha. Podeu utilitzar Terraform per fer la màgia, o podeu utilitzar fitxers de creació per utilitzar Terraform. I mireu si alguna cosa ha canviat allà, podeu llançar-lo aquí.
Com us sembla aquesta decisió? Algú creu que aquesta és una solució genial? Veig un somriure, sembla que els dubtes s'han colat.
Per descomptat, no ho proveu a casa. Terraform mai va ser dissenyat per ser executat des de Terraform.
En un informe em van dir: "No, això no funcionarà". La qüestió és que no hauria de funcionar. Tot i que sembla tan impressionant quan podeu llançar Terraform des de Terraform, i després Terraform, no hauríeu de fer-ho. Terraform sempre ha de començar molt fàcilment.
Si necessiteu l'orquestració de trucades quan alguna cosa ha canviat en un lloc, llavors hi ha Terragrunt.
Terragrunt és una utilitat, un complement de Terraform, que us permet coordinar i orquestrar trucades als mòduls d'infraestructura.
Un fitxer de configuració típic de Terraform té aquest aspecte.
Especifiqueu quin mòdul específic voleu trucar.
Quines dependències té el mòdul?
I quins arguments accepta aquest mòdul. Això és tot el que cal saber sobre Terragrunt.
La documentació hi és i hi ha 1 estrelles a GitHub. Però en la majoria dels casos això és el que necessites saber. I això és molt fàcil d'implementar en empreses que tot just comencen a treballar amb Terraform.
Així que l'orquestració és Terragrunt. Hi ha altres opcions.
Ara parlem de com treballar amb el codi.
Si necessiteu afegir noves funcions al vostre codi, en la majoria dels casos això és fàcil. Esteu escrivint un nou recurs, tot és senzill.
Si teniu algun recurs que heu creat amb antelació, per exemple, heu après sobre Terraform després d'obrir un compte d'AWS i voleu utilitzar els recursos que ja teniu, seria convenient ampliar el vostre mòdul d'aquesta manera, de manera que dóna suport a l'ús dels recursos existents.
I va donar suport a la creació de nous recursos mitjançant el recurs de bloc.
A la sortida sempre tornem l'identificador de sortida en funció del que s'ha utilitzat.
El segon problema molt significatiu de Terraform 0.11 és treballar amb llistes.
La dificultat és que si tenim aquesta llista d'usuaris.
I quan creem aquests usuaris amb recursos de blocs, tot va bé. Repassem tota la llista, creant un fitxer per a cadascun. Tot està bé. I aleshores, per exemple, l'usuari3, que està al mig, s'hauria d'eliminar d'aquí, després es recrearan tots els recursos que es van crear després d'ell perquè l'índex canviarà.
Treballar amb llistes en un entorn amb estat. Què és un entorn estatal? Aquesta és la situació en què es crea un nou valor quan es crea aquest recurs. Per exemple, AWS Access Key o AWS Secret Key, és a dir, quan creem un usuari, rebem una nova Accés o Clau secreta. I cada vegada que suprimim un usuari, aquest usuari tindrà una nova clau. Però això no és feng shui, perquè l'usuari no voldrà ser amic de nosaltres si li creem un nou usuari cada vegada que algú surti de l'equip.
Aquesta és la solució. Aquest és el codi escrit en Jsonnet. Jsonnet és un llenguatge de plantilla de Google.
Aquesta ordre us permet acceptar aquesta plantilla i com a sortida retorna un fitxer json que es fa segons la vostra plantilla.
La plantilla té aquest aspecte.
Terraform us permet treballar amb HCL i Json de la mateixa manera, de manera que si teniu la possibilitat de generar Json, podeu introduir-lo a Terraform. El fitxer amb l'extensió .tf.json es baixarà correctament.
I després treballem amb ell com de costum: terraform init, terramorm apply. I creem dos usuaris.
Ara no tenim por si algú deixa l'equip. Només editarem el fitxer json. Vasya Pupkin va marxar, Petya Pyatochkin es va quedar. Petya Pyatochkin no rebrà cap clau nova.
Integrar Terraform amb altres eines no és realment la feina de Terraform. Terraform es va crear com una plataforma per crear recursos i ja està. I tot el que sorgeixi després no és preocupació de Terraform. I no cal teixir-lo allà dins. Hi ha Ansible, que fa tot el que necessiteu.
Però sorgeixen situacions quan volem estendre Terraform i cridar alguna ordre després d'haver completat alguna cosa.
Primer camí. Creem una sortida on escrivim aquesta ordre.
I llavors cridem aquesta ordre des de la sortida de terraform de l'intèrpret d'ordres i especifiquem el valor que volem. Així, l'ordre s'executa amb tots els valors substituïts. És molt còmode.
Segon camí. Aquest és l'ús de null_resource en funció dels canvis a la nostra infraestructura. Podem trucar al mateix local-exe tan bon punt canviï l'ID d'algun recurs.
Naturalment, tot això és suau sobre el paper, perquè Amazon, com tots els altres proveïdors públics, té un munt de casos especials.
El cas més comú és que quan obriu un compte d'AWS, importa quines regions utilitzeu; aquesta característica està activada allà? potser el vas obrir després de desembre de 2013; potser utilitzeu per defecte a VPC, etc. Hi ha moltes restriccions. I Amazon els va dispersar per tota la documentació.
Hi ha algunes coses que recomano evitar.
Per començar, eviteu tots els arguments no secrets dins del pla de Terraform o de la CLI de Terraform. Tot això es pot posar en un fitxer tfvars o en una variable d'entorn.
Però no cal que memoritzeu tota aquesta ordre màgica. Pla Terraform - var i ens enfilem. La primera variable és var, la segona variable és var, la tercera, quarta. El principi més important d'infraestructura com a codi que faig servir més sovint és que només mirant el codi, hauria de tenir una comprensió clara de què s'hi desplega, en quin estat i amb quins valors. I així no he de llegir la documentació ni preguntar a Vasya quins paràmetres va utilitzar per crear el nostre clúster. Només necessito obrir un fitxer amb l'extensió tfvars, que sovint coincideix amb l'entorn, i mirar-ho tot.
A més, no utilitzeu arguments de destinació per reduir l'abast. Per a això és molt més fàcil utilitzar petits mòduls d'infraestructura.
A més, no cal limitar i augmentar el paral·lelisme. Si tinc 150 recursos i vull augmentar el paral·lelisme d'Amazon de 10 a 100 per defecte, és probable que alguna cosa surti malament. O podria anar bé ara, però quan Amazon digui que estàs fent massa trucades, tindreu problemes.
Terraform intentarà reiniciar la majoria d'aquests problemes, però no aconseguireu gairebé res. El paral·lelisme=1 és una cosa important a utilitzar si us trobeu amb algun error dins de l'API d'AWS o dins del proveïdor de Terraform. I llavors cal especificar: paral·lelisme=1 i esperar fins que Terraform acabi una trucada, després la segona i després la tercera. Els llançarà un per un.
La gent sovint em pregunta: "Per què crec que els espais de treball de Terraform són dolents?" Crec que el principi de la infraestructura com a codi és veure quina infraestructura s'ha creat i amb quins valors.
Els espais de treball no han estat creats pels usuaris. Això no vol dir que els usuaris hagin escrit a GitHub problemes que no podem viure sense espais de treball de Terraform. No, no així. Terraform Enterprise és una solució comercial. Terraform de HashiCorp va decidir que necessitàvem espais de treball, així que el vam arxivar. Em sembla molt més fàcil posar-lo en una carpeta a part. Després hi haurà una mica més de fitxers, però serà més clar.
Com treballar amb el codi? De fet, treballar amb llistes és l'únic dolor. I pren Terraform més fàcil. Això no és el que et farà tot genial. No cal posar-hi tot el que està escrit a la documentació.
El tema de l'informe es va escriure "per al futur". En parlaré molt breument. Per al futur, això significa que aviat es publicarà 0.12.
0.12 és un munt de coses noves. Si veniu de la programació habitual, us perdeu tota mena de blocs dinàmics, bucles, operacions de comparació correctes i condicionals, on els costats esquerre i dret no es calculen simultàniament, però depenent de la situació. Ho trobes molt a faltar, així que 0.12 t'ho resoldrà.
Però! Si escriviu cada cop més senzillament, utilitzant mòduls preparats i solucions de tercers, no haureu d'esperar i esperar que vingui el 0.12 i us arregli tot.
Gràcies pel reportatge! Heu parlat de la infraestructura com a codi i, literalment, heu dit una paraula sobre proves. Es necessiten proves en mòduls? De qui és aquesta responsabilitat? L'he d'escriure jo mateix o és responsabilitat dels mòduls?
L'any vinent s'omplirà d'informes que hem decidit provar-ho tot. Què provar és la pregunta més gran. Hi ha moltes dependències, moltes restriccions de diferents proveïdors. Quan estem parlant tu i jo dius: "Necessito proves", aleshores et pregunto: "Què provaràs?" Dius que provaràs a la teva regió. Aleshores dic que això no funciona a la meva regió. És a dir, ni tan sols ens podrem posar d'acord en això. Sense oblidar que hi ha molts problemes tècnics. És a dir, com escriure aquestes proves perquè siguin adequades.
Estic investigant activament aquest tema, és a dir, com generar proves automàticament en funció de la infraestructura que heu escrit. És a dir, si heu escrit aquest codi, he d'executar-lo, a partir d'això puc crear proves.
és una de les biblioteques més esmentades que us permet escriure proves d'integració per a Terraform. Aquesta és una de les utilitats. Prefereixo el tipus DSL, per exemple, rspec.
Anton, gràcies pel reportatge! Em dic Valery. Permeteu-me fer una petita pregunta filosòfica. Hi ha, condicionalment, aprovisionament, hi ha desplegament. L'aprovisionament crea la meva infraestructura, en el desplegament l'omplim amb alguna cosa útil, per exemple, servidors, aplicacions, etc. I és al meu cap que Terraform és més per aprovisionament, i Ansible és més per desplegament, perquè Ansible també és per a la infraestructura física. us permet instal·lar nginx, Postgres. Però, al mateix temps, sembla que Ansible permet l'aprovisionament, per exemple, dels recursos d'Amazon o de Google. Però Terraform també us permet desplegar algun programari mitjançant els seus mòduls. Des del vostre punt de vista, hi ha algun tipus de frontera que vagi entre Terraform i Ansible, on i què és millor utilitzar? O, per exemple, creus que Ansible ja és escombraries, hauries de provar d'utilitzar Terraform per a tot?
Bona pregunta, Valery. Crec que Terraform no ha canviat en termes de propòsit des del 2014. Va ser creat per a la infraestructura i va morir per a la infraestructura. Encara teníem i tindrem una necessitat de gestió de configuració Ansible. El repte és que hi ha dades d'usuari a launch_configuration. I aquí estireu Ansible, etc. Aquesta és la distinció estàndard que més m'agrada.
Si estem parlant d'infraestructures precioses, hi ha utilitats com Packer que recullen aquesta imatge. A continuació, Terraform utilitza la font de dades per trobar aquesta imatge i actualitzar-ne la configuració de llançament. És a dir, d'aquesta manera el pipeline és que primer tirem Tracker, després estirem Terraform. I si es produeix la construcció, es produeix un nou canvi.
Hola! Gràcies pel reportatge! Em dic Misha, empresa RBS. Podeu trucar a Ansible mitjançant el subministrador quan creeu un recurs. Ansible també té un tema anomenat inventari dinàmic. I primer podeu trucar a Terraform i després trucar a Ansible, que agafarà recursos de l'estat i els executarà. Què és millor?
La gent utilitza tots dos amb el mateix èxit. Em sembla que l'inventari dinàmic a Ansible és una cosa convenient, si no estem parlant d'un grup d'escala automàtica. Perquè al grup d'escalat automàtic ja tenim el nostre propi conjunt d'eines, que es diu launch_configuration. A launch_configuration registrem tot el que cal llançar quan creem un nou recurs. Per tant, amb Amazon, utilitzar l'inventari dinàmic i llegir el fitxer Terraform ts, al meu entendre, és excessiu. I si utilitzeu altres eines on no hi ha cap concepte de "grup d'escala automàtica", per exemple, utilitzeu DigitalOcean o algun altre proveïdor on no hi hagi cap grup d'escala automàtica, llavors haureu de treure manualment l'API, trobar adreces IP, crear un fitxer d'inventari dinàmic i Ansible ja ho passarà. És a dir, per a Amazon hi ha launch_configuration, i per a tota la resta hi ha inventari dinàmic.
Font: www.habr.com