Mukhang nag-aalok ang mga developer ng Terraform ng medyo maginhawang pinakamahusay na kasanayan para sa pagtatrabaho sa imprastraktura ng AWS. May nuance lang. Sa paglipas ng panahon, ang bilang ng mga kapaligiran ay tumataas, bawat isa ay may sarili nitong mga tampok. Lumilitaw ang halos kopya ng application stack sa kalapit na rehiyon. At ang Terraform code ay kailangang maingat na kopyahin at i-edit ayon sa mga bagong kinakailangan o gawing snowflake.
Ang aking ulat tungkol sa mga pattern sa Terraform upang labanan ang kaguluhan at manu-manong gawain sa malalaki at mahabang proyekto.
Video:
40 na ako, 20 years na ako sa IT. 12 years na akong nagtatrabaho sa Ixtens. Kami ay nakikibahagi sa ecommerce-driven-development. At 5 taon na akong nagsasanay ng mga kasanayan sa DevOps.
Ang aking kwento ay tungkol sa aking karanasan sa isang proyekto sa isang kumpanya na hindi ko sasabihin ang pangalan, na nagtatago sa likod ng isang non-disclosure agreement.
Ang mga numero sa slide ay ipinahiwatig upang maunawaan ang sukat ng proyekto. At lahat ng susunod kong sasabihin ay may kaugnayan sa Amazon.
Sumali ako sa proyektong ito 4 na taon na ang nakakaraan. At ang refactoring ng imprastraktura ay puspusan dahil ang proyekto ay lumago. At ang mga pattern na ginamit ay hindi na angkop. At dahil sa lahat ng nakaplanong paglago ng proyekto, kinakailangan na magkaroon ng bago.
Salamat kay Matvey, na sinabi sa amin kahapon kung ano ang nangyari sa Dodo Pizza. Ito ang nangyari dito 4 years ago.
Dumating ang mga developer at nagsimulang gumawa ng infrastructure code.
Ang pinaka-halatang mga dahilan kung bakit ito ay kinakailangan ay oras sa merkado. Ito ay kinakailangan upang matiyak na ang DevOps team ay hindi isang bottleneck sa panahon ng paglulunsad. At bukod sa iba pang mga bagay, ginamit ang Terraform at Puppet sa pinakaunang antas.
Ang Terraform ay isang open source na proyekto mula sa HashiCorp. At para sa mga hindi pa nakakaalam kung ano ito, ang mga susunod na slide.
Ang imprastraktura bilang code ay nangangahulugan na maaari naming ilarawan ang aming imprastraktura at hilingin sa ilang mga robot na tiyaking matatanggap namin ang mga mapagkukunang inilarawan namin.
Halimbawa, kailangan natin ng virtual machine. Ilalarawan at idaragdag namin ang ilang kinakailangang parameter.
Pagkatapos nito, iko-configure namin ang pag-access sa Amazon sa console. At hihilingin namin ang planong Terraform. Sasabihin ng plano ng Terraform: "Okay, magagawa namin ang mga bagay na ito para sa iyong mapagkukunan." At hindi bababa sa isang mapagkukunan ang idadagdag. At walang inaasahang pagbabago.
Kapag masaya ka na sa lahat, maaari mong hilingin sa Terraform na mag-apply at gagawa ang Terraform ng isang instance para sa iyo, at makakatanggap ka ng virtual machine sa iyong cloud.
Dagdag pa, ang aming proyekto ay umuunlad. Nagdaragdag kami ng ilang pagbabago doon. Humihingi kami ng higit pang mga pagkakataon, nagdagdag kami ng 53 mga entry.
At inuulit namin. Mangyaring magplano. Nakikita natin kung anong mga pagbabago ang pinaplano. Nag-a-apply kami. At ito ay kung paano lumalaki ang aming imprastraktura.
Gumagamit ang Terraform ng tinatawag na state file. Iyon ay, ang lahat ng mga pagbabago na napupunta sa Amazon ay nai-save sa isang file kung saan para sa bawat mapagkukunan na iyong inilarawan, may mga kaukulang mapagkukunan na nilikha sa Amazon. Kaya, kapag nagbago ang paglalarawan ng isang mapagkukunan, alam na alam ng Terraform kung ano ang kailangang baguhin sa Amazon.
Ang mga state file na ito ay orihinal na mga file lamang. At inimbak namin ang mga ito sa Git, na lubhang hindi maginhawa. Palaging nakalimutan ng isang tao na gumawa ng mga pagbabago, at maraming mga salungatan ang lumitaw.
Ngayon ay posible nang gamitin ang backend, ibig sabihin, ang Terraform ay tinukoy kung saan bucket at kung saan susi dapat i-save ang file ng estado. At ang Terraform mismo ang bahala sa pagkuha ng state file na ito, ginagawa ang lahat ng mahika at ibabalik ang huling resulta.
Ang aming imprastraktura ay lumalaki. Narito ang aming code. At ngayon hindi lang namin gustong lumikha ng isang virtual machine, gusto naming magkaroon ng isang pagsubok na kapaligiran.
Pinapayagan ka ng Terraform na lumikha ng isang bagay bilang isang module, iyon ay, ilarawan ang parehong bagay sa ilang folder.
At, halimbawa, sa pagsubok, tawagan ang module na ito at kunin ang parehong bagay na parang nai-execute namin ang Terraform na nalalapat sa mismong module. Para sa pagsubok magkakaroon ng code na ito.
Para sa produksyon, maaari kaming magpadala ng ilang mga pagbabago doon, dahil sa pagsubok ay hindi namin kailangan ng malalaking pagkakataon; sa produksyon, ang malalaking pagkakataon ay kapaki-pakinabang lamang.
At pagkatapos ay babalik ako sa proyekto. Ito ay isang mahirap na gawain, ang nakaplanong imprastraktura ay napakalaki. At kinakailangan na kahit papaano ay ilagay ang lahat ng code upang ito ay maging maginhawa para sa lahat: kapwa para sa mga nagsasagawa ng pagpapanatili sa code na ito at para sa mga gumagawa ng mga pagbabago. At pinlano na ang sinumang developer ay maaaring pumunta at ayusin ang imprastraktura kung kinakailangan para sa kanyang bahagi ng platform.
Ito ay isang puno ng direktoryo na inirerekomenda ng HashiCorp mismo kung mayroon kang malaking proyekto at makatuwirang hatiin ang buong imprastraktura sa ilang maliliit na piraso, at ilarawan ang bawat piraso sa isang hiwalay na folder.
Ang pagkakaroon ng isang malawak na library ng mga mapagkukunan, maaari kang tumawag ng humigit-kumulang sa parehong bagay sa pagsubok at sa produksyon.
Sa aming kaso, hindi ito ganap na angkop, dahil ang test stack para sa mga developer o para sa pagsubok ay kailangang makuha kahit papaano mas simple. Ngunit hindi ko nais na dumaan sa mga folder at ilapat ang mga ito sa kinakailangang pagkakasunud-sunod, at mag-alala na ang database ay tataas, at pagkatapos ay ang pagkakataon na gumagamit ng database na ito ay tataas. Samakatuwid, ang lahat ng pagsubok ay inilunsad mula sa isang folder. Ang parehong mga module ay tinawag doon, ngunit ang lahat ay ginawa sa isang pagtakbo.
Pinangangalagaan ng Terraform ang lahat ng dependencies. At palagi itong lumilikha ng mga mapagkukunan sa pagkakasunud-sunod upang makakuha ka ng isang IP address, halimbawa, mula sa isang bagong likhang pagkakataon, at makuha ang IP address na ito sa talaan ng ruta53.
Bilang karagdagan, ang platform ay napakalaki. At ang paglulunsad ng isang test stack, kahit na sa loob ng isang oras, kahit na sa loob ng 8 oras, ay medyo isang magastos na gawain.
At automated namin ang bagay na ito. At pinayagan kami ng trabaho ni Jenkin na patakbuhin ang stack. Sa loob nito, kinailangang maglunsad ng pull request na may mga pagbabagong gustong subukan ng developer, tukuyin ang lahat ng kinakailangang opsyon, bahagi, at sukat. Kung gusto niya ng pagsubok sa pagganap, maaari siyang kumuha ng higit pang mga pagkakataon. Kung kailangan lang niyang suriin kung may bubukas na form, maaari siyang magsimula sa minimum na sahod. At ipahiwatig din kung kailangan ang isang kumpol o hindi, atbp.
At pagkatapos ay itinulak ni Jenkins ang isang script ng shell, na bahagyang binago ang code sa folder ng Terraform. Inalis ko ang mga hindi kinakailangang file at nagdagdag ng mga kinakailangang file. At pagkatapos ay sa isang run ng Terraform apply ang stack ay itinaas.
At pagkatapos ay may iba pang mga hakbang na hindi ko gustong pumasok.
Dahil sa katotohanan na para sa pagsubok kailangan namin ng kaunti pang mga opsyon kaysa sa produksyon, kinailangan naming gumawa ng mga kopya ng mga module upang sa mga kopyang ito maidagdag namin ang mga feature na kailangan lang para sa pagsubok.
At nangyari na sa pagsubok ay gusto kong subukan ang mga pagbabagong iyon na sa kalaunan ay mapupunta sa produksyon. Ngunit sa katunayan, isang bagay ang nasubok, at isang bahagyang naiiba ang ginamit sa produksyon. At nagkaroon ng maliit na break sa pattern na sa produksyon lahat ng mga pagbabago ay inilapat ng operation team. At kung minsan ay lumabas na ang mga pagbabagong iyon na dapat pumunta mula sa pagsubok hanggang sa paggawa ay nanatili sa ibang bersyon.
Bilang karagdagan, nagkaroon ng ganoong problema kung kaya't may idinagdag na bagong serbisyo, na bahagyang naiiba sa ilang umiiral na. At sa halip na baguhin ang isang umiiral na module, kailangan naming gumawa ng kopya nito at idagdag ang mga kinakailangang pagbabago.
Sa esensya, ang Terraform ay hindi isang tunay na wika. Ito ay isang deklarasyon. Kung kailangan nating ipahayag ang isang bagay, pagkatapos ay ipahayag natin ito. At lahat ng ito ay gumagana.
Sa isang punto, nang ang isa sa aking mga kahilingan sa paghila ay tinatalakay, sinabi ng isa sa aking mga kasamahan na hindi na kailangang gumawa ng mga snowflake. Napaisip ako kung ano ang ibig niyang sabihin. Mayroong siyentipikong katotohanan na walang dalawang magkaparehong snowflake sa mundo, lahat sila ay bahagyang naiiba. At sa sandaling marinig ko ito, naramdaman ko kaagad ang buong bigat ng Terraform code. Dahil kapag kinailangang lumipat mula sa bersyon patungo sa bersyon, kinailangan ng Terraform ang mga pagbabago sa breaking chain, ibig sabihin, hindi na tugma ang code sa susunod na bersyon. At kinailangan naming gumawa ng pull request, na sumasakop sa halos kalahati ng mga file sa imprastraktura, upang dalhin ang imprastraktura sa susunod na bersyon ng Terraform.
At pagkatapos lumitaw ang gayong snowflake, ang lahat ng Terraform code na ginawa namin ay naging isang malaking, malaking tumpok ng niyebe.
Para sa isang external na developer na nasa labas ng operasyon, hindi ito mahalaga sa kanya, dahil gumawa siya ng pull request, nagsimula ang kanyang resource. At iyon nga lang, hindi na niya iyon pinagkakaabalahan. At ang koponan ng DevOps, na tinitiyak na OK ang lahat, ay kinakailangang gawin ang lahat ng mga pagbabagong ito. At ang halaga ng mga pagbabagong ito ay tumaas nang husto sa bawat karagdagang snowflake.
May kwento kung paano gumuhit ang isang estudyante sa isang seminar ng dalawang perpektong bilog na may chalk sa pisara. At ang guro ay nagulat kung paano niya nagawang gumuhit nang maayos nang walang compass. Sumagot ang estudyante: βNapakasimple, dalawang taon akong nasa hukbo sa paggawa ng gilingan ng karne.β
At sa apat na taon na kasali ako sa proyektong ito, halos dalawang taon na akong gumagawa ng Terraform. At, siyempre, mayroon akong ilang mga trick, ilang payo kung paano gawing simple ang Terraform code, magtrabaho kasama ito tulad ng isang programming language at bawasan ang pasanin sa mga developer na dapat panatilihing napapanahon ang code na ito.
Ang unang bagay na gusto kong simulan ay ang Symlinks. Ang Terraform ay may maraming paulit-ulit na code. Halimbawa, ang tawag sa provider sa halos bawat punto kung saan tayo gumagawa ng isang piraso ng imprastraktura ay pareho. At makatuwirang ilagay ito sa isang hiwalay na folder. At saanman kinakailangan ng provider na gumawa ng Symlinks sa file na ito.
Halimbawa, sa produksyon ay gumagamit ka ng assume role, na nagbibigay-daan sa iyong makakuha ng mga karapatan sa pag-access sa ilang panlabas na Amazon account. At sa pagbabago ng isang file, ang lahat ng natitira sa resource tree ay magkakaroon ng mga kinakailangang karapatan upang malaman ng Terraform kung aling bahagi ng Amazon ang maa-access.
Saan nabigo ang Symlinks? Tulad ng sinabi ko, ang Terraform ay may mga state file. At sila ay napaka, napaka-cool. Ngunit ang bagay ay pinasimulan ng Terraform ang backend sa pinakaunang lugar. At hindi siya maaaring gumamit ng anumang mga variable sa mga parameter na ito; dapat silang palaging nakasulat sa teksto.
At bilang resulta, kapag may gumawa ng bagong mapagkukunan, kinokopya niya ang ilan sa mga code mula sa ibang mga folder. At maaaring magkamali siya sa susi o sa balde. Halimbawa, gumagawa siya ng sandbox na bagay mula sa sandbox, at pagkatapos ay ginagawa ito sa produksyon. At kaya maaaring lumabas na ang balde sa produksyon ay gagamitin mula sa sandbox. Siyempre, mahahanap nila ito nang mabilis. Magiging posible na ayusin ito kahit papaano, ngunit gayunpaman ito ay isang pag-aaksaya ng oras at, sa ilang mga lawak, mga mapagkukunan.
Ano ang susunod nating gagawin? Bago magtrabaho sa Terraform, kailangan mong simulan ito. Sa pagsisimula, dina-download ng Terraform ang lahat ng plugin. Sa ilang mga punto, nahati sila mula sa isang monolith patungo sa isang mas microservice na arkitektura. At palagi mong kailangang gawin ang Terraform init upang makuha nito ang lahat ng mga module, lahat ng mga plugin.
At maaari kang gumamit ng script ng shell, na, una, ay makakakuha ng lahat ng mga variable. Ang script ng shell ay hindi limitado sa anumang paraan. At, pangalawa, ang mga landas. Kung palagi nating ginagamit ang landas na nasa repositoryo bilang susi sa file ng estado, kung gayon, nang naaayon, ang error dito ay aalisin.
Saan ko makukuha ang data? JSON file. Binibigyang-daan ka ng Terraform na magsulat ng imprastraktura hindi lamang sa hcl (HashiCorp Configuration Language), kundi pati na rin sa JSON.
Ang JSON ay madaling basahin mula sa isang shell script. Alinsunod dito, maaari mong ilagay ang configuration file na may bucket sa ilang lugar. At gamitin ang bucket na ito pareho sa Terraform code at sa shell script para sa pagsisimula.
Bakit mahalagang magkaroon ng balde para sa Terraform? Dahil mayroong isang bagay tulad ng mga malayuang file ng estado. Iyon ay, kapag nagtaas ako ng ilang mapagkukunan, upang sabihin sa Amazon: "Mangyaring itaas ang halimbawa," kailangan kong tukuyin ang maraming kinakailangang mga parameter.
At ang mga identifier na ito ay nakaimbak sa ibang folder. At maaari akong pumunta at sabihin: "Terraform, mangyaring tumakbo sa file ng estado ng mismong mapagkukunang iyon at kunin sa akin ang mga pagkakakilanlan na ito." At sa gayon ay lumilitaw ang isang tiyak na pagkakaisa sa pagitan ng iba't ibang rehiyon o kapaligiran.
Hindi laging posible na gumamit ng isang malayuang file ng estado. Halimbawa, gumawa ka ng VPC sa pamamagitan ng kamay. At ang Terraform code na lumilikha ng VPC ay lumilikha ng iba't ibang VPC na aabutin ng napakatagal at kailangan mong ayusin ang isa sa isa, para magamit mo ang sumusunod na trick.
Iyon ay, gumawa ng isang module na tila gumagawa ng isang VPC at, tulad ng dati, ay nagbibigay sa iyo ng mga identifier, ngunit sa katunayan mayroon lamang isang file na may mga hardcoded na halaga na maaaring magamit upang lumikha ng parehong halimbawa.
Hindi palaging kinakailangan na i-save ang state file sa cloud. Halimbawa, kapag sumusubok sa mga module, maaari mong gamitin ang pagsisimula ng backend, kung saan ise-save lang ang file sa disk sa oras ng pagsubok.
Ngayon ng kaunti tungkol sa pagsubok. Ano ang maaari mong subukan sa Terraform? Marahil marami ang posible, ngunit pag-uusapan ko ang 4 na bagay na ito.
May pag-unawa ang HashiCorp sa kung paano dapat i-format ang Terraform code. At pinapayagan ka ng Terraform fmt na i-format ang code na iyong ine-edit ayon sa paniniwalang ito. Alinsunod dito, kinakailangang suriin ng mga pagsubok kung ang pag-format ay tumutugma sa ipinamana ng HashiCorp, upang hindi na kailangang baguhin ang lokasyon ng mga bracket, atbp.
Ang susunod ay ang Terraform validate. Ito ay higit pa sa pagsuri sa syntax - ala, kung ang lahat ng panaklong ay ipinares. Ano ang mahalaga dito? Napakalawak ng ating imprastraktura. Mayroong maraming iba't ibang mga tatay sa loob nito. At sa bawat kailangan mong patakbuhin ang Terraform validate.
Alinsunod dito, upang mapabilis ang pagsubok, nagpapatakbo kami ng maraming proseso nang magkatulad gamit ang parallel.
Parallel ay isang napaka-cool na bagay, gamitin ito.
Ngunit sa tuwing magsisimula ang Terraform, pupunta ito sa HashiCorp at magtatanong, "Ano ang mga pinakabagong bersyon ng plugin? At ang plugin na mayroon ako sa cache - ito ba ang tama o mali?" At ito ay bumagal sa bawat hakbang.
Kung sasabihin mo sa Terraform kung nasaan ang mga plugin, sasabihin ng Terraform: "Okay, ito marahil ang pinakabagong bagay na naroroon. Hindi ako pupunta kahit saan, sisimulan ko agad ang pagpapatunay ng Terraform code mo."
Upang mapunan ang folder ng mga kinakailangang plugin, mayroon kaming napakasimpleng Terraform code na kailangan lang masimulan. Dito, siyempre, kailangan mong tukuyin ang lahat ng mga provider na kahit papaano ay lumalahok sa iyong code, kung hindi, sasabihin ng Terraform: "Hindi ko kilala ang isang partikular na provider dahil wala ito sa cache."
Susunod ay ang Terraform plan. Gaya nga ng sabi ko, cyclical ang development. Gumagawa kami ng mga pagbabago sa code. At pagkatapos ay kailangan mong malaman kung anong mga pagbabago ang binalak para sa imprastraktura.
At kapag ang imprastraktura ay napakalaki, maaari mong baguhin ang isang module, ayusin ang ilang pagsubok na kapaligiran o ilang partikular na rehiyon at sirain ang ilang kalapit na isa. Samakatuwid, ang planong Terraform ay dapat gawin para sa buong imprastraktura at ipakita kung anong mga pagbabago ang pinaplano.
Magagawa mo ito nang matalino. Halimbawa, nagsulat kami ng script ng Python na nagre-resolve ng mga dependencies. At depende sa kung ano ang nabago: isang Terraform module o isang partikular na bahagi lamang, ito ay gumagawa ng mga plano para sa lahat ng mga nakadependeng folder.
Ang mga plano sa terraform ay dapat gawin kapag hiniling. At least yun ang ginagawa namin.
Siyempre, magandang gawin ang mga pagsubok para sa bawat pagbabago, para sa bawat pangako, ngunit ang mga plano ay medyo isang mamahaling bagay. At sa isang pull request sasabihin namin, "Pakibigay sa akin ang mga plano." Nagsisimula ang robot. At nagpapadala ng mga komento o ilakip ang lahat ng mga plano na inaasahan mula sa iyong mga pagbabago.
Ang isang plano ay medyo isang mamahaling bagay. Ito ay tumatagal ng oras dahil ang Terraform ay pumupunta sa Amazon at nagtanong, "Mayroon pa bang pagkakataong ito? Ang autoscale ba na ito ay may eksaktong parehong mga parameter?" At para mapabilis ito, maaari kang gumamit ng parameter tulad ng refresh=false. Nangangahulugan ito na ang Terraform ay magda-download ng estado mula sa S3. At ito ay maniniwala na ang estado ay eksaktong tumutugma sa kung ano ang nasa Amazon.
Ang nasabing plano ng Terraform ay mas mabilis, ngunit ang estado ay dapat na tumutugma sa iyong imprastraktura, ibig sabihin, sa isang lugar, minsan ang pag-refresh ng Terraform ay dapat magsimula. Eksaktong ginagawa iyon ng pag-refresh ng Terraform: tumutugma ang estado sa kung ano ang nasa aktwal na imprastraktura.
At kailangan nating pag-usapan ang tungkol sa kaligtasan. Ito ay kung saan kailangan naming magsimula. Kung saan ka nagpapatakbo ng Terraform at tumatakbo ang Terraform sa iyong imprastraktura mayroong isang kahinaan. Iyon ay, mahalagang ipinapatupad mo ang code. At kung ang pull request ay naglalaman ng ilang uri ng malisyosong code, maaari itong isagawa sa isang imprastraktura na may masyadong maraming access. Kaya mag-ingat kung saan mo pinapatakbo ang Terraform plan.
Ang susunod na bagay na gusto kong pag-usapan ay ang pagsubok ng data ng gumagamit.
Ano ang user-data? Sa Amazon, kapag gumawa kami ng isang instance, maaari kaming magpadala ng isang partikular na sulat na may instance - meta data. Kapag nagsimula ang instance, kadalasan ang cloud init ay palaging naroroon sa mga pagkakataong ito. Binasa ni Cloud init ang liham na ito at sinabing: "OK, ngayon ako ang load balancer." At alinsunod sa mga tipan na ito ay nagsasagawa siya ng ilang mga aksyon.
Ngunit, sa kasamaang-palad, kapag ginawa namin ang Terraform plan at inilapat ang Terraform, ang data ng user ay mukhang ganitong uri ng mga numero. Ibig sabihin, pinapadala lang niya sa iyo ang hash. At ang lahat ng maaari mong tingnan sa plano ay kung magkakaroon ng anumang mga pagbabago o kung ang hash ay mananatiling pareho.
At kung hindi mo ito papansinin, ang ilang sirang text file ay maaaring mapunta sa Amazon, sa totoong imprastraktura.
Bilang kahalili, kapag nagpapatupad, maaari mong tukuyin hindi ang buong imprastraktura, ngunit ang template lamang. At sa code sabihin: "Pakipakita ang template na ito sa aking screen." At bilang isang resulta, maaari kang makakuha ng isang printout ng kung ano ang magiging hitsura ng iyong data sa Amazon.
Ang isa pang pagpipilian ay ang paggamit ng isang module upang makabuo ng data ng gumagamit. Ilalapat mo ang modyul na ito. Natanggap mo ang file sa disk. Ihambing ito sa sanggunian. At sa gayon, kung ang ilang tao ay nagpasya na iwasto nang kaunti ang data ng gumagamit, ang iyong mga pagsubok ay magsasabi: "OK, mayroong ilang mga pagbabago dito at doon - ito ay normal."
Ang susunod na bagay na gusto kong pag-usapan ay ang Automate Terraform apply.
Siyempre, medyo nakakatakot na gawin ang Terraform na mag-apply sa awtomatikong mode, dahil sino ang nakakaalam kung anong mga pagbabago ang dumating doon at kung gaano ito mapanira para sa buhay na imprastraktura.
Para sa isang kapaligiran ng pagsubok, ito ay normal. Iyon ay, isang trabaho na lumilikha ng isang kapaligiran sa pagsubok ang kailangan ng lahat ng mga developer. At ang ekspresyong tulad ng "nagtrabaho ang lahat para sa akin" ay hindi isang nakakatawang meme, ngunit patunay na ang isang tao ay nalito, nagtaas ng stack, at nagpatakbo ng ilang pagsubok sa stack na ito. At tiniyak niyang maayos ang lahat doon at sinabing: "Okay, nasubok na ang code na inilalabas ko."
Sa produksyon, sandbox at iba pang kapaligiran na mas kritikal sa negosyo, maaari mong bahagyang gumamit ng ilang mapagkukunan nang ligtas dahil hindi ito nagreresulta sa sinumang namamatay. Ito ay: mga autoscale na grupo, mga grupo ng seguridad, mga tungkulin, ruta53, at ang listahan doon ay maaaring masyadong malaki. Ngunit bantayan kung ano ang nangyayari, basahin ang mga ulat ng awtomatikong aplikasyon.
Kung saan mapanganib o nakakatakot na mag-apply, halimbawa, kung ito ay ilang patuloy na mapagkukunan mula sa isang database, pagkatapos ay makatanggap ng mga ulat na may mga hindi nailapat na pagbabago sa ilang bahagi ng imprastraktura. At ang inhinyero, sa ilalim ng pangangasiwa, ay nagsisimula ng mga trabaho upang mag-aplay o gawin ito mula sa kanyang console.
Ang Amazon ay may isang bagay tulad ng Proteksyon ng Wakasan. At maaari itong maprotektahan sa ilang mga kaso mula sa mga pagbabago na hindi kinakailangan para sa iyo. Iyon ay, pumunta si Terraform sa Amazon at sinabing: "Kailangan kong patayin ang pagkakataong ito upang makagawa ng isa pa." At sinabi ng Amazon: "Paumanhin, hindi ngayon. Mayroon kaming proteksyon ng Terminate."
At ang icing sa cake ay ang pag-optimize ng code. Kapag nagtatrabaho kami sa Terraform code, kailangan naming magpasa ng napakalaking bilang ng mga parameter sa module. Ito ang mga parameter na kinakailangan upang lumikha ng ilang uri ng mapagkukunan. At ang code ay nagiging malalaking listahan ng mga parameter na kailangang maipasa mula sa module hanggang sa module, mula sa module hanggang sa module, lalo na kung ang mga module ay naka-nest.
At napakahirap basahin. Napakahirap suriin ito. At madalas na lumalabas na ang ilang mga parameter ay sumasailalim sa pagsusuri at hindi sila eksakto kung ano ang kinakailangan. At ito ay nagkakahalaga ng oras at pera upang ayusin sa ibang pagkakataon.
Samakatuwid, iminumungkahi ko na gamitin mo ang isang bagay bilang isang kumplikadong parameter na kinabibilangan ng isang tiyak na puno ng mga halaga. Iyon ay, kailangan mo ng isang uri ng folder kung saan mayroon ka ng lahat ng mga halaga na nais mong magkaroon sa ilang kapaligiran.
At sa pamamagitan ng pagtawag sa module na ito, makakakuha ka ng isang puno na nabuo sa isang karaniwang module, iyon ay, sa isang karaniwang module na gumagana nang pareho para sa buong imprastraktura.
Sa modyul na ito maaari kang gumawa ng ilang mga kalkulasyon gamit ang isang kamakailang tampok sa Terraform bilang mga lokal. At pagkatapos, sa isang output, magbigay ng ilang kumplikadong parameter, na maaaring magsama ng mga hashes ng array, atbp.
Dito natapos ang lahat ng pinakamahusay na nahanap ko. At gusto kong magkuwento tungkol kay Columbus. Nang siya ay naghahanap ng pera para sa kanyang ekspedisyon upang matuklasan ang India (tulad ng iniisip niya noon), walang naniwala sa kanya at naisip nila na imposible ito. Pagkatapos ay sinabi niya: "Siguraduhing hindi mahulog ang itlog." Ang lahat ng mga bangkero, napakayaman at malamang na matalinong mga tao, ay sinubukan na kahit papaano ay ilagay ang itlog, at ito ay patuloy na bumagsak. Pagkatapos ay kinuha ni Columbus ang itlog at pinindot ito ng kaunti. Nalukot ang shell at nanatiling hindi gumagalaw ang itlog. Sabi nila, "Naku, napakadali!" At sumagot si Columbus: "Oo, ito ay masyadong simple. At kapag binuksan ko ang India, lahat ay gagamit ng rutang ito ng kalakalan."
At ang sinabi ko lang sa iyo ay malamang na medyo simple at walang kuwentang bagay. At kapag natutunan mo ang tungkol sa mga ito at nagsimulang gamitin ang mga ito, ito ay nasa pagkakasunud-sunod ng mga bagay. Kaya samantalahin. At kung ito ay ganap na normal na mga bagay para sa iyo, at least alam mo kung paano ilagay ang itlog upang hindi ito mahulog.
Sumang-ayon tayo:
- Subukang iwasan ang mga snowflake. At ang mas kaunting mga snowflake, mas kaunting mga mapagkukunan ang kakailanganin mong gumawa ng anumang mga pagbabago sa iyong malaking imprastraktura.
- Patuloy na pagbabago. Ibig sabihin, kapag naganap ang ilang pagbabago sa code, kailangan mong dalhin ang iyong imprastraktura sa pagsunod sa mga pagbabagong ito sa lalong madaling panahon. Hindi dapat magkaroon ng sitwasyon kung saan ang isang tao ay dumarating upang tingnan ang Elasticsearch pagkalipas ng dalawa o tatlong buwan, gagawa ng plano ng Terraform, at mayroong isang grupo ng mga pagbabago na hindi niya inaasahan. At nangangailangan ng maraming oras upang maibalik ang lahat sa ayos.
- Mga pagsubok at automation. Kung mas sakop ng mga pagsubok at feature ang iyong code, mas may kumpiyansa ka na ginagawa mo nang tama ang lahat. At ang awtomatikong paghahatid ay tataas ang iyong kumpiyansa nang maraming beses.
- Ang code para sa pagsubok at mga kapaligiran ng produksyon ay dapat na halos pareho. Sa praktikal, dahil ang produksyon ay medyo naiiba pa rin at magkakaroon pa rin ng ilang mga nuances na lalampas sa kapaligiran ng pagsubok. Ngunit gayunpaman, plus o minus, ito ay masisiguro.
- At kung marami kang Terraform code at nangangailangan ng maraming oras upang panatilihing napapanahon ang code na ito, hindi pa huli ang lahat para muling i-refactor at makuha ito sa mabuting kalagayan.
- Hindi nababagong imprastraktura. Paghahatid ng AMI sa iskedyul.
- Structure para sa route53 kapag marami kang entry at gusto mong maging pare-pareho ang pagkakasunod-sunod ng mga ito.
- Labanan ang mga limitasyon sa rate ng API. Ito ay kapag sinabi ng Amazon, "Iyon lang, hindi na ako makakatanggap ng anumang mga kahilingan, mangyaring maghintay." At kalahati ng opisina ay naghihintay hanggang sa mailunsad nito ang imprastraktura nito.
- Spot instance. Ang Amazon ay hindi isang murang kaganapan at nagbibigay-daan sa iyo ang mga spot na makatipid nang malaki. At doon maaari mong sabihin ang isang buong ulat tungkol dito.
- Mga tungkulin sa seguridad at IAM.
- Naghahanap ng mga nawawalang mapagkukunan, kapag mayroon kang mga pagkakataon na hindi alam ang pinagmulan sa Amazone, kumakain sila ng pera. Kahit na ang mga pagkakataon ay nagkakahalaga ng $100-150 bawat buwan, iyon ay higit sa $1 bawat taon. Ang paghahanap ng gayong mga mapagkukunan ay isang kumikitang negosyo.
- At mga nakalaan na pagkakataon.
Para sa akin lang yan. Napaka-cool ng Terraform, gamitin mo ito. Salamat!
mga katanungan
Salamat sa ulat! Ang iyong state file ay nasa S3, ngunit paano mo malulutas ang problema na maaaring kunin ng ilang tao ang state file na ito at subukang palawakin?
Una sa lahat, hindi kami nagmamadali. Pangalawa, may mga flag, kung saan iniuulat namin na gumagawa kami ng ilang piraso ng code. Iyon ay, sa kabila ng katotohanan na ang imprastraktura ay napakalaki, hindi ito nangangahulugan na ang isang tao ay patuloy na gumagamit ng isang bagay. At kapag nagkaroon ng aktibong yugto, ito ay isang problema; nag-imbak kami ng mga state file sa Git. Mahalaga ito, kung hindi, may gagawa ng state file, at kailangan naming manu-manong pagsama-samahin ang mga ito para magpatuloy ang lahat. Ngayon ay walang ganoong problema. Sa pangkalahatan, nalutas ng Terraform ang problemang ito. At kung ang isang bagay ay patuloy na nagbabago, maaari kang gumamit ng mga kandado, na pumipigil sa iyong sinabi.
Gumagamit ka ba ng open source o enterprise?
Walang negosyo, ibig sabihin, lahat ng maaari mong puntahan at i-download nang libre.
Ang pangalan ko ay Stanislav. Nais kong gumawa ng isang maliit na karagdagan. Nag-usap ka tungkol sa isang feature ng Amazon na nagbibigay-daan sa iyong gawin ang isang instance na hindi mapatay. Ito rin ay nasa Terraform mismo; sa Life Second block maaari mong tukuyin ang pagbabawal sa mga pagbabago o pagbabawal sa pagsira.
Limitado ang oras. Magandang punto.
Dalawang bagay din ang gusto kong itanong. Una, pinag-usapan mo ang pagsubok. Gumamit ka ba ng anumang mga tool sa pagsubok? Narinig ko ang tungkol sa Test Kitchen plugin. Baka may iba pa. At gusto ko rin magtanong tungkol sa Local Values. Paano sila pangunahing naiiba sa Mga Variable ng Input? At bakit hindi ko ma-parameter ang isang bagay sa pamamagitan lang ng Local Values? Sinubukan kong alamin ang paksang ito, ngunit sa paanuman ay hindi ko maisip ito sa aking sarili.
Maaari tayong mag-usap nang mas detalyado sa labas ng silid na ito. Ang aming mga tool sa pagsubok ay ganap na ginawa sa sarili. Walang anumang bagay doon upang subukan. Sa pangkalahatan, may mga opsyon kapag kinuha ng mga awtomatikong pagsubok ang imprastraktura sa isang lugar, tingnan kung OK ito, at pagkatapos ay sirain ang lahat gamit ang isang ulat na ang iyong imprastraktura ay nasa mabuting kalagayan pa rin. Wala kaming ganito dahil pinapatakbo ang mga test stack araw-araw. At sapat na iyon. At kung magsisimulang masira ang isang bagay, magsisimula itong masira nang hindi natin ito sinusuri sa ibang lugar.
Tungkol sa Local Values, ituloy natin ang pag-uusap sa labas ng kwarto.
Kamusta! Salamat sa ulat! Napaka informative. Sinabi mo na marami kang kaparehong uri ng code upang ilarawan ang imprastraktura. Naisipan mo bang bumuo ng code na ito?
Mahusay na tanong, salamat! Ang punto ay kapag ginamit namin ang imprastraktura bilang code, ipinapalagay namin na tinitingnan namin ang code at nauunawaan kung anong imprastraktura ang nasa likod ng code na iyon. Kung nabuo ang code, kailangan nating isipin kung anong code ang bubuo upang maunawaan kung anong uri ng imprastraktura ang naroroon. Alinman sa bumuo kami ng code, i-commit ito, at mahalagang pareho ang nangyayari. Kaya sinundan namin ang landas na aming isinulat, nakuha namin ito. Lumitaw ang mga plus generator nang ilang sandali nang sinimulan naming gawin ang mga ito. At huli na para magbago.
May narinig ka na ba tungkol sa jsonnet?
Hindi.
Tingnan mo, ito ay isang napaka-cool na bagay. Nakikita ko ang isang partikular na kaso kung saan maaari mong ilapat ito at bumuo ng istraktura ng data.
Ang mga generator ay mabuti kapag mayroon ka nito, tulad ng sa biro tungkol sa isang shaving machine. Iyon ay, sa unang pagkakataon na ang mukha ay naiiba, ngunit pagkatapos ay lahat ay may parehong mukha. Ang mga generator ay gumagana nang mahusay. Ngunit, sa kasamaang palad, ang aming mga mukha ay bahagyang naiiba. Problema ito.
Tingnan mo lang. Salamat!
Ang pangalan ko ay Maxim, ako ay mula sa Sberbank. Nag-usap ka ng kaunti tungkol sa kung paano mo sinusubukang dalhin ang Terraform sa katumbas ng isang programming language. Hindi ba mas madaling gamitin ang Ansible?
Ang mga ito ay ibang-iba. Maaari kang lumikha ng mga mapagkukunan sa Ansible, at ang Puppet ay maaaring lumikha ng mga mapagkukunan sa Amazon. Ngunit ang Terraform ay diretsong pinatalas.
Amazona lang ba ang meron ka?
Hindi yung Amazon lang meron tayo. Halos Amazon lang ang meron tayo. Ngunit ang pangunahing tampok ay naaalala ng Terraform. Sa Ansible, kung sasabihin mo: "Bigyan mo ako ng 5 pagkakataon," tataas ito, at pagkatapos ay sasabihin mo: "At ngayon kailangan ko ng 3." At sasabihin ng Terraform: "Okay, papatayin ko ang 2," at sasabihin ng Ansible: "Okay, narito ang 3 para sa iyo." Kabuuan 8.
Kamusta! Salamat sa iyong ulat! Napaka-interesante na marinig ang tungkol sa Terraform. Gusto kong agad na gumawa ng isang maliit na komento tungkol sa katotohanan na ang Terraform ay wala pa ring matatag na paglabas, kaya't ituring ang Terraform nang may matinding pag-iingat.
Isang magandang kutsara para sa hapunan. Iyon ay, kung kailangan mo ng isang solusyon, kung minsan ay ipagpaliban mo kung ano ang hindi matatag, atbp., ngunit ito ay gumagana at nakatulong ito sa amin.
Ang tanong ay ito. Gumagamit ka ng Remote backend, gumagamit ka ng S 3. Bakit hindi mo gamitin ang opisyal na backend?
Opisyal?
Terraform Cloud.
Kailan siya nagpakita?
Mga 4 na buwan na ang nakalipas.
Kung ito ay lumitaw 4 na taon na ang nakakaraan, malamang nasagot ko na ang iyong tanong.
Mayroon nang built-in na function at mga lock, at maaari kang mag-imbak ng state file. Subukan. Pero hindi ko pa nasubukan.
Kami ay naglalakbay sa isang malaking tren na kumikilos nang napakabilis. At hindi ka maaaring kumuha ng ilang kotse at itapon ang mga ito.
Nagsalita ka tungkol sa mga snowflake, bakit hindi ka gumamit ng sanga? Bakit hindi ito gumana sa ganoong paraan?
Ang aming diskarte ay ang buong imprastraktura ay nasa isang imbakan. Terraform, Puppet, lahat ng mga script na kahit papaano ay nauugnay dito, lahat sila ay nasa isang repository. Sa ganitong paraan, masisiguro natin na ang mga incremental na pagbabago ay susubok nang paisa-isa. Kung ito ay isang grupo ng mga sanga, kung gayon ang gayong proyekto ay halos imposible na mapanatili. Lumipas ang anim na buwan, at magkaiba sila nang labis na ito ay isang uri lamang ng parusa. Ito ang gusto kong takasan bago mag-refactor.
Kaya hindi ito gumagana?
Ito ay hindi gumagana sa lahat.
Sa sangay ay pinutol ko ang slide ng folder. Iyon ay, kung gagawin mo ito para sa bawat test stack, halimbawa, ang team A ay may sariling folder, ang team B ay may sariling folder, kung gayon hindi rin ito gagana. Gumawa kami ng pinag-isang code ng environment ng pagsubok na sapat na flexible para umangkop sa lahat. Ibig sabihin, nagsilbi kami ng isang code.
Kamusta! Yura ang pangalan ko! Salamat sa ulat! Tanong tungkol sa mga module. Sinasabi mo na gumagamit ka ng mga module. Paano mo lulutasin ang isyu kung ang mga pagbabago ay ginawa sa isang module na hindi tugma sa pagbabago ng ibang tao? Ikaw ba ay kahit papaano ay nagbe-bersyon ng mga module o sinusubukang magdala ng isang wunderwaffle upang matugunan ang dalawang kinakailangan?
Ito ay isang malaking problema sa snow pile. Ito ang dinaranas natin kapag ang ilang hindi nakapipinsalang pagbabago ay maaaring masira ang ilang bahagi ng imprastraktura. At ito ay mapapansin lamang pagkatapos ng mahabang panahon.
Ibig sabihin, hindi pa nareresolba?
Gumagawa ka ng mga unibersal na module. Iwasan ang mga snowflake. At lahat ay gagana. Ang ikalawang kalahati ng ulat ay tungkol sa kung paano ito maiiwasan.
Kamusta! Salamat sa ulat! Gusto kong linawin. Sa likod ng mga eksena ay may malaking tumpok na pinuntahan ko. Paano pinagsama-sama ang puppet at pamamahagi ng tungkulin?
User-data.
Ibig sabihin, iniluwa mo lang ang file at kahit papaano ay i-execute ito?
Ang data ng user ay isang tala, ibig sabihin, kapag gumawa kami ng isang clone ng imahe, si Daemon ay bumangon doon at, sinusubukang malaman kung sino siya, binabasa ang tala na siya ay isang load balancer.
Ibig sabihin, ito ba ay isang uri ng hiwalay na proseso na ibinibigay?
Hindi namin ito inimbento. Ginagamit namin ito.
Kamusta! May tanong lang ako tungkol sa User - data. Sabi mo may mga problema doon, baka may magpadala sa maling lugar. Mayroon bang ilang paraan upang mag-imbak ng data ng user sa parehong Git, upang laging malinaw kung ano ang tinutukoy ng User-data?
Bumubuo kami ng User-data mula sa template. Iyon ay, isang tiyak na bilang ng mga variable ang ginagamit doon. At binubuo ng Terraform ang huling resulta. Samakatuwid, hindi mo maaaring tingnan lamang ang template at sabihin kung ano ang mangyayari, dahil ang lahat ng mga problema ay nauugnay sa katotohanan na iniisip ng developer na nagpapasa siya ng isang string sa variable na ito, ngunit isang array ang ginagamit doon. At siya - si bam at ako - si ganito-at-ganito, si ganito-at-ganoon, ang susunod na linya, at lahat ay nasira. Kung ito ay isang bagong mapagkukunan at kinuha ito ng isang tao at nakitang may hindi gumagana, pagkatapos ay mabilis itong naresolba. At kung ang autoscale group na ito ay na-update, pagkatapos ay sa ilang mga punto ang mga pagkakataon sa autoscale group ay magsisimulang mapalitan. At bang, may hindi gumagana. Masakit.
Ito ay lumabas na ang tanging solusyon ay ang pagsubok?
Oo, nakikita mo ang problema, nagdagdag ka ng mga hakbang sa pagsubok doon. Iyon ay, ang output ay maaari ding masuri. Maaaring hindi ito masyadong maginhawa, ngunit maaari ka ring maglagay ng ilang mga marka - tingnan kung ang User-data ay ipinako dito.
Ang pangalan ko ay Timur. Napakaganda na may mga ulat kung paano maayos na ayusin ang Terraform.
Hindi ko pa nasisimulan.
Sa tingin ko baka sa susunod na conference meron. Simpleng tanong ko. Bakit mo hardcoding ang halaga sa isang hiwalay na module sa halip na gumamit ng mga tfvar, ibig sabihin, bakit ang isang module na may mga halaga ay mas mahusay kaysa sa mga tfvar?
Ibig sabihin, dapat ba akong sumulat dito (slide: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork at stvars β maaari ko bang makuha ang parehong bagay?
Ganyan talaga ang ginagawa namin. Sumangguni kami sa module ng pinagmulan ng setting, halimbawa.
Mahalaga, ito ay tulad ng tfvars. Ang Tfvars ay napaka-maginhawa sa isang kapaligiran ng pagsubok. Mayroon akong tfvars para sa malalaking pagkakataon, para sa maliliit. At inihagis ko ang isang file sa folder. At nakuha ko ang gusto ko. Kapag tayo ay nagpuputol ng imprastraktura, gusto natin na matingnan at agad na maunawaan ang lahat. At kaya lumalabas na kailangan mong tumingin dito, pagkatapos ay tumingin sa tfvars.
Posible bang magkaroon ng lahat sa isang lugar?
Oo, ang tfvars ay kapag mayroon kang isang code. At ito ay ginagamit sa maraming iba't ibang mga lugar na may iba't ibang mga nuances. Pagkatapos ay magtapon ka ng mga tfvars at makuha ang iyong mga nuances. At tayo ay imprastraktura bilang code sa pinakadalisay nitong anyo. Tumingin ako at naintindihan.
Kamusta! Nakatagpo ka na ba ng mga sitwasyon kung saan nakikialam ang cloud provider sa ginawa mong Terraform? Sabihin nating ine-edit namin ang metadata. May mga ssh key. At patuloy na inilalagay ng Google ang metadata nito at ang mga susi nito doon. At palaging isinusulat ng Terraform na mayroon itong mga pagbabago. Pagkatapos ng bawat pagtakbo, kahit walang pagbabago, lagi niyang sinasabi na ia-update niya ang field na ito ngayon.
Sa mga susi, ngunit oo, ang bahagi ng imprastraktura ay apektado ng bagay na ito, ibig sabihin, hindi maaaring baguhin ng Terraform ang anuman. Hindi rin natin mababago ang anuman gamit ang ating mga kamay. Mabubuhay tayo dito sa ngayon.
Iyon ay, nakatagpo ka ng isang bagay na tulad nito, ngunit hindi nakabuo ng anuman, paano niya ito ginagawa at ginagawa ito sa kanyang sarili?
Sa kasamaang palad, oo.
Kamusta! Ang pangalan ko ay Starkov Stanislav. Mail. ru Pangkat. Paano mo malulutas ang problema sa pagbuo ng isang tag sa..., paano mo ito ipapasa sa loob? Sa pagkakaintindi ko, sa pamamagitan ng User - data para tukuyin ang pangalan ng host, itakda ang Puppet sa? At ang pangalawang bahagi ng tanong. Paano mo malulutas ang isyung ito sa SG, ibig sabihin, kapag nakabuo ka ng SG, daan-daang instance ng parehong uri, ano ang tamang pangalan para sa kanila?
Yung mga pagkakataong napakaimportante sa amin, maganda ang pangalan namin. Yung mga hindi kailangan, may note na autoscale group ito. At sa teorya maaari mo itong ipako at makakuha ng bago.
Kung tungkol sa problema sa tag, walang ganoong problema, ngunit mayroong ganoong gawain. At gumagamit kami ng mga tag nang napaka, napakabigat, dahil ang imprastraktura ay malaki at mahal. At kailangan nating tingnan kung saan napupunta ang pera, kaya pinapayagan tayo ng mga tag na masira kung ano ang napunta kung saan. At, ayon dito, ang paghahanap para sa isang bagay na nangangahulugang maraming pera ang ginugol dito.
Ano pa ang naging tanong?
Kapag ang SG ay lumikha ng daan-daang mga pagkakataon, kailangan ba silang makilala kahit papaano?
Hindi, huwag. Sa bawat pagkakataon mayroong isang ahente na nag-uulat na mayroon akong problema. Kung nag-ulat ang isang ahente, alam ng ahente ang tungkol sa kanya at, sa pinakamababa, umiiral ang kanyang IP address. Maaari ka nang tumakas. Pangalawa, ginagamit namin ang Consul for Discovery, kung saan wala ang Kubernetes. At ipinapakita din ng Consul ang IP address ng instance.
Iyon ay, partikular na nakatuon ka ba sa IP, at hindi sa pangalan ng host?
Imposibleng mag-navigate ayon sa pangalan ng host, ibig sabihin, marami sa kanila. May mga instance identifier - AE, atbp. Mahahanap mo ito sa isang lugar, maaari mo itong itapon sa paghahanap.
Kamusta! Napagtanto ko na ang Terraform ay isang magandang bagay, na pinasadya para sa mga ulap.
Hindi lang.
Ito mismo ang tanong na interesado ako. Kung magpasya kang lumipat, sabihin, sa Bare Metal nang maramihan kasama ang lahat ng iyong mga pagkakataon? Magkakaroon ba ng anumang mga problema? O kailangan mo pa bang gumamit ng iba pang mga produkto, halimbawa, ang parehong Ansible na nabanggit dito?
Ang Ansible ay kaunti tungkol sa ibang bagay. Ibig sabihin, gumagana na ang Ansible kapag nagsimula na ang instance. At gumagana ang Terraform bago magsimula ang instance. Lumipat sa Bare Metal - hindi.
Hindi ngayon, ngunit darating ang negosyo at sasabihin: "Halika."
Lumipat sa isa pang ulap - oo, ngunit mayroong isang bahagyang naiibang trick dito. Kailangan mong magsulat ng Terraform code sa paraang maaari kang lumipat sa ibang cloud na may kaunting pagsisikap.
Sa una, ang gawain ay itinakda na ang aming buong imprastraktura ay agnostic, ibig sabihin, anumang ulap ay dapat na angkop, ngunit sa isang punto ang negosyo ay sumuko at sinabi: "Okay, sa susunod na N taon ay hindi kami pupunta kahit saan, maaari kaming gumamit ng mga serbisyo mula sa Amazon"
Binibigyang-daan ka ng Terraform na lumikha ng mga trabaho sa Front-End, i-configure ang PagerDuty, data doc, atbp. Ito ay may maraming mga buntot. Halos kaya niyang kontrolin ang buong mundo.
Salamat sa ulat! Gumagamit din ako ng Terraform sa loob ng 4 na taon na ngayon. Sa yugto ng isang maayos na paglipat sa Terraform, sa imprastraktura, sa isang deklaratibong paglalarawan, nahaharap kami sa isang sitwasyon kung saan may gumagawa ng isang bagay sa pamamagitan ng kamay, at sinusubukan mong gumawa ng plano. At nagkaroon ako ng ilang uri ng pagkakamali doon. Paano mo haharapin ang mga ganitong problema? Paano mo mahahanap ang mga nawawalang mapagkukunan na nakalista?
Unang-una gamit ang ating mga kamay at mata, kung may nakikita tayong kakaiba sa ulat, pagkatapos ay sinusuri natin kung ano ang nangyayari doon, o tayo ay pumatay na lang. Sa pangkalahatan, ang mga kahilingan sa paghila ay isang pangkaraniwang bagay.
Kung may error, rollback ka ba? Nasubukan mo na bang gawin ito?
Hindi, ito ay desisyon ng isang tao sa sandaling nakakakita siya ng problema.
Pinagmulan: www.habr.com