Reprezenti infrastrukturon kiel kodon en ripetebla tekstformato estas simpla plej bona praktiko por sistemoj kiuj ne postulas ludadon kun musoj. Ĉi tiu praktiko havas nomon - , kaj ĝis nun ekzistas du popularaj iloj por efektivigi ĝin, precipe en AWS: и .
Komparante sperton kun Terraform kaj CloudFormation
Antaŭ ol veni al (li estas ) Mi laboris kaj uzis Terraform dum tri jaroj. Ĉe la nova loko, mi ankaŭ uzis Terraform kun ĉiuj miaj fortoj, kaj tiam la firmao antaŭenpuŝis la transiron al ĉio en Amazon, inkluzive de CloudFormation. Mi diligente evoluigis plej bonajn praktikojn por ambaŭ, kaj uzis ambaŭ ilojn en tre kompleksaj, tutorganizaj laborfluoj. Poste, pripensinte la implicojn de migrado de Terraform al CloudFormation, mi konvinkiĝis, ke Terraform verŝajne estas la plej bona elekto por la organizo.
Terraform Terura
Beta-programaro
Terraform eĉ ne publikigis version 1.0 ankoraŭ, kio estas bona kialo por ne uzi ĝin. Ĝi multe ŝanĝiĝis de kiam mi unue provis ĝin mem, sed tiam terraform apply ofte paneis post pluraj ĝisdatigoj aŭ simple post kelkaj jaroj da uzo. Mi dirus, ke "ĉio estas alia nun", sed... tion ĉiuj ŝajnas diri, ĉu ne? Estas ŝanĝoj, kiuj estas malkongruaj kun antaŭaj versioj, kvankam ili estas taŭgaj, kaj eĉ ŝajnas, ke la sintakso kaj abstraktaĵoj de rimedaj vendejoj nun estas kion ni bezonas. La instrumento ŝajnas vere pliboniĝi, sed... :-0
Aliflanke, AWS faris bonan laboron konservante malantaŭan kongruecon. Ĉi tio verŝajne estas ĉar iliaj servoj ofte estas ĝisfunde testitaj ene de la organizo kaj nur tiam, renomitaj, estas publikigitaj. Do "ili klopodis" estas subkompreno. Konservi malantaŭan kongruon kun API-oj por sistemo tiel varia kaj kompleksa kiel AWS estas nekredeble malfacila. Ĉiu, kiu devis konservi publikajn API-ojn, kiuj estas uzataj same vaste, devus kompreni kiom malfacile estas fari tion dum tiom da jaroj. Sed la konduto de CloudFormation, en mia memoro, neniam ŝanĝiĝis tra la jaroj.
Renkontu la kruron... ĝi estas kuglo
Laŭ mia scio, forigu la rimedon eksterulo CloudFormation-stako de via CF-stako ne eblas. La sama estas vera kun Terraform. Ĝi permesas vin importi ekzistantajn rimedojn en vian stakon. Oni povas diri, ke la funkcio estas mirinda, sed kun granda potenco venas granda respondeco. Vi nur bezonas aldoni rimedon al la stako, kaj dum vi laboras kun via stako, vi ne povas forigi aŭ ŝanĝi ĉi tiun rimedon. Iun tagon ĝi miskarburis. Iun tagon ĉe Twitch, iu hazarde importis la sekurecan grupon de AWS de aliulo en sian propran Terraform-stakon, dum ne faris ajnan petolon. Mi enigis plurajn komandojn kaj... la sekureca grupo (kune kun envenanta trafiko) malaperis.
Terraform Granda
Reakiro de nekompletaj statoj
Kelkfoje CloudFormation malsukcesas tute transiri de unu ŝtato al alia. Samtempe, li provos reveni al la antaŭa. Domaĝe, ke tio ne ĉiam estas farebla. Povas esti sufiĉe timiga sencimi kio okazis poste - vi neniam scias ĉu CloudFormation estos feliĉa ke ĝi estas hakita - eĉ nur por ripari ĝin. Ĉu li povos reveni al la antaŭa stato aŭ ne, li ne vere scias kiel determini kaj, defaŭlte, pendas dum horoj atendante miraklon.
Terraform, aliflanke, emas resaniĝi de malsukcesaj transiroj multe pli gracie kaj ofertas altnivelajn sencimigajn ilojn.
Pli klaraj ŝanĝoj al dokumenta stato
“Bone, ŝarĝbalancilo, vi ŝanĝas. Sed kiel?"
—maltrankvila inĝeniero, preta premi la butonon "akcepti".
Kelkfoje mi devas fari iujn manipuladojn kun la ŝarĝbalancilo en la stako CloudFormation, kiel aldoni havenon aŭ ŝanĝi sekurecan grupon. ClouFormation montras ŝanĝojn malbone. Mi, sur pingloj kaj nadloj, duoble kontrolas la yaml-dosieron dek fojojn por certigi, ke mi ne forigis ion necesan kaj aldonis nenion nenecesan.
Terraform estas multe pli travidebla ĉi-rilate. Kelkfoje li estas eĉ tro travidebla (legu: enuiga). Feliĉe, la plej nova versio inkluzivas plibonigitan montradon de ŝanĝoj, tiel ke vi nun povas vidi ĝuste kio ŝanĝiĝas.
Fleksebleco
Skribu programaron malantaŭen.
Por diri ĝin malklare, la plej grava karakterizaĵo de longdaŭra programaro estas la kapablo adaptiĝi al ŝanĝo. Skribu ajnan programaron malantaŭen. Plej ofte mi eraris prenante "simplan" servon, kaj tiam komencante ŝtopiĝi ĉion en ununuran CloudFormation aŭ Terraform-stakon. Kaj kompreneble, monatojn poste estis rivelita, ke mi komprenis ĉion malbone, kaj la servo fakte ne estis simpla! Kaj nun mi devas iel rompi grandan stakon en malgrandajn komponantojn. Kiam vi laboras kun CloudFormation, ĉi tio povas esti farita nur unue rekreante la ekzistantan stakon, kaj mi ne faras tion kun miaj datumbazoj. Terraform, aliflanke, ebligis dissekci la stakon kaj rompi ĝin en pli kompreneblajn pli malgrandajn partojn.
Moduloj en git
Kunhavigi Terraform-kodon tra pluraj stakoj estas multe pli facila ol kunhavigi CloudFormation-kodon. Kun Terraform, vi povas meti vian kodon en git-deponejon kaj aliri ĝin uzante semantikan version-kontrolon. Ĉiu kun aliro al ĉi tiu deponejo povas reuzi la komunan kodon. La ekvivalento de CloudFormation estas S3, sed ĝi ne havas la samajn avantaĝojn, kaj ne ekzistas kialo kial ni tute forlasu git favore al S3.
La organizo kreskis kaj la kapablo dividi oftajn stakojn atingis kritikan nivelon. Terraform faras ĉi tion ĉio facila kaj natura, dum CloudFormation igos vin salti tra ringoj antaŭ ol vi povas fari ion tian funkciadon.
Operacioj kiel kodo
"Ni skribu ĝin kaj bone."
—inĝeniero 3 jarojn antaŭ ol inventi la Terraform-biciklon.
Kiam temas pri programaro, Go aŭ Java programo ne estas nur kodo.
Kodo kiel Kodo
Ekzistas ankaŭ la infrastrukturo sur kiu ĝi funkcias.
Infrastrukturo kiel Kodo
Sed de kie ŝi estas? Kiel kontroli ĝin? Kie loĝas via kodo? Ĉu programistoj bezonas alirpermeson?
Operacioj kiel Kodo
Esti programisto ne signifas nur skribi kodon.
AWS ne estas la sola: vi verŝajne uzas aliajn provizantojn. SignalFx, PagerDuty aŭ Github. Eble vi havas internan Jenkins-servilon por CI/KD aŭ internan Grafana panelo por monitorado. Infra kiel Kodo estas elektita pro malsamaj kialoj, kaj ĉiu estas same grava por ĉio rilata al programaro.
Kiam mi laboris ĉe Twitch, ni akcelis servojn en la miksitaj enigitaj kaj AWS-sistemoj de Amazon. Ni ellaboris kaj subtenis multajn mikroservojn, pliigante funkciajn kostojn. La diskutoj iris tiel:
- Я: Damne, tio estas multaj gestoj por overclock unu mikroservo. Mi devos uzi ĉi tiun rubon por krei AWS-konton (ni iris al 2 kontoj sur mikroservo), tiam ĉi tiu por agordi atentigojn, ĉi tiun por koddeponejo, kaj ĉi tiu por retpoŝta listo, kaj poste ĉi tiu...
- Plumbo: Ni skribu ĝin kaj bone.
- Я: Bone, sed la skripto mem ŝanĝiĝos. Devos esti maniero kontroli, ke ĉiuj ĉi tiuj enkonstruitaj Amazon-aparatoj estas ĝisdatigitaj.
- Plumbo: Sonas bone. Kaj ni skribos skripton por ĉi tio.
- Я: Bonege! Kaj la skripto probable ankoraŭ bezonos agordi parametrojn. Ĉu li akceptos ilin?
- Plumbo: Li prenu kien li iras!
- Я: La procezo povas ŝanĝiĝi kaj malantaŭen kongruo estos perdita. Ia semantika versio-kontrolo estos postulata.
- Plumbo: Bonega ideo!
- Я: Iloj povas esti ŝanĝitaj permane, ene de la uzantinterfaco. Ni bezonos manieron kontroli kaj ripari ĉi tion.
… 3 jarojn poste:
- Plumbo: Kaj ni akiris teraformon.
La moralo de la rakonto estas: eĉ se vi super kalkanoj en ĉio Amazon, vi ankoraŭ uzas ion ne de AWS, kaj ĉi tiuj servoj havas staton, kiu uzas agordan lingvon por konservi tiun staton sinkronigita.
CloudFormation lambda vs git-moduloj terraform
lambda estas la solvo de CloudFormation al la kutima logika problemo. Kun lambda vi povas aŭ . Ĉi tiu aliro lanĉas kromajn kompleksecojn kiuj ne ĉeestas en la semantika versio de Terraform de git-moduloj. Por mi, la plej urĝa problemo estis administri permesojn por ĉiuj ĉi tiuj uzantlambdoj (kaj ĉi tiuj estas dekoj da AWS-kontoj). Alia grava problemo estis la problemo "kio unue venis, la kokido aŭ la ovo?": ĝi rilatis al lambda kodo. Ĉi tiu funkcio mem estas infrastrukturo kaj kodo, kaj ĝi mem bezonas monitoradon kaj ĝisdatigojn. La fina najlo en la ĉerko estis la malfacileco en semantike ĝisdatigi lambda kodŝanĝojn; ni ankaŭ devis certigi, ke la stakaj agoj sen rekta komando ne ŝanĝiĝis inter kuroj.
Mi memoras, ke iam mi volis krei kanarian deplojon por la Elastic Beanstalk-medio kun klasika ŝarĝbalancilo. La plej facila afero estus fari duan deplojon por la EB apud la produktadmedio, farante ĝin pli for: kombinante la aŭto-skalan kanarian deplojgrupon kun la deplojo LB en la produktadmedion. Kaj ĉar Terraform uzas , ĉi tio postulos 4 kromajn liniojn de kodo en Terraform. Kiam mi demandis, ĉu ekzistas komparebla solvo en CloudFormation, ili indikis min al tuta git-deponejo kun disfalda dukto kaj ĉio, ĉio pro io, kion povraj 4 linioj de Terraform-kodo povus fari.
Ĝi pli bone detektas drivon
Certigu, ke realeco kongruas kun atendoj.
estas tre potenca operacio kiel koda trajto ĉar ĝi helpas certigi ke realeco kongruas atendojn. Ĝi estas havebla kun kaj CloudFormation kaj Terraform. Sed dum la produktadstako kreskis, serĉi drivon en CloudFormation produktis pli kaj pli da malveraj detektoj.
Kun Terraform vi havas multe pli altnivelajn vivciklajn hokojn por detekto de drivo. Ekzemple, vi enigu la komandon rekte en la ECS-taskodifino se vi volas ignori ŝanĝojn al specifa taskodifino sen ignori ŝanĝojn al via tuta ECS-deplojo.
CDK kaj la estonteco de CloudFormation
CloudFormation estas malfacile administrebla je grandaj, trans-infrastrukturaj skaloj. Multaj el ĉi tiuj malfacilaĵoj estas rekonitaj kaj la ilo bezonas aferojn kiel , kadro por difini nuban infrastrukturon en kodo kaj prizorgi ĝin per AWS CloudFormation. Estos interese vidi, kion la estonteco rezervas por aws-cdk, sed malfacile konkuros kun la aliaj fortoj de Terraform; por ĝisdatigi CloudFormation, necesas tutmondaj ŝanĝoj.
Do ke Terraform ne seniluziigas
Ĉi tio estas "infrastrukturo kiel kodo", kaj ne "kiel teksto".
Mia unua impreso pri Terraform estis sufiĉe malbona. Mi pensas, ke mi simple ne komprenis la aliron. Preskaŭ ĉiuj inĝenieroj nevole perceptas ĝin kiel tekstformaton, kiu devas esti konvertita en la deziratan infrastrukturon. NE FARU TIEL.
La veraĵoj de bona programaro ankaŭ validas por Terraform.
Mi vidis multajn praktikojn adoptitajn por krei bonan kodon ignoritajn en Terraform. Vi studis dum jaroj por fariĝi bona programisto. Ne rezignu ĉi tiun sperton nur ĉar vi laboras kun Terraform. La veraĵoj de bona programaro-disvolviĝo validas por Terraform.
Kiel oni povas ne dokumenti la kodon?
Mi vidis grandegajn Terraform-stakojn kun absolute neniu dokumentaro. Kiel vi povas skribi kodon en paĝoj - sen absolute neniu dokumentado? Aldonu dokumentadon, kiu klarigas vian kodo Terraform (emfazo sur la vorto "kodo"), kial ĉi tiu sekcio estas tiel grava, kaj kion vi faras.
Kiel ni povas disfaldi servojn, kiuj iam estis unu granda ĉefa () funkcio?
Mi vidis tre kompleksajn Terraform-stakojn prezentitajn kiel ununuran modulon. Kial ni ne deplojas programaron ĉi tiel? Kial ni dividas grandajn funkciojn en pli malgrandajn? La samaj respondoj validas por Terraform. Se via modulo estas tro granda, vi devas dividi ĝin en pli malgrandajn modulojn.
Ĉu via kompanio ne uzas bibliotekojn?
Mi vidis kiel inĝenieroj, ŝpinante novan projekton uzante Terraform, stulte kopiis grandegajn pecojn de aliaj projektoj en sian propran, kaj poste tuŝis ilin ĝis ĝi ekfunkciis. Ĉu vi laborus tiel kun "batala" kodo en via kompanio? Ni ne nur uzas bibliotekojn. Jes, sed kie ni estas principe sen komunaj bibliotekoj?!
Ĉu vi ne uzas PEP8 aŭ gofmt?
Plej multaj lingvoj havas norman, akceptitan formatskemon. En Python ĉi tio estas PEP8. En Go - gofmt. Terraform havas sian propran: terraform fmt. Ĝuu ĝin por via sano!
Ĉu vi uzos React sen koni JavaScript?
Terraform-moduloj povas simpligi iun parton de la kompleksa infrastrukturo, kiun vi kreas, sed ĉi tio ne signifas, ke vi tute ne povas ludi ĝin. Ĉu vi volas uzi Terraform ĝuste sen kompreni rimedojn? Vi estas kondamnita: tempo pasos, kaj vi neniam regos Terraform.
Ĉu vi kodas per singletons aŭ dependa injekto?
Dependeca injekto estas agnoskita plej bona praktiko por programaro kaj estas preferita ol unuopaĵoj. Kiel tio utilas en Terraform? Mi vidis Terraform-modulojn kiuj dependas de fora stato. Anstataŭ skribi modulojn kiuj reakiras malproksiman staton, skribu modulon kiu prenas parametrojn. Kaj poste transdonu ĉi tiujn parametrojn al la modulo.
Ĉu viaj bibliotekoj faras dek aferojn bone aŭ unu aferon bonega?
Bibliotekoj kiuj funkcias plej bone estas tiuj, kiuj fokusiĝas al unu tasko, kiun ili tre bone faras. Anstataŭ verki grandajn modulojn de Terraform, kiuj provas fari ĉion samtempe, konstruu partojn de ili, kiuj bone faras unu aferon. Kaj tiam kombini ilin laŭbezone.
Kiel vi faras ŝanĝojn al bibliotekoj sen retrokongruo?
Ofta Terraform-modulo, kiel regula biblioteko, bezonas iel komuniki ŝanĝojn al uzantoj sen esti malantaŭen kongrua. Estas ĝene kiam ĉi tiuj ŝanĝoj okazas en bibliotekoj, kaj same ĝenas kiam ne-malantaŭen-kongruaj ŝanĝoj estas faritaj en moduloj de Terraform. Oni rekomendas uzi git-etikedojn kaj semver kiam oni uzas Terraform-modulojn.
Ĉu via produktadservo funkcias sur via tekkomputilo aŭ en datumcentro?
Hashicorp havas ilojn kiel por prizorgi vian terraformon. Ĉi tiuj centralizitaj servoj faciligas administri, revizii kaj aprobi teraformajn ŝanĝojn.
Ĉu vi ne skribas testojn?
Inĝenieroj rekonas, ke la kodo devas esti provita, sed ili mem ofte forgesas pri testado kiam ili laboras kun Terraform. Por infrastrukturo, ĉi tio estas plena de perfidaj momentoj. Mia konsilo estas "testi" aŭ "krei ekzemplojn" stakojn uzante modulojn kiuj povas esti deplojitaj ĝuste por testado dum CI/KD.
Terraform kaj mikroservoj
La vivo kaj morto de mikroservaj kompanioj dependas de la rapideco, novigo kaj interrompo de novaj mikroservoj.
La plej ofta negativa aspekto asociita kun mikroservaj arkitekturoj, kaj kiu ne povas esti forigita, rilatas al la laboro, ne al la kodo. Se vi pensas pri Terraform kiel nur maniero aŭtomatigi nur la infrastrukturan flankon de mikroserva arkitekturo, tiam vi maltrafas la verajn avantaĝojn de la sistemo. Nun jam estas .
fonto: www.habr.com