Alam at ginagamit ng maraming tao ang Terraform sa kanilang pang-araw-araw na gawain, ngunit hindi pa nabubuo ang pinakamahuhusay na kagawian para dito. Ang bawat koponan ay kailangang mag-imbento ng sarili nitong mga diskarte at pamamaraan.
Ang iyong imprastraktura ay halos tiyak na nagsisimula sa simple: ilang mapagkukunan + ilang developer. Sa paglipas ng panahon, lumalaki ito sa lahat ng uri ng direksyon. Nakahanap ka ba ng mga paraan upang ipangkat ang mga mapagkukunan sa mga module ng Terraform, ayusin ang code sa mga folder, at ano pa ang posibleng magkamali? (sikat na mga huling salita)
Lumipas ang oras at pakiramdam mo ang iyong imprastraktura ay ang iyong bagong alagang hayop, ngunit bakit? Nag-aalala ka tungkol sa hindi maipaliwanag na mga pagbabago sa imprastraktura, natatakot kang hawakan ang imprastraktura at code - bilang resulta, inaantala mo ang bagong pag-andar o binabawasan ang kalidad...
Pagkatapos ng tatlong taon ng pamamahala ng isang koleksyon ng mga module ng komunidad ng Terraform para sa AWS sa Github at pangmatagalang pagpapanatili ng Terraform sa produksyon, handa si Anton Babenko na ibahagi ang kanyang karanasan: kung paano magsulat ng mga module ng TF upang hindi ito masaktan sa hinaharap.
Sa pagtatapos ng talumpati, magiging mas pamilyar ang mga kalahok sa mga prinsipyo sa pamamahala ng mapagkukunan sa Terraform, pinakamahuhusay na kagawiang nauugnay sa mga module sa Terraform, at ilang tuluy-tuloy na prinsipyo ng pagsasama-sama na nauugnay sa pamamahala ng imprastraktura.
Disclaimer: Tandaan ko na ang ulat na ito ay may petsang Nobyembre 2018β2 taon na ang lumipas. Ang bersyon ng Terraform 0.11 na tinalakay sa ulat ay hindi na sinusuportahan. Sa nakalipas na 2 taon, 2 bagong release ang inilabas, na naglalaman ng maraming inobasyon, pagpapahusay at pagbabago. Mangyaring bigyang pansin ito at suriin ang dokumentasyon.
Link:
- +
- β auto-formatting code at dokumentasyon
- β generator ng Terraform modules (WIP)
- β Terraform code generator mula sa mga visual diagram (WIP)
- www.terraform-best-practices.com
- (Ang mga bagong post ay nasa aking personal na website www.antonbabenko.com/)
- @antonbabenko - Twitter, at isang grupo ng iba't ibang Slacks
Ang pangalan ko ay Anton Babenko. Malamang na ginamit ng ilan sa inyo ang code na isinulat ko. Magsasalita ako ngayon tungkol dito nang may higit na kumpiyansa kaysa dati, dahil mayroon akong access sa mga istatistika.
Nagtatrabaho ako sa Terraform at naging aktibong kalahok at kontribyutor sa malaking bilang ng mga open source na proyekto na nauugnay sa Terraform at Amazon mula noong 2015.
Simula noon nakapagsulat na ako ng sapat na code upang ilagay ito sa isang kawili-wiling paraan. At susubukan kong sabihin sa iyo ang tungkol dito ngayon.
Pag-uusapan ko ang tungkol sa mga intricacies at mga detalye ng pagtatrabaho sa Terraform. Ngunit hindi talaga iyon ang paksa ng HighLoad. At ngayon mauunawaan mo kung bakit.
Sa paglipas ng panahon, nagsimula akong magsulat ng mga module ng Terraform. Sumulat ang mga gumagamit ng mga tanong, isinulat ko muli ang mga ito. Pagkatapos ay nagsulat ako ng iba't ibang mga kagamitan upang i-format ang code gamit ang isang pre-commit hook, atbp.
Maraming mga kagiliw-giliw na proyekto. Gusto ko ang pagbuo ng code dahil gusto ko ang computer na gumawa ng mas maraming trabaho para sa akin at sa programmer, kaya kasalukuyang gumagawa ako ng Terraform code generator mula sa mga visual na diagram. Marahil ang ilan sa inyo ay nakakita na sa kanila. Ito ay mga magagandang kahon na may mga arrow. At sa tingin ko ito ay mahusay kung maaari mong i-click ang "I-export" na button at makuha ang lahat ng ito bilang code.
Ako ay mula sa Ukraine. Ako ay nanirahan sa Norway sa loob ng maraming taon.
Gayundin, ang impormasyon para sa ulat na ito ay nakolekta mula sa mga taong nakakaalam ng aking pangalan at nahahanap ako sa mga social network. Halos pareho lang ako ng nickname.
Gaya ng nabanggit ko, ako ang pangunahing tagapangasiwa ng mga module ng Terraform AWS, na isa sa pinakamalaking repositoryo sa GitHub kung saan nagho-host kami ng mga module para sa mga pinakakaraniwang gawain: VPC, Autoscaling, RDS.
At ang narinig mo ngayon ang pinakapangunahing. Kung nagdududa ka na nauunawaan mo kung ano ang Terraform, mas mabuting gugulin ang iyong oras sa ibang lugar. Magkakaroon ng maraming teknikal na termino dito. At hindi ako nagdalawang-isip na ideklara ang antas ng ulat bilang pinakamataas. Nangangahulugan ito na maaari akong makipag-usap gamit ang lahat ng posibleng mga termino nang walang gaanong paliwanag.
Ang Terraform ay lumabas noong 2014 bilang isang utility na nagbigay-daan sa iyong magsulat, magplano at pamahalaan ang imprastraktura bilang code. Ang pangunahing konsepto dito ay "imprastraktura bilang code."
Lahat ng dokumentasyon, gaya ng sinabi ko, ay nakasulat . Sana alam ng karamihan sa mga tao ang tungkol sa site na ito at nabasa na nila ang dokumentasyon. Kung gayon, nasa tamang lugar ka.
Ito ang hitsura ng isang regular na Terraform configuration file, kung saan una naming tinukoy ang ilang mga variable.
Sa kasong ito, tinukoy namin ang "aws_region".
Pagkatapos ay inilalarawan namin kung anong mga mapagkukunan ang gusto naming likhain.
Nagpapatakbo kami ng ilang mga utos, lalo na ang "terraform init" upang mai-load ang mga dependency at provider.
At pinapatakbo namin ang command na "terraform apply" upang masuri kung ang tinukoy na configuration ay tumutugma sa mga mapagkukunang ginawa namin. Dahil wala pa kaming nagagawa dati, sinenyasan kami ng Terraform na gawin ang mga mapagkukunang ito.
Kinukumpirma namin ito. Kaya gumawa kami ng isang balde na tinatawag na seasnail.
Mayroon ding ilang katulad na mga kagamitan. Marami sa inyo na gumagamit ng Amazon ang nakakaalam ng AWS CloudFormation o Google Cloud Deployment Manager o Azure Resource Manager. Ang bawat isa sa kanila ay may sariling pagpapatupad ng ilang uri para sa pamamahala ng mga mapagkukunan sa loob ng bawat isa sa mga pampublikong tagapagbigay ng ulap na ito. Lalo na kapaki-pakinabang ang Terraform dahil pinapayagan ka nitong pamahalaan ang higit sa 100 provider. (Higit pang mga detalye )
Ang mga layunin na hinabol ng Terraform mula pa sa simula:
- Nagbibigay ang Terraform ng iisang view ng mga mapagkukunan.
- Binibigyang-daan kang suportahan ang lahat ng modernong platform.
- At ang Terraform ay idinisenyo mula pa sa simula bilang isang utility na nagbibigay-daan sa iyong baguhin ang imprastraktura nang ligtas at mahuhulaan.
Noong 2014, ang salitang "mahuhulaan" ay parang hindi pangkaraniwan sa kontekstong ito.
Ang Terraform ay isang unibersal na utility. Kung mayroon kang API, maaari mong kontrolin ang lahat ng bagay:
- Maaari kang gumamit ng higit sa 120 provider para pamahalaan ang lahat ng gusto mo.
- Halimbawa, maaari mong gamitin ang Terraform upang ilarawan ang pag-access sa mga repositoryo ng GitHub.
- Maaari ka ring gumawa at magsara ng mga bug sa Jira.
- Maaari mong pamahalaan ang mga sukatan ng Bagong Relic.
- Maaari ka ring lumikha ng mga file sa dropbox kung talagang gusto mo.
Nagagawa ang lahat ng ito gamit ang mga provider ng Terraform, na may bukas na API na maaaring ilarawan sa Go.
Sabihin nating nagsimula kaming gumamit ng Terraform, nagbasa ng ilang dokumentasyon sa site, nanood ng ilang video, at nagsimulang magsulat ng main.tf, tulad ng ipinakita ko sa mga nakaraang slide.
At lahat ay mahusay, mayroon kang isang file na lumilikha ng isang VPC.
Kung gusto mong gumawa ng VPC, tutukuyin mo ang humigit-kumulang 12 linyang ito. Ilarawan kung aling rehiyon ang gusto mong gawin, kung aling cidr_block ng mga IP address ang gagamitin. Iyon lang.
Natural, unti-unting lalago ang proyekto.
At magdaragdag ka ng isang grupo ng mga bagong bagay doon: mga mapagkukunan, mga pinagmumulan ng data, isasama mo sa mga bagong provider, biglang gugustuhin mong gamitin ang Terraform upang pamahalaan ang mga user sa iyong GitHub account, atbp. Maaaring gusto mong gumamit ng ibang Mga DNS provider , i-cross ang lahat. Pinapadali ito ng Terraform.
Tingnan natin ang sumusunod na halimbawa.
Unti-unti kang nagdaragdag ng internet_gateway dahil gusto mong magkaroon ng internet access ang mga mapagkukunan mula sa iyong VPC. Ito ay isang magandang ideya.
Ang resulta ay ito main.tf:
Ito ang tuktok na bahagi ng main.tf.
Ito ang ibabang bahagi ng main.tf.
Pagkatapos ay magdagdag ka ng subnet. Sa oras na gusto mong magdagdag ng NAT gateway, ruta, routing table at isang grupo ng iba pang mga subnet, hindi ka magkakaroon ng 38 na linya, ngunit humigit-kumulang 200-300 na linya.
Ibig sabihin, unti-unting lumalaki ang iyong main.tf file. At madalas na inilalagay ng mga tao ang lahat sa isang file. Lumilitaw ang 10-20 Kb sa main.tf. Isipin na ang 10-20 Kb ay nilalaman ng teksto. At lahat ay konektado sa lahat. Ito ay unti-unting nagiging mahirap gawin. Ang 10-20 Kb ay isang magandang user case, minsan higit pa. At hindi palaging iniisip ng mga tao na ito ay masama.
Tulad ng sa regular na programming, ibig sabihin, hindi imprastraktura bilang code, nakasanayan na nating gumamit ng isang grupo ng iba't ibang klase, pakete, module, pagpapangkat. Binibigyang-daan ka ng Terraform na gawin ang parehong bagay.
- Lumalaki ang code.
- Ang mga dependency sa pagitan ng mga mapagkukunan ay lumalaki din.
At mayroon tayong malaking, malaking pangangailangan. Naiintindihan namin na hindi na kami mabubuhay ng ganito. Ang aming code ay nagiging napakalaki. Ang 10-20 Kb ay, siyempre, hindi masyadong malawak, ngunit ang pinag-uusapan lang natin ay ang network stack, ibig sabihin, nagdagdag ka lang ng mga mapagkukunan ng network. Hindi namin pinag-uusapan ang Application Load Balancer, deployment ES cluster, Kubernetes, atbp., kung saan ang 100 Kb ay madaling ma-weaved. Kung isusulat mo ang lahat ng ito, malalaman mo sa lalong madaling panahon na ang Terraform ay nagbibigay ng mga module ng Terraform.
Ang mga module ng Terraform ay isang self-contained na configuration ng Terraform na pinamamahalaan bilang isang grupo. Iyon lang ang kailangan mong malaman tungkol sa mga module ng Terraform. Hindi sila matalino sa lahat, hindi nila pinapayagan kang gumawa ng anumang kumplikadong koneksyon depende sa isang bagay. Ang lahat ng ito ay nakasalalay sa mga balikat ng mga developer. Ibig sabihin, isa lang itong uri ng configuration ng Terraform na naisulat mo na. At maaari mo lamang itong tawagan bilang isang grupo.
Kaya sinusubukan naming maunawaan kung paano namin i-optimize ang aming 10-20-30 Kb ng code. Unti-unti nating napagtatanto na kailangan nating gumamit ng ilang modules.
Ang unang uri ng mga module na nakatagpo mo ay mga resource module. Hindi nila naiintindihan kung tungkol saan ang iyong imprastraktura, tungkol saan ang negosyo mo, saan at ano ang mga kondisyon. Ito ang eksaktong mga module na pinangangasiwaan ko, kasama ang open source na komunidad, at inilagay namin bilang pinakaunang mga bloke ng gusali para sa iyong imprastraktura.
Isang halimbawa ng resource module.
Kapag tumawag kami ng resource module, tinutukoy namin kung saang landas namin dapat i-load ang mga nilalaman nito.
Ipinapahiwatig namin kung aling bersyon ang gusto naming i-download.
Nagpasa kami ng isang grupo ng mga argumento doon. Iyon lang. Iyan lang ang kailangan nating malaman kapag ginamit natin ang modyul na ito.
Iniisip ng maraming tao na kung gagamitin nila ang pinakabagong bersyon, magiging matatag ang lahat. Pero hindi. Dapat na may bersyon ang imprastraktura; dapat nating malinaw na sagutin kung saang bersyon ito o ang bahaging iyon ay na-deploy.
Narito ang code na nasa loob ng modyul na ito. Module ng pangkat ng seguridad. Dito napupunta ang scroll sa ika-640 na linya. Ang paglikha ng isang mapagkukunan ng seguridad-croup sa Amazon sa bawat posibleng pagsasaayos ay isang napaka-walang halaga na gawain. Hindi sapat na gumawa lang ng grupo ng seguridad at sabihin dito kung anong mga panuntunan ang ipapasa dito. Ito ay magiging napaka-simple. Mayroong isang milyong iba't ibang mga paghihigpit sa loob ng Amazon. Halimbawa, kung gagamitin mo VPC endpoint, listahan ng prefix, iba't ibang API at sinusubukang pagsamahin ang lahat ng ito sa lahat ng iba pa, kung gayon hindi ka pinapayagan ng Terraform na gawin ito. At hindi rin ito pinapayagan ng Amazon API. Samakatuwid, kailangan nating itago ang lahat ng kakila-kilabot na logic na ito sa isang module at ibigay ang user code na ganito ang hitsura.
Hindi kailangang malaman ng gumagamit kung paano ito ginawa sa loob.
Ang pangalawang uri ng mga module, na binubuo ng mga resource module, ay nilulutas na ang mga problema na mas naaangkop sa iyong negosyo. Kadalasan ito ay isang lugar na isang extension para sa Terraform at nagtatakda ng ilang matibay na halaga para sa mga tag, para sa mga pamantayan ng kumpanya. Maaari ka ring magdagdag ng functionality doon na kasalukuyang hindi pinapayagan ng Terraform na gamitin mo. Ito ay sa ngayon. Ngayon bersyon 0.11, na malapit nang maging isang bagay ng nakaraan. Ngunit gayon pa man, ang mga preprocessor, jsonnet, cookiecutter at marami pang iba ay ang pantulong na mekanismo na dapat gamitin para sa ganap na trabaho.
Susunod na ipapakita ko ang ilang mga halimbawa nito.
Ang module ng imprastraktura ay tinatawag sa eksaktong parehong paraan.
Ang pinagmulan kung saan ida-download ang nilalaman ay ipinahiwatig.
Ang isang grupo ng mga halaga ay ipinapasa at ipinapasa sa modyul na ito.
Susunod, sa loob ng module na ito, isang grupo ng mga resource module ang tinatawag para gumawa ng VPC o Application Load Balancer, o para gumawa ng security-group o para sa isang Elastic Container Service cluster.
Mayroong dalawang uri ng mga module. Mahalagang maunawaan ito dahil karamihan sa impormasyong aking pinagsama-sama sa ulat na ito ay hindi nakasulat sa dokumentasyon.
At ang dokumentasyon sa Terraform ngayon ay medyo may problema dahil sinasabi lang nito na mayroong mga tampok na ito, maaari mong gamitin ang mga ito. Ngunit hindi niya sinasabi kung paano gamitin ang mga tampok na ito, kung bakit mas mahusay na gamitin ang mga ito. Samakatuwid, napakaraming tao ang nagsusulat ng isang bagay na hindi nila kayang pakisamahan.
Tingnan natin kung paano isulat ang mga modyul na ito sa susunod. Pagkatapos ay makikita natin kung paano tatawagan ang mga ito at kung paano gamitin ang code.
Terraform Registry -
Tip #0 ay huwag magsulat ng mga resource module. Karamihan sa mga modyul na ito ay naisulat na para sa iyo. Gaya ng sinabi ko, open source sila, wala silang anumang logic sa negosyo mo, wala silang hardcoded values ββpara sa mga IP address, password, atbp. Napaka-flexible ng module. At ito ay malamang na naisulat na. Mayroong maraming mga module para sa mga mapagkukunan mula sa Amazon. Mga 650. At karamihan sa kanila ay may magandang kalidad.
Sa halimbawang ito, may lumapit sa iyo at nagsabing, βGusto kong makapag-manage ng database. Gumawa ng module para makagawa ako ng database." Hindi alam ng tao ang mga detalye ng pagpapatupad ng alinman sa Amazon o Terraform. Sabi lang niya: "Gusto kong pamahalaan ang MSSQL." Iyon ay, ang ibig naming sabihin ay tatawagin nito ang aming module, ipapasa ang uri ng engine doon, at ipahiwatig ang time zone.
At hindi dapat malaman ng isang tao na gagawa tayo ng dalawang magkaibang mapagkukunan sa loob ng modyul na ito: isa para sa MSSQL, ang pangalawa para sa lahat ng iba pa, dahil lamang sa Terraform 0.11 hindi mo maaaring tukuyin ang mga halaga ng time zone bilang opsyonal.
At sa paglabas mula sa modyul na ito, ang isang tao ay makakatanggap lamang ng isang address. Hindi niya malalaman mula sa kung aling database, mula sa kung aling mapagkukunan namin nililikha ang lahat ng ito sa loob. Ito ay isang napakahalagang elemento ng pagtatago. At nalalapat ito hindi lamang sa mga module na iyon na pampubliko sa open source, kundi pati na rin sa mga module na isusulat mo sa loob ng iyong mga proyekto at mga koponan.
Ito ang pangalawang argumento, na medyo mahalaga kung matagal ka nang gumagamit ng Terraform. Mayroon kang repositoryo kung saan inilalagay mo ang lahat ng iyong Terraform module para sa iyong kumpanya. At medyo normal na sa paglipas ng panahon ang proyektong ito ay lalago sa laki ng isa o dalawang megabytes. Ito ay mabuti.
Ngunit ang problema ay kung paano tinawag ng Terraform ang mga module na ito. Halimbawa, kung tatawag ka ng module para likhain ang bawat indibidwal na user, ilo-load muna ng Terraform ang buong repository at pagkatapos ay mag-navigate sa folder kung saan matatagpuan ang partikular na module na iyon. Sa ganitong paraan magda-download ka ng isang megabyte sa bawat oras. Kung namamahala ka ng 100 o 200 user, magda-download ka ng 100 o 200 megabytes, at pagkatapos ay pumunta sa folder na iyon. Kaya natural na hindi mo nais na mag-download ng isang bungkos ng mga bagay-bagay sa tuwing pinindot mo ang "Terraform init".
Mayroong dalawang solusyon sa problemang ito. Ang una ay ang paggamit ng mga kamag-anak na landas. Sa ganitong paraan, ipinapahiwatig mo sa code na ang folder ay lokal (./). At bago ka maglunsad ng anuman, gagawa ka ng Git clone ng repositoryong ito nang lokal. Sa ganitong paraan gagawin mo ito nang isang beses.
Mayroong, siyempre, maraming mga downsides. Halimbawa, hindi ka maaaring gumamit ng bersyon. At ito ay minsan mahirap pakisamahan.
Pangalawang solusyon. Kung mayroon kang maraming mga submodules at mayroon ka nang ilang uri ng naitatag na pipeline, pagkatapos ay mayroong proyekto ng MBT, na nagpapahintulot sa iyo na mangolekta ng maraming iba't ibang mga pakete mula sa isang monorepository at i-upload ang mga ito sa S3. Ito ay isang napakahusay na paraan. Kaya, ang iam-user-1.0.0.zip na file ay tumitimbang lamang ng 1 Kb, dahil napakaliit ng code upang lumikha ng mapagkukunang ito. At ito ay gagana nang mas mabilis.
Pag-usapan natin kung ano ang hindi magagamit sa mga module.
Bakit ito kasamaan sa mga module? Ang pinakamasamang bagay ay ang mag-assume ng user. Ipagpalagay na ang user ay isang opsyon sa pagpapatunay ng provider na maaaring gamitin ng iba't ibang tao. Halimbawa, lahat tayo ay mag-assimilate sa papel. Nangangahulugan ito na gagawin ng Terraform ang tungkuling ito. At pagkatapos ay sa papel na ito magsasagawa ito ng iba pang mga aksyon.
At ang kasamaan ay kung gusto ni Vasya na kumonekta sa Amazon sa isang paraan, halimbawa, gamit ang default na variable ng kapaligiran, at gusto ni Petya na gamitin ang kanyang nakabahaging key, na mayroon siya sa isang lihim na lugar, kung gayon hindi mo matukoy ang pareho sa Terraform. At upang hindi sila makaranas ng pagdurusa, hindi na kailangang ipahiwatig ang bloke na ito sa modyul. Dapat itong ipahiwatig sa mas mataas na antas. Ibig sabihin, mayroon kaming isang resource module, isang infrastructure module at isang komposisyon sa itaas. At dapat itong ipahiwatig sa isang lugar na mas mataas.
Ang pangalawang kasamaan ay ang tagapagbigay. Narito ang kasamaan ay hindi gaanong mahalaga, dahil kung sumulat ka ng code at ito ay gumagana para sa iyo, maaari mong isipin na kung ito ay gumagana, kung gayon bakit ito baguhin.
Ang masama ay hindi mo laging kontrolin kung kailan ilulunsad ang provisioner na ito, una. At pangalawa, hindi mo kontrolado kung ano ang ibig sabihin ng aws ec2, ibig sabihin, Linux o Windows ba ang pinag-uusapan natin ngayon. Kaya hindi ka maaaring magsulat ng isang bagay na gagana nang pareho sa iba't ibang mga operating system o para sa iba't ibang mga kaso ng user.
Ang pinakakaraniwang halimbawa, na ipinahiwatig din sa opisyal na dokumentasyon, ay kung sumulat ka ng aws_instance at tumukoy ng isang grupo ng mga argumento, walang mali doon kung tinukoy mo ang provisioner na "local-exec" doon at patakbuhin ang iyong ansible- playbook .
Sa katunayan, oo, walang mali doon. Ngunit literal sa lalong madaling panahon ay mapagtanto mo na ang lokal na-exec na bagay na ito ay hindi umiiral, halimbawa, sa launch_configuration.
At kapag gumamit ka ng launch_configuration, at gusto mong lumikha ng autoscaling group mula sa isang pagkakataon, pagkatapos ay sa launch_configuration walang konsepto ng "provisioner". Mayroong konsepto ng "data ng gumagamit".
Samakatuwid, ang isang mas unibersal na solusyon ay ang paggamit ng data ng user. At ilulunsad ito sa mismong instance, kapag naka-on ang instance, o sa parehong data ng user, kapag ginamit ng autoscaling group ang launch_configuration na ito.
Kung gusto mo pa ring patakbuhin ang provisioner, dahil ito ay isang gluing component, kapag ang isang mapagkukunan ay nilikha, sa sandaling iyon kailangan mong patakbuhin ang iyong provisioner, ang iyong command. Mayroong maraming mga ganoong sitwasyon.
At ang pinakatamang mapagkukunan para dito ay tinatawag na null_resource. Ang Null_resource ay isang dummy na mapagkukunan na hindi kailanman aktwal na nilikha. Hindi ito humahawak ng anuman, walang API, walang autoscaling. Ngunit pinapayagan ka nitong kontrolin kung kailan patakbuhin ang utos. Sa kasong ito, ang utos ay pinapatakbo sa panahon ng paglikha.
Link
Mayroong ilang mga palatandaan. Hindi ko tatalakayin ang lahat ng mga palatandaan nang detalyado. May isang artikulo tungkol dito. Ngunit kung nagtrabaho ka sa Terraform o gumamit ng mga module ng ibang tao, madalas mong napansin na maraming mga module, tulad ng karamihan sa mga code sa open source, ay isinulat ng mga tao para sa kanilang sariling mga pangangailangan. Isinulat ito ng isang lalaki at nalutas ang kanyang problema. Inilagay ko ito sa GitHub, hayaan itong mabuhay. Mabubuhay ito, ngunit kung walang dokumentasyon at mga halimbawa doon, kung gayon walang gagamit nito. At kung walang pag-andar na nagbibigay-daan sa iyo upang malutas nang kaunti pa kaysa sa tiyak na gawain nito, kung gayon walang sinuman ang gagamit nito. Napakaraming paraan para mawala ang mga user.
Kung nais mong magsulat ng isang bagay upang magamit ito ng mga tao, pagkatapos ay inirerekomenda kong sundin ang mga palatandaang ito.
Ang mga ito ay:
- Dokumentasyon at mga halimbawa.
- Buong pag-andar.
- Mga makatwirang default.
- Malinis na code.
- Mga Pagsubok.
Ang mga pagsubok ay ibang sitwasyon dahil medyo mahirap isulat. Mas naniniwala ako sa dokumentasyon at mga halimbawa.
Kaya, tiningnan namin kung paano magsulat ng mga module. Mayroong dalawang argumento. Ang una, na pinakamahalaga, ay huwag magsulat kung kaya mo, dahil maraming tao ang nakagawa na ng mga gawaing ito bago ka. At pangalawa, kung magpapasya ka pa rin, subukang huwag gumamit ng mga provider sa mga module at provisioner.
Ito ang kulay abong bahagi ng dokumentasyon. Maaaring iniisip mo ngayon: βMay hindi malinaw. Hindi kumbinsido." Ngunit makikita natin sa loob ng anim na buwan.
Ngayon ay pag-usapan natin kung paano tawagan ang mga module na ito.
Naiintindihan namin na lumalaki ang aming code sa paglipas ng panahon. Wala na tayong isang file, mayroon na tayong 20 files. Lahat sila ay nasa isang folder. O baka limang folder. Marahil ay nagsisimula na tayong hatiin ang mga ito ayon sa rehiyon, sa pamamagitan ng ilang bahagi. Pagkatapos ay naiintindihan namin na ngayon ay mayroon na kaming ilang mga simulain ng pag-synchronize at orkestrasyon. Ibig sabihin, dapat nating maunawaan kung ano ang dapat nating gawin kung binago natin ang mga mapagkukunan ng network, kung ano ang dapat nating gawin sa iba pa nating mga mapagkukunan, kung paano maging sanhi ng mga dependency na ito, atbp.
Mayroong dalawang sukdulan. Ang unang extreme ay all in one. Mayroon kaming isang master file. Sa ngayon, ito ang opisyal na pinakamahusay na kasanayan sa website ng Terraform.
Ngunit ngayon ito ay nakasulat bilang hindi na ginagamit at inalis. Sa paglipas ng panahon, napagtanto ng komunidad ng Terraform na malayo ito sa pinakamahusay na kasanayan, dahil nagsimulang gamitin ng mga tao ang proyekto sa iba't ibang paraan. At may mga problema. Halimbawa, kapag inilista namin ang lahat ng dependencies sa isang lugar. May mga sitwasyon kapag nag-click kami sa "Terraform plan" at hanggang sa i-update ng Terraform ang mga estado ng lahat ng mapagkukunan, maraming oras ang maaaring lumipas.
Ang maraming oras ay, halimbawa, 5 minuto. Para sa ilan, ito ay maraming oras. May nakita akong mga kaso kung saan tumagal ito ng 15 minuto. Ang AWS API ay gumugol ng 15 minuto sa pagsubok na alamin kung ano ang nangyayari sa estado ng bawat mapagkukunan. Ito ay isang napakalawak na lugar.
At, natural, may lalabas na kaugnay na problema kapag gusto mong baguhin ang isang bagay sa isang lugar, pagkatapos ay maghintay ka ng 15 minuto, at bibigyan ka nito ng canvas ng ilang pagbabago. Dumura ka, sumulat ng "Oo", at nagkamali. Ito ay isang tunay na halimbawa. Hindi sinusubukan ng Terraform na protektahan ka mula sa mga problema. Ibig sabihin, isulat mo ang gusto mo. Magkakaroon ng mga problema - ang iyong mga problema. Habang ang Terraform 0.11 ay hindi sinusubukang tulungan ka sa anumang paraan. Mayroong ilang mga kagiliw-giliw na lugar sa 0.12 na nagbibigay-daan sa iyo na sabihin: "Vasya, gusto mo talaga ito, maaari ka bang matauhan?"
Ang pangalawang paraan ay upang bawasan ang lugar na ito, iyon ay, ang mga tawag mula sa isang lugar ay maaaring hindi gaanong konektado mula sa ibang lugar.
Ang tanging problema ay kailangan mong magsulat ng higit pang code, ibig sabihin, kailangan mong ilarawan ang mga variable sa isang malaking bilang ng mga file at i-update ito. Ang ilang mga tao ay hindi gusto ito. Ito ay normal para sa akin. At iniisip ng ilang tao: "Bakit isulat ito sa iba't ibang lugar, ilalagay ko lahat sa isang lugar." Posible ito, ngunit ito ang pangalawang sukdulan.
Sino ang naninirahan sa isang lugar? Isa, dalawa, tatlong tao, ibig sabihin, may gumagamit nito.
At sino ang tumatawag sa isang partikular na bahagi, isang bloke o isang module ng imprastraktura? Lima hanggang pitong tao. Ito ay astig.
Ang pinakakaraniwang sagot ay nasa gitna. Kung ang proyekto ay malaki, kung gayon madalas kang magkakaroon ng isang sitwasyon kung saan walang solusyon na angkop at hindi lahat ay gumagana doon, kaya napupunta ka sa isang timpla. Walang masama dito, basta naiintindihan mo na pareho ang may pakinabang.
Kung may nagbago sa stack VPC at gusto mong ilapat ang mga pagbabagong ito sa EC2, ibig sabihin, gusto mong i-update ang autoscaling group dahil mayroon kang bagong subnet, pagkatapos ay tinatawag kong ganitong uri ng dependency orchestration. Mayroong ilang mga solusyon: sino ang gumagamit ng ano?
Maaari kong imungkahi kung anong mga solusyon ang mayroon. Maaari mong gamitin ang Terraform upang gawin ang mahika, o maaari mong gamitin ang mga makefile upang magamit ang Terraform. At tingnan kung may nagbago doon, maaari mo itong ilunsad dito.
Paano mo gusto ang desisyong ito? May naniniwala ba na ito ay isang cool na solusyon? Nakikita ko ang isang ngiti, tila may mga pagdududa.
Siyempre, huwag subukan ito sa bahay. Ang Terraform ay hindi kailanman idinisenyo upang patakbuhin mula sa Terraform.
Sa isang ulat sinabi nila sa akin: "Hindi, hindi ito gagana." Ang punto ay hindi ito dapat gumana. Bagama't mukhang napakaganda kapag maaari mong ilunsad ang Terraform mula sa Terraform, at pagkatapos ay ang Terraform, hindi mo dapat gawin iyon. Ang Terraform ay dapat palaging magsimula nang napakadali.
Kung kailangan mo ng orkestrasyon ng tawag kapag may nagbago sa isang lugar, mayroong Terragrunt.
Ang Terragrunt ay isang utility, isang add-on sa Terraform, na nagbibigay-daan sa iyong pag-coordinate at pag-orchestrate ng mga tawag sa mga module ng imprastraktura.
Ang isang tipikal na Terraform configuration file ay ganito ang hitsura.
Tinukoy mo kung aling partikular na module ang gusto mong tawagan.
Anong mga dependency ang mayroon ang module?
At anong mga argumento ang tinatanggap ng modyul na ito. Iyon lang ang dapat malaman tungkol sa Terragrunt.
Ang dokumentasyon ay naroon, at mayroong 1 bituin sa GitHub. Ngunit sa karamihan ng mga kaso ito ang kailangan mong malaman. At ito ay napakadaling ipatupad sa mga kumpanyang nagsisimula pa lang magtrabaho sa Terraform.
Kaya ang orkestrasyon ay Terragrunt. Mayroong iba pang mga pagpipilian.
Ngayon pag-usapan natin kung paano gamitin ang code.
Kung kailangan mong magdagdag ng mga bagong feature sa iyong code, sa karamihan ng mga kaso madali ito. Nagsusulat ka ng isang bagong mapagkukunan, ang lahat ay simple.
Kung mayroon kang ilang mapagkukunan na nilikha mo nang maaga, halimbawa, natutunan mo ang tungkol sa Terraform pagkatapos mong buksan ang isang AWS account at nais mong gamitin ang mga mapagkukunan na mayroon ka na, kung gayon ay angkop na palawigin ang iyong module sa ganitong paraan, upang sinusuportahan nito ang paggamit ng mga kasalukuyang mapagkukunan.
At suportado ang paglikha ng mga bagong mapagkukunan gamit ang mapagkukunan ng block.
Sa output palagi kaming nagbabalik ng output id depende sa ginamit.
Ang pangalawang napaka makabuluhang problema sa Terraform 0.11 ay gumagana sa mga listahan.
Ang hirap kasi kung meron tayong ganyang listahan ng mga user.
At kapag ginawa namin ang mga user na ito gamit ang block resource, magiging maayos ang lahat. Pumunta kami sa buong listahan, lumilikha ng isang file para sa bawat isa. Maayos ang lahat. At pagkatapos, halimbawa, ang user3, na nasa gitna, ay dapat na alisin mula dito, pagkatapos ang lahat ng mga mapagkukunan na nilikha pagkatapos niya ay muling likhain dahil magbabago ang index.
Paggawa gamit ang mga listahan sa isang stateful na kapaligiran. Ano ang isang stateful na kapaligiran? Ito ang sitwasyon kung saan nalikha ang isang bagong halaga kapag nilikha ang mapagkukunang ito. Halimbawa, AWS Access Key o AWS Secret Key, ibig sabihin, kapag gumawa kami ng user, makakatanggap kami ng bagong Access o Secret Key. At sa tuwing magde-delete kami ng user, magkakaroon ng bagong key ang user na ito. Ngunit hindi ito feng shui, dahil hindi gugustuhin ng user na makipagkaibigan sa atin kung gagawa tayo ng bagong user para sa kanya tuwing may aalis sa team.
Ito ang solusyon. Ito ay code na nakasulat sa Jsonnet. Ang Jsonnet ay isang templating language mula sa Google.
Ang utos na ito ay nagpapahintulot sa iyo na tanggapin ang template na ito at bilang output ay nagbabalik ito ng isang json file na ginawa ayon sa iyong template.
Ang template ay ganito ang hitsura.
Binibigyang-daan ka ng Terraform na magtrabaho kasama ang HCL at Json sa parehong paraan, kaya kung may kakayahan kang bumuo ng Json, maaari mo itong ipasok sa Terraform. Matagumpay na mada-download ang file na may extension na .tf.json.
At pagkatapos ay ginagawa namin ito gaya ng dati: terraform init, nalalapat ang terramorm. At gumawa kami ng dalawang user.
Ngayon hindi kami natatakot kung may umalis sa koponan. I-edit lang namin ang json file. Umalis si Vasya Pupkin, nanatili si Petya Pyatochkin. Hindi makakatanggap ng bagong susi si Petya Pyatochkin.
Ang pagsasama ng Terraform sa iba pang mga tool ay hindi talaga trabaho ng Terraform. Ang Terraform ay nilikha bilang isang platform para sa paglikha ng mga mapagkukunan at iyon lang. At lahat ng lumalabas sa ibang pagkakataon ay hindi pinag-aalala ng Terraform. At hindi na kailangang ihabi ito doon. Mayroong Ansible, na ginagawa ang lahat ng kailangan mo.
Ngunit lumilitaw ang mga sitwasyon kapag gusto nating palawigin ang Terraform at tumawag ng ilang command pagkatapos makumpleto ang isang bagay.
Unang paraan. Lumilikha kami ng isang output kung saan isinusulat namin ang utos na ito.
At pagkatapos ay tinatawag namin ang command na ito mula sa shell terraform output at tukuyin ang halaga na gusto namin. Kaya, ang utos ay isinasagawa kasama ang lahat ng mga pinalit na halaga. Ito ay napaka komportable.
Pangalawang paraan. Ito ang paggamit ng null_resource depende sa mga pagbabago sa aming imprastraktura. Maaari naming tawagan ang parehong local-exe sa sandaling magbago ang ID ng ilang mapagkukunan.
Naturally, ang lahat ng ito ay makinis sa papel, dahil ang Amazon, tulad ng lahat ng iba pang pampublikong tagapagkaloob, ay may isang bungkos ng sarili nitong mga kaso sa gilid.
Ang pinakakaraniwang edge case ay kapag nagbukas ka ng AWS account, mahalaga kung aling mga rehiyon ang iyong ginagamit; pinagana ba ang tampok na ito doon; baka binuksan mo ito pagkatapos ng Disyembre 2013; baka gumagamit ka ng default sa VPC atbp. Maraming restrictions. At ikinalat sila ng Amazon sa buong dokumentasyon.
Mayroong ilang mga bagay na inirerekomenda kong iwasan.
Upang magsimula, iwasan ang lahat ng hindi lihim na argumento sa loob ng Terraform plan o Terraform CLI. Ang lahat ng ito ay maaaring ilagay alinman sa isang tfvars file o sa isang environment variable.
Ngunit hindi mo kailangang kabisaduhin ang buong magic command na ito. Plano ng Terraform β var at umalis na kami. Ang unang variable ay var, ang pangalawang variable ay var, ang pangatlo, ikaapat. Ang pinakamahalagang prinsipyo ng imprastraktura bilang code na madalas kong ginagamit ay sa pamamagitan lamang ng pagtingin sa code, dapat ay mayroon akong malinaw na pag-unawa sa kung ano ang naka-deploy doon, sa anong estado at kung anong mga halaga. At kaya hindi ko na kailangang basahin ang dokumentasyon o tanungin si Vasya kung anong mga parameter ang ginamit niya upang lumikha ng aming kumpol. Kailangan ko lang magbukas ng file na may extension ng tfvars, na kadalasang tumutugma sa kapaligiran, at tingnan ang lahat doon.
Gayundin, huwag gumamit ng mga target na argumento upang bawasan ang saklaw. Para dito, mas madaling gumamit ng maliliit na module ng imprastraktura.
Gayundin, hindi na kailangang limitahan at dagdagan ang paralelismo. Kung mayroon akong 150 na mapagkukunan at gusto kong dagdagan ang paralelismo ng Amazon mula sa default na 10 hanggang 100, malamang na may magkamali. O maaari itong maging maayos ngayon, ngunit kapag sinabi ng Amazon na gumagawa ka ng masyadong maraming mga tawag, ikaw ay nasa problema.
Susubukan ng Terraform na i-restart ang karamihan sa mga problemang ito, ngunit halos wala kang makakamit. Ang Parallelism=1 ay isang mahalagang bagay na dapat gamitin kung makaranas ka ng ilang bug sa loob ng AWS API o sa loob ng provider ng Terraform. At pagkatapos ay kailangan mong tukuyin ang: parallelism=1 at maghintay hanggang matapos ang Terraform ng isang tawag, pagkatapos ay ang pangalawa, pagkatapos ay ang pangatlo. Isa-isa niyang ilulunsad ang mga ito.
Madalas itanong sa akin ng mga tao, "Bakit sa tingin ko ay masama ang mga workspace ng Terraform?" Naniniwala ako na ang prinsipyo ng imprastraktura bilang code ay upang makita kung anong imprastraktura ang nilikha at kung anong mga halaga.
Ang mga workspace ay hindi ginawa ng mga user. Hindi ito nangangahulugan na sumulat ang mga user sa mga isyu sa GitHub na hindi namin mabubuhay nang walang mga workspace ng Terraform. Hindi hindi ganito. Ang Terraform Enterprise ay isang komersyal na solusyon. Nagpasya ang Terraform mula sa HashiCorp na kailangan namin ng mga workspace, kaya inihain namin ito. Mas madaling ilagay ito sa isang hiwalay na folder. Pagkatapos ay magkakaroon ng kaunti pang mga file, ngunit ito ay magiging mas malinaw.
Paano magtrabaho kasama ang code? Sa katunayan, ang pagtatrabaho sa mga listahan ay ang tanging sakit. At kunin ang Terraform nang mas madali. Hindi ito ang bagay na gagawin ang lahat ng mahusay para sa iyo. Hindi na kailangang itulak ang lahat ng nakasulat sa dokumentasyon doon.
Ang paksa ng ulat ay isinulat "para sa hinaharap." Pag-uusapan ko ito nang maikli. Para sa hinaharap, nangangahulugan ito na malapit nang ilabas ang 0.12.
Ang 0.12 ay isang tonelada ng mga bagong bagay. Kung nanggaling ka sa regular na programming, pagkatapos ay makaligtaan mo ang lahat ng mga uri ng mga dynamic na bloke, mga loop, tama at kondisyon na paghahambing na mga operasyon, kung saan ang kaliwa at kanang bahagi ay hindi kinakalkula nang sabay-sabay, ngunit depende sa sitwasyon. Marami kang nami-miss, kaya 0.12 ang makakalutas nito para sa iyo.
Ngunit! Kung mas kaunti at mas simple ang isusulat mo, gamit ang mga yari na module at mga third-party na solusyon, hindi mo na kailangang maghintay at umaasa na darating ang 0.12 at ayusin ang lahat para sa iyo.
Salamat sa ulat! Nagsalita ka tungkol sa imprastraktura bilang code at literal na nagsabi ng isang salita tungkol sa mga pagsubok. Kailangan ba ang mga pagsusulit sa mga module? Kaninong responsibilidad ito? Kailangan ko bang isulat ito sa aking sarili o ito ba ay responsibilidad ng mga modyul?
Ang susunod na taon ay mapupuno ng mga ulat na nagpasya kaming subukan ang lahat. Ano ang susuriin ang pinakamalaking tanong. Mayroong maraming mga dependency, maraming mga paghihigpit mula sa iba't ibang mga provider. Kapag ikaw at ako ay nag-uusap at sinabi mong: "Kailangan ko ng mga pagsubok," pagkatapos ay itatanong ko: "Ano ang susuriin mo?" Ang sabi mo ay magsusubok ka sa iyong rehiyon. Pagkatapos ay sinasabi ko na hindi ito gumagana sa aking rehiyon. Ibig sabihin, hindi rin tayo magkakasundo dito. Hindi banggitin na mayroong maraming mga teknikal na problema. Iyon ay, kung paano isulat ang mga pagsusulit na ito upang ang mga ito ay sapat.
Aktibo kong sinasaliksik ang paksang ito, ibig sabihin, kung paano awtomatikong bumuo ng mga pagsubok batay sa imprastraktura na iyong isinulat. Iyon ay, kung isinulat mo ang code na ito, kailangan kong patakbuhin ito, batay dito maaari akong lumikha ng mga pagsubok.
ay isa sa pinakamadalas na binanggit na mga aklatan na nagbibigay-daan sa iyong magsulat ng mga pagsubok sa pagsasama para sa Terraform. Isa ito sa mga utility. Mas gusto ko ang uri ng DSL, halimbawa, rspec.
Anton, salamat sa ulat! Ang pangalan ko ay Valery. Hayaan akong magtanong ng isang maliit na pilosopikal na tanong. May, conditionally, provisioning, may deployment. Ginagawa ng provisioning ang aking imprastraktura, sa pag-deploy ay pinupuno namin ito ng isang bagay na kapaki-pakinabang, halimbawa, mga server, application, atbp. At nasa isip ko na ang Terraform ay higit pa para sa provisioning, at ang Ansible ay higit pa para sa pag-deploy, dahil ang Ansible ay para din sa pisikal na Ang imprastraktura nagpapahintulot sa iyo na mag-install ng nginx, Postgres. Ngunit sa parehong oras, mukhang pinapayagan ng Ansible ang pagbibigay, halimbawa, ng mga mapagkukunan ng Amazon o Google. Ngunit pinapayagan ka rin ng Terraform na mag-deploy ng ilang software gamit ang mga module nito. Mula sa iyong pananaw, mayroon bang ilang uri ng hangganan na tumatakbo sa pagitan ng Terraform at Ansible, kung saan at ano ang mas mahusay na gamitin? O, halimbawa, sa tingin mo ba ay basura na ang Ansible, dapat mong subukang gamitin ang Terraform para sa lahat?
Magandang tanong, Valery. Naniniwala ako na ang Terraform ay hindi nagbago sa mga tuntunin ng layunin mula noong 2014. Ito ay nilikha para sa imprastraktura at namatay para sa imprastraktura. Nagkaroon at magkakaroon pa kami ng pangangailangan para sa pamamahala ng pagsasaayos ng Ansible. Ang hamon ay mayroong data ng user sa loob ng launch_configuration. At doon mo hilahin ang Ansible, atbp. Ito ang karaniwang pagkakaiba na pinakagusto ko.
Kung pinag-uusapan natin ang tungkol sa magagandang imprastraktura, kung gayon mayroong mga utility tulad ng Packer na kumukuha ng larawang ito. At pagkatapos ay ginagamit ng Terraform ang data source upang mahanap ang larawang ito at i-update ang launch_configuration nito. Ibig sabihin, sa ganitong paraan ang pipeline ay una nating hilahin ang Tracker, pagkatapos ay hilahin ang Terraform. At kung naganap ang pagtatayo, may bagong pagbabagong magaganap.
Kamusta! Salamat sa ulat! Ang pangalan ko ay Misha, kumpanya ng RBS. Maaari kang tumawag sa Ansible sa pamamagitan ng provisioner kapag gumagawa ng mapagkukunan. Ang Ansible ay mayroon ding paksang tinatawag na dynamic na imbentaryo. At maaari mo munang tawagan ang Terraform, at pagkatapos ay tawagan ang Ansible, na kukuha ng mga mapagkukunan mula sa estado at isakatuparan ito. Ano ang mas maganda?
Ginagamit ng mga tao ang parehong may pantay na tagumpay. Para sa akin, ang dynamic na imbentaryo sa Ansible ay isang maginhawang bagay, kung hindi natin pinag-uusapan ang tungkol sa autoscaling group. Dahil sa autoscaling group mayroon na tayong sariling toolkit, na tinatawag na launch_configuration. Sa launch_configuration, itinatala namin ang lahat ng kailangang ilunsad kapag lumikha kami ng bagong mapagkukunan. Samakatuwid, sa Amazon, ang paggamit ng dynamic na imbentaryo at pagbabasa ng Terraform ts file, sa palagay ko, ay labis-labis na. At kung gumagamit ka ng iba pang mga tool kung saan walang konsepto ng "autoscaling group", halimbawa, gumagamit ka ng DigitalOcean o ilang iba pang provider kung saan walang autoscaling group, pagkatapos doon ay kailangan mong manual na hilahin ang API, maghanap ng mga IP address, lumikha isang dynamic na file ng imbentaryo , at lalakarin na ito ng Ansible. Iyon ay, para sa Amazon mayroong launch_configuration, at para sa lahat ng iba pa ay mayroong dynamic na imbentaryo.
Pinagmulan: www.habr.com