Margir þekkja og nota Terraform í daglegu starfi en bestu starfsvenjur fyrir það hafa ekki enn verið mótaðar. Hvert lið þarf að finna upp sínar eigin aðferðir og aðferðir.
Innviðir þínir byrja næstum örugglega einfaldir: nokkrar auðlindir + nokkrir verktaki. Með tímanum vex það í allar áttir. Finnurðu leiðir til að flokka auðlindir í Terraform einingar, skipuleggja kóða í möppur og hvað annað getur hugsanlega farið úrskeiðis? (fræg síðustu orð)
Tíminn líður og þér líður eins og innviðir þínir séu nýja gæludýrið þitt, en hvers vegna? Þú hefur áhyggjur af óútskýranlegum breytingum á innviðunum, þú ert hræddur við að snerta innviðina og kóðann - þar af leiðandi seinkar þú nýrri virkni eða dregur úr gæðum...
Eftir þriggja ára umsjón með safni Terraform samfélagseininga fyrir AWS á Github og langtímaviðhald á Terraform í framleiðslu, er Anton Babenko tilbúinn að deila reynslu sinni: hvernig á að skrifa TF einingar svo það skaði ekki í framtíðinni.
Í lok ræðunnar munu þátttakendur kynnast auðlindastjórnunarreglum í Terraform betur, bestu starfsvenjur tengdar einingar í Terraform og nokkrar samfelldar samþættingarreglur tengdar innviðastjórnun.
Fyrirvari: Ég tek fram að þessi skýrsla er dagsett í nóvember 2018—2 ár eru þegar liðin. Útgáfan af Terraform 0.11 sem fjallað er um í skýrslunni er ekki lengur studd. Undanfarin 2 ár hafa verið gefnar út 2 nýjar útgáfur sem innihalda mikið af nýjungum, endurbótum og breytingum. Vinsamlegast athugaðu þetta og athugaðu skjölin.
Tilvísanir:
- +
- — sjálfvirkt sniðkóða og skjöl
- — rafall Terraform eininga (WIP)
- — Terraform kóðarafall úr sjónrænum skýringarmyndum (WIP)
- www.terraform-best-practices.com
- (Nýjar færslur eru á persónulegu vefsíðunni minni www.antonbabenko.com/)
- @antonbabenko - Twitter, og fullt af mismunandi Slacks
Ég heiti Anton Babenko. Sum ykkar notuðu líklega kóðann sem ég skrifaði. Ég mun nú tala um þetta með meira öryggi en nokkru sinni fyrr, því ég hef aðgang að tölfræði.
Ég vinn á Terraform og hef verið virkur þátttakandi og stuðlað að fjölda opinna verkefna sem tengjast Terraform og Amazon síðan 2015.
Síðan þá hef ég skrifað nægan kóða til að setja hann á áhugaverðan hátt. Og ég skal reyna að segja þér frá þessu núna.
Ég mun tala um ranghala og sérstöðu þess að vinna með Terraform. En það er í raun ekki efni HighLoad. Og nú munt þú skilja hvers vegna.
Með tímanum byrjaði ég að skrifa Terraform einingar. Notendur skrifuðu spurningar, ég endurskrifaði þær. Síðan skrifaði ég ýmis tól til að forsníða kóðann með því að nota pre-commit krók o.s.frv.
Þar voru mörg áhugaverð verkefni. Mér líkar við kóðagerð vegna þess að mér finnst gaman að tölvan geri sífellt meiri vinnu fyrir mig og forritarann, svo ég er núna að vinna að Terraform kóðarafalli úr sjónrænum skýringarmyndum. Kannski hafa einhver ykkar séð þá. Þetta eru fallegir kassar með örvum. Og mér finnst það frábært ef þú getur smellt á „Flytja út“ hnappinn og fengið þetta allt sem kóða.
Ég er frá Úkraínu. Ég hef búið í Noregi í mörg ár.
Einnig var upplýsingum fyrir þessa skýrslu safnað frá fólki sem þekkir nafnið mitt og finnur mig á samfélagsmiðlum. Ég er næstum alltaf með sama gælunafnið.
Eins og ég nefndi er ég aðalviðhaldari Terraform AWS eininga, sem er ein af stærstu geymslum GitHub þar sem við hýsum einingar fyrir algengustu verkefnin: VPC, Autoscaling, RDS.
Og það sem þú heyrðir núna er það grundvallaratriði. Ef þú efast um að þú skiljir hvað Terraform er, þá er betra að eyða tíma þínum annars staðar. Það verður mikið af tæknilegum hugtökum hér. Og ég hikaði ekki við að lýsa því yfir að stigi skýrslunnar væri hæstv. Þetta þýðir að ég get talað með öllum mögulegum hugtökum án mikillar skýringa.
Terraform birtist árið 2014 sem tól sem gerði þér kleift að skrifa, skipuleggja og stjórna innviðum sem kóða. Lykilhugtakið hér er „innviðir sem kóða.
Öll skjöl, eins og ég sagði, eru skrifuð inn . Ég vona að flestir viti af þessari síðu og hafi lesið skjölin. Ef svo er, þá ertu á réttum stað.
Svona lítur venjuleg Terraform stillingarskrá út, þar sem við skilgreinum fyrst nokkrar breytur.
Í þessu tilviki skilgreinum við "aws_region".
Síðan lýsum við hvaða auðlindum við viljum búa til.
Við keyrum nokkrar skipanir, sérstaklega „terraform init“ til að hlaða ósjálfstæði og veitum.
Og við keyrum skipunina „terraform apply“ til að athuga hvort tilgreind uppsetning passi við auðlindirnar sem við bjuggum til. Þar sem við höfum ekki búið til neitt áður, hvetur Terraform okkur til að búa til þessar auðlindir.
Við staðfestum þetta. Þannig búum við til fötu sem kallast sjónögl.
Það eru líka nokkrar svipaðar veitur. Mörg ykkar sem nota Amazon þekkja AWS CloudFormation eða Google Cloud Deployment Manager eða Azure Resource Manager. Hver þeirra hefur sína eigin útfærslu af einhverju tagi til að stjórna auðlindum innan hvers þessara opinberu skýjaveitna. Terraform er sérstaklega gagnlegt vegna þess að það gerir þér kleift að stjórna yfir 100 veitendum. (Nánari upplýsingar )
Markmiðin sem Terraform hefur stefnt að frá upphafi:
- Terraform veitir eina sýn á auðlindir.
- Gerir þér kleift að styðja alla nútíma vettvang.
- Og Terraform var hannað frá upphafi sem tól sem gerir þér kleift að breyta innviðum á öruggan og fyrirsjáanlegan hátt.
Árið 2014 hljómaði orðið „fyrirsjáanlegt“ mjög óvenjulegt í þessu samhengi.
Terraform er alhliða tól. Ef þú ert með API, þá geturðu stjórnað nákvæmlega öllu:
- Þú getur notað meira en 120 veitendur til að stjórna öllu sem þú vilt.
- Til dæmis geturðu notað Terraform til að lýsa aðgangi að GitHub geymslum.
- Þú getur jafnvel búið til og lokað villum í Jira.
- Þú getur stjórnað mæligildum New Relic.
- Þú getur jafnvel búið til skrár í dropbox ef þú virkilega vilt.
Þetta er allt náð með því að nota Terraform veitendur, sem eru með opið API sem hægt er að lýsa í Go.
Segjum að við höfum byrjað að nota Terraform, lesið smá skjöl á síðunni, horft á myndband og byrjað að skrifa main.tf, eins og ég sýndi á fyrri glærunum.
Og allt er frábært, þú ert með skrá sem býr til VPC.
Ef þú vilt búa til VPC, þá tilgreinir þú um það bil þessar 12 línur. Lýstu á hvaða svæði þú vilt búa til, hvaða cidr_block af IP tölum á að nota. Það er allt og sumt.
Auðvitað mun verkefnið stækka smám saman.
Og þú munt bæta við fullt af nýju efni þar: auðlindum, gagnaveitum, þú munt samþætta nýjum veitendum, skyndilega muntu vilja nota Terraform til að stjórna notendum á GitHub reikningnum þínum, osfrv. Þú gætir viljað nota mismunandi DNS veitendur, krossaðu allt. Terraform gerir þetta auðvelt.
Við skulum líta á eftirfarandi dæmi.
Þú bætir smám saman við internet_gateway vegna þess að þú vilt að auðlindir frá VPC þínum hafi netaðgang. Þetta er góð hugmynd.
Niðurstaðan er þessi main.tf:
Þetta er efsti hluti main.tf.
Þetta er neðsti hluti main.tf.
Síðan bætir þú við undirneti. Þegar þú vilt bæta við NAT gáttum, leiðum, leiðartöflum og fullt af öðrum undirnetum, muntu ekki hafa 38 línur, heldur um það bil 200-300 línur.
Það er, main.tf skráin þín er smám saman að stækka. Og oft setur fólk allt í eina skrá. 10-20 Kb birtist í main.tf. Ímyndaðu þér að 10-20 Kb sé textainnihald. Og allt er tengt öllu. Þetta er smám saman að verða erfitt að vinna með. 10-20 Kb er gott notendafall, stundum meira. Og fólk heldur ekki alltaf að þetta sé slæmt.
Eins og í venjulegri forritun, þ.e.a.s. ekki innviði sem kóða, erum við vön að nota fullt af mismunandi flokkum, pakka, einingum, hópum. Terraform gerir þér kleift að gera mikið af því sama.
- Kóðinn er að stækka.
- Ósjálfstæði milli auðlinda fara einnig vaxandi.
Og við höfum mikla þörf. Við skiljum að við getum ekki lifað svona lengur. Kóðinn okkar er að verða gríðarlegur. 10-20 Kb er auðvitað ekki mjög mikið, en við erum aðeins að tala um netstafla, þ.e.a.s. þú hefur aðeins bætt við netauðlindum. Við erum ekki að tala um Application Load Balancer, dreifingu ES cluster, Kubernetes o.s.frv., þar sem auðvelt er að vefja 100 Kb inn. Ef þú skrifar allt þetta niður muntu mjög fljótlega komast að því að Terraform býður upp á Terraform einingar.
Terraform einingar eru sjálfstætt Terraform stillingar sem er stjórnað sem hópur. Það er allt sem þú þarft að vita um Terraform einingar. Þeir eru alls ekki klárir, þeir leyfa þér ekki að gera flóknar tengingar eftir einhverju. Þetta fellur allt á herðar hönnuða. Það er, þetta er bara einhvers konar Terraform stillingar sem þú hefur þegar skrifað. Og þú getur einfaldlega kallað það sem hóp.
Svo við erum að reyna að skilja hvernig við munum fínstilla 10-20-30 Kb af kóðanum okkar. Við erum smám saman að átta okkur á því að við þurfum að nota nokkrar einingar.
Fyrsta tegund eininga sem þú lendir í eru auðlindaeiningar. Þeir skilja ekki um hvað innviðir þínir snúast, um hvað fyrirtæki þitt snýst, hvar og hvaða aðstæður eru. Þetta eru akkúrat einingarnar sem ég, ásamt opnum uppspretta samfélaginu, umsjón og sem við setjum fram sem fyrstu byggingareiningar fyrir innviði þína.
Dæmi um auðlindareiningu.
Þegar við köllum á auðlindareiningu tilgreinum við hvaða slóð við eigum að hlaða innihald hennar.
Við tilgreinum hvaða útgáfu við viljum hlaða niður.
Við afgreiðum fullt af rökum þar. Það er allt og sumt. Það er allt sem við þurfum að vita þegar við notum þessa einingu.
Margir halda að ef þeir nota nýjustu útgáfuna verði allt stöðugt. En nei. Uppbyggingin verður að vera útgáfa, við verðum að svara skýrt í hvaða útgáfu þessi eða hinn íhluturinn var settur á.
Hér er kóðinn sem er inni í þessari einingu. Öryggishópseining. Hér fer rollan í 640. línuna. Að búa til öryggishópaauðlind í Amazon í öllum mögulegum stillingum er mjög ekki léttvægt verkefni. Það er ekki nóg að stofna bara öryggishóp og segja honum hvaða reglur eigi að setja til hans. Það væri mjög einfalt. Það eru milljón mismunandi takmarkanir inni á Amazon. Til dæmis ef þú notar VPC endapunktur, forskeytislisti, ýmis API og reynir að sameina allt þetta við allt hitt, þá leyfir Terraform þér ekki að gera þetta. Og Amazon API leyfir þetta ekki heldur. Þess vegna þurfum við að fela alla þessa hræðilegu rökfræði í einingu og gefa notandakóðann sem lítur svona út.
Notandinn þarf ekki að vita hvernig það er gert inni.
Önnur gerð eininga, sem samanstendur af auðlindareiningum, leysir nú þegar vandamál sem eiga betur við fyrirtæki þitt. Oft er þetta staður sem er framlenging fyrir Terraform og setur nokkur stíf gildi fyrir merki, fyrir fyrirtækisstaðla. Þú getur líka bætt við virkni þar sem Terraform leyfir þér ekki að nota eins og er. Þetta er einmitt núna. Nú er útgáfa 0.11, sem er við það að heyra fortíðinni til. En samt eru forvinnsluvélar, jsonnet, cookiecutter og fullt af öðrum hlutum aukabúnaðurinn sem þarf að nota fyrir fulla vinnu.
Næst mun ég sýna nokkur dæmi um þetta.
Innviðaeiningin er kölluð á nákvæmlega sama hátt.
Tilgreint er hvaðan á að hlaða efnið niður.
Fullt af gildum eru send inn og send inn í þessa einingu.
Næst, inni í þessari einingu, er hópur auðlindareininga kallaðir til að búa til VPC eða Application Load Balancer, eða til að búa til öryggishóp eða fyrir Elastic Container Service klasa.
Það eru tvær tegundir af einingum. Þetta er mikilvægt að skilja vegna þess að flestar upplýsingarnar sem ég hef flokkað í þessari skýrslu eru ekki skrifaðar í skjölin.
Og skjölin í Terraform núna eru frekar erfið vegna þess að það segir bara að það séu þessir eiginleikar, þú getur notað þá. En hún segir ekki hvernig eigi að nota þessa eiginleika, hvers vegna það er betra að nota þá. Þess vegna skrifar mjög mikill fjöldi fólks eitthvað sem það getur ekki lifað með.
Við skulum skoða hvernig á að skrifa þessar einingar næst. Síðan munum við sjá hvernig á að hringja í þá og hvernig á að vinna með kóðann.
Terraform Registry -
Ábending #0 er að skrifa ekki auðlindaeiningar. Flestar þessar einingar eru þegar skrifaðar fyrir þig. Eins og ég sagði, þeir eru opinn uppspretta, þeir innihalda enga viðskiptarökfræði þína, þeir hafa ekki harðkóðun gildi fyrir IP tölur, lykilorð osfrv. Einingin er mjög sveigjanleg. Og það hefur líklegast þegar verið skrifað. Það eru margar einingar fyrir auðlindir frá Amazon. Um 650. Og flestir eru í góðum gæðum.
Í þessu dæmi kom einhver til þín og sagði: „Ég vil geta stjórnað gagnagrunni. Búðu til einingu svo ég geti búið til gagnagrunn." Viðkomandi veit ekki útfærsluupplýsingar hvorki Amazon né Terraform. Hann segir einfaldlega: "Ég vil stjórna MSSQL." Það er, við meinum að það mun kalla á eininguna okkar, fara framhjá vélargerðinni þar og gefa til kynna tímabeltið.
Og maður ætti ekki að vita að við munum búa til tvö mismunandi tilföng inni í þessari einingu: annað fyrir MSSQL, annað fyrir allt annað, aðeins vegna þess að í Terraform 0.11 er ekki hægt að tilgreina tímabeltisgildi sem valfrjálst.
Og við brottför frá þessari einingu mun einstaklingur geta einfaldlega fengið heimilisfang. Hann mun ekki vita úr hvaða gagnagrunni, úr hvaða auðlind við erum að búa til allt þetta innbyrðis. Þetta er mjög mikilvægur þáttur leyndar. Og þetta á ekki aðeins við um þær einingar sem eru opinberar í opnum hugbúnaði, heldur einnig þær einingar sem þú munt skrifa inn í verkefnin þín og teymi.
Þetta er önnur rökin, sem er mjög mikilvæg ef þú hefur notað Terraform í nokkurn tíma. Þú ert með geymslu þar sem þú setur allar Terraform einingarnar þínar fyrir fyrirtækið þitt. Og það er alveg eðlilegt að með tímanum muni þetta verkefni vaxa upp í eitt eða tvö megabæti. Þetta er fínt.
En vandamálið er hvernig Terraform kallar þessar einingar. Til dæmis, ef þú hringir í einingu til að búa til hvern einstakan notanda, mun Terraform fyrst hlaða alla geymsluna og fara síðan í möppuna þar sem þessi tiltekna eining er staðsett. Þannig munt þú hala niður einu megabæti í hvert skipti. Ef þú stjórnar 100 eða 200 notendum muntu hala niður 100 eða 200 megabæti og fara síðan í þá möppu. Svo þú vilt náttúrulega ekki hlaða niður fullt af dóti í hvert skipti sem þú smellir á "Terraform init".
Það eru tvær lausnir á þessu vandamáli. Í fyrsta lagi er að nota afstæðar leiðir. Þannig gefur þú til kynna í kóðanum að mappan sé staðbundin (./). Og áður en þú setur eitthvað af stað, gerirðu Git klón af þessari geymslu á staðnum. Svona gerirðu það einu sinni.
Það eru auðvitað margir gallar. Til dæmis er ekki hægt að nota útgáfu. Og þetta er stundum erfitt að lifa með.
Önnur lausn. Ef þú ert með mikið af undireiningum og þú ert nú þegar með einhvers konar staðfesta leiðslu, þá er MBT verkefnið, sem gerir þér kleift að safna mörgum mismunandi pakka úr eingeymslu og hlaða þeim upp á S3. Þetta er mjög góð leið. Þannig mun iam-user-1.0.0.zip skráin vega aðeins 1 Kb, vegna þess að kóðinn til að búa til þessa auðlind er mjög lítill. Og það mun vinna miklu hraðar.
Við skulum tala um það sem ekki er hægt að nota í einingum.
Af hverju er þetta illt í mátunum? Það versta er að gera ráð fyrir notanda. Gerum ráð fyrir að notandi sé auðkenningarvalkostur þjónustuveitunnar sem mismunandi fólk getur notað. Til dæmis munum við öll tileinka okkur hlutverkið. Þetta þýðir að Terraform mun taka að sér þetta hlutverk. Og þá með þessu hlutverki mun það framkvæma aðrar aðgerðir.
Og meinið er að ef Vasya líkar við að tengjast Amazon á einn hátt, til dæmis með því að nota sjálfgefna umhverfisbreytuna, og Petya vill nota sameiginlega lykilinn sinn, sem hann hefur á leynilegum stað, þá er ekki hægt að tilgreina báða í Terraform. Og svo að þeir upplifi ekki þjáningu er engin þörf á að gefa til kynna þennan blokk í einingunni. Þetta verður að koma fram á hærra stigi. Það er að segja að við höfum auðlindareiningu, innviðaeiningu og samsetningu ofan á. Og þetta ætti að vera gefið til kynna einhvers staðar hærra.
Annað illt er útvegurinn. Hér er illskan ekki svo léttvæg, því ef þú skrifar kóða og hann virkar fyrir þig, þá gætirðu hugsað að ef hann virkar, hvers vegna þá að breyta honum.
Hið illa er að þú stjórnar ekki alltaf hvenær þessi úthlutun verður hleypt af stokkunum, í fyrsta lagi. Og í öðru lagi ræður þú ekki hvað aws ec2 þýðir, þ.e.a.s. erum við að tala um Linux eða Windows núna. Svo þú getur ekki skrifað eitthvað sem virkar eins á mismunandi stýrikerfum eða fyrir mismunandi notendatilvik.
Algengasta dæmið, sem einnig er gefið til kynna í opinberu skjölunum, er að ef þú skrifar aws_instance og tilgreinir fullt af rökum, þá er ekkert athugavert við það ef þú tilgreinir ákvæðið „local-exec“ þar og keyrir þitt ansible- leikbók.
Reyndar, já, það er ekkert athugavert við það. En bókstaflega fljótlega muntu átta þig á því að þetta local-exec hlutur er ekki til, til dæmis í launch_configuration.
Og þegar þú notar launch_configuration, og þú vilt búa til sjálfvirkan stærðarhóp úr einu tilviki, þá er ekkert hugtak í launch_configuration um „provisioner“. Það er hugtakið „notendagögn“.
Þess vegna er alhliða lausnin að nota notendagögn. Og það verður ræst annaðhvort á tilvikinu sjálfu, þegar kveikt er á tilvikinu, eða í sömu notendagögnum, þegar sjálfvirka mælikvarðahópurinn notar þessa launch_configuration.
Ef þú vilt samt keyra úthlutunina, vegna þess að hann er límhluti, þegar eitt tilfang er búið til, þá þarftu að keyra úthlutunina þína, skipunina þína. Það er fullt af slíkum aðstæðum.
Og réttasta úrræðið fyrir þetta er kallað null_resource. Null_resource er dummy auðlind sem er í raun aldrei búin til. Það snertir ekki neitt, ekkert API, engin sjálfkvörðun. En það gerir þér kleift að stjórna hvenær á að keyra skipunina. Í þessu tilviki er skipunin keyrð meðan á stofnun stendur.
Link
Það eru nokkur merki. Ég ætla ekki að fara nákvæmlega út í öll merki. Það er grein um þetta. En ef þú hefur unnið með Terraform eða notað einingar annarra, þá hefur þú oft tekið eftir því að margar einingar, eins og flestir kóðar í opnum uppspretta, eru skrifaðar af fólki fyrir eigin þarfir. Maður skrifaði það og leysti vandamál sitt. Ég festi það í GitHub, láttu það lifa. Það mun lifa, en ef það eru engin skjöl og dæmi þar, þá mun enginn nota það. Og ef það er engin virkni sem gerir þér kleift að leysa aðeins meira en tiltekið verkefni þess, þá mun enginn nota það heldur. Það eru svo margar leiðir til að missa notendur.
Ef þú vilt skrifa eitthvað svo fólk noti það, þá mæli ég með því að fylgja þessum skiltum.
Þetta eru:
- Skjöl og dæmi.
- Full virkni.
- Sanngjarnt vanskil.
- Hreinn kóða.
- Próf.
Próf eru önnur staða vegna þess að það er frekar erfitt að skrifa þau. Ég trúi meira á skjöl og dæmi.
Svo skoðuðum við hvernig á að skrifa einingar. Það eru tvö rök. Það fyrsta, sem er mikilvægast, er að skrifa ekki ef þú getur, því fullt af fólki hefur þegar unnið þessi verkefni á undan þér. Og í öðru lagi, ef þú ákveður enn, reyndu þá að nota ekki veitendur í einingum og afgreiðslum.
Þetta er grái hluti skjalanna. Þú gætir nú hugsað: „Eitthvað er óljóst. Ekki sannfærður." En við sjáum til eftir sex mánuði.
Nú skulum við tala um hvernig á að kalla þessar einingar.
Við skiljum að kóðinn okkar stækkar með tímanum. Við höfum ekki lengur eina skrá, við erum nú þegar með 20 skrár. Þau eru öll í einni möppu. Eða kannski fimm möppur. Kannski erum við farin að skipta þeim á einhvern hátt niður eftir svæðum, eftir einhverjum þáttum. Þá skiljum við að nú höfum við nokkur grunnatriði samstillingar og hljómsveitar. Það er, við verðum að skilja hvað við ættum að gera ef við breyttum netauðlindum, hvað við ættum að gera við restina af auðlindum okkar, hvernig á að valda þessum ósjálfstæði osfrv.
Það eru tvær öfgar. Fyrsta öfga er allt í einu. Við erum með eina aðalskrá. Í bili var þetta opinbera besti aðferðin á Terraform vefsíðunni.
En nú er það skrifað sem aflagt og fjarlægt. Með tímanum áttaði Terraform samfélagið að þetta var langt frá því að vera besti aðferðin, því fólk fór að nota verkefnið á mismunandi hátt. Og það eru vandamál. Til dæmis, þegar við skráum öll ósjálfstæði á einum stað. Það eru aðstæður þegar við smellum á „Terraform áætlun“ og þangað til Terraform uppfærir stöðu allra auðlinda getur mikill tími liðið.
Mikill tími er til dæmis 5 mínútur. Fyrir suma er þetta mikill tími. Ég hef séð tilvik þar sem það tók 15 mínútur. AWS API eyddi 15 mínútum í að reyna að komast að því hvað var að gerast með stöðu hverrar auðlindar. Þetta er mjög stórt svæði.
Og náttúrulega mun tengt vandamál birtast þegar þú vilt breyta einhverju á einum stað, þá bíðurðu í 15 mínútur og það gefur þér striga af nokkrum breytingum. Þú hræktir, skrifaðir „Já“ og eitthvað fór úrskeiðis. Þetta er mjög raunverulegt dæmi. Terraform reynir ekki að verja þig fyrir vandamálum. Það er að segja, skrifaðu það sem þú vilt. Það verða vandamál - vandamál þín. Þó að Terraform 0.11 sé ekki að reyna að hjálpa þér á nokkurn hátt. Það eru ákveðnir áhugaverðir staðir í 0.12 sem leyfa þér að segja: "Vasya, þú vilt virkilega þetta, geturðu komið til vits og ára?"
Önnur leiðin er að minnka þetta svæði, það er að símtöl frá einum stað geta verið minna tengd frá öðrum stað.
Eina vandamálið er að þú þarft að skrifa meiri kóða, þ.e.a.s. þú þarft að lýsa breytum í miklum fjölda skráa og uppfæra þetta. Sumum líkar það ekki. Þetta er eðlilegt fyrir mig. Og sumir hugsa: "Af hverju að skrifa þetta á mismunandi stöðum, ég mun setja þetta allt á einn stað." Þetta er mögulegt, en þetta er önnur öfga.
Hver á þetta allt saman á einum stað? Einn, tveir, þrír, það er að segja einhver er að nota það.
Og hver kallar einn ákveðinn íhlut, eina blokk eða eina innviðaeiningu? Fimm til sjö manns. Þetta er svalt.
Algengasta svarið er einhvers staðar í miðjunni. Ef verkefnið er stórt þá er oft sú staða að engin lausn hentar og ekki gengur allt upp þar, þannig að þú endar með blöndun. Það er ekkert athugavert við þetta, svo lengi sem þú skilur að hvort tveggja hefur kosti.
Ef eitthvað breyttist í stafla VPC og þú vildir beita þessum breytingum á EC2, þ.e.a.s. þú vildir uppfæra sjálfvirka skalahópinn vegna þess að þú varst með nýtt undirnet, þá kalla ég þessa tegund af ósjálfstæði. Það eru nokkrar lausnir: hver notar hvað?
Ég get bent á hvaða lausnir það eru. Þú getur notað Terraform til að gera töfrana, eða þú getur notað makefiles til að nota Terraform. Og sjáðu hvort eitthvað hefur breyst þar, þú getur ræst það hér.
Hvernig líst þér á þessa ákvörðun? Trúir einhver að þetta sé flott lausn? Ég sé bros, efasemdir hafa greinilega laumast að.
Auðvitað, ekki reyna þetta heima. Terraform var aldrei hannað til að keyra frá Terraform.
Í einni skýrslu sögðu þeir mér: „Nei, þetta mun ekki virka. Málið er að það ætti ekki að virka. Þó það líti svo áhrifamikið út þegar þú getur ræst Terraform frá Terraform, og síðan Terraform, þá ættirðu ekki að gera það. Terraform ætti alltaf að byrja mjög auðveldlega.
Ef þig vantar símtalshljómsveit þegar eitthvað hefur breyst á einum stað, þá er það Terragrunt.
Terragrunt er tól, viðbót við Terraform, sem gerir þér kleift að samræma og skipuleggja símtöl í innviðaeiningar.
Dæmigerð Terraform stillingarskrá lítur svona út.
Þú tilgreinir hvaða tiltekna einingu þú vilt hringja í.
Hvaða ósjálfstæði hefur einingin?
Og hvaða rök samþykkir þessi eining. Það er allt sem þarf að vita um Terragrunt.
Skjölin eru til og það eru 1 stjörnur á GitHub. En í flestum tilfellum er þetta það sem þú þarft að vita. Og þetta er mjög auðvelt að innleiða í fyrirtækjum sem eru að byrja að vinna með Terraform.
Svo hljómsveitin er Terragrunt. Það eru aðrir valkostir.
Nú skulum við tala um hvernig á að vinna með kóðann.
Ef þú þarft að bæta nýjum eiginleikum við kóðann þinn er þetta í flestum tilfellum auðvelt. Þú ert að skrifa nýtt tilfang, allt er einfalt.
Ef þú ert með einhverja auðlind sem þú bjóst til fyrirfram, til dæmis, þú lærðir um Terraform eftir að þú opnaðir AWS reikning og vilt nota þau auðlind sem þú hefur nú þegar, þá væri rétt að stækka eininguna þína á þennan hátt, þannig að það styður við notkun núverandi auðlinda.
Og studdi stofnun nýrra auðlinda með því að nota blokkaauðlindina.
Við úttak skilum við alltaf framleiðsluauðkenni eftir því hvað var notað.
Annað mjög þýðingarmikið vandamál í Terraform 0.11 er að vinna með lista.
Erfiðleikarnir eru að ef við höfum slíkan lista yfir notendur.
Og þegar við búum til þessa notendur með því að nota blokkarúrræði, þá gengur allt vel. Við förum í gegnum allan listann og búum til skrá fyrir hvern. Allt er í lagi. Og svo ætti td user3, sem er í miðjunni, að fjarlægja héðan, þá verða öll tilföng sem voru búin til eftir hann endurgerð því vísitalan mun breytast.
Vinna með lista í ríkulegu umhverfi. Hvað er ástandsríkt umhverfi? Þetta er ástandið þar sem nýtt gildi verður til þegar þessi auðlind er búin til. Til dæmis, AWS Access Key eða AWS Secret Key, þ.e. þegar við búum til notanda fáum við nýjan aðgang eða leynilykil. Og í hvert skipti sem við eyðum notanda mun þessi notandi hafa nýjan lykil. En þetta er ekki feng shui, því notandinn vill ekki vera vinur okkar ef við búum til nýjan notanda fyrir hann í hvert sinn sem einhver yfirgefur liðið.
Þetta er lausnin. Þetta er kóði skrifaður í Jsonnet. Jsonnet er sniðmát tungumál frá Google.
Þessi skipun gerir þér kleift að samþykkja þetta sniðmát og sem úttak skilar það json skrá sem er gerð í samræmi við sniðmátið þitt.
Sniðmátið lítur svona út.
Terraform gerir þér kleift að vinna með bæði HCL og Json á sama hátt, þannig að ef þú hefur getu til að búa til Json, þá geturðu sett það inn í Terraform. Skránni með endingunni .tf.json verður hlaðið niður.
Og svo vinnum við með það eins og venjulega: terraform init, terramorm gilda. Og við búum til tvo notendur.
Nú erum við ekki hræddir um að einhver fari frá liðinu. Við munum bara breyta json skránni. Vasya Pupkin fór, Petya Pyatochkin var eftir. Petya Pyatochkin mun ekki fá nýjan lykil.
Að samþætta Terraform við önnur verkfæri er í raun ekki hlutverk Terraform. Terraform var búið til sem vettvangur til að búa til auðlindir og það er það. Og allt sem kemur upp seinna er ekki áhyggjuefni Terraform. Og það er óþarfi að vefja það þarna inn. Það er Ansible, sem gerir allt sem þú þarft.
En aðstæður koma upp þegar við viljum lengja Terraform og kalla á einhverja skipun eftir að eitthvað hefur lokið.
Fyrsta leiðin. Við búum til úttak þar sem við skrifum þessa skipun.
Og þá köllum við þessa skipun frá skelinni terraform úttak og tilgreinum gildið sem við viljum. Þannig er skipunin keyrð með öllum gildum sem skipt er út. Það er mjög þægilegt.
Önnur leið. Þetta er notkun á null_resource eftir breytingum á innviðum okkar. Við getum hringt í sama local-exe um leið og auðkenni einhverrar auðlindar breytist.
Auðvitað er þetta allt slétt á pappírnum, vegna þess að Amazon, eins og allir aðrir opinberir veitendur, hefur fullt af eigin brúnum málum.
Algengasta brún tilvikið er að þegar þú opnar AWS reikning skiptir það máli hvaða svæði þú notar; er þessi eiginleiki virkur þar; kannski þú opnaðir það eftir desember 2013; kannski ertu að nota default í VPC osfrv. Það eru margar takmarkanir. Og Amazon dreifði þeim um skjölin.
Það eru nokkur atriði sem ég mæli með að forðast.
Til að byrja, forðastu öll óleynileg rök innan Terraform áætlunarinnar eða Terraform CLI. Allt þetta er hægt að setja annað hvort í tfvars skrá eða í umhverfisbreytu.
En þú þarft ekki að leggja alla þessa töfraskipun á minnið. Terraform áætlun – var og við förum. Fyrsta breytan er var, önnur breytan er var, þriðja, fjórða. Mikilvægasta reglan um innviði sem kóða sem ég nota oftast er að bara með því að skoða kóðann ætti ég að hafa skýran skilning á því hvað er notað þar, í hvaða ástandi og með hvaða gildi. Og svo ég þarf ekki að lesa skjölin eða spyrja Vasya hvaða færibreytur hann notaði til að búa til þyrpinguna okkar. Ég þarf bara að opna skrá með tfvars endingunni sem passar oft við umhverfið og skoða allt þar.
Einnig má ekki nota markrök til að minnka umfangið. Fyrir þetta er miklu auðveldara að nota litlar innviðaeiningar.
Einnig er engin þörf á að takmarka og auka samsvörun. Ef ég er með 150 auðlindir og ég vil auka samhliða Amazon frá sjálfgefna 10 í 100, þá mun líklega eitthvað fara úrskeiðis. Eða það gæti gengið vel núna, en þegar Amazon segir að þú sért að hringja of mörg símtöl, verður þú í vandræðum.
Terraform mun reyna að endurræsa flest þessara vandamála, en þú nærð nánast engu. Parallelism=1 er mikilvægt að nota ef þú rekst á einhverja villu inni í AWS API eða inni í Terraform veitunni. Og þá þarftu að tilgreina: parallelism=1 og bíða þar til Terraform klárar eitt símtal, svo annað, svo þriðja. Hann mun hleypa þeim af stað einn af öðrum.
Fólk spyr mig oft: "Hvers vegna held ég að Terraform vinnusvæði séu vond?" Ég tel að meginreglan um innviði sem kóða sé að sjá hvaða innviðir hafa verið búnir til og með hvaða gildum.
Vinnusvæði voru ekki búin til af notendum. Þetta þýðir ekki að notendur hafi skrifað í GitHub mál að við getum ekki lifað án Terraform vinnusvæða. Nei ekki svona. Terraform Enterprise er viðskiptalausn. Terraform frá HashiCorp ákvað að við þyrftum vinnusvæði, svo við sendum það í burtu. Mér finnst miklu auðveldara að setja það í sérstaka möppu. Þá verða aðeins fleiri skrár, en það verður skýrara.
Hvernig á að vinna með kóðann? Reyndar er eini sársaukinn að vinna með lista. Og taktu Terraform auðveldara. Þetta er ekki hluturinn sem mun gera allt frábært fyrir þig. Það þarf ekki að troða öllu sem er skrifað í skjölin þar.
Efni skýrslunnar var skrifað „til framtíðar“. Ég ætla að ræða þetta mjög stuttlega. Fyrir framtíðina þýðir þetta að 0.12 mun koma út fljótlega.
0.12 er fullt af nýju efni. Ef þú kemur frá venjulegri forritun, þá missir þú af alls kyns kubbum, lykkjum, réttum og skilyrtum samanburðaraðgerðum, þar sem vinstri og hægri hlið eru ekki reiknuð samtímis, heldur eftir aðstæðum. Þú saknar þess mikið, svo 0.12 mun leysa það fyrir þig.
En! Ef þú skrifar minna og einfaldara með því að nota tilbúnar einingar og þriðja aðila lausnir, þá þarftu ekki að bíða og vona að 0.12 komi og laga allt fyrir þig.
Takk fyrir skýrsluna! Þú talaðir um innviði sem kóða og sagðir bókstaflega eitt orð um próf. Er þörf á prófum í einingum? Á hverra ábyrgð er þetta? Þarf ég að skrifa það sjálfur eða er það á ábyrgð eininganna?
Næsta ár verður fullt af skýrslum um að við höfum ákveðið að prófa allt. Hvað á að prófa er stærsta spurningin. Það er mikið af ósjálfstæði, mikið af takmörkunum frá mismunandi veitendum. Þegar ég og þú erum að tala saman og þú segir: "Ég þarf próf," þá spyr ég: "Hvað ætlarðu að prófa?" Þú segir að þú munt prófa á þínu svæði. Þá segi ég að þetta virkar ekki á mínu svæði. Það er, við munum ekki einu sinni geta verið sammála um þetta. Svo ekki sé minnst á að það eru mikil tæknileg vandamál. Það er, hvernig á að skrifa þessi próf þannig að þau séu fullnægjandi.
Ég er virkur að rannsaka þetta efni, þ.e. hvernig á að búa til próf sjálfkrafa út frá innviðunum sem þú skrifaðir. Það er, ef þú skrifaðir þennan kóða, þá þarf ég að keyra hann, út frá þessu get ég búið til próf.
er eitt algengasta bókasafnið sem gerir þér kleift að skrifa samþættingarpróf fyrir Terraform. Þetta er ein af tólunum. Ég vil frekar DSL gerð, til dæmis, rspec.
Anton, takk fyrir skýrsluna! Ég heiti Valery. Leyfðu mér að spyrja smá heimspekilegrar spurningar. Það er, með skilyrðum, útvegun, það er dreifing. Úthlutun skapar innviði mína, í uppsetningu fyllum við það af einhverju gagnlegu, til dæmis, netþjónum, forritum osfrv. Og það er í hausnum á mér að Terraform er meira fyrir útvegun og Ansible er meira fyrir dreifingu, því Ansible er líka fyrir líkamlega innviði gerir þér kleift að setja upp nginx, Postgres. En á sama tíma virðist Ansible leyfa úthlutun, til dæmis, á Amazon eða Google auðlindum. En Terraform gerir þér líka kleift að setja upp hugbúnað með því að nota einingar þess. Frá þínu sjónarhorni, eru einhvers konar landamæri sem liggja á milli Terraform og Ansible, hvar og hvað er betra að nota? Eða, til dæmis, heldurðu að Ansible sé nú þegar rusl, ættir þú að prófa að nota Terraform fyrir allt?
Góð spurning, Valery. Ég tel að Terraform hafi ekki breyst hvað varðar tilgang síðan 2014. Það var búið til fyrir innviði og dó fyrir innviði. Við höfðum enn og munum hafa þörf fyrir stillingarstjórnun Ansible. Áskorunin er sú að það eru notendagögn inni í launch_configuration. Og þarna dregurðu Ansible, o.s.frv. Þetta er staðalgreiningin sem mér líkar best við.
Ef við erum að tala um í fallegum innviðum, þá eru tól eins og Packer sem safna þessari mynd. Og svo notar Terraform gagnagjafann til að finna þessa mynd og uppfæra launch_configuration hennar. Það er, á þennan hátt er leiðslan sú að við drögum fyrst Tracker, drögum síðan Terraform. Og ef uppbygging á sér stað, þá á sér stað ný breyting.
Halló! Takk fyrir skýrsluna! Ég heiti Misha, RBS fyrirtæki. Þú getur hringt í Ansible í gegnum úthlutun þegar þú býrð til tilföng. Ansible hefur einnig efni sem kallast dynamic inventory. Og þú getur fyrst hringt í Terraform og síðan hringt í Ansible, sem mun taka fjármagn frá ríkinu og framkvæma það. Hvað er betra?
Fólk notar hvort tveggja með jöfnum árangri. Mér sýnist að kraftmikið birgðahald í Ansible sé hentugur hlutur, ef við erum ekki að tala um sjálfvirkan flokkunarhóp. Vegna þess að í sjálfstærðunarhópnum höfum við nú þegar okkar eigin verkfærakistu, sem kallast launch_configuration. Í launch_configuration skráum við allt sem þarf að ræsa þegar við búum til nýtt tilfang. Þess vegna, með Amazon, að nota kraftmikla birgðaskrá og lesa Terraform ts skrána, að mínu mati, er of mikið. Og ef þú notar önnur verkfæri þar sem það er ekkert hugtak um „sjálfvirkan stærðarhóp“, til dæmis, þú notar DigitalOcean eða einhvern annan þjónustuaðila þar sem enginn sjálfstýringarhópur er til, þá verður þú að draga API handvirkt, finna IP tölur, búa til kraftmikla birgðaskrá og Ansible mun þegar reika í gegnum hana. Það er, fyrir Amazon er launch_configuration, og fyrir allt annað er kraftmikið birgðahald.
Heimild: www.habr.com