Watu wengi wanajua na kutumia Terraform katika kazi zao za kila siku, lakini mbinu bora zaidi kwa hilo bado hazijaanzishwa. Kila timu inapaswa kuunda njia na mbinu zake.
Miundombinu yako karibu inaanza rahisi: rasilimali chache + watengenezaji wachache. Baada ya muda, inakua kwa kila aina ya njia. Unapata njia za kuweka rasilimali katika moduli za Terraform, panga nambari kwenye folda, na ni nini kinachoweza kwenda vibaya? (Maneno maarufu ya mwisho.)
Muda unapita, na unahisi kama miundombinu yako ni mnyama wako mpya, lakini kwa nini? Una wasiwasi kuhusu mabadiliko ambayo hayajafafanuliwa kwenye miundombinu, unaogopa kuigusa na msimbo—na kwa sababu hiyo, unaishia kuchelewesha vipengele vipya au kupunguza ubora...
Baada ya miaka mitatu kusimamia mkusanyiko wa moduli za jamii za Terraform za AWS kwenye Github na kusaidia Terraform katika uzalishaji kwa muda mrefu, Anton Babenko yuko tayari kushiriki uzoefu wake: jinsi ya kuandika moduli za Terraform ili kuepuka maumivu ya baadaye.
Kufikia mwisho wa mazungumzo, washiriki watakuwa wamefahamu zaidi kanuni za usimamizi wa rasilimali katika Terraform, mbinu bora zinazohusiana na moduli za Terraform, na baadhi ya kanuni zinazoendelea za ujumuishaji zinazohusiana na usimamizi wa miundombinu.
disclaimer: Tafadhali kumbuka kwamba hotuba hii ni ya Novemba 2018—miaka miwili imepita. Toleo la Terraform lililojadiliwa katika mazungumzo haya, 0.11, halitumiki tena. Katika miaka miwili iliyopita, matoleo mawili mapya yametolewa, na kutambulisha idadi kubwa ya vipengele vipya, maboresho na mabadiliko. Tafadhali makini na hili na uangalie nyaraka.
Marejeo:
- +
- — uumbizaji otomatiki wa msimbo na nyaraka
- - Jenereta ya moduli ya Terraform (WIP)
- - Jenereta ya nambari ya Terraform kutoka kwa michoro inayoonekana (WIP)
- www.terraform-best-practices.com
- (Machapisho mapya yapo kwenye tovuti ya kibinafsi www.antonbabenko.com/)
- @antonbabenko - Twitter, na kundi la Slacks tofauti
Jina langu ni Anton Babenko. Labda baadhi yenu mmetumia msimbo nilioandika. Ninaweza kusema hili kwa ujasiri zaidi kuliko hapo awali kwa sababu ninaweza kupata takwimu.
Mimi ni msanidi wa Terraform na nimekuwa mshiriki hai na mchangiaji kwa idadi ya miradi ya chanzo huria inayohusiana na Terraform na Amazon tangu 2015.
Tangu wakati huo, nimeandika nambari ya kutosha kuwasilisha hii kwa njia ya kupendeza. Na nitajaribu kuelezea sasa.
Nitakuwa nikishughulikia ugumu na maelezo ya kufanya kazi na Terraform. Lakini hiyo si kweli lengo la HighLoad. Na utaona kwa nini sasa.
Baada ya muda, nilianza kuandika moduli za Terraform. Watumiaji wangetuma maswali, na ningeyaandika upya. Kisha niliandika huduma mbali mbali za fomati ya msimbo kwa kutumia ndoano za kujitolea kabla, nk.
Kumekuwa na miradi mingi ya kuvutia. Ninafurahia utengenezaji wa msimbo kwa sababu napenda kuruhusu kompyuta kufanya kazi zaidi na zaidi kwa ajili yangu na programu, kwa hivyo ninafanya kazi kwenye jenereta ya msimbo wa Terraform kulingana na michoro za kuona. Huenda baadhi yenu mmewaona. Ni masanduku mazuri yenye mishale. Na nadhani ni nzuri ikiwa unaweza kubofya kitufe cha "Hamisha" na upate yote kama nambari.
Ninatoka Ukraine. Nimeishi Norway kwa miaka mingi.
Taarifa za ripoti hii pia zilikusanywa kutoka kwa watu wanaojua jina langu na kunipata kwenye mitandao ya kijamii. Karibu kila wakati nina jina la utani sawa.
Kama nilivyotaja, mimi ndiye mtunzaji mkuu wa moduli za Terraform AWS, ambayo ni moja wapo ya hazina kubwa kwenye GitHub ambapo tunapangisha moduli za kazi za kawaida: VPC, Autoscaling, RDS.
Ulichosikia hivi punde ni kiwango cha chini kabisa. Ikiwa huna uhakika kuhusu Terraform, ni bora kutumia muda wako mahali pengine. Kutakuwa na jargon nyingi za kiufundi hapa. Na sioni haya kutangaza kiwango cha mazungumzo haya kuwa cha juu sana. Hii inamaanisha naweza kuielezea kwa kutumia kila istilahi inayowezekana bila maelezo mengi.
Terraform ilizinduliwa mnamo 2014 kama zana iliyoruhusu wasanidi programu kuandika, kupanga, na kudhibiti miundombinu kama nambari. Wazo kuu hapa ni "miundombinu kama kanuni."
Nyaraka zote, kama nilivyosema, zimeandikwa ndani Natumai watu wengi wanajua kuhusu tovuti hii na wamesoma hati. Ikiwa ndivyo, umefika mahali pazuri.
Hivi ndivyo faili ya kawaida ya usanidi wa Terraform inavyoonekana, ambapo tunafafanua kwanza vigeu kadhaa.
Katika kesi hii tunafafanua "aws_region".
Kisha tunaelezea ni rasilimali gani tunataka kuunda.
Tunaendesha baadhi ya amri, hasa "terraform init" ili kupakia vitegemezi na watoa huduma.
Tunaendesha amri ya "terraform apply" ili kuangalia kama usanidi uliobainishwa unalingana na rasilimali tulizounda. Kwa kuwa bado hatujaunda chochote, Terraform inatuhimiza kuunda nyenzo hizi.
Tunathibitisha hili. Kwa hivyo, tunaunda ndoo inayoitwa seasnail.
Pia kuna huduma kadhaa zinazofanana. Wengi wenu mnaotumia Amazon mnajua AWS CloudFormation, Google Cloud Deployment Manager, au Azure Resource Manager. Kila moja ina utekelezaji wake wa kudhibiti rasilimali ndani ya kila mmoja wa watoa huduma hawa wa wingu wa umma. Terraform ni muhimu sana kwa sababu hukuruhusu kudhibiti zaidi ya watoa huduma 100. (Jifunze zaidi) )
Malengo ambayo Terraform imekuwa nayo tangu mwanzo ni:
- Terraform hutoa mtazamo wa umoja wa rasilimali.
- Huruhusu usaidizi kwa majukwaa yote ya kisasa.
- Na Terraform ilibuniwa tangu mwanzo kama matumizi ambayo inaruhusu miundombinu kubadilishwa kwa usalama na kutabirika.
Mnamo 2014, neno "inayotabirika" lilisikika kuwa la kawaida sana katika muktadha huu.
Terraform ni matumizi ya ulimwengu wote. Ikiwa una API, unaweza kudhibiti kila kitu kabisa:
- Unaweza kutumia zaidi ya watoa huduma 120 kudhibiti kila kitu ambacho moyo wako unatamani.
- Kwa mfano, unaweza kutumia Terraform kuelezea ufikiaji wa hazina za GitHub.
- Unaweza kuunda na kufunga hitilafu huko Jira.
- Unaweza kudhibiti vipimo vya Relic Mpya.
- Unaweza kuunda faili kwenye Dropbox ikiwa unataka kweli.
Haya yote yanafikiwa kwa kutumia watoa huduma wa Terraform, ambao wana API iliyo wazi ambayo inaweza kuelezewa katika Go.
Wacha tuseme tulianza kutumia Terraform, tukasoma hati fulani kwenye wavuti, tukatazama video, na tukaanza kuandika main.tf, kama nilivyoonyesha kwenye slaidi zilizopita.
Na kila kitu ni nzuri kwako, una faili inayounda VPC.
Ikiwa unataka kuunda VPC, unabainisha takriban mistari hii 12. Unaelezea eneo ambalo ungependa kuunda na cidr_block ya anwani za IP za kutumia. Ni hayo tu.
Kwa kawaida, mradi huo utakua hatua kwa hatua.
Na utakuwa unaongeza rundo la vitu vipya: rasilimali, vyanzo vya data, kuunganishwa na watoa huduma wapya, na ghafla utataka kutumia Terraform kudhibiti watumiaji katika akaunti yako ya GitHub, n.k. Unaweza kutaka kutumia watoa huduma tofauti wa DNS, kuchanganya na kulinganisha kila kitu. Terraform hurahisisha hii.
Hebu tuchunguze mfano ufuatao.
Unaongeza hatua kwa hatua internet_gateway kwa sababu unataka rasilimali katika VPC yako ziwe na ufikiaji wa mtandao. Hili ni wazo zuri.
Matokeo yake ni main.tf kama hii:
Hii ni sehemu ya juu ya main.tf.
Hii ndio sehemu ya chini ya main.tf.
Kisha unaongeza subnet. Kufikia wakati unapotaka kuongeza lango la NAT, njia, jedwali za uelekezaji, na rundo la nyati nyingine ndogo, hutakuwa na mistari 38, lakini kama mistari 200-300.
Kwa hivyo, faili yako ya main.tf inakua polepole. Na mara nyingi, watu huweka kila kitu kwenye faili moja. 10-20 KB inaonekana katika main.tf. Fikiria kuwa 10-20 KB ni maudhui ya maandishi. Na kila kitu kimeunganishwa na kila kitu kingine. Hatua kwa hatua inakuwa ngumu kufanya kazi nayo. 10-20 KB ni kesi nzuri ya mtumiaji, na wakati mwingine zaidi. Na watu huwa hawafikirii kuwa ni mbaya kila wakati.
Kama ilivyo katika upangaji wa kitamaduni—yaani, sio miundombinu kama msimbo—tumezoea kutumia kundi la madarasa tofauti, vifurushi, moduli na vikundi. Terraform inaturuhusu kufanya takribani kitu kimoja.
- Kanuni inakua.
- Utegemezi kati ya rasilimali pia unakua.
Na kisha tuna hitaji kubwa. Tunatambua kuwa hatuwezi kuendelea kuishi hivi. Nambari yetu inazidi kuwa kubwa. 10-20 KB sio kubwa kabisa, lakini hiyo ni safu ya mtandao tu, kumaanisha kuwa umeongeza rasilimali za mtandao pekee. Hata hatuzungumzii kuhusu Kisawazisha cha Upakiaji wa Programu, nguzo ya ES ya kusambaza, Kubernetes, na kadhalika, ambapo unaweza kubana kwa urahisi katika KB100 nyingine. Ikiwa ungeandika haya yote, ungegundua hivi karibuni kwamba Terraform hutoa moduli za Terraform.
Moduli za Terraform ni usanidi unaojitosheleza wa Terraform ambao unadhibitiwa kama kikundi. Hiyo ndiyo yote unayohitaji kujua kuhusu moduli za Terraform. Hawana akili; hazikuruhusu kufanya miunganisho tata kulingana na chochote. Hiyo yote ni kwa watengenezaji. Kwa maneno mengine, ni usanidi wa Terraform ambao tayari umeandika. Na unaweza kuwaita tu kama kikundi.
Kwa hivyo tunajaribu kufahamu jinsi ya kuboresha 10, 20, au 30 KB zetu za msimbo. Tunatambua hatua kwa hatua kwamba tunahitaji kutumia baadhi ya moduli.
Aina ya kwanza ya moduli tunazokutana nazo ni moduli za rasilimali. Hawaelewi miundombinu yako ni nini, biashara yako ni nini, iko wapi, na hali gani. Hizi ndizo moduli ambazo mimi, pamoja na jumuiya ya programu huria, tunasimamia na tunazozikuza kama vizuizi vya msingi vya ujenzi wa miundombinu yako.
Mfano wa moduli ya rasilimali.
Tunapoita moduli ya rasilimali, tunataja kutoka kwa njia ambayo tunapaswa kupakia yaliyomo.
Tunaonyesha ni toleo gani tunataka kupakua.
Tunapitisha rundo la hoja hapo. Na ndivyo hivyo. Hayo tu ndiyo tunayohitaji kujua tunapotumia moduli hii.
Watu wengi wanafikiri kwamba ikiwa wanatumia toleo la hivi karibuni, kila kitu kitakuwa imara. Lakini sivyo ilivyo. Miundombinu lazima ibadilishwe; lazima tuonyeshe kwa uwazi ni toleo gani la kila sehemu lilitumika.
Hapa kuna msimbo ndani ya moduli hii. Moduli ya kikundi cha usalama. Tembeza chini hadi mstari wa 640. Kuunda rasilimali ya kikundi cha usalama huko Amazon na usanidi wote unaowezekana ni kazi isiyo ya kawaida sana. Haitoshi tu kuunda kikundi cha usalama na kukiambia ni sheria gani za kupitisha kwake. Hiyo itakuwa rahisi sana. Amazon ina vikwazo milioni tofauti. Kwa mfano, ikiwa unatumia Mwisho wa VPC, orodha ya kiambishi awali, API mbalimbali na inajaribu kuchanganya haya yote na kila kitu kingine, lakini Terraform haikuruhusu kufanya hivyo. Na API ya Amazon hairuhusu pia. Kwa hivyo lazima ufiche mantiki hii yote ya kutisha kwenye moduli na upe nambari ya mtumiaji inayoonekana kama hii.
Mtumiaji hahitaji kujua jinsi inavyotengenezwa ndani.
Aina ya pili ya moduli, inayojumuisha moduli za rasilimali, hutatua matatizo yanayotumika zaidi kwa biashara yako. Mara nyingi hiki ni kiendelezi cha Terraform ambacho hufafanua maadili madhubuti ya vitambulisho na viwango vya kampuni. Inaweza pia kutumika kuongeza utendaji ambao Terraform haitumii kwa sasa. Hii ni kweli hasa kwa sasa. Kwa sasa tuko katika toleo la 0.11, ambalo linakaribia kustaafu. Hata hivyo, vichakataji awali, jsonnet, vidakuzi, na wingi wa vipengele vingine bado ni mbinu zinazosaidia ambazo zinafaa kutumika kwa utendakazi kamili.
Ifuatayo nitaonyesha mifano kadhaa ya hii.
Moduli ya miundombinu inaitwa kwa njia sawa.
Hubainisha chanzo cha kupakua maudhui.
Kuna rundo la maadili ambayo hupitishwa kwenye moduli hii.
Kisha, ndani ya moduli hii, rundo la moduli za rasilimali huitwa kuunda VPC au Usawazishaji wa Upakiaji wa Programu, au kuunda kikundi cha usalama au nguzo ya Huduma ya Kontena Elastiki.
Kuna aina mbili za moduli. Hili ni muhimu kuelewa kwa sababu habari nyingi ambazo nimekusanya pamoja katika mazungumzo haya hazijaandikwa.
Nyaraka za Terraform kwa sasa zina matatizo sana kwa sababu inasema tu kwamba vipengele hivi vipo na kwamba unaweza kuvitumia. Lakini haielezi jinsi ya kuzitumia au kwa nini zinatumiwa vizuri zaidi. Kwa hiyo, watu wengi huishia kuandika mambo ambayo hayatekelezeki.
Wacha tuangalie zaidi jinsi ya kuandika moduli hizi. Kisha tutaangalia jinsi ya kuwaita na jinsi ya kufanya kazi na msimbo.
Usajili wa Terraform -
Kidokezo #0 ni kuzuia kuandika moduli za rasilimali. Nyingi za moduli hizi tayari zimeandikiwa kwa ajili yako. Kama nilivyosema, hizi ni chanzo huria, hazina mantiki yoyote ya biashara yako, na hazina thamani za misimbo ngumu za anwani za IP, manenosiri, n.k. Sehemu hii ni rahisi kubadilika. Na kuna uwezekano mkubwa kuwa tayari imeandikwa. Kuna moduli nyingi za rasilimali za Amazon-karibu 650. Na wengi wao ni wa ubora mzuri.
Katika mfano huu, mtu anakuja kwako na kusema, "Nataka kuwa na uwezo wa kusimamia hifadhidata. Unda moduli ili niweze kuunda hifadhidata." Mtu huyu hajui maelezo ya utekelezaji wa Amazon au Terraform. Wanasema tu, "Nataka kusimamia MSSQL." Kwa hivyo, tunadhania wataita moduli yetu, kupita katika aina ya injini, na kutaja eneo la saa.
Na mtu huyo hapaswi kujua kuwa tutakuwa tunaunda rasilimali mbili tofauti ndani ya moduli hii: moja kwa MSSQL, ya pili kwa kila kitu kingine, kwa sababu tu katika Terraform 0.11 huwezi kutaja maadili ya eneo la saa kama hiari.
Na wakati wa kutoka kwa moduli hii, mtumiaji ataweza kupata anwani kwa urahisi. Hawatajua ni hifadhidata gani au rasilimali gani tunaunda haya yote ndani. Hiki ni kipengele muhimu sana cha faragha. Na hii inatumika sio tu kwa moduli ambazo zinapatikana kwa umma katika chanzo huria, lakini pia kwa moduli hizo unazoandika ndani ya miradi na timu zako.
Hii ni hoja ya pili, ambayo ni muhimu sana ikiwa umekuwa ukitumia Terraform kwa muda. Una hazina ambapo unahifadhi moduli zote za kampuni yako ya Terraform. Na ni kawaida kabisa kwa mradi huu kukua hadi ukubwa wa megabaiti moja au mbili kwa wakati. Hiyo ni kawaida.
Lakini shida iko katika jinsi Terraform inaita moduli hizi. Kwa mfano, ukiita moduli ili kuunda kila mtumiaji binafsi, Terraform itapakua kwanza hazina nzima na kisha kuelekea kwenye folda iliyo na moduli hiyo maalum. Hii inamaanisha kuwa utapakua megabaiti moja kila wakati. Ikiwa unadhibiti watumiaji 100 au 200, utapakua megabaiti 100 au 200 na kisha uende kwenye folda hiyo. Kwa hivyo, kwa kawaida, hutaki kupakua rundo la vitu kila wakati unapogonga "Terraform init."
Kuna masuluhisho mawili ya tatizo hili. Ya kwanza ni kutumia njia za jamaa. Kwa njia hii, unabainisha katika msimbo wako kwamba folda ni ya ndani (./). Na kabla ya kuendesha kitu chochote, unatengeneza nakala ya Git ya hazina hii ndani ya nchi. Kwa njia hii, lazima uifanye mara moja tu.
Kuna, bila shaka, mengi ya downsides. Kwa mfano, huwezi kutumia toleo. Na hiyo inaweza kuwa ngumu kuishi nayo wakati mwingine.
Suluhisho la pili. Ikiwa una submodule nyingi na bomba iliyoanzishwa, kuna mradi wa MBT, ambao hukuruhusu kuunda vifurushi vingi kutoka kwa monorepo na kuzipakia kwa S3. Hii ni mbinu nzuri sana. Kwa njia hii, faili ya iam-user-1.0.0.zip itakuwa na uzito wa KB 1 tu kwa sababu msimbo unaohitajika kuunda rasilimali hii ni ndogo sana. Hii pia itafanya mambo kuwa haraka zaidi.
Wacha tuzungumze juu ya kile ambacho hakiwezi kutumika katika moduli.
Kwa nini uovu huu katika moduli? Jambo la kutisha zaidi ni mtumiaji wa kudhani. Mtumiaji wa kudhania ni chaguo la uthibitishaji wa mtoa huduma ambalo linaweza kutumiwa na watu tofauti. Kwa mfano, sote tutachukua jukumu. Hii inamaanisha Terraform itachukua jukumu hili. Na kisha itafanya vitendo vingine vyote na jukumu hili.
Tatizo ni kwamba ikiwa Vasya anapenda kuunganisha kwa Amazon kwa njia moja, kwa mfano, kwa kutumia kutofautiana kwa mazingira ya kawaida, wakati Petya anapenda kutumia ufunguo wake wa pamoja, ambao huweka mahali pa siri, basi Terraform haiwezi kutaja zote mbili. Na ili kuwaepusha kuteseka, usibainishe kizuizi hiki kwenye moduli. Inahitaji kubainishwa kwa kiwango cha juu. Kwa hivyo, tunayo moduli ya rasilimali, moduli ya miundombinu, na muundo juu. Na hii inahitaji kuainishwa mahali fulani juu.
Uovu wa pili ni mtoaji. Hii sio ndogo sana, kwa sababu ukiandika nambari na ikakufanyia kazi, unaweza kufikiria, "Ikiwa inafanya kazi, kwa nini uibadilishe?"
Tatizo ni kwamba, kwanza, hudhibiti kila wakati mtoa huduma huyu atakapozinduliwa. Na, pili, hudhibiti maana ya aws ec2, yaani, tunazungumzia Linux au kuhusu WindowsKwa hivyo huwezi kuandika kitu ambacho kitafanya kazi sawa kwenye mifumo endeshi tofauti au kwa visa tofauti vya watumiaji.
Mfano wa kawaida, ambao pia umeonyeshwa katika hati rasmi, ni kwamba ikiwa utaandika aws_instance na kubainisha kundi la hoja, basi hakuna ubaya na hilo ikiwa pia utabainisha mtoaji wa "local-exec" hapo na kuendesha kitabu chako cha kucheza.
Kweli, ndiyo, hakuna kitu kibaya na hilo. Lakini hivi karibuni utagundua kuwa jambo hili la mtendaji wa ndani halipo, tuseme, launch_configuration.
Na unapotumia launch_configuration na unataka kuunda kikundi cha kuongeza kasi kiotomatiki kutoka kwa mfano mmoja, launch_configuration haina dhana ya "mtoa huduma." Ina dhana ya "data ya mtumiaji."
Kwa hivyo, suluhisho la ulimwengu wote ni kutumia data ya mtumiaji. Hii itaendeshwa kwa mfano yenyewe inapoanzishwa, au katika data sawa ya mtumiaji wakati kikundi cha kuongeza kasi kiotomatiki kinatumia launch_configuration.
Ikiwa bado unataka kuendesha mtoaji, kwa sababu ni sehemu ya gundi, unahitaji kuendesha mtoaji wako mwenyewe, amri yako mwenyewe, mara rasilimali moja inapoundwa. Kuna hali nyingi kama hizo.
Na rasilimali inayofaa zaidi kwa hii inaitwa null_resource. Null_resource ni rasilimali dummy ambayo haijaundwa kamwe. Haigusi chochote, hakuna API, hakuna kuongeza otomatiki. Lakini hukuruhusu kudhibiti wakati amri inaendeshwa. Katika kesi hii, amri inaendeshwa wakati wa uumbaji.
Kiungo
Kuna ishara kadhaa. Sitaingia kwa undani juu yao yote. Kuna makala kuhusu hilo. Lakini ikiwa umefanya kazi na Terraform au kutumia moduli za watu wengine, mara nyingi umegundua kuwa moduli nyingi, kama vile msimbo wa chanzo huria, huandikwa na watu kwa mahitaji yao wenyewe. Mtu aliiandika, akasuluhisha shida yao, akaitupa kwenye GitHub, na kuiacha iishi. Itaishi, lakini ikiwa hakuna hati au mifano, hakuna mtu atakayeitumia. Na ikiwa haina utendakazi unaokuruhusu kutatua kidogo zaidi ya shida yako maalum, hakuna mtu atakayeitumia pia. Kuna njia nyingi za kupoteza watumiaji.
Ikiwa unataka kuandika kitu ambacho watu watatumia, napendekeza kufuata ishara hizi.
Hizi ni:
- Nyaraka na mifano.
- Utendaji kamili.
- Thamani chaguomsingi zinazokubalika.
- Nambari safi.
- Vipimo.
Majaribio ni jambo tofauti kwa sababu ni vigumu sana kuandika. Ninategemea zaidi nyaraka na mifano.
Kwa hivyo, tumeangalia jinsi ya kuandika moduli. Kuna hoja mbili. La kwanza, na la muhimu zaidi, ni usiyaandike ikiwa unaweza kusaidia, kwani watu wengi tayari wameshafanya kazi hizi kabla yako. Na ya pili, ikiwa utaamua kuifanya, jaribu kuzuia kutumia watoa huduma katika moduli na watoa huduma.
Hii ni eneo la kijivu la nyaraka. Huenda unafikiri, "Kuna jambo lisiloeleweka. Sijashawishika." Lakini tutaona baada ya miezi sita.
Sasa hebu tuzungumze juu ya jinsi ya kupiga moduli hizi.
Tunatambua kwamba baada ya muda, kanuni zetu zinaongezeka. Hatuna tena faili moja; tuna faili 20. Zote ziko kwenye folda moja. Au labda katika folda tano. Labda tunaanza kuzigawanya kwa kanda, kwa sehemu. Kisha tunagundua kuwa tunaanza kuona mwanzo wa ulandanishi na uimbaji. Hiyo ni, tunahitaji kuelewa nini cha kufanya ikiwa tutabadilisha rasilimali za mtandao, nini cha kufanya na rasilimali zetu nyingine, jinsi ya kuomba utegemezi huu, na kadhalika.
Kuna uliokithiri mbili. Uliokithiri wa kwanza ni kila kitu katika moja. Tunayo faili moja kuu. Kwa muda, hii ilikuwa mazoezi bora rasmi kwenye tovuti ya Terraform.
Lakini sasa hii imeacha kutumika na kuondolewa. Baada ya muda, jumuiya ya Terraform iligundua kuwa hii ni mbali na utendaji bora, kwa sababu watu wanaanza kutumia mradi kwa njia tofauti. Na kuna matatizo. Kwa mfano, tunapobainisha vitegemezi vyote katika sehemu moja, kuna hali tunapobofya "Mpango wa Terraform," na inaweza kuchukua muda mrefu kwa Terraform kusasisha majimbo ya rasilimali zote.
Muda mwingi ni, kwa mfano, dakika 5. Kwa wengine, hiyo ni wakati mwingi. Nimeona kesi ambapo ilichukua dakika 15. API ya AWS ilitumia dakika 15 kutafuta kujua hali ya kila rasilimali. Hilo ni eneo kubwa sana.
Na, kwa kawaida, tatizo linalohusiana litatokea wakati unataka kubadilisha kitu katika sehemu moja, kisha kusubiri dakika 15, na inakuonyesha orodha ya mabadiliko fulani. Uliruka bunduki, ukaandika "Ndiyo," na hitilafu fulani. Huu ni mfano halisi kabisa. Terraform haijaribu kukukinga na matatizo. Kwa hivyo, andika chochote unachotaka. Ikiwa kuna shida, hiyo ni shida yako. Terraform 0.11 haijaribu kukusaidia kwa njia yoyote bado. Kuna baadhi ya maeneo ya kuvutia katika 0.12 ambayo inakuwezesha kusema, "Vasya, unataka hii kweli? Je, unaweza kufikiria upya?"
Njia ya pili ni kupunguza eneo hili, i.e. kuunganisha simu kutoka sehemu moja hadi nyingine chini.
Shida pekee ni kwamba lazima uandike nambari zaidi, ikimaanisha lazima utangaze vijiti kwenye faili nyingi na uendelee kusasisha. Watu wengine hawapendi hivyo. Kwangu mimi ni sawa. Lakini baadhi ya watu hufikiri, "Kwa nini uandike hii katika sehemu mbalimbali? Nitaiweka tu katika sehemu moja." Hilo linawezekana, lakini huo ni ule mwingine uliokithiri.
Nani ana haya yote katika sehemu moja? Mtu mmoja, wawili, watatu, yaani, mtu anaitumia.
Na ni nani anayeita sehemu moja maalum, block moja, au moduli moja ya miundombinu? Watu watano hadi saba. Hiyo ni nzuri.
Jibu la kawaida ni mahali fulani katikati. Ikiwa mradi ni mkubwa, mara nyingi utajikuta katika hali ambapo hakuna ufumbuzi unaofaa na kila kitu haifanyi kazi, kwa hiyo unaishia na mchanganyiko. Hakuna ubaya na hilo, mradi tu unaelewa kuwa zote mbili zina faida.
Iwapo kitu kitabadilika katika rundo la VPC na ungependa kutumia mabadiliko hayo kwa EC2—yaani, unataka kusasisha kikundi cha kuongeza kasi kiotomatiki kwa sababu una subnet mpya—naita aina hii ya okestra ya utegemezi. Kuna suluhisho: ni nani anayeitumia?
Ninaweza kupendekeza suluhisho kadhaa. Unaweza kutumia Terraform kufanya uchawi, au unaweza kutumia makefiles kutumia Terraform. Na unaweza kuiendesha hapa ili kuona ikiwa kuna kitu kimebadilika.
Unapendaje uamuzi huu? Kuna mtu yeyote anaamini kuwa hii ni suluhisho nzuri? Ninaona tabasamu, inaonekana mashaka yameingia.
Bila shaka, usijaribu hii nyumbani. Terraform haikuundwa kamwe kuendeshwa kutoka Terraform.
Katika mazungumzo moja, mtu aliniambia, "Hapana, hiyo haitafanya kazi." Jambo ni kwamba, haipaswi kufanya kazi. Hata ingawa inaonekana ya kuvutia sana wakati unaweza kuendesha Terraform kutoka Terraform, na kisha Terraform nyingine, haifai kuifanya kwa njia hiyo. Terraform inapaswa kuwa rahisi sana kukimbia kila wakati.
Ikiwa unahitaji kupanga simu wakati kitu kinabadilika mahali pamoja, basi kuna Terragrunt.
Terragrunt ni matumizi, nyongeza ya Terraform, ambayo hukuruhusu kuratibu na kupanga simu kwa moduli za miundombinu.
Faili ya kawaida ya usanidi wa Terraform inaonekana kama hii.
Unabainisha ni moduli gani maalum unayotaka kupiga simu.
Je, moduli ina utegemezi gani?
Na moduli hii inakubali hoja gani? Hiyo ndiyo yote unayohitaji kujua kuhusu Terragrunt.
Kuna hati hapo, na ina nyota 1,700 kwenye GitHub. Lakini katika hali nyingi, hii ndiyo yote unayohitaji kujua. Na ni rahisi sana kutekeleza kwa kampuni zinazoanza na Terraform.
Kwa hivyo, orchestration ni Terragrunt. Kuna chaguzi nyingine.
Sasa hebu tuzungumze kuhusu jinsi ya kufanya kazi na kanuni.
Ikiwa unahitaji kuongeza vipengele vipya kwenye msimbo wako, kwa kawaida ni rahisi. Unaandika nyenzo mpya, na yote ni moja kwa moja.
Iwapo una nyenzo ambayo tayari umeunda, kwa mfano, ulijifunza kuhusu Terraform baada ya kufungua akaunti ya AWS na kutaka kutumia rasilimali ulizo nazo, basi itakuwa vyema kuongeza moduli yako ili iauni matumizi ya rasilimali zilizopo.
Na iliunga mkono uundaji wa rasilimali mpya kwa kutumia rasilimali ya kuzuia.
Kwenye pato, kila wakati tunarudisha kitambulisho cha pato kulingana na kile kilichotumiwa.
Suala la pili muhimu sana katika Terraform 0.11 ni kufanya kazi na orodha.
Ugumu ni kwamba ikiwa tunayo orodha kama hiyo ya watumiaji.
Na tunapounda watumiaji hawa kwa kutumia rasilimali ya kuzuia, kila kitu kinakwenda sawa. Tunapitia orodha nzima, na kuunda faili kwa kila mmoja. Kila kitu kiko sawa. Na kisha, kwa mfano, user3, ambayo ni katikati, inapaswa kuondolewa kutoka hapa, basi rasilimali zote zilizoundwa baada yake zitafanywa upya kwa sababu index itabadilika.
Kufanya kazi na orodha katika mazingira mazuri. Mazingira ya serikali ni nini? Ni hali ambapo thamani mpya huundwa wakati rasilimali inapoundwa. Kwa mfano, Ufunguo wa Ufikiaji wa AWS au Ufunguo wa Siri wa AWS. Kwa hivyo, kila wakati tunapounda mtumiaji, tunapokea Ufunguo mpya wa Ufikiaji au Ufunguo wa Siri. Na kila wakati tunapofuta mtumiaji, mtumiaji huyo atakuwa na ufunguo mpya. Lakini hii si Feng Shui, kwa sababu mtumiaji hatataka kuwa marafiki nasi ikiwa tutamundia mtumiaji mpya kila wakati mtu anapoondoka kwenye timu.
Suluhisho ni hili: Nambari hii imeandikwa katika Jsonnet. Jsonnet ni lugha ya Google ya kuiga.
Amri hii hukuruhusu kukubali kiolezo hiki na kwa matokeo inarudisha faili ya json ambayo imetengenezwa kulingana na kiolezo chako.
Template inaonekana kama hii.
Terraform inafanya kazi na HCL na JSON kwa usawa, kwa hivyo ikiwa una uwezo wa kutengeneza JSON, unaweza kuipitisha kwa Terraform. Faili ya .tf.json itapakiwa.
Na kisha tunafanya kazi nayo kama kawaida: terraform init, terramorm kuomba. Na tunaunda watumiaji wawili.
Sasa hatuna haja ya kuwa na wasiwasi kuhusu mtu kuondoka kwenye timu. Tutahariri faili ya JSON. Vasya Pupkin kushoto, Petya Pyatochkin alikaa. Petya Pyatochkin hatapata ufunguo mpya.
Kuunganisha Terraform na zana zingine sio kazi ya Terraform. Terraform iliundwa kama jukwaa la kuunda rasilimali, na ndivyo hivyo. Chochote kinachokuja baadaye sio wasiwasi wa Terraform. Hakuna haja ya kuifunga ndani yake. Kuna Ansible, ambayo hufanya kila kitu unachohitaji.
Lakini kuna hali wakati tunataka kupanua Terraform na kuita amri fulani baada ya kitu kukamilika.
Njia ya kwanza: Tunaunda pato ambapo tunaandika amri hii.
Kisha tunaita amri hii kutoka kwa ganda la pato la terraform na kutaja thamani tunayotaka. Hii inatekeleza amri na maadili yote yamebadilishwa. Hii ni rahisi sana.
Njia ya pili ni kutumia null_resource kulingana na mabadiliko katika miundombinu yetu. Tunaweza kuita eneo lile lile kutekelezwa wakati wowote kitambulisho cha rasilimali kinapobadilika.
Kwa kawaida, hii yote inaonekana nzuri kwenye karatasi, kwa sababu Amazon, kama watoa huduma wengine wote wa umma, ina rundo la kesi zake za makali.
Kesi ya kawaida ya makali ni kwamba unapofungua akaunti ya AWS, ni muhimu ni maeneo gani unayotumia; ikiwa kipengele hiki kimewezeshwa hapo; labda uliifungua baada ya Desemba 2013; labda unatumia VPC chaguo-msingi, nk. Kuna vikwazo vingi. Na Amazon imewatawanya katika nyaraka zote.
Kuna mambo machache ninapendekeza kuepuka.
Kwanza, epuka mabishano yote yasiyo ya siri ndani ya mpango wa Terraform au Terraform CLI. Hizi zinaweza kuhifadhiwa katika faili ya tfvars au anuwai za mazingira.
Lakini huna haja ya kukumbuka amri hii yote ya kichawi. Mpango wa Terraform - var na tunaenda mbali. Tofauti ya kwanza ni var, ya pili ni var, ya tatu, ya nne. Kanuni muhimu zaidi ya miundombinu kama msimbo, ambayo mimi hutumia mara nyingi zaidi, ni kwamba kwa kuangalia tu nambari, ninapaswa kuwa na uwezo wa kuelewa vizuri kile kilichowekwa hapo, katika hali gani, na kwa maadili gani. Kwa hivyo sihitaji kusoma hati au kumuuliza Vasya ni vigezo gani alitumia kuunda nguzo yetu. Ninafungua tu faili ya tfvars, ambayo mara nyingi inaambatana na mazingira, na angalia kila kitu hapo.
Pia, usitumie hoja lengwa ili kupunguza wigo. Ni rahisi zaidi kutumia moduli ndogo za miundombinu kwa hilo.
Pia, usiweke kikomo au kuongeza usawa. Ikiwa nina rasilimali 150 na ninataka kuongeza usawa wa Amazon kutoka chaguo-msingi 10 hadi 100, kuna uwezekano kwamba kuna kitu kitaenda vibaya. Au inaweza kufanya kazi vizuri sasa, lakini Amazon inaponiambia kuwa unapiga simu nyingi sana, utakumbana na matatizo.
Terraform itajaribu kuanzisha tena shida nyingi hizi, lakini hautafanikiwa chochote. Parallelism=1 ni kipengele muhimu cha kutumia ikiwa umekumbana na hitilafu katika API ya AWS au ndani ya mtoa huduma wa Terraform. Kisha unahitaji kutaja parallelism=1 na kusubiri Terraform kukamilisha simu moja, kisha ya pili, kisha ya tatu. Itaziendesha kwa kufuatana.
Mara nyingi mimi huulizwa, "Kwa nini nadhani nafasi za kazi za Terraform ni mbaya?" Ninaamini kanuni ya miundombinu kama kanuni ni kuona ni miundombinu gani ilijengwa na kwa maadili gani.
Nafasi za kazi hazikuundwa na watumiaji. Hii haimaanishi watumiaji waliandika maswala ya GitHub wakisema hawawezi kuishi bila Nafasi za Kazi za Terraform. Hapana, hiyo si kweli. Terraform Enterprise ni suluhisho la kibiashara. Terraform ya HashiCorp iliamua tunahitaji nafasi za kazi, kwa hivyo tutaiunda. Nadhani ni rahisi zaidi kuiweka kwenye folda tofauti. Itahitaji faili chache zaidi, lakini itakuwa wazi zaidi.
Je, unafanyaje kazi na kanuni? Kimsingi, kufanya kazi na orodha ndio maumivu pekee. Na kuchukua Terraform lightly. Sio kitu ambacho kitafanya kila kitu kikamilifu. Usiingize kila kitu kwenye hati ndani yake.
Mada ya ripoti hiyo ilisema "kwa siku zijazo." Nitaeleza hilo kwa ufupi sana. "Kwa siku zijazo" inamaanisha kuwa 0.12 itatolewa hivi karibuni.
0.12 ni tani ya vitu vipya. Iwapo unatoka kwenye mandharinyuma ya kitamaduni ya programu, utakosa vizuizi vyote vinavyobadilika, mizunguko, na ulinganisho sahihi na wa masharti ambapo pande za kushoto na kulia hazijatathminiwa kwa wakati mmoja, lakini badala yake kutegemea hali. Utakosa hayo yote sana, kwa hivyo 0.12 itakusuluhisha hilo.
Lakini! Ukiandika kwa urahisi na kwa urahisi zaidi, ukitumia moduli zilizotengenezwa tayari na suluhu za wahusika wengine, hutahitaji kusubiri na kutumaini 0.12 kuja na kukutengenezea kila kitu.
Asante kwa mazungumzo! Ulizungumza juu ya miundombinu kama nambari na ukasema neno moja kuhusu majaribio. Vipimo vinahitajika katika moduli? Ni jukumu la nani hilo? Je, niziandikie mwenyewe, au hilo ni jukumu la moduli?
Mwaka ujao utajazwa na ripoti kuhusu jinsi tumeamua kujaribu kila kitu. Nini cha kupima ni swali kubwa zaidi. Kuna tani ya utegemezi, tani ya mapungufu kutoka kwa watoa huduma tofauti. Tunapozungumza, na unasema, "Ninahitaji vipimo," ninauliza, "Utajaribu nini?" Unasema utajaribu katika eneo lako. Kisha nasema haifanyi kazi katika mkoa wangu. Kwa hiyo, hatuwezi hata kukubaliana juu ya hilo. Bila kusema, kuna shida nyingi za kiufundi. Hiyo ni, jinsi ya kuandika majaribio haya ili yawe ya kutosha.
Ninatafiti mada hii kikamilifu, yaani, jinsi ya kutengeneza majaribio kiotomatiki kulingana na miundombinu uliyoandika. Kwa hivyo, ikiwa umeandika nambari hii, basi ninahitaji kuiendesha, na kwa kuzingatia hilo, naweza kuunda vipimo.
- Hii ni moja ya maktaba zinazotajwa mara kwa mara za kuandika majaribio ya ujumuishaji ya Terraform. Ni moja ya huduma. Napendelea DSL kama rspec.
Anton, asante kwa mazungumzo! Jina langu ni Valery. Ngoja nikuulize swali la kifalsafa kidogo. Kuna utoaji, kwa kusema, na kuna kupelekwa. Utoaji hutengeneza miundombinu yangu, na katika utumaji tunaijaza na vitu muhimu, kama vile seva, programu, na kadhalika. Inaonekana kwangu kuwa Terraform ni zaidi ya utoaji, na Ansible ni zaidi ya kupelekwa, kwa sababu Ansible inakuwezesha kusakinisha NGINX na Postgres kwenye miundombinu ya kimwili. Lakini wakati huo huo, Ansible pia inaonekana kukuruhusu kutoa rasilimali, kama Amazon au Google. Terraform pia hukuruhusu kupeleka programu kwa kutumia moduli zake. Kwa maoni yako, kuna mstari wa kugawanya kati ya Terraform na Ansible, na wapi ni bora kutumia ipi? Au, kwa mfano, unafikiri Ansible ni kupoteza muda na kwamba Terraform inapaswa kutumika kwa kila kitu?
Swali zuri, Valery. Ninaamini madhumuni ya Terraform hayajabadilika tangu 2014. Iliundwa kwa ajili ya miundombinu na ilikufa kwa ajili ya miundombinu. Bado tuna na tutaendelea kuhitaji usimamizi wa usanidi wa Ansible. Changamoto ni kwamba ina data ya mtumiaji ndani launch_configuration. Na kisha unaomba Ansible, nk. Hii ndiyo tofauti ya kawaida ninayoipenda zaidi.
Ikiwa tunazungumza kuhusu miundombinu mizuri, kuna huduma kama Packer zinazounda picha hii. Terraform kisha hutumia chanzo cha data kupata picha hii na kusasisha launch_configuration yake. Kwa hivyo, bomba linajumuisha kwanza kupiga simu Tracker, kisha kupiga Terraform. Na ikiwa ujenzi hutokea, mabadiliko mapya hutokea.
Habari! Asante kwa mazungumzo! Jina langu ni Misha, kutoka RBS. Unaweza kupiga simu Ansible kupitia mtoaji wakati wa kuunda rasilimali. Ansible pia ina kipengele kinachoitwa orodha ya nguvu. Unaweza pia kupiga simu Terraform kwanza, na kisha piga Ansible, ambayo itachukua rasilimali kutoka kwa serikali na kuzitekeleza. Ambayo ni bora zaidi?
Watu hutumia zote mbili kwa mafanikio sawa. Nadhani orodha inayobadilika katika Ansible ni kipengele kinachofaa, isipokuwa tunazungumza kuhusu kikundi cha kuongeza kasi kiotomatiki. Kwa sababu katika kikundi cha kupima kiotomatiki, tayari tuna zana yetu inayoitwa launch_configuration. Katika launch_configuration, tunarekodi kila kitu kinachohitaji kuzinduliwa wakati wa kuunda rasilimali mpya. Kwa hivyo, kwa Amazon, kutumia hesabu yenye nguvu na kusoma faili ya Terraform .ts, kwa maoni yangu, sio lazima. Na ikiwa unatumia zana zingine ambazo hazina dhana ya "kikundi cha kuongeza otomatiki" - kwa mfano, unatumia DigitalOcean au mtoaji mwingine ambaye hana kikundi cha kuongeza otomatiki - basi itabidi ufikie API mwenyewe, utafute anwani za IP, utengeneze faili ya hesabu inayobadilika, na Ansible itapita. Kwa hivyo, kwa Amazon, kuna launch_configuration, na kwa kila kitu kingine, kuna hesabu ya nguvu.
Chanzo: mapenzi.com
