Om infrastruktuur as kode in 'n herhaalbare teksformaat voor te stel, is 'n eenvoudige beste praktyk vir stelsels wat nie met muise hoef te vroetel nie. Hierdie praktyk het 'n naam - , en tot dusver is daar twee gewilde instrumente om dit te implementeer, veral in AWS: и .
Vergelyk ervaring met Terraform en CloudFormation
Voor kom na (hy is ) Ek het gewerk en het Terraform drie jaar lank gebruik. By die nuwe plek het ek Terraform ook met alle mag gebruik, en toe het die maatskappy die oorgang na alles a la Amazon gedryf, insluitend CloudFormation. Ek het ywerig beste praktyke vir albei ontwikkel, en het albei instrumente in baie komplekse, organisasiewye werkvloeie gebruik. Later, nadat ek die implikasies van die migreer van Terraform na CloudFormation deeglik opgeweeg het, het ek oortuig geraak dat Terraform waarskynlik die beste keuse vir die organisasie was.
Terraform Verskriklik
Beta sagteware
Terraform het nog nie eers weergawe 1.0 vrygestel nie, wat 'n goeie rede is om dit nie te gebruik nie. Dit het baie verander sedert ek dit die eerste keer self probeer het, maar destyds terraform apply het dikwels gebreek na verskeie opdaterings of bloot na 'n paar jaar se gebruik. Ek sou sê dat "alles nou anders is," maar ... dit is wat almal blykbaar sê, nee? Daar is veranderinge wat nie met vorige weergawes versoenbaar is nie, hoewel dit gepas is, en dit voel selfs of die sintaksis en abstraksies van hulpbronwinkels nou is wat ons nodig het. Dit lyk of die instrument regtig beter geword het, maar... :-0
Aan die ander kant het AWS 'n goeie werk gedoen om terugwaartse verenigbaarheid te handhaaf. Dit is waarskynlik omdat hul dienste dikwels deeglik binne die organisasie getoets word en eers dan, hernoem, gepubliseer word. So "hulle het hard probeer" is 'n understatement. Dit is ongelooflik moeilik om terugwaartse verenigbaarheid met API's te handhaaf vir 'n stelsel so gevarieerd en kompleks soos AWS. Enigiemand wat publieke API's moes onderhou wat so wyd gebruik word as wat hulle is, moet verstaan hoe moeilik dit is om dit vir soveel jare te doen. Maar die gedrag van CloudFormation, in my geheue, het nooit oor die jare verander nie.
Ontmoet die been... dis 'n koeël
Sover ek weet, verwyder die hulpbron buitestander CloudFormation-stapel vanaf jou CF-stapel is nie moontlik nie. Dieselfde geld met Terraform. Dit laat jou toe om bestaande hulpbronne in jou stapel in te voer. Die funksie kan gesê word dat dit ongelooflik is, maar met groot krag kom groot verantwoordelikheid. Jy hoef net 'n hulpbron by die stapel te voeg, en terwyl jy met jou stapel werk, kan jy nie hierdie hulpbron uitvee of verander nie. Eendag het dit teruggeval. Eendag op Twitch het iemand per ongeluk iemand anders se AWS-sekuriteitsgroep in hul eie Terraform-stapel ingevoer terwyl hy nie met enige onheil was nie. Ek het verskeie opdragte ingevoer en ... die sekuriteitsgroep (saam met inkomende verkeer) het verdwyn.
Terraform Groot
Herstel van onvolledige toestande
Soms kan CloudFormation nie heeltemal van een toestand na 'n ander oorgaan nie. Terselfdertyd sal hy probeer om terug te keer na die vorige een. Dit is jammer dat dit nie altyd haalbaar is nie. Dit kan nogal skrikwekkend wees om te ontfout wat later gebeur het - jy weet nooit of CloudFormation gelukkig sal wees dat dit gehack word nie - selfs net om dit reg te maak. Of dit moontlik sal wees om terug te keer na die vorige toestand, weet hy regtig nie hoe om te bepaal nie en, by verstek, hang hy vir ure en wag vir 'n wonderwerk.
Terraform, aan die ander kant, is geneig om baie meer grasieus van mislukte oorgange te herstel en bied gevorderde ontfoutingsinstrumente.
Duideliker veranderinge aan dokumentstatus
“Goed, load balancer, jy verander. Maar hoe?"
- benoude ingenieur, gereed om die "aanvaar"-knoppie te druk.
Soms moet ek 'n paar manipulasies met die lasbalanseerder in die CloudFormation-stapel doen, soos om 'n poortnommer by te voeg of 'n sekuriteitsgroep te verander. ClouFormation vertoon veranderinge swak. Ek, op spelde en naalde, gaan die yaml-lêer tien keer na om seker te maak dat ek niks wat nodig is uitgevee het nie en niks onnodig bygevoeg het nie.
Terraform is baie meer deursigtig in hierdie verband. Soms is hy selfs te deursigtig (lees: vervelig). Gelukkig bevat die jongste weergawe verbeterde vertoon van veranderinge sodat jy nou presies kan sien wat verander.
Buigsaamheid
Skryf sagteware agteruit.
Om dit reguit te stel, is die belangrikste kenmerk van langlewende sagteware die vermoë om by verandering aan te pas. Skryf enige sagteware agteruit. Ek het meestal foute gemaak deur 'n "eenvoudige" diens te neem en dan alles in 'n enkele CloudFormation- of Terraform-stapel te begin prop. En natuurlik, maande later het dit aan die lig gekom dat ek alles verkeerd verstaan het, en die diens was eintlik nie eenvoudig nie! En nou moet ek op een of ander manier 'n groot stapel in klein komponente breek. As u met CloudFormation werk, kan dit slegs gedoen word deur eers die bestaande stapel te herskep, en ek doen dit nie met my databasisse nie. Terraform, aan die ander kant, het dit moontlik gemaak om die stapel te dissekteer en dit in meer verstaanbare kleiner dele af te breek.
Modules in git
Om Terraform-kode oor verskeie stapels te deel is baie makliker as om CloudFormation-kode te deel. Met Terraform kan u u kode in 'n git-bewaarplek plaas en toegang daartoe kry met behulp van semantiese weergawebeheer. Enigiemand met toegang tot hierdie bewaarplek kan die gedeelde kode hergebruik. CloudFormation se ekwivalent is S3, maar dit het nie dieselfde voordele nie, en daar is geen rede waarom ons git enigsins ten gunste van S3 moet laat vaar nie.
Die organisasie het gegroei en die vermoë om gemeenskaplike stapels te deel het 'n kritieke vlak bereik. Terraform maak dit alles maklik en natuurlik, terwyl CloudFormation jou deur hoepels sal laat spring voordat jy so iets kan laat werk.
Bewerkings as kode
"Kom ons skryf dit en goed."
-'n ingenieur 3 jaar voor die uitvind van die Terraform-fiets.
As dit by sagteware-ontwikkeling kom, is Go of 'n Java-program nie net kode nie.
Kodeer as Kode
Daar is ook die infrastruktuur waarop dit werk.
Infrastruktuur as kode
Maar waar kom sy vandaan? Hoe om dit te monitor? Waar woon jou kode? Het ontwikkelaars toegangstoestemming nodig?
Bedrywighede as kode
Om 'n sagteware-ontwikkelaar te wees, beteken nie net om kode te skryf nie.
AWS is nie die enigste een nie: jy gebruik waarskynlik ander verskaffers. SignalFx, PagerDuty of Github. Miskien het jy 'n interne Jenkins-bediener vir CI/CD of 'n interne Grafana-dashboard vir monitering. Infra as Code word om verskillende redes gekies, en elkeen is ewe belangrik vir alles wat met sagteware verband hou.
Toe ek by Twitch gewerk het, het ons dienste binne Amazon se gemengde ingebedde en AWS-stelsels versnel. Ons het baie mikrodienste uitgestof en ondersteun, wat die bedryfskoste verhoog het. Die besprekings het iets soos volg verloop:
- Я: Damn, dit is baie gebare om een mikrodiens te oorklok. Ek sal hierdie gemors moet gebruik om 'n AWS-rekening te skep (ons het na 2 rekeninge gegaan mikrodiens), dan hierdie een vir die opstel van waarskuwings, hierdie een vir 'n kodebewaarplek, en hierdie een vir 'n e-poslys, en dan hierdie een ...
- Lood: Kom ons skryf dit en goed.
- Я: Goed, maar die skrif self sal verander. Ons sal 'n manier nodig hê om seker te maak dat al hierdie ingeboude Amazon-gizmo's op datum is.
- Lood: Klink goed. En ons sal 'n draaiboek hiervoor skryf.
- Я: Puik! En die skrif sal waarskynlik nog parameters moet stel. Sal hy hulle aanvaar?
- Lood: Laat hy vat waar hy gaan!
- Я: Die proses kan verander en terugwaartse versoenbaarheid sal verlore gaan. 'n Soort semantiese weergawebeheer sal vereis word.
- Lood: Goeie idee!
- Я: Gereedskap kan met die hand verander word, binne die gebruikerskoppelvlak. Ons sal 'n manier nodig hê om dit na te gaan en reg te stel.
… 3 jaar later:
- Lood: En ons het terraform gekry.
Die moraal van die storie is: al is jy halsoorkop in alles Amazon, jy gebruik steeds iets wat nie van AWS af is nie, en hierdie dienste het 'n toestand wat 'n konfigurasietaal gebruik om daardie toestand gesinchroniseer te hou.
CloudFormation lambda vs git modules terraform
lambda is CloudFormation se oplossing vir die pasgemaakte logika-kwessie. Met lambda kan jy of . Hierdie benadering stel bykomende kompleksiteite bekend wat nie teenwoordig is in Terraform se semantiese weergawe van git-modules nie. Vir my was die mees dringende probleem die bestuur van toestemmings vir al hierdie gebruikers lambdas (en dit is dosyne AWS-rekeninge). Nog 'n belangrike probleem was die "wat het eerste gekom, die hoender of die eier?"-probleem: dit het verband gehou met lambda-kode. Hierdie funksie self is infrastruktuur en kode, en dit self benodig monitering en opdaterings. Die laaste spyker in die kis was die moeilikheid om lambda-kode veranderinge semanties by te werk; ons moes ook seker maak dat die stapelaksies sonder 'n direkte opdrag nie tussen lopies verander nie.
Ek onthou dat ek eenkeer 'n kanarie-ontplooiing vir die Elastic Beanstalk-omgewing wou skep met 'n klassieke load balancer. Die maklikste ding om te doen sou wees om 'n tweede ontplooiing vir die EB langs die produksie-omgewing te maak, wat dit 'n stap verder neem: die kombinasie van die outo-skaal kanarie-ontplooiingsgroep met die ontplooiing LB in die produksie-omgewing. En aangesien Terraform gebruik , sal dit 4 ekstra reëls kode in Terraform vereis. Toe ek gevra het of daar 'n vergelykbare oplossing in CloudFormation is, het hulle my na 'n hele git-bewaarplek met 'n ontplooiingspyplyn en alles gewys, alles ter wille van iets wat swak 4 reëls Terraform-kode kon doen.
Dit bespeur dryf beter
Maak seker die werklikheid pas by verwagtinge.
is 'n baie kragtige bedrywighede as kode-funksie, want dit help verseker dat die werklikheid ooreenstem met verwagtinge. Dit is beskikbaar met beide CloudFormation en Terraform. Maar namate die produksiestapel gegroei het, het soek na drif in CloudFormation meer en meer vals bespeurings opgelewer.
Met Terraform het jy baie meer gevorderde lewensiklushake vir dryfbespeuring. Byvoorbeeld, jy voer die opdrag in direk in die ECS-taakdefinisie as jy veranderinge aan 'n spesifieke taakdefinisie wil ignoreer sonder om veranderinge aan jou hele ECS-ontplooiing te ignoreer.
CDK en die toekoms van CloudFormation
CloudFormation is moeilik om te bestuur op groot, kruis-infrastruktuur skale. Baie van hierdie probleme word erken en die instrument benodig dinge soos , 'n raamwerk om wolkinfrastruktuur in kode te definieer en dit deur AWS CloudFormation te laat loop. Dit sal interessant wees om te sien wat die toekoms vir aws-cdk inhou, maar dit sal moeilik met Terraform se ander sterkpunte meeding; om CloudFormation op datum te bring, sal globale veranderinge vereis word.
Sodat Terraform nie teleurstel nie
Dit is "infrastruktuur as 'n kode", en nie "as 'n teks nie".
My eerste indruk van Terraform was nogal sleg. Ek dink ek het net nie die benadering verstaan nie. Byna alle ingenieurs sien dit onwillekeurig as 'n teksformaat wat in die verlangde infrastruktuur omgeskakel moet word. MOENIE DIT SO DOEN NIE.
Die waarheid van goeie sagteware-ontwikkeling geld ook vir Terraform.
Ek het gesien hoe baie praktyke wat aangeneem is om goeie kode te skep, in Terraform geïgnoreer word. Jy het jare lank studeer om 'n goeie programmeerder te word. Moenie hierdie ervaring opgee net omdat jy met Terraform werk nie. Die waarheid van goeie sagteware-ontwikkeling is van toepassing op Terraform.
Hoe kan die kode nie gedokumenteer word nie?
Ek het groot Terraform-stapels gesien met absoluut geen dokumentasie nie. Hoe kan jy kode in bladsye skryf - met absoluut geen dokumentasie nie? Voeg dokumentasie by wat jou verduidelik kode Terraform (klem op die woord "kode"), hoekom hierdie afdeling so belangrik is, en wat jy doen.
Hoe kan ons dienste ontplooi wat eens een groot hoof()-funksie was?
Ek het baie komplekse Terraform-stapels gesien wat as 'n enkele module aangebied word. Hoekom ontplooi ons nie sagteware op hierdie manier nie? Hoekom verdeel ons groot funksies in kleineres? Dieselfde antwoorde geld vir Terraform. As jou module te groot is, moet jy dit in kleiner modules opdeel.
Gebruik jou maatskappy nie biblioteke nie?
Ek het gesien hoe ingenieurs, wat 'n nuwe projek met behulp van Terraform saamgestel het, groot stukke van ander projekte domweg in hul eie gekopieer het, en dan met hulle gepeuter het totdat dit begin werk het. Sal jy so werk met "combat" kode in jou maatskappy? Ons gebruik nie net biblioteke nie. Ja, maar waar is ons in beginsel sonder gedeelde biblioteke?!
Gebruik jy nie PEP8 of gofmt nie?
Die meeste tale het 'n standaard, aanvaarde formateringskema. In Python is dit PEP8. In Go - gofmt. Terraform het sy eie: terraform fmt. Geniet dit vir jou gesondheid!
Sal jy React gebruik sonder om JavaScript te ken?
Terraform-modules kan 'n deel van die komplekse infrastruktuur wat jy skep vereenvoudig, maar dit beteken nie dat jy glad nie daaraan kan peuter nie. Wil jy Terraform korrek gebruik sonder om hulpbronne te verstaan? Jy is gedoem: tyd sal verbygaan, en jy sal nooit Terraform bemeester nie.
Koder jy met enkellinge of afhanklikheidsinspuiting?
Afhanklikheidsinspuiting is 'n erkende beste praktyk vir sagteware-ontwikkeling en word verkies bo enkellopendes. Hoe is dit nuttig in Terraform? Ek het Terraform-modules gesien wat afhanklik is van afgeleë toestand. In plaas daarvan om modules te skryf wat afgeleë toestand herwin, skryf 'n module wat parameters neem. En gee dan hierdie parameters deur na die module.
Doen jou biblioteke tien dinge goed of een ding wonderlik?
Biblioteke wat die beste werk, is dié wat fokus op een taak wat hulle baie goed doen. In plaas daarvan om groot Terraform-modules te skryf wat alles op een slag probeer doen, bou dele daarvan wat een ding goed doen. En kombineer hulle dan soos nodig.
Hoe maak jy veranderinge aan biblioteke sonder terugwaartse versoenbaarheid?
'n Algemene Terraform-module, soos 'n gewone biblioteek, moet op een of ander manier veranderinge aan gebruikers kommunikeer sonder om agteruit versoenbaar te wees. Dit is irriterend wanneer hierdie veranderinge in biblioteke plaasvind, en dit is net so irriterend wanneer nie-terugversoenbare veranderinge in Terraform-modules gemaak word. Dit word aanbeveel om git-tags en semver te gebruik wanneer Terraform-modules gebruik word.
Werk jou produksiediens op jou skootrekenaar of in 'n datasentrum?
Hashicorp het gereedskap soos om jou terraform te hardloop. Hierdie gesentraliseerde dienste maak dit maklik om terraform-veranderinge te bestuur, te oudit en goed te keur.
Skryf jy nie toetse nie?
Ingenieurs erken dat die kode getoets moet word, maar hulle vergeet self dikwels van toetsing wanneer hulle met Terraform werk. Vir infrastruktuur is dit belaai met verraderlike oomblikke. My raad is om stapels te "toets" of "voorbeelde te skep" deur modules te gebruik wat korrek ontplooi kan word vir toetsing tydens CI/CD.
Terraform en mikrodienste
Die lewe en dood van mikrodiensmaatskappye hang af van die spoed, innovasie en ontwrigting van nuwe mikrodienswerkstapels.
Die mees algemene negatiewe aspek wat verband hou met mikrodiensargitekture, en wat nie uitgeskakel kan word nie, hou verband met die werk, nie die kode nie. As u aan Terraform dink as net 'n manier om slegs die infrastruktuurkant van 'n mikrodiensargitektuur te outomatiseer, dan mis u die ware voordele van die stelsel. Nou is dit reeds .
Bron: will.com