Ŝajnus, ke la programistoj de Terraform ofertas sufiĉe oportunajn plej bonajn praktikojn por labori kun la AWS-infrastrukturo. Nur estas nuanco. Kun la tempo, la nombro da medioj pliiĝas, ecoj aperas en ĉiu. Aperas preskaŭ kopio de la aplikaĵa stako en la najbara regiono. Kaj la Terraform-kodo devas esti zorge kopiita kaj redaktita laŭ la novaj postuloj aŭ por fari neĝeron.
Mia raporto temas pri ŝablonoj en Terraform por kontraŭbatali kaoson kaj manan rutinon en grandaj kaj longaj projektoj.
Video:
Mi estas 40-jara, mi estas en IT dum 20 jaroj. Mi laboras ĉe Ixtens dum 12 jaroj. Ni okupiĝas pri disvolviĝo de elektronika komerco. Kaj mi praktikas DevOps-praktikojn dum 5 jaroj.
Mia rakonto estos pri la sperto en projekto en firmao, kies nomon mi ne diros, kaŝante malantaŭ nediskoniga interkonsento.
La nombroj sur la glito estas donitaj por kompreni la amplekson de la projekto. Kaj ĉio, kion mi diros poste, rilatas al Amazono.
Mi aliĝis al ĉi tiu projekto antaŭ 4 jaroj. Kaj la infrastruktura refaktorado estis en plena svingo, ĉar la projekto kreskis. Kaj tiuj ŝablonoj, kiuj estis uzitaj, ili ne plu taŭgas. Kaj konsiderante la tutan planitan kreskon de la projekto, estis necese elpensi ion novan.
Dankon al Matvey, kiu rakontis al ni hieraŭ, kio okazis ĉe Dodo Pizza. Jen kio okazis al ni antaŭ 4 jaroj.
Programistoj venis kaj komencis fari infrastrukturan kodon.
La plej evidentaj kialoj, kial ĉi tio estis postulata, estis tempo por merkati. Necesis certigi, ke la DevOps-teamo ne estis botelo dum la disvastigo. Kaj inter aliaj aĵoj, Terraform kaj Puppet estis uzitaj ĉe la plej unua nivelo.
Terraform estas malfermkoda projekto de HashiCorp. Kaj por tiuj, kiuj tute ne scias, kio ĝi estas, la sekvaj diapozitivoj.
Infrastrukturo kiel kodo signifas, ke ni povas priskribi nian infrastrukturon kaj peti iujn robotojn certigi, ke ni ricevas la rimedojn, kiujn ni priskribis.
Ekzemple, ni bezonas virtualan maŝinon. Ni priskribos, aldonos kelkajn postulatajn parametrojn.
Post tio, ni agordos aliron al Amazon en la konzolo. Kaj petu Terraform-planon. Terraform-plano diros: "Bone, por via rimedo, ni povas fari ĉi tiujn aferojn." Kaj almenaŭ unu rimedo estos aldonita. Kaj neniuj ŝanĝoj estas atenditaj.
Post kiam ĉio konvenas al vi, vi povas peti al Terraform apliki kaj Terraform kreos ekzemplon por vi, kaj vi ricevos virtualan maŝinon en via nubo.
Plue, nia projekto evoluas. Ni aldonas kelkajn ŝanĝojn tie. Ni petas pli da ekzemploj, ni aldonas 53 enskribojn.
Kaj ni ripetas. Bonvolu plani. Ni vidas, kiaj ŝanĝoj estas planitaj. Apliki. Kaj tiel nia infrastrukturo kreskas.
Terraform uzas tian aĵon kiel ŝtatdosierojn. Tio estas, ĝi konservas ĉiujn ŝanĝojn, kiuj iras al Amazon en dosiero, kie por ĉiu rimedo, kiun vi priskribis, estas respondaj rimedoj, kiuj estis kreitaj en Amazon. Tiel, kiam ŝanĝas la priskribon de rimedo, Terraform scias precize, kio devas esti ŝanĝita en Amazon.
Ĉi tiuj ŝtataj dosieroj estis origine nur dosieroj. Kaj ni konservis ilin en Git, kio estis ege maloportuna. Senĉese iu forgesis fari ŝanĝojn, kaj estis multaj konfliktoj.
Nun eblas uzi la backend, t.e. Terraform estas indikita en kiu sitelo, per kiu ŝlosilo la ŝtatdosiero estu konservita. Kaj Terraform mem zorgos ricevi ĉi tiun ŝtatan dosieron, farante la tutan magion kaj remeti la finan rezulton.
Nia infrastrukturo kreskas. Jen nia kodo. Kaj nun ni ne volas nur krei virtualan maŝinon, ni volas havi testan medion.
Terraform permesas al vi fari ion kiel modulon, t.e. priskribi la samon en iu dosierujo.
Kaj, ekzemple, en testado, voku ĉi tiun modulon kaj ricevu la samon kiel se ni farus aplikadon de Terraform en la modulo mem. Jen la kodo por testado.
Por produktado, ni povas sendi iujn ŝanĝojn tien, ĉar en testado ni ne bezonas grandajn okazojn, en produktado grandaj okazoj utilos.
Kaj poste mi reiros al la projekto. Estis malfacila tasko, la infrastrukturo estis planita tre granda. Kaj necesis iel meti la tutan kodon, por ke ĝi estu oportuna por ĉiuj: por tiuj, kiuj plenumas prizorgadon de ĉi tiu kodo, kaj por tiuj, kiuj faras ŝanĝojn. Kaj estis planite, ke ĉiu programisto povus iri kaj ripari la infrastrukturon laŭbezone por sia parto de la platformo.
Ĉi tio estas dosieruja arbo rekomendita de HashiCorp se vi havas grandan projekton kaj havas sencon dividi la tutan infrastrukturon en kelkajn malgrandajn pecojn, kaj priskribi ĉiun pecon en aparta dosierujo.
Havante ampleksan resursan bibliotekon, vi povas telefoni pri la sama afero en testado kaj en produktado.
En nia kazo, ĉi tio ne estis tute taŭga, ĉar la testa stako por programistoj aŭ por testado devis esti akirita iel pli simpla. Kaj mi ne volis trarigardi la dosierujojn kaj apliki en la ĝusta sinsekvo, kaj zorgi, ke la bazo altiĝos, kaj tiam la kazo, kiu uzas ĉi tiun bazon, altiĝos. Tial ĉiuj provoj estis lanĉitaj de unu dosierujo. La samaj moduloj estis nomitaj tie, sed ĉio trapasis en unu kuro.
Terraform prizorgas ĉiujn dependecojn. Kaj ĝi ĉiam kreas rimedojn en tiu sinsekvo tiel ke vi povas akiri IP-adreson, ekzemple, de ĵus kreita kazo, kaj akiri ĉi tiun IP-adreson en la eniro route53.
Krome, la platformo estas tre granda. Kaj ruli provan stakon, eĉ se dum horo, eĉ se dum 8 horoj, estas sufiĉe multekosta komerco.
Kaj ni aŭtomatigis ĉi tiun komercon. Kaj la laboro de Jenkins permesis al la stako kuri. Necesis lanĉi en ĝi tiran peton kun la ŝanĝoj, kiujn la programisto volas provi, specifi ĉiujn necesajn opciojn, komponantojn kaj grandecojn. Se li volas agadotestadon, tiam li povas preni pli da kazoj. Se li nur bezonas kontroli, ke iu formo malfermiĝas, li povus komenci ĉe la minimuma salajro. Kaj ankaŭ indiku ĉu areto necesas aŭ ne, ktp.
Kaj tiam Jenkins puŝis ŝelan skripton, kiu iomete modifis la kodon en la dosierujo Terraform. Forigis nenecesajn dosierojn, aldonis la necesajn dosierojn. Kaj tiam, kun unu kuro de Terraform apliki, la stako altiĝis.
Kaj tiam estis aliaj paŝoj, kiujn mi ne volas eniri.
Pro tio, ke por testado ni bezonis iom pli da ebloj ol en produktado, ni devis fari kopiojn de la moduloj por ke en ĉi tiuj kopioj ni povu aldoni tiujn funkciojn, kiuj estas bezonataj nur en testado.
Kaj okazis, ke en testado, ŝajnas, ke vi volas testi tiujn ŝanĝojn, kiuj poste iros al produktado. Sed fakte, unu afero estis provita, kaj iomete malsama estis uzata en produktado. Kaj estis malgranda rompo en la ŝablono, ke en produktado ĉiuj ŝanĝoj estis aplikitaj de la operacia teamo. Kaj foje montriĝis, ke tiuj ŝanĝoj, kiuj devis iri de testado al produktado, ili restis en alia versio.
Krome, estis tia problemo ke nova servo estis aldonita, kiu estis iomete malsama de iu ekzistanta. Kaj anstataŭ modifi ekzistantan modulon, vi devis fari kopion de ĝi kaj aldoni la necesajn ŝanĝojn.
Fakte, Terraform ne estas vera lingvo. Ĉi tio estas deklaro. Se ni bezonas deklari ion, tiam ni deklaras ĝin. Kaj ĉio funkcias.
Iam, diskutante pri unu el miaj tirpetoj, unu el miaj kolegoj diris, ke ne necesas produkti neĝerojn. Mi scivolis, kion li celis. Estas tia scienca fakto, ke en la mondo ne ekzistas du identaj neĝeroj, ili ĉiuj estas iomete, sed malsamaj. Kaj tuj kiam mi aŭdis tion, mi tuj sentis la plenan pezon de la Terraform-kodo. Ĉar kiam estis postulate moviĝi de versio al versio, Terraform postulis rompiĝan ĉenŝanĝon, t.e. la kodo ne plu estis kongrua kun la venonta versio. Kaj mi devis fari tirpeton, kiu kovris preskaŭ duonon de la dosieroj en la infrastrukturo, por alporti la infrastrukturon al la sekva versio de Terraform.
Kaj post kiam tia neĝfloko aperis, la tuta Terraform-kodo, kiun ni transformis en grandan, grandan amason da neĝo.
Por ekstera programisto, kiu estas ekster funkciado, ne multe gravas al li, ĉar li faris tiran peton, lia rimedo komenciĝis. Kaj jen, ĝi ne estas lia zorgo. Kaj la teamo DevOps, kiu certigas, ke ĉio estas en ordo, devas fari ĉiujn ĉi tiujn ŝanĝojn. Kaj la kosto de ĉi tiuj ŝanĝoj tre, tre multe pliiĝis kun ĉiu plia neĝero.
Estas rakonto pri kiel studento ĉe seminario desegnas du perfektajn cirklojn per kreto sur nigra tabulo. Kaj la instruisto estas surprizita, kiel li sukcesis desegni tiel glate sen kompaso. La studento respondas: "Estas tre simple, mi turnis viandan muelilon dum du jaroj en la armeo."
Kaj el la kvar jaroj kiam mi estis en ĉi tiu projekto, mi faras Terraform dum ĉirkaŭ du jaroj. Kaj, kompreneble, mi havas kelkajn lertaĵojn, kelkajn konsiletojn pri kiel simpligi la Terraform-kodon, labori kun ĝi kiel programlingvo kaj redukti la ŝarĝon de programistoj, kiuj devas konservi ĉi tiun kodon ĝisdatigita.
La unua afero, per kiu mi ŝatus komenci, estas Simligoj. Terraform havas multe da ripetema kodo. Ekzemple, voki provizanton ĉe preskaŭ ĉiu punkto kie ni kreas pecon de infrastrukturo estas la sama. Kaj estas logike meti ĝin en apartan paĉjon. Kaj kie ajn la provizanto estas postulata por fari Simligojn al ĉi tiu dosiero.
Ekzemple, vi uzas supozi rolon en produktado, kio permesas vin akiri alirrajtojn al iu ekstera Amazon-konto. Kaj ŝanĝante unu dosieron, ĉiuj ceteraj, kiuj estas en la rimeda arbo, havos la postulatajn rajtojn, por ke Terraform sciu kiun Amazon-segmento aliri.
Kie Simligoj ne funkcias? Kiel mi diris, Terraform havas ŝtatajn dosierojn. Kaj ili estas tre, tre bonegaj. Sed la fakto estas, ke Terraform pravigas la backend en la plej unua. Kaj li ne povas uzi ajnajn variablojn en ĉi tiuj parametroj, ili ĉiam devas esti skribitaj en teksto.
Kaj kiel rezulto, kiam iu faras novan rimedon, li kopias parton de la kodo el aliaj dosierujoj. Kaj li povas erari per la ŝlosilo aŭ per la sitelo. Ekzemple, li faras sablokeston aĵon el sablokesto, kaj tiam faras ĝin en produktado. Kaj do povas rezulti, ke la sitelo en produktado estos uzata el la sablokesto. Kompreneble, ili trovos ĝin rapide. Eblos iel ripari tion, sed tamen ĝi estas malŝparo de tempo kaj, iagrade, rimedoj.
Kion ni povas fari poste? Antaŭ ol labori kun Terraform, vi devas pravalorigi ĝin. En la momento de inicialigo, Terraform elŝutas ĉiujn kromaĵojn. En iu momento, ili rompis de monolito al pli mikroserva arkitekturo. Kaj vi ĉiam devas fari Terraform init por ke ĝi elprenu ĉiujn modulojn, ĉiujn kromaĵojn.
Kaj vi povas uzi ŝelan skripton, kiu unue povas akiri ĉiujn variablojn. Ŝelo-skripto estas senlima. Kaj, due, la vojo. Se ni ĉiam uzas la vojon, kiu estas en la deponejo, kiel la ŝlosilon al la ŝtatdosiero, tiam, sekve, la eraro estos ekskludita ĉi tie.
Kie akiri datumojn? JSON dosiero. Terraform permesas skribi infrastrukturon ne nur en hcl (HashiCorp Configuration Language), sed ankaŭ en JSON.
JSON estas facile legebla el ŝela skripto. Sekve, vi povas meti agordan dosieron kun sitelo en iu loko. Kaj uzu ĉi tiun sitelon kaj en la Terraform-kodo kaj en la ŝelo-skripto por inicialigo.
Kial gravas havi Terraform sitelon? Ĉar ekzistas tia afero kiel foraj ŝtatdosieroj. Tio estas, kiam mi levas iun rimedon, por diri al Amazon: "Bonvolu levi ekzemplon", mi devas specifi multajn postulatajn parametrojn.
Kaj ĉi tiuj identigiloj estas konservitaj en iu alia dosierujo. Kaj mi povas preni ĝin kaj diri: "Terraform, bonvolu kuri al la ŝtatdosiero de tiu sama rimedo kaj ricevi al mi ĉi tiujn identigilojn." Kaj tiel estas ia unuiĝo inter diversaj regionoj aŭ medioj.
Ne ĉiam eblas uzi foran ŝtatdosieron. Ekzemple, vi permane kreis VPC. Kaj la Terraform-kodo, kiu kreas la VPC, kreas tiel malsaman VPC, ke ĝi prenas tre longan tempon kaj vi devas ĝustigi unu al la alia, do vi povas uzi la sekvan lertaĵon.
Tio estas, fari modulon kiu, kvazaŭ, faras VPC kaj donas al vi identigilojn, sed fakte ekzistas nur dosiero kun malmolaj valoroj, kiu povas esti uzata por krei la saman ekzemplon.
Ne ĉiam necesas konservi la ŝtatdosieron en la nubo. Ekzemple, dum testado de moduloj, vi povas uzi backend-komencigon, kiam la dosiero estos konservita nur sur disko en la momento de testado.
Nun iomete pri testado. Kion oni povas provi en Terraform? Verŝajne, multe eblas, sed mi parolos pri ĉi tiuj 4 aferoj.
HashiCorp havas komprenon pri kiel formati Terraform-kodon. Kaj Terraform fmt permesas formati la kodon, kiun vi redaktas laŭ tiu kredo. Sekve, la testoj devas nepre kontroli ĉu la formatado kongruas kun tio, kion HashiCorp testamentis, por ke vi ne devu ŝanĝi la lokon de krampoj ktp.
La sekva estas Terraform validigi. Ĝi faras iom pli ol sintaksa kontrolo - ve, ĉu ĉiuj krampoj estas parigitaj. Kio estas grava ĉi tie? Ni havas tre maldikan infrastrukturon. Ĝi havas multajn malsamajn dosierujojn. Kaj en ĉiu vi devas ruli Terraform validigi.
Sekve, por akceli testadon, ni kuras plurajn procezojn paralele uzante paralele.
Paralelo estas tre bonega afero, uzu ĝin.
Sed ĉiufoje kiam Terraform estas pravigita, ĝi iras al HashiCorp kaj demandas, "Kio estas la plej novaj kromprogramoj? Kaj la kromprogramon kiun mi havas en la kaŝmemoro - ĉu ĝi estas tiu aŭ ne tiu? Kaj ĝi malrapidiĝis ĉe ĉiu paŝo.
Se Terraform diras al vi, kie estas la kromprogramoj, Terraform diros: "Bone, ĉi tio verŝajne estas la plej freŝa afero. Mi iros nenien, mi tuj komencos validigi vian Terraform-kodon."
Por plenigi la dosierujon per la necesaj kromprogramoj, ni havas tre simplan Terraform-kodon, kiu nur bezonas esti pravigita. Ĉi tie, kompreneble, vi devas specifi ĉiujn provizantoj, kiuj iel partoprenas en via kodo, alie Terraform diros: "Mi konas neniun provizanton, ĉar ĝi ne estas en la kaŝmemoro."
La sekva estas la plano Terraform. Kiel mi diris, evoluo estas cikla. Ni faras kodon kun ŝanĝoj. Kaj tiam vi devas ekscii, kiaj ŝanĝoj estas planitaj por la infrastrukturo.
Kaj kiam la infrastrukturo estas tre, tre granda, vi povas ŝanĝi unu modulon, ripari iun testan medion aŭ iun specifan regionon kaj rompi iun najbaran. Tial, Terraform-plano devus esti farita por la tuta infrastrukturo kaj montri kiajn ŝanĝojn estas planitaj.
Vi povas fari ĝin laŭ la saĝa maniero. Ekzemple, ni skribis Python-skripton, kiu solvas dependecojn. Kaj depende de tio, kio estis ŝanĝita: modulo Terraform aŭ nur specifa komponanto, ĝi faras planojn por ĉiuj dependaj dosierujoj.
Terraform-plano devas esti farita laŭ peto. Almenaŭ tion ni faras.
Testoj, kompreneble, estas bonaj por fari por ĉiu ŝanĝo, por ĉiu kompromiso, sed planoj estas sufiĉe multekosta afero. Kaj ni diras en la tirpeto: "Bonvolu doni al mi la planojn." La roboto ekiras. Kaj sendas al la komentoj aŭ alligi ĉiujn planojn, kiuj atendas de viaj ŝanĝoj.
La plano estas sufiĉe multekosta afero. Necesas tempo ĉar Terraform iras al Amazon kaj demandas, "Ĉu ĉi tiu kazo ankoraŭ ekzistas? Ĉu ĉi tiu aŭtoskalo havas ĝuste la samajn parametrojn?”. Kaj por akceli ĝin, vi povas uzi parametron kiel refresh=false. Ĉi tio signifas, ke Terraform malŝveligos la S3-ŝtaton. Kaj kredos, ke la ŝtato ĝuste kongruos, kio estas en Amazono.
Tia Terraform-plano estas multe pli rapida, sed la ŝtato devas kongrui kun via infrastrukturo, t.e., ie, iam Terraform-refreŝiĝo devas komenciĝi. Terraform refreŝigas ĝuste tion, tiel ke la ŝtato respondas al kio estas en la reala infrastrukturo.
Kaj mi devas diri pri sekureco. Jen kie ĝi devus komenciĝi. Kie vi kuras Terraform kaj Terraform funkcias kun via infrastrukturo, estas vundebleco. Tio estas, vi esence plenumas kodon. Kaj se la tirpeto enhavas ian malican kodon, tiam ĝi povas esti efektivigita sur infrastrukturo kiu havas tro da aliro. Tial, atentu kie vi lanĉas Terraform-planon.
La sekva afero, pri kiu mi ŝatus paroli, estas testado de uzant-datumoj.
Kio estas uzant-datumoj? En Amazon, kiam ni kreas ekzemplon, ni povas sendi ian leteron de la kazo - metadatenoj. Kiam kazo estas komencita, kutime cloud init ĉiam ĉeestas en tiuj kazoj. Cloud init legas ĉi tiun leteron kaj diras: "Bone, hodiaŭ mi estas ŝarĝbalancisto." Kaj konforme al ĉi tiuj preskriboj, li faras kelkajn agojn.
Sed, bedaŭrinde, kiam ni faras Terraform-planon kaj Terraform aplikas, uzant-datumoj aspektas kiel ĉi tiu suspensiaĵo de nombroj. Tio estas, li nur sendas al vi haŝiŝon. Kaj ĉio, kion vi povas vidi en la plano, estas ĉu estos ŝanĝoj aŭ la haŝo restos la sama.
Kaj se vi ne atentas ĉi tion, tiam iu batita tekstdosiero povas iri al Amazon, al la reala infrastrukturo.
Alternative, vi povas specifi ne la tutan infrastrukturon dum ekzekuto, sed nur la ŝablonon. Kaj en la kodo, diru: "Bonvolu montri ĉi tiun ŝablonon por mi." Kaj kiel rezulto, vi povas ricevi presaĵon de kiel aspektos viaj datumoj sur Amazon.
Alia opcio estas uzi modulon por generi uzant-datumojn. Vi aplikos ĉi tiun modulon. Akiru la dosieron sur disko. Komparu ĝin kun la referenco. Kaj tiel, se iu jun decidas ripari iom da uzantdatumoj, tiam viaj testoj diros: "Bone, estas iuj ŝanĝoj ĉi tie kaj tie - ĉi tio estas normala."
La sekva afero, pri kiu mi ŝatus paroli, estas Aŭtomatigi Terraform apliki.
Kompreneble, estas sufiĉe timige fari Terraform apliki en aŭtomata reĝimo, ĉar kiu scias kiajn ŝanĝojn venis tie kaj kiom malutilaj ili povas esti por vivanta infrastrukturo.
Por testa medio, ĉi tio estas en ordo. Tio estas, laboro kiu kreas testan medion estas kion ĉiuj programistoj bezonas. Kaj tia esprimo kiel "ĉio funkciis por mi" ne estas amuza memo, sed pruvo, ke homo konfuziĝis, levis stakon, lanĉis kelkajn provojn sur ĉi tiu stako. Kaj li certigis, ke ĉio estas en ordo tie kaj diris: "Bone, la kodo, kiun mi liberigas, estis provita."
En produktado, sablokesto, kaj aliaj medioj kiuj estas pli komerca-kritikaj, estas sekure uzi iujn rimedojn ĉar ĝi ne kaŭzas iun morti. Ĉi tiuj estas: aŭtoskalaj grupoj, sekurecaj grupoj, roloj, route53 kaj tie la listo povas esti sufiĉe granda. Sed atentu tion, kio okazas, legu raportojn pri aŭtomataj aplikoj.
Kie estas danĝera aŭ timiga uzi, ekzemple, se ĉi tiuj estas iuj persistaj rimedoj, de datumbazo, tiam ricevu raportojn, ke estas neaplikataj ŝanĝoj en iu infrastrukturo. Kaj la inĝeniero jam estas kontrolita kurante laborojn por apliki aŭ farante ĝin de sia konzolo.
Amazon havas tian aĵon kiel Termina protekto. Kaj ĝi povas protekti en iuj kazoj kontraŭ ŝanĝoj, kiuj ne estas postulataj por vi. Do Terraform iris al Amazon kaj diras "Mi devas mortigi ĉi tiun kazon por fari alian". Kaj Amazon diras: "Pardonu, ne hodiaŭ. Ni havas Terminan protekton."
Kaj la glaciaĵo sur la kuko estas koda optimumigo. Kiam ni laboras kun Terraform-kodo, ni devas pasi tre grandan nombron da parametroj al la modulo. Ĉi tiuj estas la parametroj necesaj por krei ian rimedon. Kaj la kodo iĝas grandaj listoj de parametroj, kiujn oni devas pasi de modulo al modulo, de modulo al modulo, precipe se la moduloj estas nestitaj.
Kaj estas tre malfacile legebla. Estas tre malfacile revizii ĉi tion. Kaj tre ofte rezultas, ke iuj parametroj estas reviziitaj kaj ili ne estas tute tiuj, kiujn oni bezonas. Kaj kostas tempon kaj monon ripari ĝin poste.
Tial mi sugestas, ke vi uzu tian aferon kiel kompleksan parametron, kiu inkluzivas certan arbon de valoroj. Tio estas, vi bezonas ian dosierujon, kie vi havas ĉiujn valorojn, kiujn vi ŝatus havi en ia medio.
Kaj nomante ĉi tiun modulon, vi povas akiri arbon, kiu estas generita en unu komuna modulo, tio estas, en komuna modulo, kiu funkcias same por la tuta infrastrukturo.
En ĉi tiu modulo, vi povas fari kelkajn kalkulojn uzante tian freŝan funkcion en Terraform kiel lokuloj. Kaj tiam en unu eligo, eligu ian kompleksan parametron, kiu povas inkluzivi hashojn, tabelojn ktp.
Pri ĉi tio, ĉiuj plej bonaj trovoj, kiujn mi finis. Kaj mi ŝatus rakonti historion pri Kolumbo. Kiam li serĉis monon por sia ekspedicio malkovri Hindion (kiel li tiam pensis), neniu kredis lin kaj kredis ke ĝi estas neebla. Tiam li diris: "Atentu, ke la ovo ne falu." Ĉiuj bankieroj, tre riĉaj kaj verŝajne inteligentaj homoj, provis iel meti la ovon, kaj ĝi falis la tutan tempon. Tiam Kolumbo prenis la ovon, premis ĝin iomete. La ŝelo ĉifiĝis kaj la ovo restis senmova. Ili diris: "Ho, tio estas tro facila!" Kaj Kolumbo respondis: “Jes, ĝi estas tro simpla. Kaj kiam mi malfermos Hindion, ĉiuj uzos ĉi tiun komercan vojon."
Kaj tio, kion mi ĵus diris al vi, verŝajne estas sufiĉe simplaj kaj bagatelaj aferoj. Kaj kiam vi ekscias pri ili kaj komencas uzi ilin, tio estas en la ordo de la aferoj. Do uzu ĝin. Kaj se ĉi tiuj estas tute normalaj aferoj por vi, tiam almenaŭ vi scias kiel meti ovon, por ke ĝi ne falu.
Ni resumu:
- Provu eviti neĝerojn. Kaj ju malpli da neĝeroj, des malpli da rimedoj vi bezonos por fari ajnajn ŝanĝojn al via tuta granda infrastrukturo.
- Konstanta ŝanĝo. Tio estas, kiam iuj ŝanĝoj okazis en la kodo, vi devas laŭigi vian infrastrukturon kun ĉi tiuj ŝanĝoj kiel eble plej baldaŭ. Ne devus esti situacio, kiam iu venos post du aŭ tri monatoj por rigardi Elasticsearch, faras Terraform-planon, kaj estas multaj ŝanĝoj, kiujn li ne atendis. Kaj necesas multe da tempo por remeti ĉion en ordo.
- Testoj kaj aŭtomatigo. Ju pli via kodo estas kovrita per testoj kaj blatoj, des pli vi havas konfidon, ke vi faras ĉion ĝuste. Kaj aŭtomata livero multfoje pliigos vian fidon.
- La kodo por la testaj kaj produktadmedioj devus esti preskaŭ la sama. Praktike, ĉar post ĉio, produktado estas iom malsama kaj ankoraŭ estos iuj nuancoj, kiuj iros preter la testa medio. Sed tamen pli aŭ minus ĝi povas esti provizita.
- Kaj se vi havas multajn Terraform-kodon kaj necesas multe da tempo por teni ĉi tiun kodon ĝisdatigita, tiam neniam estas tro malfrue refactori kaj alporti ĝin en bonan formon.
- neŝanĝebla infrastrukturo. AMI-livero laŭhoraro.
- Strukturo por route53 kiam vi havas multajn enskribojn kaj volas, ke ili estu en konsekvenca ordo.
- Batalu kontraŭ API-indico-limoj. Jen kiam Amazon diras: "Jen, mi ne povas akcepti pliajn petojn, bonvolu atendi." Kaj duono de la oficejo atendas ĝis ĝi povas lanĉi sian infrastrukturon.
- ekvidi okazojn. Amazono ne estas malmultekosta evento kaj lokoj permesas vin ŝpari sufiĉe multe. Kaj tie vi povas rakonti tutan raporton pri ĝi.
- Roloj pri sekureco kaj IAM.
- Serĉu perditajn rimedojn, kiam vi havas kazojn de nekonata origino en Amazone, ili manĝas monon. Eĉ se okazoj kostas $100-150 monate, ĝi estas pli ol $1 jare. Trovi tiajn rimedojn estas enspeziga komerco.
- Kaj rezervitaj okazoj.
Tio estas ĉio por mi. Terraform estas tre bonega, uzu ĝin. Dankon!
Viaj demandoj
Dankon pro la raporto! Vi havas ŝtatan dosieron en S3, sed kiel vi solvas la problemon, ke pluraj homoj povas preni ĉi tiun ŝtatan dosieron kaj provi disfaldi?
Unue, ni ne rapidas. Due, estas flagoj, en kiuj ni raportas, ke ni laboras pri iu kodo. Tio estas, malgraŭ la fakto, ke la infrastrukturo estas tre granda, tio ne signifas, ke iu konstante uzas ion. Kaj kiam estis aktiva fazo, ĉi tio estis problemo, ni konservis ŝtatdosierojn en Git. Ĉi tio estis grava, alie iu farus ŝtatdosieron, kaj ni devis mane kolekti ilin amase por daŭrigi plu. Nun tia problemo ne ekzistas. Ĝenerale, Terraform solvis ĉi tiun problemon. Kaj se io konstante ŝanĝiĝas, tiam vi povas uzi serurojn, kiuj malhelpas tion, kion vi diris.
Ĉu vi uzas malferman fonton aŭ entreprenon?
Neniu entrepreno, tio estas, ĉio, kion vi povas iri kaj elŝuti senpage.
Mia nomo estas Stanislav. Mi volis fari malgrandan aldonon. Vi parolis pri la Amazon-trajto, kiu ebligas al vi igi kazon nemortigebla. Ĉi tio ankaŭ estas en Terraform mem, en la Vivo Dua bloko, vi povas preskribi malpermeson de ŝanĝo, aŭ malpermeson de detruo.
Estis limigita en tempo. Bona punkto.
Mi ankaŭ volis demandi du aferojn. Unue, vi parolis pri testado. Ĉu vi uzis iujn testajn ilojn? Mi aŭdis pri la aldonaĵo Test Kitchen. Eble estas io alia. Kaj mi ŝatus demandi pri Lokaj Valoroj. Kiel ili esence diferencas de Enigo-Variabloj? Kaj kial mi ne povas parametrigi ion nur per Lokaj Valoroj? Mi provis trakti ĉi tiun temon, sed iel mi ne eltrovis ĝin mem.
Ni povas paroli pli detale malantaŭ ĉi tiu salono. Testaj iloj estas niaj kompletaj memfaritaj. Estas nenio tie por testi. Ĝenerale, ekzistas ebloj kiam aŭtomataj provoj levas la infrastrukturon ie, kontrolu, ke ĝi estas en ordo, kaj poste detruu ĉion kun raporto, ke via infrastrukturo ankoraŭ estas en bona formo. Ni ne havas tion ĉar la teststakoj funkcias ĉiutage. Kaj tio sufiĉas. Kaj se io ekrompos, tiam ĝi ekrompos sen ke ni kontrolos ĝin aliloke.
Pri Lokaj Valoroj, ni daŭrigu la konversacion ekster la publiko.
Saluton! Dankon pro la raporto! Tre informa. Vi diris, ke vi havas multe da samaspeca kodo por priskribi la infrastrukturon. Ĉu vi pripensis generi ĉi tiun kodon?
Bonega demando, dankon! La punkto estas, ke kiam ni uzas infrastrukturon kiel kodon, ni supozas, ke ni rigardas la kodon kaj komprenas kian infrastrukturon kuŝas malantaŭ ĉi tiu kodo. Se la kodo estas generita, tiam ni devas imagi, kia kodo estos generita por kompreni kian infrastrukturon estos tie. Aŭ ni generas la kodon, faras ĝin kaj, fakte, ni ricevas la samon. Tial, ni iris kiel ni skribis, ni ricevis ĝin. Krome, generatoroj aperis iom poste, kiam ni komencis fari. Kaj estis tro malfrue por ŝanĝi.
Ĉu vi aŭdis pri jsonnet?
Ne
Rigardu, ĉi tio estas vere bonega aĵo. Mi vidas specifan kazon, kie vi povas apliki ĝin kaj generi datuman strukturon.
Generatoroj estas bonaj kiam vi havas ilin, kiel en la ŝerco pri la razmaŝino. Tio estas, la unuan fojon la vizaĝo estas malsama, sed tiam ĉiuj havas la saman vizaĝon. La generatoroj estas tre bonegaj. Sed, bedaŭrinde, niaj vizaĝoj estas iom malsamaj. Ĉi tio estas problemo.
Nur rigardu. Dankon!
Mi nomiĝas Maxim, mi estas de Sberbank. Vi iomete diris, ke vi provis alporti Terraform al analogo de programlingvo. Ĉu ne estas pli facile uzi Ansible?
Ĉi tiuj estas tre malsamaj aferoj. Ansible povas krei rimedojn, kaj Puppet povas krei rimedojn en Amazon. Sed Terraform estas rekte akrigita.
Ĉu vi nur havas Amazonon?
Ne estas ke ni nur havas Amazonon. Ni preskaŭ nur havas Amazonon. Sed la ĉefa trajto estas, ke Terraform memoras. En Ansible, se vi diras: "Prenu al mi 5 okazojn", tiam ĝi leviĝos, kaj tiam vi diras: "Kaj nun mi bezonas 3". Kaj Terraform diros: "Bone, mi mortigos 2", kaj Ansible diros: "Bone, jen 3 por vi." Sumo 8.
Saluton! Dankon pro via raporto! Estis tre interese aŭdi pri Terraform. Mi nur volas fari etan komenton pri tio, ke Terraform ankoraŭ ne havas stabilan eldonon, do estu tre singarda kun Terraform.
Bela kulero por vespermanĝo. Tio estas, se vi bezonas solvon, tiam vi foje prokrastas tion, kio estas malstabila ktp., sed ĝi funkcias kaj helpis nin.
La demando estas. Vi uzas la Foran backend, vi uzas S 3. Kial vi ne uzas la oficialan backend?
Oficiala?
Terraform Nubo.
Kiam li aperis?
antaŭ 4 monatoj.
Se ĝi estus aperinta antaŭ 4 jaroj, tiam, verŝajne, mi respondus vian demandon.
Jam ekzistas enkonstruita funkcio kaj seruroj, kaj vi povas konservi ŝtatdosieron. Provu ĝin. Sed mi ankaŭ ne testis.
Ni estas en granda trajno, kiu veturas rapide. Kaj vi ne povas simple preni kaj elĵeti kelkajn aŭtojn.
Vi parolis pri neĝeroj, kial vi ne uzis branĉon? Kial ĝi ne funkciis tiel?
Ni havas tian aliron, ke la tuta infrastrukturo estas en unu deponejo. Terraform, Puppet, ĉiuj skriptoj, kiuj iel rilatas al ĉi tio, ili ĉiuj estas en unu deponejo. Tiel ni povas certigi, ke pliigaj ŝanĝoj estas provitaj unu post alia. Se ĝi estus aro da branĉoj, tiam tia projekto estus preskaŭ neeble konservi. Ses monatoj pasas, kaj ili tiom diverĝas, ke ĝi estas nur ia puno. Jen kion mi volis forkuri antaŭ refactoring.
t.e. ĉu ĝi ne funkcias?
Ĝi tute ne funkcias.
En branĉo, mi eltranĉis la dosierujon. Tio estas, se vi faras por ĉiu prova stako, ekzemple, teamo A havas sian propran paĉjon, teamo B havas sian propran paĉjon, tiam ankaŭ ĉi tio ne funkcias. Ni faris unuigitan testan mediokodon sufiĉe fleksebla por konveni al ĉiuj. Tio estas, ni servis unu kodon.
Saluton! Mia nomo estas Yura! Dankon pro la raporto! Demando pri moduloj. Vi diras, ke vi uzas modulojn. Kiel vi solvas la problemon se oni faris ŝanĝojn en unu modulo, kiuj ne kongruas kun la ŝanĝo de alia persono? Iel versioni modulojn aŭ provi alporti mirinfanon por plenumi du postulojn?
Ĉi tio estas la granda problemo de neĝostako. Jen kion ni suferas, kiam iu senkulpa ŝanĝo povas rompi iun parton de la infrastrukturo. Kaj ĝi estos rimarkebla nur post longa tempo.
Tio estas, ?i ankora? ne estas decidita?
Vi faras universalajn modulojn. Evitu neĝerojn. Kaj ĉio funkcios. La dua duono de la raporto temas pri kiel eviti ĝin.
Saluton! Dankon pro la raporto! Mi ŝatus klarigi. Malantaŭ la kulisoj estis granda amaso, por kiu mi venis. Kiel estas Puppet kaj roldistribuo integritaj?
uzanto-datumoj.
Tio estas, ĉu vi nur kraĉas la dosieron kaj iel ekzekutas sur ĝi?
Uzanto-datumoj estas noto, t.e. kiam ni faras bildklonon, tiam Daemon ekstaras tie kaj provante eltrovi kiu li estas, legas noton ke li estas ŝarĝbalancisto.
Tio estas, ĉu ĝi estas ia aparta procezo, kiu estas fordonita?
Ni ne inventis ĝin. Ni uzas ĝin.
Saluton! Mi nur havas demandon pri Uzanto - datumoj. Vi diris, ke ekzistas problemoj tie, ke iu povus sendi ion al la malĝusta loko. Ĉu ekzistas iu maniero stoki uzanto-datumojn en la sama Git, por ke ĉiam estu klare, al kio Uzant-datumoj rilatas?
Ni generas Uzantajn datumojn el ŝablono. Tio estas, certa nombro da variabloj recurre tie. Kaj Terraform generas la finan rezulton. Sekve, vi ne povas simple rigardi la ŝablonon kaj diri kio okazas, ĉar ĉiuj problemoj rilatas al tio, ke la programisto pensas, ke li pasas ĉenon en ĉi tiu variablo, kaj tiam tabelo estas uzata. Kaj li — bang kaj mi — tiel kaj tiel, tiel kaj tiel, la sekva linio, kaj ĉio rompiĝis. Se ĉi tio estas nova rimedo kaj persono levas ĝin, vidas, ke io ne funkcias, tiam ĉi tio estas rapide solvita. Kaj se ĉi tiu aŭtoskala grupo estis ĝisdatigita, tiam iam la okazoj en la aŭtoskala grupo komencas esti anstataŭigitaj. Kaj aplaŭdu, io ne funkcias. Doloras.
Montriĝas, ke la sola solvo estas testi?
Jes, vi vidas la problemon, vi aldonas provajn paŝojn tie. Tio estas, eligo ankaŭ povas esti provita. Eble ne tiom oportune, sed vi ankaŭ povas meti markojn - kontrolu, ke Uzanto-datumoj estas najlita ĉi tie.
Mia nomo estas Timur. Estas tre mojose ke ekzistas raportoj pri kiel ĝuste organizi Terraform .
Mi eĉ ne komencis.
Mi pensas, ke en la venonta konferenco, eble estos. Mi havas simplan demandon. Kial vi malmola kodas la valoron en aparta modulo prefere ol uzi tfvars, t.e. ĉu modulo kun valoroj pli bona ol tfvars?
Tio estas, mi skribu ĉi tie (diagramo: Production/environment/settings.tf): domajno = variablo, domajno vpcnetwork, vpcnetwork variablo kaj stvars - akiri la samon?
Ni faras ĝuste tion. Ni rilatas al la agorda fontomodulo, ekzemple.
Fakte, ĉi tio estas tia tfvars. Tfvars estas tre oportuna en prova medio. Mi havas tfvarojn por grandaj okazoj, por malgrandaj. Kaj mi ĵetis unu dosieron en la dosierujon. Kaj ricevis tion, kion mi volis. Kiam ni vidis infrastrukturon, ni volas povi vidi kaj tuj kompreni ĉion. Kaj do rezultas, ke vi devas rigardi ĉi tie, poste rigardi en tfvars.
Montriĝas, ke ĉio estis en unu loko?
Jes, tfvars estas kiam vi havas unu kodon. Kaj ĝi estas uzata en pluraj malsamaj lokoj kun malsamaj nuancoj. Tiam vi ĵetus tfvarojn kaj ricevus viajn nuancojn. Kaj ni estas infrastrukturo kiel kodo en ĝia plej pura formo. Rigardis kaj komprenis.
Saluton! Ĉu vi renkontis situaciojn, kie la nuba provizanto malhelpas tion, kion vi faris kun Terraform? Ni diru, ke ni redaktas la metadatumojn. Estas ssh-ŝlosiloj. Kaj Guglo konstante glitas siajn metadatumojn, ĝiajn ŝlosilojn tie. Kaj Terraform ĉiam skribas, ke ĝi havas ŝanĝojn. Post ĉiu kuro, eĉ se nenio ŝanĝiĝas, li ĉiam diras, ke li ĝisdatigos ĉi tiun kampon nun.
Per ŝlosiloj, sed - jes, parto de la infrastrukturo estas tuŝita de tia afero, t.e. Terraform ne povas ŝanĝi ion ajn. Ni ankaŭ ne povas ŝanĝi ion per niaj manoj. Tiel longe kiel ni vivas kun ĝi.
Tio estas, vi renkontis ĉi tion, sed nenion elpensis, kiel li faras kaj faras ĝin mem?
Bedaŭrinde jes.
Saluton! Mia nomo estas Stanislav Starkov. Poŝto. eo Grupo. Kiel vi solvas la problemon kun generado de etikedo sur ..., kiel vi pasas ĝin enen? Kiel mi komprenas ĝin, per Uzanto - datumoj, por specifi la gastigan nomon, inciti Puppeton? Kaj la dua parto de la demando. Kiel vi solvas ĉi tiun problemon en SG, t.e. kiam vi generas SG, cent okazojn de la sama tipo, kiel nomi ilin ĝuste?
Tiujn okazojn, kiuj estas tre gravaj por ni, ni bele nomos ilin. Tiuj, kiuj ne estas bezonataj, estas postskribo, ke ĉi tio estas aŭtoskala grupo. Kaj en teorio ĝi povas esti najlita, kaj akiri novan.
Koncerne la problemon kun la etikedo, ne ekzistas tia problemo, sed ekzistas tia tasko. Kaj ni uzas etikedojn tre, tre peze, ĉar la infrastrukturo estas granda kaj multekosta. Kaj ni devas rigardi pri kio mono estas elspezita, do etikedoj permesas al ni ordigi kio kaj kien ĝi iris. Kaj, sekve, la serĉo de io ĉi tie estas multe da mono elspezita.
Pri kio alia estis la demando?
Kiam SG kreas cent okazojn, ĉu oni devas iel distingi ilin?
Ne, ne faru. Ĉiu okazo havas agenton, kiu diras al mi, ke mi havas problemon. Se la agento raportas, tiam la agento scias pri li kaj, almenaŭ, lia IP-adreso ekzistas. Vi jam povas kuri. Due, ni uzas Consul for Discovery, kie ne ekzistas Kubernetes. Kaj Konsulo ankaŭ montras la IP-adreson de la petskribo.
Tio estas, ĉu vi celas ĝuste la IP, kaj ne la gastigan nomon?
Estas neeble navigi per gastiga nomo, t.e. estas multaj el ili. Estas ekzempleridentigiloj - AE, ktp. Vi povas trovi ĝin ie, vi povas ĵeti ĝin en la serĉon.
Saluton! Mi rimarkis, ke Terraform estas bona afero, adaptita al la nuboj.
Ne nur.
Jen la demando, kiu interesas min. Se vi decidas translokiĝi, ekzemple, al Bare Metal amase kun ĉiuj viaj okazoj? Ĉu estos problemoj? Aŭ ĉu vi ankoraŭ devas uzi aliajn produktojn, ekzemple la saman Ansible, kiu estis menciita ĉi tie?
Ansible estas iom pri io alia. Tio estas, Ansible jam funkcias kiam okazo komenciĝis. Kaj Terraform funkcias antaŭ ol la petskribo komenciĝis. Ŝanĝi al Bare Metalo ne estas.
Ne nun, sed venos komerco kaj diros: "Venu."
Ŝanĝi al alia nubo - jes, sed estas iomete malsama trajto ĉi tie. Vi devas skribi Terraform-kodon tiel, ke vi povas ŝanĝi al iu alia nubo kun malpli da sangoverŝado.
Komence, la tasko estis, ke nia tuta infrastrukturo estas agnostika, t.e. ajna nubo estu bona, sed iam la komerco rezignis kaj diris: "Bone, en la venontaj N jaroj ni ne iros ien, vi povas uzi servojn de Amazono".
Terraform permesas krei Front-End-laborojn, agordi PagerDuty, datumdokumentojn, ktp. Ĝi havas multajn vostojn. Li povas praktike regi la tutan mondon.
Dankon pro la raporto! Mi ankaŭ ŝpinas Terraform jam 4 jarojn. En la stadio de glata transiro al Terraform, al infrastrukturo, al deklara priskribo, ni alfrontis situacion kie iu faris ion mane, kaj vi provis fari planon. Kaj mi ricevis iun eraron tie. Kiel vi traktas tiajn problemojn? Kiel vi trovas la perditajn rimedojn, kiuj estis indikitaj?
Plejparte per niaj manoj kaj okuloj, se ni vidas ion strangan en la raporto, tiam ni analizas kio okazas tie, aŭ ni simple mortigas ĝin. Ĝenerale, tirpetoj estas ofta afero.
Se estas eraro, ĉu vi renversas? Ĉu vi provis fari ĉi tion?
Ne, ĉi tio estas decido de homo en la momento, kiam li vidas la problemon.
fonto: www.habr.com