Ang kumakatawan sa imprastraktura bilang code sa isang paulit-ulit na format ng text ay isang simpleng pinakamahusay na kasanayan para sa mga system na hindi nangangailangan ng kalikot sa mga daga. Ang pagsasanay na ito ay may pangalan - , at sa ngayon ay may dalawang sikat na tool para ipatupad ito, lalo na sa AWS: ΠΈ .
Paghahambing ng karanasan sa Terraform at CloudFormation
Bago dumating sa (Aka ) Nagtrabaho ako at gumamit ng Terraform sa loob ng tatlong taon. Sa bagong lugar, ginamit ko rin ang Terraform nang buong lakas, at pagkatapos ay itinulak ng kumpanya ang paglipat sa lahat ng bagay sa Amazon, kasama ang CloudFormation. Masigasig akong nakabuo ng pinakamahuhusay na kagawian para sa pareho, at ginamit ko ang parehong mga tool sa napakakomplikado, mga daloy ng trabaho sa buong organisasyon. Nang maglaon, pagkatapos maingat na timbangin ang mga implikasyon ng paglipat mula sa Terraform patungo sa CloudFormation, nakumbinsi ako na ang Terraform ay marahil ang pinakamahusay na pagpipilian para sa organisasyon.
Terraform Nakakatakot
Beta software
Ang Terraform ay hindi pa naglalabas ng bersyon 1.0, na isang magandang dahilan upang hindi ito gamitin. Malaki na ang pinagbago simula nung una kong sinubukan ang sarili ko, pero noon terraform apply madalas na nasira pagkatapos ng ilang pag-update o pagkatapos lamang ng ilang taon ng paggamit. Sasabihin ko na "lahat ay iba na ngayon," ngunit... iyon ang tila sinasabi ng lahat, hindi ba? May mga pagbabagong hindi tugma sa mga nakaraang bersyon, bagama't angkop ang mga ito, at parang ang syntax at abstraction ng mga resource store ang kailangan natin ngayon. Parang gumanda talaga yung instrument, pero... :-0
Sa kabilang banda, nagawa ng AWS ang isang mahusay na trabaho sa pagpapanatili ng backward compatibility. Ito ay marahil dahil ang kanilang mga serbisyo ay madalas na lubusang nasubok sa loob ng organisasyon at pagkatapos lamang, pinalitan ng pangalan, ay nai-publish. Kaya ang "they tried hard" ay isang understatement. Ang pagpapanatili ng pabalik na compatibility sa mga API para sa isang system na iba-iba at kumplikado gaya ng AWS ay napakahirap. Ang sinumang kailangang magpanatili ng mga pampublikong API na ginagamit nang kasing dami ng mga ito ay dapat na maunawaan kung gaano kahirap gawin ito sa loob ng maraming taon. Ngunit ang pag-uugali ng CloudFormation, sa aking memorya, ay hindi kailanman nagbago sa paglipas ng mga taon.
Salubungin ang binti... ito ay isang bala
Sa pagkakaalam ko, tanggalin ang mapagkukunan tagalabas CloudFormation stack mula sa iyong CF stack ay hindi posible. Ang parehong ay totoo sa Terraform. Pinapayagan ka nitong mag-import ng mga umiiral nang mapagkukunan sa iyong stack. Ang pag-andar ay masasabing kamangha-manghang, ngunit may malaking kapangyarihan ay may malaking responsibilidad. Kailangan mo lang magdagdag ng resource sa stack, at habang nagtatrabaho ka sa iyong stack, hindi mo matatanggal o mababago ang resource na ito. Isang araw nag backfire ito. Isang araw sa Twitch, may hindi sinasadyang nag-import ng grupo ng seguridad ng AWS ng ibang tao sa sarili nilang Terraform stack habang hindi umabot sa anumang kalokohan. Naglagay ako ng ilang command at... nawala ang grupo ng seguridad (kasama ang papasok na trapiko).
Mahusay ang Terraform
Pagbawi mula sa hindi kumpletong mga estado
Minsan nabigo ang CloudFormation na ganap na lumipat mula sa isang estado patungo sa isa pa. At the same time, susubukan niyang bumalik sa dati. Nakakalungkot na hindi ito palaging magagawa. Maaaring medyo nakakatakot na i-debug ang nangyari sa ibang pagkakataon - hindi mo alam kung matutuwa ang CloudFormation na na-hack ito - kahit para lang ayusin ito. Posible man o hindi na bumalik sa dating estado, talagang hindi niya alam kung paano matukoy at, bilang default, nakabitin nang ilang oras na naghihintay para sa isang himala.
Ang Terraform, sa kabilang banda, ay may posibilidad na makabawi mula sa mga nabigong transition nang mas maganda at nag-aalok ng mga advanced na tool sa pag-debug.
Mas malinaw na mga pagbabago sa estado ng dokumento
βSige, load balancer, nagpapalit ka. Pero paano?"
βnababalisa na engineer, handang pindutin ang βacceptβ button.
Minsan kailangan kong gumawa ng ilang manipulasyon sa load balancer sa CloudFormation stack, gaya ng pagdaragdag ng port number o pagpapalit ng security group. Ang ClouFormation ay nagpapakita ng mga pagbabago nang hindi maganda. Ako, sa mga pin at karayom, i-double check ang yaml file ng sampung beses upang matiyak na hindi ko nabura ang anumang bagay na kailangan at hindi nagdagdag ng anumang hindi kailangan.
Ang Terraform ay mas transparent sa bagay na ito. Minsan masyado siyang transparent (read: boring). Sa kabutihang palad, kasama sa pinakabagong bersyon ang pinahusay na pagpapakita ng mga pagbabago upang makita mo na ngayon nang eksakto kung ano ang nagbabago.
Kakayahang umangkop
Sumulat ng software pabalik.
Sa madaling salita, ang pinakamahalagang katangian ng matagal nang software ay ang kakayahang umangkop sa pagbabago. Sumulat ng anumang software pabalik. Kadalasan ay nagkakamali ako sa pamamagitan ng pagkuha ng isang "simpleng" serbisyo, at pagkatapos ay simulang isiksik ang lahat sa isang solong CloudFormation o Terraform stack. At siyempre, pagkaraan ng ilang buwan ay nabunyag na naunawaan ko ang lahat ng mali, at ang serbisyo ay talagang hindi simple! At ngayon kailangan kong hatiin ang isang malaking stack sa maliliit na bahagi. Kapag nagtatrabaho ka sa CloudFormation, magagawa lamang ito sa pamamagitan ng unang muling paggawa ng umiiral na stack, at hindi ko ito ginagawa sa aking mga database. Ang Terraform, sa kabilang banda, ay naging posible na i-dissect ang stack at hatiin ito sa mas mauunawaang maliliit na bahagi.
Mga module sa git
Ang pagbabahagi ng Terraform code sa maraming stack ay mas madali kaysa sa pagbabahagi ng CloudFormation code. Sa Terraform, maaari mong ilagay ang iyong code sa isang git repository at i-access ito gamit ang semantic version control. Maaaring gamitin muli ng sinumang may access sa repositoryong ito ang nakabahaging code. Ang katumbas ng CloudFormation ay S3, ngunit wala itong parehong mga benepisyo, at walang dahilan kung bakit dapat nating talikuran ang git pabor sa S3.
Ang organisasyon ay lumago at ang kakayahang magbahagi ng mga karaniwang stack ay umabot sa isang kritikal na antas. Ginagawang madali at natural ito ng Terraform, samantalang gagawin ka ng CloudFormation na tumalon sa mga hoop bago mo magawa ang isang bagay na tulad nito.
Mga operasyon bilang code
"I-script natin ito at okay."
βisang inhinyero 3 taon bago naimbento ang Terraform na bisikleta.
Pagdating sa software development, ang Go o isang Java program ay hindi lamang code.
Code bilang Code
Mayroon ding imprastraktura kung saan ito gumagana.
Ang imprastraktura bilang Code
Pero saan siya galing? Paano ito subaybayan? Saan nakatira ang iyong code? Kailangan ba ng mga developer ng pahintulot sa pag-access?
Mga operasyon bilang Code
Ang pagiging isang software developer ay hindi lamang nangangahulugan ng pagsusulat ng code.
Hindi lang ang AWS: malamang na gumagamit ka ng ibang mga provider. SignalFx, PagerDuty o Github. Marahil ay mayroon kang panloob na server ng Jenkins para sa CI/CD o isang panloob na dashboard ng Grafana para sa pagsubaybay. Ang Infra bilang Code ay pinili para sa iba't ibang dahilan, at ang bawat isa ay pantay na mahalaga para sa lahat ng bagay na nauugnay sa software.
Noong nagtrabaho ako sa Twitch, pinabilis namin ang mga serbisyo sa loob ng pinaghalong naka-embed at AWS system ng Amazon. Nag-churn out kami at sumuporta sa maraming microservice, na nagpapataas ng mga gastos sa pagpapatakbo. Ang mga talakayan ay naging ganito:
- Π―: Damn, napakaraming galaw para mag-overclock ng isang microservice. Kailangan kong gamitin ang basurang ito para gumawa ng AWS account (pumunta kami sa 2 account noong microservice), pagkatapos ang isang ito para sa pag-set up ng mga alerto, ang isang ito para sa isang imbakan ng code, at ang isang ito para sa isang listahan ng email, at pagkatapos ang isang ito...
- Tingga: I-script natin at okay.
- Π―: Okay, ngunit ang script mismo ay magbabago. Kakailanganin namin ang isang paraan upang suriin na ang lahat ng mga built-in na Amazon gizmos na ito ay napapanahon.
- Tingga: Mukhang maganda. At gagawa kami ng script para dito.
- Π―: Malaki! At ang script ay malamang na kailangan pa ring magtakda ng mga parameter. Matatanggap ba niya ang mga ito?
- Tingga: Hayaan siyang dalhin kung saan siya pupunta!
- Π―: Maaaring magbago ang proseso at mawawala ang backward compatibility. Kakailanganin ang ilang uri ng semantic version control.
- Tingga: Magandang ideya!
- Π―: Maaaring baguhin nang manu-mano ang mga tool, sa loob ng user interface. Kakailanganin namin ang isang paraan upang suriin at ayusin ito.
β¦3 taon mamaya:
- Tingga: At nakakuha kami ng terraform.
Ang moral ng kwento ay: kahit na ikaw ulos sa takong sa lahat ng bagay sa Amazon, gumagamit ka pa rin ng isang bagay na hindi mula sa AWS, at ang mga serbisyong ito ay may estado na gumagamit ng configuration language upang panatilihing naka-sync ang estadong iyon.
CloudFormation lambda vs git modules terraform
Ang lambda ay solusyon ng CloudFormation sa custom na isyu sa lohika. Sa lambda kaya mo o . Ang diskarte na ito ay nagpapakilala ng mga karagdagang pagkakumplikado na wala sa semantikong bersyon ng git module ng Terraform. Para sa akin, ang pinakamabigat na problema ay ang pamamahala ng mga pahintulot para sa lahat ng mga lambda ng user na ito (at ito ay dose-dosenang mga AWS account). Ang isa pang mahalagang problema ay ang problemang βano ang nauna, ang manok o ang itlog?β: ito ay nauugnay sa lambda code. Ang function na ito mismo ay imprastraktura at code, at ito mismo ay nangangailangan ng pagsubaybay at pag-update. Ang huling pako sa kabaong ay ang kahirapan sa semantikong pag-update ng mga pagbabago sa lambda code; kailangan din naming tiyakin na ang mga pagkilos ng stack na walang direktang utos ay hindi nagbabago sa pagitan ng mga pagtakbo.
Naaalala ko noong isang beses gusto kong gumawa ng canary deployment para sa Elastic Beanstalk environment na may klasikong load balancer. Ang pinakamadaling gawin ay ang gumawa ng pangalawang deployment para sa EB sa tabi ng production environment, na humahantong pa: pagsasamahin ang auto-scaling canary deployment group sa deployment LB sa production environment. At dahil ang Terraform ay gumagamit , mangangailangan ito ng 4 na karagdagang linya ng code sa Terraform. Nang tanungin ko kung may maihahambing na solusyon sa CloudFormation, itinuro nila ako sa isang buong git repository na may deployment pipeline at lahat ng bagay, lahat para sa kapakanan ng isang bagay na magagawa ng mahihirap na 4 na linya ng Terraform code.
Mas nade-detect nito ang drift
Tiyaking tumutugma ang katotohanan sa mga inaasahan.
ay isang napakalakas na pagpapatakbo bilang tampok na code dahil nakakatulong ito na matiyak na ang katotohanan ay tumutugma sa mga inaasahan. Available ito sa parehong CloudFormation at Terraform. Ngunit habang lumalaki ang stack ng produksyon, ang paghahanap ng drift sa CloudFormation ay nagdulot ng higit pang mga maling pagtuklas.
Sa Terraform mayroon kang mas advanced na lifecycle hook para sa drift detection. Halimbawa, ipinasok mo ang utos direkta sa kahulugan ng gawain ng ECS ββkung gusto mong huwag pansinin ang mga pagbabago sa isang partikular na kahulugan ng gawain nang hindi binabalewala ang mga pagbabago sa iyong buong deployment ng ECS.
CDK at ang hinaharap ng CloudFormation
Mahirap pangasiwaan ang CloudFormation sa malalaking sukat ng cross-infrastructure. Marami sa mga paghihirap na ito ay kinikilala at ang tool ay nangangailangan ng mga bagay tulad , isang framework para sa pagtukoy ng cloud infrastructure sa code at pagpapatakbo nito sa pamamagitan ng AWS CloudFormation. Magiging kawili-wiling makita kung ano ang hinaharap para sa aws-cdk, ngunit mahihirapan itong makipagkumpitensya sa iba pang lakas ng Terraform; para mapapanahon ang CloudFormation, kakailanganin ang mga pandaigdigang pagbabago.
Upang ang Terraform ay hindi mabigo
Ito ay "imprastraktura bilang isang code", at hindi "bilang isang teksto".
Ang aking unang impression sa Terraform ay medyo masama. Sa tingin ko hindi ko lang naintindihan ang diskarte. Halos lahat ng mga inhinyero ay hindi sinasadyang madama ito bilang isang format ng teksto na kailangang i-convert sa nais na imprastraktura. HUWAG GAWIN ITO.
Ang mga katotohanan ng mahusay na pagbuo ng software ay nalalapat din sa Terraform.
Nakakita ako ng maraming gawi na pinagtibay upang lumikha ng magandang code na hindi pinapansin sa Terraform. Nag-aral ka ng maraming taon upang maging isang mahusay na programmer. Huwag isuko ang karanasang ito dahil lang sa nagtatrabaho ka sa Terraform. Ang mga katotohanan ng mahusay na pagbuo ng software ay nalalapat sa Terraform.
Paano hindi maidokumento ang code?
Nakakita ako ng malalaking stack ng Terraform na walang dokumentasyon. Paano ka makakasulat ng code sa mga pahina - na walang ganap na dokumentasyon? Magdagdag ng dokumentasyong nagpapaliwanag sa iyong kodigo Terraform (diin sa salitang "code"), kung bakit napakahalaga ng seksyong ito, at kung ano ang iyong ginagawa.
Paano tayo makakapag-deploy ng mga serbisyong dating isang malaking main() function?
Nakakita ako ng napakakomplikadong Terraform stack na ipinakita bilang isang module. Bakit hindi namin i-deploy ang software sa ganitong paraan? Bakit natin hinahati ang malalaking function sa mas maliliit? Ang parehong mga sagot ay nalalapat sa Terraform. Kung masyadong malaki ang iyong module, kailangan mong hatiin ito sa mas maliliit na module.
Hindi ba gumagamit ang iyong kumpanya ng mga aklatan?
Nakita ko kung paanong ang mga inhinyero, na nagpapaikot ng bagong proyekto gamit ang Terraform, ay walang kabuluhang kinopya-paste ang malalaking tipak mula sa iba pang mga proyekto sa kanilang sarili, at pagkatapos ay pinag-uusapan ang mga ito hanggang sa magsimula itong gumana. Gagawa ka ba ng ganito gamit ang "combat" code sa iyong kumpanya? Hindi lang mga library ang ginagamit namin. Oo, ngunit saan tayo walang shared library sa prinsipyo?!
Hindi ka ba gumagamit ng PEP8 o gofmt?
Karamihan sa mga wika ay may pamantayan, tinatanggap na pamamaraan ng pag-format. Sa Python ito ay PEP8. Sa Go - gofmt. Ang Terraform ay may sariling: terraform fmt. Tangkilikin ito para sa iyong kalusugan!
Gagamitin mo ba ang React nang hindi alam ang JavaScript?
Ang mga module ng Terraform ay maaaring pasimplehin ang ilang bahagi ng kumplikadong imprastraktura na iyong nilikha, ngunit hindi ito nangangahulugan na hindi mo ito maaaring pag-usapan. Gusto mong gamitin nang tama ang Terraform nang hindi nauunawaan ang mga mapagkukunan? Ikaw ay tiyak na mapapahamak: lilipas ang oras, at hinding-hindi mo mahahawakan ang Terraform.
Nagco-coding ka ba ng mga singleton o dependency injection?
Ang dependency injection ay isang kinikilalang pinakamahusay na kasanayan para sa pagbuo ng software at mas gusto kaysa sa mga singleton. Paano ito kapaki-pakinabang sa Terraform? Nakakita ako ng mga module ng Terraform na nakadepende sa malayong estado. Sa halip na magsulat ng mga module na kumukuha ng malayuang estado, magsulat ng isang module na kumukuha ng mga parameter. At pagkatapos ay ipasa ang mga parameter na ito sa module.
Nagagawa ba ng iyong mga aklatan ang sampung bagay nang maayos o isang bagay na mahusay?
Ang mga aklatan na pinakamahusay na gumagana ay ang mga nakatuon sa isang gawain na mahusay nilang ginagawa. Sa halip na magsulat ng malalaking Terraform module na sumusubok na gawin ang lahat nang sabay-sabay, bumuo ng mga bahagi ng mga ito na gumagawa ng isang bagay nang maayos. At pagkatapos ay pagsamahin ang mga ito kung kinakailangan.
Paano ka gagawa ng mga pagbabago sa mga aklatan nang walang backward compatibility?
Ang isang karaniwang module ng Terraform, tulad ng isang regular na aklatan, ay kailangang kahit papaano ay makipag-usap ng mga pagbabago sa mga user nang hindi ito tugma sa likuran. Nakakainis kapag nangyayari ang mga pagbabagong ito sa mga aklatan, at nakakainis din kapag ginawa ang mga hindi katugmang pagbabago sa mga module ng Terraform. Inirerekomenda na gumamit ng mga git tag at semver kapag gumagamit ng mga module ng Terraform.
Gumagana ba ang iyong serbisyo sa produksyon sa iyong laptop o sa isang data center?
Ang Hashicorp ay may mga tool tulad ng upang patakbuhin ang iyong terraform. Pinapadali ng mga sentralisadong serbisyong ito ang pamamahala, pag-audit, at pag-apruba ng mga pagbabago sa terraform.
Hindi ka ba nagsusulat ng mga pagsubok?
Kinikilala ng mga inhinyero na ang code ay kailangang masuri, ngunit sila mismo ay madalas na nakakalimutan ang tungkol sa pagsubok kapag nagtatrabaho sa Terraform. Para sa imprastraktura, ito ay puno ng mga taksil na sandali. Ang payo ko ay "subukan" o "lumikha ng halimbawa" na mga stack gamit ang mga module na maaaring i-deploy nang tama para sa pagsubok sa panahon ng CI/CD.
Terraform at microservices
Ang buhay at pagkamatay ng mga kumpanya ng microservice ay nakasalalay sa bilis, pagbabago, at pagkagambala ng mga bagong microservice workstack.
Ang pinakakaraniwang negatibong aspeto na nauugnay sa mga arkitektura ng microservice, at hindi maaaring alisin, ay nauugnay sa trabaho, hindi sa code. Kung sa tingin mo ang Terraform ay isang paraan lang para i-automate lang ang bahagi ng imprastraktura ng isang arkitektura ng microservices, nawawala ka sa mga tunay na benepisyo ng system. Ngayon ay na .
Pinagmulan: www.habr.com