Multaj homoj konas kaj uzas Terraform en sia ĉiutaga laboro, sed plej bonaj praktikoj por ĝi ankoraŭ ne estis formitaj. Ĉiu teamo devas inventi siajn proprajn alirojn kaj metodojn.
Via infrastrukturo preskaŭ certe komenciĝas simple: kelkaj rimedoj + kelkaj programistoj. Kun la tempo, ĝi kreskas en ĉiaj direktoj. Ĉu vi trovas manierojn grupigi rimedojn en Terraform-modulojn, organizi kodon en dosierujojn, kaj kio alia eble misfunkcias? (famaj lastaj vortoj)
La tempo pasas kaj vi sentas, ke via infrastrukturo estas via nova dorlotbesto, sed kial? Vi maltrankviliĝas pri neklarigeblaj ŝanĝoj en la infrastrukturo, vi timas tuŝi la infrastrukturon kaj kodon - kiel rezulto, vi prokrastas novan funkciecon aŭ malpliigas kvaliton...
Post tri jaroj de administrado de kolekto de komunumaj moduloj de Terraform por AWS sur Github kaj longtempa prizorgado de Terraform en produktado, Anton Babenko pretas kunhavigi sian sperton: kiel verki TF-modulojn por ke ĝi ne doloru estonte.
Antaŭ la fino de la parolado, partoprenantoj pli konos principojn pri administrado de rimedoj en Terraform, plej bonaj praktikoj asociitaj kun moduloj en Terraform, kaj iuj daŭraj integriĝprincipoj asociitaj kun infrastruktura administrado.
Malgarantio: Mi rimarkas, ke ĉi tiu raporto estas datita de novembro 2018—2 jaroj jam pasis. La versio de Terraform 0.11 diskutita en la raporto ne plu estas subtenata. Dum la pasintaj 2 jaroj, 2 novaj eldonoj estis publikigitaj, kiuj enhavas multajn novigojn, plibonigojn kaj ŝanĝojn. Bonvolu atenti ĉi tion kaj kontroli la dokumentadon.
Referencoj
- +
- — aŭtomatformata kodo kaj dokumentado
- - generatoro de Terraform-moduloj (WIP)
- - Terraform-kodgeneratoro de vidaj diagramoj (WIP)
- www.terraform-best-practices.com
- (Novaj afiŝoj estas en mia persona retejo www.antonbabenko.com/)
- @antonbabenko - Tvitero, kaj amaso da malsamaj Slacks
Mi nomiĝas Anton Babenko. Iuj el vi verŝajne uzis la kodon, kiun mi skribis. Mi nun parolos pri tio kun pli fido ol iam ajn, ĉar mi havas aliron al statistiko.
Mi laboras pri Terraform kaj estas aktiva partoprenanto kaj kontribuanto al granda nombro da malfermkodaj projektoj rilataj al Terraform kaj Amazon ekde 2015.
Ekde tiam mi verkis sufiĉe da kodo por meti ĝin en interesa maniero. Kaj mi provos rakonti al vi pri tio nun.
Mi parolos pri la komplikaĵoj kaj specifaĵoj de laboro kun Terraform. Sed tio ne vere estas la temo de HighLoad. Kaj nun vi komprenos kial.
Kun la tempo, mi komencis verki Terraform-modulojn. Uzantoj skribis demandojn, mi reverkis ilin. Poste mi skribis diversajn utilecojn por formati la kodon per antaŭ-kommit-hoko ktp.
Estis multaj interesaj projektoj. Mi ŝatas generadon de kodo ĉar mi ŝatas, ke la komputilo faru pli kaj pli da laboro por mi kaj la programisto, do mi nuntempe laboras pri kodgeneratoro Terraform el vidaj diagramoj. Eble iuj el vi vidis ilin. Ĉi tiuj estas belaj skatoloj kun sagoj. Kaj mi pensas, ke estas bonege, se vi povas alklaki la butonon "Eksporti" kaj akiri ĉion kiel kodon.
Mi estas el Ukrainio. Mi loĝas en Norvegio dum multaj jaroj.
Ankaŭ informoj por ĉi tiu raporto estis kolektitaj de homoj, kiuj konas mian nomon kaj trovas min en sociaj retoj. Mi preskaŭ ĉiam havas la saman kromnomon.
Kiel mi menciis, mi estas la ĉefa prizorganto de Terraform AWS-moduloj, kiu estas unu el la plej grandaj deponejoj en GitHub, kie ni gastigas modulojn por la plej oftaj taskoj: VPC, Autoscaling, RDS.
Kaj tio, kion vi aŭdis nun, estas la plej baza. Se vi dubas, ke vi komprenas, kio estas Terraform, tiam estas pli bone pasigi vian tempon aliloke. Ĉi tie estos multaj teknikaj terminoj. Kaj mi ne hezitis deklari, ke la nivelo de la raporto estas la plej alta. Ĉi tio signifas, ke mi povas paroli uzante ĉiujn eblajn terminojn sen multe da klarigo.
Terraform aperis en 2014 kiel ilo, kiu permesis vin skribi, plani kaj administri infrastrukturon kiel kodon. La ŝlosila koncepto ĉi tie estas "infrastrukturo kiel kodo".
Ĉiu dokumentaro, kiel mi diris, estas enskribita . Mi esperas, ke plej multaj homoj scias pri ĉi tiu retejo kaj legis la dokumentaron. Se jes, tiam vi estas en la ĝusta loko.
Jen kiel aspektas regula agorda dosiero de Terraform, kie ni unue difinas kelkajn variablojn.
En ĉi tiu kazo ni difinas "aws_region".
Poste ni priskribas kiajn rimedojn ni volas krei.
Ni rulas kelkajn komandojn, precipe "terraform init" por ŝarĝi dependecojn kaj provizantojn.
Kaj ni rulas la komandon "terraform apply" por kontroli ĉu la specifita agordo kongruas kun la rimedoj, kiujn ni kreis. Ĉar ni kreis nenion antaŭe, Terraform instigas nin krei ĉi tiujn rimedojn.
Ni konfirmas ĉi tion. Tiel ni kreas sitelon nomatan marheliko.
Estas ankaŭ pluraj similaj utilecoj. Multaj el vi, kiuj uzas Amazon, konas AWS CloudFormation aŭ Google Cloud Deployment Manager aŭ Azure Resource Manager. Ĉiu el ili havas sian propran efektivigon de iu speco por administri rimedojn ene de ĉiu el ĉi tiuj publikaj nubaj provizantoj. Terraform estas precipe utila ĉar ĝi permesas vin administri pli ol 100 provizantojn. (Pli da detaloj )
La celoj kiujn Terraform persekutis de la komenco mem:
- Terraform disponigas ununuran vidon de resursoj.
- Permesas vin subteni ĉiujn modernajn platformojn.
- Kaj Terraform estis desegnita ekde la komenco kiel ilo, kiu permesas vin ŝanĝi infrastrukturon sekure kaj antaŭvideble.
En 2014, la vorto "antaŭvidebla" sonis tre nekutima en ĉi tiu kunteksto.
Terraform estas universala utileco. Se vi havas API, tiam vi povas kontroli absolute ĉion:
- Vi povas uzi pli ol 120 provizantojn por administri ĉion, kion vi volas.
- Ekzemple, vi povas uzi Terraform por priskribi aliron al GitHub-deponejoj.
- Vi eĉ povas krei kaj fermi cimojn en Jira.
- Vi povas administri New Relic-metrikojn.
- Vi povas eĉ krei dosierojn en dropbox se vi vere volas.
Ĉio ĉi estas atingita per Terraform-provizantoj, kiuj havas malferman API, kiu povas esti priskribita en Go.
Ni diru, ke ni ekuzis Terraform, legis iom da dokumentaro en la retejo, spektis iun videon, kaj komencis verki main.tf, kiel mi montris sur la antaŭaj lumbildoj.
Kaj ĉio estas bonega, vi havas dosieron, kiu kreas VPC.
Se vi volas krei VPC, tiam vi specifu proksimume ĉi tiujn 12 liniojn. Priskribu en kiu regiono vi volas krei, kiun cidr_block de IP-adresoj uzi. Tio estas ĉio.
Nature, la projekto iom post iom kreskos.
Kaj vi aldonos tie multe da novaj aferoj: rimedoj, datumfontoj, vi integriĝos kun novaj provizantoj, subite vi volos uzi Terraform por administri uzantojn en via GitHub-konto, ktp. Vi eble volas uzi malsamajn. DNS-provizantoj, transiru ĉion. Terraform faciligas ĉi tion.
Ni rigardu la sekvan ekzemplon.
Vi iom post iom aldonas internet_gateway ĉar vi volas, ke rimedoj de via VPC havu interretan aliron. Ĉi tio estas bona ideo.
La rezulto estas ĉi tiu main.tf:
Ĉi tio estas la supra parto de main.tf.
Ĉi tio estas la malsupra parto de main.tf.
Poste vi aldonas subreton. Kiam vi volas aldoni NAT-enirejojn, itinerojn, vojtabelojn kaj amason da aliaj subretoj, vi ne havos 38 liniojn, sed proksimume 200-300 liniojn.
Tio estas, via main.tf dosiero iom post iom kreskas. Kaj sufiĉe ofte homoj metas ĉion en unu dosieron. 10-20 Kb aperas en main.tf. Imagu, ke 10-20 Kb estas tekstenhavo. Kaj ĉio estas ligita al ĉio. Ĉi tio iom post iom fariĝas malfacile labori. 10-20 Kb estas bona uzantkazo, foje pli. Kaj homoj ne ĉiam pensas, ke ĉi tio estas malbona.
Kiel en regula programado, t.e. ne infrastrukturo kiel kodo, ni kutimas uzi aron da malsamaj klasoj, pakaĵoj, moduloj, grupiĝoj. Terraform permesas vin fari preskaŭ la samon.
- La kodo kreskas.
- Dependecoj inter rimedoj ankaŭ kreskas.
Kaj ni havas grandan, grandan bezonon. Ni komprenas, ke ni ne plu povas vivi tiel. Nia kodo fariĝas grandega. 10-20 Kb estas kompreneble ne tre vasta, sed ni parolas nur pri la reta stako, t.e. vi nur aldonis retajn rimedojn. Ni ne parolas pri Application Load Balancer, deplojo ES-grupo, Kubernetes, ktp., kie 100 Kb povas facile esti teksitaj. Se vi skribas ĉion ĉi, vi tre baldaŭ ekscios, ke Terraform provizas Terraform-modulojn.
Terraform-moduloj estas memstara Terraform-agordo kiu estas administrita kiel grupo. Tio estas ĉio, kion vi bezonas scii pri Terraform-moduloj. Ili tute ne estas inteligentaj, ili ne permesas al vi fari iujn kompleksajn konektojn depende de io. Ĉi ĉio falas sur la ŝultrojn de la programistoj. Tio estas, ĉi tio estas nur ia Terraform-agordo, kiun vi jam skribis. Kaj vi povas simple nomi ĝin kiel grupo.
Do ni provas kompreni kiel ni optimumigos nian 10-20-30 Kb da kodo. Ni iom post iom rimarkas, ke ni bezonas uzi kelkajn modulojn.
La unua speco de moduloj, kiujn vi renkontas, estas rimedmoduloj. Ili ne komprenas pri kio temas via infrastrukturo, pri kio temas via komerco, kie kaj kiaj kondiĉoj estas. Ĉi tiuj estas ĝuste la moduloj, kiujn mi, kune kun la malfermkoda komunumo, administras, kaj kiujn ni prezentas kiel la plej komencajn konstrubriketojn por via infrastrukturo.
Ekzemplo de rimeda modulo.
Kiam ni vokas rimedan modulon, ni specifas de kiu vojo ni devus ŝargi ĝian enhavon.
Ni indikas kiun version ni volas elŝuti.
Ni pasigas aron da argumentoj tie. Tio estas ĉio. Tio estas ĉio, kion ni bezonas scii, kiam ni uzas ĉi tiun modulon.
Multaj homoj pensas, ke se ili uzas la lastan version, ĉio estos stabila. Sed ne. La infrastrukturo devas esti versionita; ni devas klare respondi al kiu versio tiu aŭ alia komponanto estis deplojita.
Jen la kodo kiu estas ene de ĉi tiu modulo. Sekureca grupo-modulo. Ĉi tie la rullibro iras al la 640-a linio. Krei sekurecan rimedon en Amazon en ĉiu ebla agordo estas tre ne-triviala tasko. Ne sufiĉas simple krei sekurecan grupon kaj diri al ĝi kiajn regulojn transdoni al ĝi. Estus tre simpla. Estas miliono da malsamaj limigoj en Amazon. Ekzemple, se vi uzas VPC-finpunkto, prefiksa listo, diversaj APIoj kaj provas kombini ĉion ĉi kun ĉio alia, tiam Terraform ne permesas al vi fari tion. Kaj la Amazon API ankaŭ ne permesas ĉi tion. Sekve, ni devas kaŝi ĉi tiun teruran logikon en modulo kaj doni la uzantkodon, kiu aspektas ĝuste tiel.
La uzanto ne bezonas scii kiel ĝi estas farita ene.
La dua speco de moduloj, kiu konsistas el rimedmoduloj, jam solvas problemojn, kiuj estas pli aplikeblaj al via komerco. Ofte ĉi tio estas loko, kiu estas etendo por Terraform kaj fiksas iujn rigidajn valorojn por etikedoj, por firmaaj normoj. Vi ankaŭ povas aldoni funkciojn tie, kiujn Terraform nuntempe ne permesas al vi uzi. Ĉi tio estas ĝuste nun. Nun versio 0.11, kiu estas farota afero de la pasinteco. Sed tamen, antaŭprocesoroj, jsonnet, kuketo kaj amaso da aliaj aferoj estas la helpmekanismo, kiu devas esti uzata por plena laboro.
Poste mi montros kelkajn ekzemplojn de tio.
La infrastruktura modulo estas nomita ĝuste en la sama maniero.
La fonto de kie elŝuti la enhavon estas indikita.
Aro da valoroj estas transdonitaj kaj transdonitaj en ĉi tiun modulon.
Poste, ene de ĉi tiu modulo, amaso da rimedmoduloj estas vokitaj por krei VPC aŭ Aplikaĵan Ŝarĝbalancilon, aŭ por krei sekurecan grupon aŭ por Elastic Container Service-grupo.
Estas du specoj de moduloj. Ĉi tio estas grave kompreni ĉar la plej multaj el la informoj, kiujn mi grupigis en ĉi tiu raporto, ne estas skribitaj en la dokumentado.
Kaj la dokumentado en Terraform nun estas sufiĉe problema ĉar ĝi nur diras, ke ekzistas ĉi tiuj funkcioj, vi povas uzi ilin. Sed ŝi ne diras kiel uzi ĉi tiujn funkciojn, kial estas pli bone uzi ilin. Tial tre granda nombro da homoj skribas ion, kion ili ne povas vivi.
Ni rigardu kiel skribi ĉi tiujn modulojn poste. Tiam ni vidos kiel voki ilin kaj kiel labori kun la kodo.
Terraform Registry -
Konsilo #0 estas ne skribi rimedmodulojn. Plej multaj el ĉi tiuj moduloj jam estas skribitaj por vi. Kiel mi diris, ili estas malfermitaj fontoj, ili ne enhavas vian komercan logikon, ili ne havas malmolajn valorojn por IP-adresoj, pasvortoj, ktp. La modulo estas tre fleksebla. Kaj plej verŝajne ĝi jam estas skribita. Estas multaj moduloj por rimedoj de Amazon. Ĉirkaŭ 650. Kaj la plej multaj el ili estas bonkvalitaj.
En ĉi tiu ekzemplo, iu venis al vi kaj diris: "Mi volas povi administri datumbazon. Kreu modulon por ke mi povu krei datumbazon." La persono ne konas la efektivigdetalojn de aŭ Amazon aŭ Terraform. Li simple diras: "Mi volas administri MSSQL." Tio estas, ni volas diri, ke ĝi vokos nian modulon, pasigos la motoran tipon tie kaj indikos la horzonon.
Kaj homo ne devas scii, ke ni kreos du malsamajn rimedojn ene de ĉi tiu modulo: unu por MSSQL, la dua por ĉio alia, nur ĉar en Terraform 0.11 vi ne povas specifi horzonajn valorojn kiel laŭvolajn.
Kaj ĉe la eliro el ĉi tiu modulo, persono povos simple ricevi adreson. Li ne scios el kiu datumbazo, el kiu rimedo ni kreas ĉion ĉi interne. Ĉi tio estas tre grava elemento de kaŝado. Kaj ĉi tio validas ne nur por tiuj moduloj, kiuj estas publikaj en malferma fonto, sed ankaŭ por tiuj moduloj, kiujn vi skribos ene de viaj projektoj kaj teamoj.
Ĉi tiu estas la dua argumento, kiu estas sufiĉe grava se vi uzas Terraform dum kelka tempo. Vi havas deponejon en kiu vi metas ĉiujn viajn Terraform-modulojn por via kompanio. Kaj estas tute normale, ke kun la tempo ĉi tiu projekto kreskos al grandeco de unu aŭ du megabajtoj. Ĉi tio estas bone.
Sed la problemo estas kiel Terraform nomas ĉi tiujn modulojn. Ekzemple, se vi vokas modulon por krei ĉiun individuan uzanton, Terraform unue ŝargos la tutan deponejon kaj poste navigos al la dosierujo kie troviĝas tiu specifa modulo. Tiel vi elŝutos unu megabajton ĉiufoje. Se vi administras 100 aŭ 200 uzantojn, tiam vi elŝutos 100 aŭ 200 megabajtojn, kaj poste iros al tiu dosierujo. Do kompreneble vi ne volas elŝuti amason da aĵoj ĉiufoje kiam vi trafas "Terraform init".
Estas du solvoj al ĉi tiu problemo. La unua estas uzi relativajn vojojn. Tiel vi indikas en la kodo, ke la dosierujo estas loka (./). Kaj antaŭ ol vi lanĉas ion ajn, vi faras Git-klonon de ĉi tiu deponejo loke. Tiel vi faras ĝin unufoje.
Estas, kompreneble, multaj malavantaĝoj. Ekzemple, vi ne povas uzi versionadon. Kaj ĉi tio foje estas malfacile vivi.
Dua solvo. Se vi havas multajn submodulojn kaj vi jam havas ian establitan dukton, tiam ekzistas la MBT-projekto, kiu permesas vin kolekti multajn malsamajn pakaĵojn el monodeponejo kaj alŝuti ilin al S3. Ĉi tio estas tre bona maniero. Tiel, la iam-user-1.0.0.zip-dosiero pezos nur 1 Kb, ĉar la kodo por krei ĉi tiun rimedon estas tre malgranda. Kaj ĝi funkcios multe pli rapide.
Ni parolu pri tio, kio ne povas esti uzata en moduloj.
Kial ĉi tiu malbono estas en moduloj? La plej malbona afero estas supozi uzanton. Supozu, ke uzanto estas provizanta aŭtentikiga opcio, kiu povas esti uzata de malsamaj homoj. Ekzemple, ni ĉiuj asimilos la rolon. Ĉi tio signifas, ke Terraform prenos ĉi tiun rolon. Kaj tiam kun ĉi tiu rolo ĝi plenumos aliajn agojn.
Kaj la malbono estas, ke se Vasja ŝatas konektiĝi al Amazon unumaniere, ekzemple, uzante la defaŭltan mediovariablon, kaj Petja ŝatas uzi sian komunan ŝlosilon, kiun li havas en sekreta loko, tiam vi ne povas specifi ambaŭ en Terraform. Kaj por ke ili ne spertu suferon, ne necesas indiki ĉi tiun blokon en la modulo. Ĉi tio devas esti indikita je pli alta nivelo. Tio estas, ni havas rimedan modulon, infrastrukturan modulon kaj kunmetaĵon supre. Kaj ĉi tio estu indikita ie pli alte.
La dua malbono estas la provizanto. Ĉi tie la malbono ne estas tiom bagatela, ĉar se vi skribas kodon kaj ĝi funkcias por vi, tiam vi eble pensas, ke se ĝi funkcias, kial do ŝanĝi ĝin.
La malbono estas, ke vi ne ĉiam regas kiam ĉi tiu provianto estos lanĉita, unue. Kaj due, vi ne regas, kion signifas aws ec2, t.e. ĉu ni parolas pri Linukso aŭ Vindozo nun. Do vi ne povas skribi ion, kio funkcios same en malsamaj operaciumoj aŭ por malsamaj uzantkazoj.
La plej ofta ekzemplo, kiu ankaŭ estas indikita en la oficiala dokumentaro, estas ke se vi skribas aws_instance kaj specifas aron da argumentoj, tiam estas nenio malbona kun tio se vi specifas la provizanton "local-exec" tie kaj rulu vian ansible- ludlibro.
Fakte, jes, estas nenio malbona en tio. Sed laŭvorte baldaŭ vi rimarkos, ke ĉi tiu loka-ekzekuta afero ne ekzistas, ekzemple, en lanĉo_agordo.
Kaj kiam vi uzas launch_configuration, kaj vi volas krei aŭtoskalan grupon de unu okazo, tiam en launch_configuration ne ekzistas koncepto de "provizanto". Estas la koncepto de "uzantdatenoj".
Tial pli universala solvo estas uzi datumojn de uzantoj. Kaj ĝi estos lanĉita aŭ sur la petskribo mem, kiam la petskribo estas ŝaltita, aŭ en la samaj uzantdatenoj, kiam la aŭtoskala grupo uzas ĉi tiun lanĉon_agordon.
Se vi ankoraŭ volas ruli la provizanton, ĉar ĝi estas glua komponanto, kiam unu rimedo estas kreita, en tiu momento vi devas ruli vian provizanton, vian komandon. Estas multaj tiaj situacioj.
Kaj la plej ĝusta rimedo por ĉi tio nomiĝas nula_rimedo. Null_resource estas falsa rimedo kiu neniam estas efektive kreita. Ĝi tuŝas nenion, neniun API, neniun aŭtoskalon. Sed ĝi permesas vin kontroli kiam ruli la komandon. En ĉi tiu kazo, la komando ruliĝas dum kreado.
ligilo
Estas pluraj signoj. Mi ne eniros ĉiujn signojn tre detale. Estas artikolo pri tio. Sed se vi laboris kun Terraform aŭ uzis modulojn de aliaj homoj, tiam vi ofte rimarkis, ke multaj moduloj, kiel la plej granda parto de la kodo en malferma fonto, estas skribitaj de homoj por siaj propraj bezonoj. Viro skribis ĝin kaj solvis sian problemon. Mi ŝtopis ĝin en GitHub, lasu ĝin vivi. Ĝi vivos, sed se tie mankas dokumentaro kaj ekzemploj, tiam neniu uzos ĝin. Kaj se ne ekzistas funkcio, kiu permesas vin solvi iom pli ol ĝia specifa tasko, tiam neniu ankaŭ uzos ĝin. Estas tiom da manieroj perdi uzantojn.
Se vi volas skribi ion por ke homoj uzu ĝin, tiam mi rekomendas sekvi ĉi tiujn signojn.
Ĉi tiuj estas:
- Dokumentado kaj ekzemploj.
- Plena funkcieco.
- Raciaj defaŭltoj.
- Pura kodo.
- Testoj.
Testoj estas malsama situacio ĉar ili estas sufiĉe malfacile verkeblaj. Mi kredas pli je dokumentado kaj ekzemploj.
Do, ni rigardis kiel skribi modulojn. Estas du argumentoj. La unua, kiu estas la plej grava, estas ne skribi, se vi povas, ĉar amaso da homoj jam faris ĉi tiujn taskojn antaŭ vi. Kaj due, se vi ankoraŭ decidas, do provu ne uzi provizantojn en moduloj kaj provizantoj.
Ĉi tio estas la griza parto de la dokumentaro. Vi eble nun pensas: “Io estas neklara. Ne konvinkita." Sed ni vidos post ses monatoj.
Nun ni parolu pri kiel voki ĉi tiujn modulojn.
Ni komprenas, ke nia kodo kreskas kun la tempo. Ni ne plu havas unu dosieron, ni jam havas 20 dosierojn. Ili ĉiuj estas en unu dosierujo. Aŭ eble en kvin dosierujoj. Eble ni komencas iel malkonstrui ilin laŭ regiono, laŭ kelkaj komponantoj. Tiam ni komprenas, ke nun ni havas kelkajn rudimentojn de sinkronigado kaj orkestrado. Tio estas, ni devas kompreni, kion ni devus fari se ni ŝanĝis retajn rimedojn, kion ni devus fari kun la ceteraj niaj rimedoj, kiel kaŭzi ĉi tiujn dependecojn, ktp.
Estas du ekstremoj. La unua ekstremo estas ĉio en unu. Ni havas unu majstran dosieron. Por la momento, ĉi tio estis la oficiala plej bona praktiko en la retejo Terraform.
Sed nun ĝi estas skribita kiel malrekomendita kaj forigita. Kun la tempo, la Terraform-komunumo ekkomprenis ke tio estis malproksima de la plej bona praktiko, ĉar homoj komencis uzi la projekton laŭ malsamaj manieroj. Kaj estas problemoj. Ekzemple, kiam ni listigas ĉiujn dependecojn en unu loko. Estas situacioj, kiam ni alklakas "Terraform-planon" kaj ĝis Terraform ĝisdatigas la statojn de ĉiuj rimedoj, multe da tempo povas pasi.
Multa tempo estas, ekzemple, 5 minutoj. Por iuj tio estas multe da tempo. Mi vidis kazojn, kie ĝi daŭris 15 minutojn. La AWS API pasigis 15 minutojn provante eltrovi kio okazas kun la stato de ĉiu rimedo. Ĉi tio estas tre granda areo.
Kaj, nature, rilata problemo aperos kiam vi volas ŝanĝi ion en unu loko, tiam vi atendas 15 minutojn, kaj ĝi donas al vi tolon de iuj ŝanĝoj. Vi kraĉis, skribis "Jes", kaj io misfunkciis. Ĉi tio estas tre reala ekzemplo. Terraform ne provas ŝirmi vin kontraŭ problemoj. Tio estas, skribu kion vi volas. Estos problemoj - viaj problemoj. Dum Terraform 0.11 neniel provas helpi vin. Estas certaj interesaj lokoj en 0.12, kiuj permesas vin diri: "Vasja, vi vere volas ĉi tion, ĉu vi povas rekonsciiĝi?"
La dua maniero estas redukti ĉi tiun areon, tio estas, vokoj de unu loko povas esti malpli konektitaj de alia loko.
La nura problemo estas, ke vi devas skribi pli da kodo, t.e. vi devas priskribi variablojn en granda nombro da dosieroj kaj ĝisdatigi ĉi tion. Kelkaj homoj ne ŝatas ĝin. Ĉi tio estas normala por mi. Kaj kelkaj homoj pensas: "Kial skribi ĉi tion en malsamaj lokoj, mi metos ĉion en unu lokon." Ĉi tio eblas, sed ĉi tio estas la dua ekstremo.
Kiu havas ĉion ĉi vivi en unu loko? Unu, du, tri homoj, tio estas, iu uzas ĝin.
Kaj kiu nomas unu apartan komponanton, unu blokon aŭ unu infrastrukturan modulon? Kvin ĝis sep homoj. Ĉi tio estas mojosa.
La plej ofta respondo estas ie en la mezo. Se la projekto estas granda, tiam vi ofte havos situacion, kie neniu solvo taŭgas kaj ne ĉio funkcias tie, do vi finas kun miksaĵo. Ĉi tio estas nenio malbona, kondiĉe ke vi komprenas, ke ambaŭ havas avantaĝojn.
Se io ŝanĝiĝis en la stako VPC kaj vi volis apliki ĉi tiujn ŝanĝojn al EC2, t.e. vi volis ĝisdatigi la aŭtoskalan grupon ĉar vi havis novan subreton, tiam mi nomas ĉi tiun specon de dependeca orkestrado. Estas kelkaj solvoj: kiu uzas kion?
Mi povas sugesti kiajn solvojn ekzistas. Vi povas uzi Terraform por fari la magion, aŭ vi povas uzi makefiles por uzi Terraform. Kaj vidu ĉu io ŝanĝiĝis tie, vi povas lanĉi ĝin ĉi tie.
Kiel vi ŝatas ĉi tiun decidon? Ĉu iu kredas, ke ĉi tio estas bonega solvo? Mi vidas rideton, ŝajne duboj enŝteliĝis.
Kompreneble, ne provu ĉi tion hejme. Terraform neniam estis dizajnita por esti prizorgita de Terraform.
Ĉe unu raporto ili diris al mi: "Ne, ĉi tio ne funkcios." La afero estas, ke ĝi ne devus funkcii. Kvankam ĝi aspektas tiel impona kiam vi povas lanĉi Terraform de Terraform, kaj poste Terraform, vi ne devus fari tion. Terraform devus ĉiam komenci tre facile.
Se vi bezonas voki instrumentadon kiam io ŝanĝiĝis en unu loko, tiam ekzistas Terragrunt.
Terragrunt estas ilo, aldonaĵo al Terraform, kiu permesas vin kunordigi kaj reĝisori vokojn al infrastrukturaj moduloj.
Tipa agorda dosiero de Terraform aspektas tiel.
Vi specifas kiun specifan modulon vi volas voki.
Kiajn dependecojn havas la modulo?
Kaj kiajn argumentojn ĉi tiu modulo akceptas. Tio estas ĉio por scii pri Terragrunt.
La dokumentaro estas tie, kaj estas 1 steloj sur GitHub. Sed plejofte ĉi tio estas kion vi bezonas scii. Kaj ĉi tio estas tre facile efektivigi en kompanioj, kiuj ĵus komencas labori kun Terraform.
Do orkestrado estas Terragrunt. Estas aliaj ebloj.
Nun ni parolu pri kiel labori kun la kodo.
Se vi bezonas aldoni novajn funkciojn al via kodo, plejofte ĉi tio estas facila. Vi skribas novan rimedon, ĉio estas simpla.
Se vi havas iun rimedon, kiun vi kreis antaŭe, ekzemple, vi lernis pri Terraform post kiam vi malfermis AWS-konton kaj volas uzi la rimedojn, kiujn vi jam havas, tiam taŭgus etendi vian modulon tiamaniere, por ke ĝi subtenas la uzon de ekzistantaj rimedoj.
Kaj subtenis la kreadon de novaj rimedoj uzante la blokrimedon.
Sur eligo ni ĉiam resendas eligo-identigilon depende de tio, kio estis uzata.
La dua tre signifa problemo en Terraform 0.11 estas labori kun listoj.
La malfacilaĵo estas ke se ni havas tian liston de uzantoj.
Kaj kiam ni kreas ĉi tiujn uzantojn uzante blokrimedon, tiam ĉio iras bone. Ni trarigardas la tutan liston, kreante dosieron por ĉiu. Ĉio estas en ordo. Kaj tiam, ekzemple, uzanto3, kiu estas en la mezo, devus esti forigita de ĉi tie, tiam ĉiuj rimedoj, kiuj estis kreitaj post li, estos rekreitaj ĉar la indekso ŝanĝiĝos.
Laborante kun listoj en ŝtata medio. Kio estas ŝtata medio? Ĉi tiu estas la situacio kie nova valoro estas kreita kiam ĉi tiu rimedo estas kreita. Ekzemple, AWS Access Key aŭ AWS Secret Key, t.e. kiam ni kreas uzanton, ni ricevas novan Aliron aŭ Sekretan Ŝlosilon. Kaj ĉiufoje kiam ni forigas uzanton, ĉi tiu uzanto havos novan ŝlosilon. Sed ĉi tio ne estas feng shui, ĉar la uzanto ne volos amikiĝi kun ni se ni kreos novan uzanton por li ĉiufoje kiam iu forlasas la teamon.
Jen la solvo. Ĉi tio estas kodo skribita en Jsonnet. Jsonnet estas ŝablona lingvo de Guglo.
Ĉi tiu komando permesas al vi akcepti ĉi tiun ŝablonon kaj kiel eligo ĝi resendas json-dosieron kiu estas farita laŭ via ŝablono.
La ŝablono aspektas tiel.
Terraform permesas vin labori kun ambaŭ HCL kaj Json en la sama maniero, do se vi havas la kapablon generi Json, tiam vi povas gliti ĝin en Terraform. La dosiero kun la etendo .tf.json estos elŝutita sukcese.
Kaj tiam ni laboras kun ĝi kiel kutime: terraform init, terramorm apliki. Kaj ni kreas du uzantojn.
Nun ni ne timas, se iu forlasas la teamon. Ni simple redaktos la json-dosieron. Vasja Pupkin foriris, Petja Pjatochkin restis. Petya Pyatochkin ne ricevos novan ŝlosilon.
Integri Terraform kun aliaj iloj ne estas vere la laboro de Terraform. Terraform estis kreita kiel platformo por krei rimedojn kaj jen ĝi. Kaj ĉio, kio aperas poste, ne koncernas Terraform. Kaj ne necesas teksi ĝin tie. Estas Ansible, kiu faras ĉion, kion vi bezonas.
Sed situacioj aperas kiam ni volas etendi Terraform kaj voki iun komandon post kiam io finiĝis.
Unua vojo. Ni kreas eligon, kie ni skribas ĉi tiun komandon.
Kaj tiam ni nomas ĉi tiun komandon el la ŝelo-teraform-produktaĵo kaj specifu la valoron, kiun ni volas. Tiel, la komando estas ekzekutita kun ĉiuj anstataŭigitaj valoroj. Ĝi estas tre komforta.
Dua vojo. Ĉi tio estas la uzo de null_resource depende de ŝanĝoj en nia infrastrukturo. Ni povas voki la saman lokan-exe tuj kiam la ID de iu rimedo ŝanĝiĝas.
Kompreneble, ĉi tio estas glata sur papero, ĉar Amazon, kiel ĉiuj aliaj publikaj provizantoj, havas amason da siaj propraj randaj kazoj.
La plej ofta randa kazo estas, ke kiam vi malfermas AWS-konton, gravas kiujn regionojn vi uzas; ĉu ĉi tiu funkcio estas ebligita tie; eble vi malfermis ĝin post decembro 2013; eble vi uzas defaŭltan en VPC ktp. Estas multaj limigoj. Kaj Amazon disigis ilin tra la dokumentado.
Estas kelkaj aferoj, kiujn mi rekomendas eviti.
Por komenci, evitu ĉiujn nesekretajn argumentojn ene de la Terraform-plano aŭ Terraform CLI. Ĉio ĉi povas esti metita aŭ en tfvars-dosieron aŭ en mediovariablon.
Sed vi ne bezonas parkerigi ĉi tiun tutan magian komandon. Terraform-plano - var kaj for ni iru. La unua variablo estas var, la dua variablo estas var, la tria, kvara. La plej grava principo de infrastrukturo kiel kodo, kiun mi plej ofte uzas, estas ke nur rigardante la kodon, mi devus havi klaran komprenon pri kio estas deplojita tie, en kiu stato kaj kun kiaj valoroj. Kaj do mi ne devas legi la dokumentaron aŭ demandi Vasja, kiajn parametrojn li uzis por krei nian areton. Mi nur bezonas malfermi dosieron kun la etendo tfvars, kiu ofte kongruas kun la medio, kaj rigardi ĉion tie.
Ankaŭ, ne uzu celargumentojn por redukti la amplekson. Por tio estas multe pli facile uzi malgrandajn infrastrukturajn modulojn.
Ankaŭ, ne necesas limigi kaj pliigi paralelecon. Se mi havas 150 rimedojn kaj mi volas pliigi Amazonan paralelecon de la defaŭlta 10 al 100, tiam plej verŝajne io misfunkcios. Aŭ ĝi eble iros bone nun, sed kiam Amazon diras, ke vi faras tro da vokoj, vi havos problemojn.
Terraform provos rekomenci la plej multajn el ĉi tiuj problemoj, sed vi atingos preskaŭ nenion. Paralelismo=1 estas grava afero por uzi se vi trovas iun cimon en la AWS API aŭ en la Terraform-provizanto. Kaj tiam vi devas specifi: paralelismo=1 kaj atendi ĝis Terraform finas unu vokon, tiam la duan, tiam la trian. Li lanĉos ilin unu post la alia.
Homoj ofte demandas min, "Kial mi pensas, ke la laborspacoj de Terraform estas malbonaj?" Mi kredas, ke la principo de infrastrukturo kiel kodo estas vidi, kia infrastrukturo estis kreita kaj kun kiaj valoroj.
Laborspacoj ne estis kreitaj de uzantoj. Ĉi tio ne signifas, ke uzantoj skribis en GitHub-problemojn, ke ni ne povas vivi sen laborspacoj de Terraform. Ne ne tiel. Terraform Enterprise estas komerca solvo. Terraform de HashiCorp decidis, ke ni bezonas laborspacojn, do ni arkivis ĝin. Mi trovas multe pli facile meti ĝin en apartan dosierujon. Tiam estos iom pli da dosieroj, sed ĝi estos pli klara.
Kiel labori kun la kodo? Fakte, labori kun listoj estas la sola doloro. Kaj prenu Terraform pli facile. Ĉi tio ne estas tio, kio faros ĉion bonega por vi. Ne necesas ŝovi tien ĉion, kio estas skribita en la dokumentaro.
La temo de la raporto estis skribita "por la estonteco". Mi parolos pri tio tre mallonge. Por la estonteco, tio signifas, ke 0.12 estos liberigita baldaŭ.
0.12 estas amaso da novaj aferoj. Se vi venas de regula programado, tiam vi maltrafas ĉiajn dinamikajn blokojn, buklojn, ĝustajn kaj kondiĉajn komparoperaciojn, kie la maldekstraj kaj dekstraj flankoj ne estas kalkulitaj samtempe, sed depende de la situacio. Vi multe sopiras, do 0.12 solvos ĝin por vi.
Sed! Se vi skribas malpli kaj pli simple, uzante pretajn modulojn kaj triajn solvojn, tiam vi ne devos atendi kaj esperi, ke venos 0.12 kaj riparos ĉion por vi.
Dankon pro la raporto! Vi parolis pri infrastrukturo kiel kodo kaj laŭvorte diris unu vorton pri testoj. Ĉu testoj necesas en moduloj? Kies respondeco estas ĉi tiu? Ĉu mi devas mem skribi ĝin aŭ ĉu ĝi estas respondeco de la moduloj?
La venonta jaro estos plenigita de raportoj, ke ni decidis provi ĉion. Kion testi estas la plej granda demando. Estas multaj dependecoj, multaj limigoj de malsamaj provizantoj. Kiam vi kaj mi parolas kaj vi diras: "Mi bezonas testojn", tiam mi demandas: "Kion vi provos?" Vi diras, ke vi provos en via regiono. Tiam mi diras, ke tio ne funkcias en mia regiono. Tio estas, ni eĉ ne povos konsenti pri tio. Sen mencii, ke estas multaj teknikaj problemoj. Tio estas, kiel skribi ĉi tiujn provojn por ke ili estu adekvataj.
Mi aktive esploras ĉi tiun temon, t.e. kiel aŭtomate generi testojn bazitajn sur la infrastrukturo, kiun vi skribis. Tio estas, se vi skribis ĉi tiun kodon, tiam mi devas ruli ĝin, surbaze de ĉi tio mi povas krei testojn.
estas unu el la plej ofte menciitaj bibliotekoj, kiu permesas vin verki integrigajn testojn por Terraform. Ĉi tiu estas unu el la utilecoj. Mi preferas la DSL-tipo, ekzemple, rspec.
Antono, dankon pro la raporto! Mia nomo estas Valery. Mi faru etan filozofian demandon. Estas, kondiĉe, provizado, estas deplojo. Provizado kreas mian infrastrukturon, en deplojo ni plenigas ĝin per io utila, ekzemple, serviloj, aplikaĵoj, ktp. Kaj estas en mia kapo, ke Terraform estas pli por provizora, kaj Ansible estas pli por deplojo, ĉar Ansible estas ankaŭ por fizika La infrastrukturo. permesas instali nginx, Postgres. Sed samtempe, Ansible ŝajnas permesi provizon, ekzemple, de Amazon- aŭ Guglo-resursoj. Sed Terraform ankaŭ permesas vin disfaldi iun programaron uzante ĝiajn modulojn. De via vidpunkto, ĉu ekzistas ia limo, kiu kuras inter Terraform kaj Ansible, kie kaj kio estas pli bone uzi? Aŭ, ekzemple, ĉu vi pensas, ke Ansible jam estas rubo, vi devus provi uzi Terraform por ĉio?
Bona demando, Valery. Mi kredas, ke Terraform ne ŝanĝiĝis laŭ celo ekde 2014. Ĝi estis kreita por infrastrukturo kaj mortis por infrastrukturo. Ni ankoraŭ havis kaj havos bezonon por agorda administrado Ansible. La defio estas, ke estas uzantdatenoj ene de launch_configuration. Kaj tie vi tiras Ansible ktp. Ĉi tiu estas la norma distingo, kiun mi plej ŝatas.
Se ni parolas pri bela infrastrukturo, tiam ekzistas utilecoj kiel Packer, kiuj kolektas ĉi tiun bildon. Kaj tiam Terraform uzas la datumfonton por trovi ĉi tiun bildon kaj ĝisdatigi ĝian lanĉon_agordon. Tio estas, tiamaniere la dukto estas ke ni unue tiras Tracker, tiam tiras Terraform. Kaj se konstruo okazas, tiam nova ŝanĝo okazas.
Saluton! Dankon pro la raporto! Mia nomo estas Misha, RBS-firmao. Vi povas voki Ansible per provizanto dum kreado de rimedo. Ansible ankaŭ havas temon nomitan dinamika inventaro. Kaj vi unue povas voki Terraform, kaj poste voki Ansible, kiu prenos rimedojn de la ŝtato kaj ekzekutos ĝin. Kio estas pli bona?
Homoj uzas ambaŭ kun egala sukceso. Ŝajnas al mi, ke dinamika inventaro en Ansible estas oportuna afero, se ni ne parolas pri aŭtoskala grupo. Ĉar en la grupo de aŭtoskalo ni jam havas nian propran ilaron, kiu nomiĝas lanĉo_agordo. En launch_configuration ni registras ĉion, kio bezonas esti lanĉita kiam ni kreas novan rimedon. Sekve, kun Amazon, uzi dinamikan inventaron kaj legi la Terraform ts-dosieron, laŭ mi, estas troege. Kaj se vi uzas aliajn ilojn, kie ne ekzistas koncepto de "aŭtomatskala grupo", ekzemple, vi uzas DigitalOcean aŭ iun alian provizanton, kie ne ekzistas aŭtoskala grupo, tiam vi devos mane tiri la API, trovi IP-adresojn, krei. dinamika inventaro dosiero , kaj Ansible jam vagos tra ĝi. Tio estas, por Amazon estas launch_configuration, kaj por ĉio alia estas dinamika inventaro.
fonto: www.habr.com