Infrastruktuurin esittäminen koodina toistettavassa tekstimuodossa on yksinkertainen paras käytäntö järjestelmille, jotka eivät vaadi hiirillä näpertelyä. Tällä harjoituksella on nimi - , ja toistaiseksi sen toteuttamiseen on kaksi suosittua työkalua, erityisesti AWS:ssä: и .
Kokemusten vertailu Terraformista ja CloudFormationista
Ennen tuloaan (Aka ) Työskentelin ja käytti Terraformia kolme vuotta. Uudessa paikassa käytin myös Terraformia kaikin voimin, ja sitten yritys painoi siirtymistä kaikkeen a la Amazoniin, mukaan lukien CloudFormation. Olen ahkerasti kehittänyt parhaita käytäntöjä molemmille ja olen käyttänyt molempia työkaluja erittäin monimutkaisissa, organisaation laajuisissa työnkulkuissa. Myöhemmin punnittuani Terraformista CloudFormationiin siirtymisen seurauksia vakuuttuin siitä, että Terraform oli luultavasti paras valinta organisaatiolle.
Terraform kamala
Beta-ohjelmisto
Terraform ei ole vielä edes julkaissut versiota 1.0, mikä on hyvä syy olla käyttämättä sitä. Se on muuttunut paljon siitä lähtien, kun kokeilin sitä itse, mutta silloin terraform apply hajosi usein useiden päivitysten jälkeen tai yksinkertaisesti muutaman vuoden käytön jälkeen. Sanoisin, että "kaikki on nyt toisin", mutta... näin kaikki näyttävät sanovan, eikö? On muutoksia, jotka eivät ole yhteensopivia aiempien versioiden kanssa, vaikka ne ovat asianmukaisia, ja tuntuu jopa siltä, että resurssivarastojen syntaksi ja abstraktiot ovat nyt sitä, mitä tarvitsemme. Instrumentti näyttää todella parantuneen, mutta... :-0
Toisaalta AWS on tehnyt hyvää työtä taaksepäin yhteensopivuuden ylläpitämisessä. Tämä johtuu luultavasti siitä, että heidän palvelunsa testataan usein perusteellisesti organisaatiossa ja vasta sitten nimetään uudelleen, ne julkaistaan. Joten "he yrittivät kovasti" on vähättelyä. AWS:n kaltaisen monipuolisen ja monimutkaisen järjestelmän taaksepäin yhteensopivuuden ylläpitäminen API:iden kanssa on uskomattoman vaikeaa. Jokaisen, joka on joutunut ylläpitämään julkisia sovellusliittymiä, joita käytetään yhtä laajasti kuin ne ovat, pitäisi ymmärtää, kuinka vaikeaa se on tehdä niin monta vuotta. Mutta muistini mukaan CloudFormationin käyttäytyminen ei ole koskaan muuttunut vuosien varrella.
Tapaa jalka... se on luoti
Sikäli kuin tiedän, poista resurssi ulkopuolinen CloudFormation-pino CF-pinostasi ei ole mahdollista. Sama pätee Terraformiin. Sen avulla voit tuoda olemassa olevia resursseja pinoosi. Toimintoa voidaan sanoa hämmästyttäväksi, mutta suurella teholla tuo mukanaan suuri vastuu. Sinun tarvitsee vain lisätä resurssi pinoon, ja kun työskentelet pinon kanssa, et voi poistaa tai muuttaa tätä resurssia. Eräänä päivänä se kolahti. Eräänä päivänä Twitchissä joku toi vahingossa jonkun toisen AWS-suojausryhmän omaan Terraform-pinoonsa ilman, että hän teki mitään pahaa. Annoin useita komentoja ja... turvaryhmä (saapuvan liikenteen kanssa) katosi.
Terraform loistava
Toipuminen epätäydellisistä tiloista
Joskus CloudFormation ei pysty täysin siirtymään tilasta toiseen. Samalla hän yrittää palata edelliseen. Harmi, että tämä ei aina ole mahdollista. Voi olla melko pelottavaa jäljittää mitä tapahtui myöhemmin - et koskaan tiedä, onko CloudFormation iloinen, että se hakkeroidaan - jopa vain korjatakseen sen. Onko mahdollista palata edelliseen tilaan vai ei, hän ei todellakaan tiedä kuinka määrittää ja oletuksena roikkuu tuntikausia odottaen ihmettä.
Toisaalta Terraformilla on taipumus toipua epäonnistuneista siirroista paljon sulavammin ja tarjoaa edistyneitä virheenkorjaustyökaluja.
Selkeämmät muutokset asiakirjan tilaan
"Okei, kuormantasaaja, olet muuttumassa. Mutta miten?"
— ahdistunut insinööri, valmis painamaan "hyväksy"-painiketta.
Joskus minun on tehtävä joitain manipulaatioita CloudFormation-pinon kuormituksen tasapainottimella, kuten lisättävä porttinumero tai muutettava suojausryhmää. ClouFormation näyttää muutokset huonosti. Tarkistan yaml-tiedoston kymmenen kertaa, että en ole poistanut mitään tarpeellista enkä lisännyt mitään tarpeetonta.
Terraform on paljon läpinäkyvämpi tässä suhteessa. Joskus hän on jopa liian läpinäkyvä (lue: tylsä). Onneksi uusimmassa versiossa on paranneltu muutosten näyttö, joten voit nyt nähdä tarkalleen, mikä muuttuu.
joustavuus
Kirjoita ohjelmisto taaksepäin.
Suoraan sanottuna pitkäikäisten ohjelmistojen tärkein ominaisuus on kyky sopeutua muutoksiin. Kirjoita mikä tahansa ohjelmisto taaksepäin. Useimmiten tein virheitä ottamalla "yksinkertaisen" palvelun ja aloin sitten pakata kaiken yhteen CloudFormation- tai Terraform-pinoon. Ja tietysti kuukausia myöhemmin paljastui, että olin ymmärtänyt kaiken väärin, eikä palvelu todellakaan ollut yksinkertaista! Ja nyt minun täytyy jotenkin hajottaa suuri pino pieniksi komponenteiksi. Kun työskentelet CloudFormationin kanssa, tämä voidaan tehdä vain luomalla ensin olemassa oleva pino uudelleen, mutta en tee tätä tietokantoillani. Terraform puolestaan mahdollisti pinon leikkaamisen ja jakamisen ymmärrettävämmiksi pienempiin osiin.
Moduulit gitissä
Terraform-koodin jakaminen useiden pinojen kesken on paljon helpompaa kuin CloudFormation-koodin jakaminen. Terraformin avulla voit laittaa koodisi git-tietovarastoon ja käyttää sitä semanttisen versionhallinnan avulla. Jokainen, jolla on pääsy tähän tietovarastoon, voi käyttää jaettua koodia uudelleen. CloudFormationin vastine on S3, mutta sillä ei ole samoja etuja, eikä ole mitään syytä miksi meidän pitäisi luopua gitistä S3:n hyväksi.
Organisaatio kasvoi ja kyky jakaa yhteisiä pinoja saavutti kriittisen tason. Terraform tekee tästä kaikesta helppoa ja luonnollista, kun taas CloudFormation saa sinut hyppäämään vanteiden läpi ennen kuin saat tämän toimimaan.
Toiminnot koodina
"Käsikirjoitetaan se ja okei."
-insinööri 3 vuotta ennen Terraform-pyörän keksimistä.
Mitä tulee ohjelmistokehitykseen, Go tai Java-ohjelma ei ole vain koodia.
Koodi koodina
Siellä on myös infrastruktuuri, jolla se toimii.
Infrastruktuuri koodina
Mutta mistä hän on kotoisin? Miten sitä valvotaan? Missä koodisi sijaitsee? Tarvitsevatko kehittäjät käyttöoikeudet?
Toiminnot koodina
Ohjelmistokehittäjänä oleminen ei tarkoita vain koodin kirjoittamista.
AWS ei ole ainoa: käytät todennäköisesti muita palveluntarjoajia. SignalFx, PagerDuty tai Github. Ehkä sinulla on sisäinen Jenkins-palvelin CI/CD:tä varten tai sisäinen Grafana-kojelauta valvontaa varten. Infra koodiksi valitaan eri syistä, ja jokainen on yhtä tärkeä kaikessa ohjelmistoon liittyvässä.
Kun työskentelin Twitchillä, nopeutimme palveluita Amazonin sulautettujen ja AWS-järjestelmien sisällä. Suoritimme ja tuimme monia mikropalveluita, mikä nosti käyttökustannuksia. Keskustelut menivät jotenkin näin:
- Я: Hitto, siinä on paljon eleitä yhden mikropalvelun ylikellottamiseksi. Minun on käytettävä tätä roskaa AWS-tilin luomiseen (menimme kahteen tiliin mikropalvelu), sitten tämä hälytyksiä varten, tämä koodivarastoa varten ja tämä sähköpostilistaa varten ja sitten tämä...
- Johtaa: Käsikirjoitetaan se ja ok.
- Я: Okei, mutta itse käsikirjoitus muuttuu. Tarvitsemme tavan tarkistaa, että kaikki nämä sisäänrakennetut Amazonin laitteet ovat ajan tasalla.
- Johtaa: Kuulostaa hyvältä. Ja kirjoitamme käsikirjoituksen tähän.
- Я: Loistava! Ja skriptin on todennäköisesti vielä asetettava parametreja. Hyväksyykö hän ne?
- Johtaa: Anna hänen viedä minne menee!
- Я: Prosessi saattaa muuttua ja taaksepäin yhteensopivuus menetetään. Jonkinlainen semanttinen versionhallinta vaaditaan.
- Johtaa: Hyvä idea!
- Я: Työkaluja voidaan vaihtaa manuaalisesti käyttöliittymän sisällä. Tarvitsemme keinon tarkistaa ja korjata tämä.
…3 vuotta myöhemmin:
- Johtaa: Ja meillä on terraform.
Tarinan moraali on: vaikka sinä pään yli kaikessa Amazonissa, käytät edelleen jotain muuta kuin AWS:stä, ja näillä palveluilla on tila, joka käyttää määrityskieltä pitääkseen tilan synkronoituna.
CloudFormation lambda vs git moduulit terraform
lambda on CloudFormationin ratkaisu mukautettuun logiikkaongelmaan. Lambdalla voi tai . Tämä lähestymistapa tuo ylimääräisiä monimutkaisuuksia, joita ei ole Terraformin git-moduulien semanttisessa versiossa. Minulle kiireellisin ongelma oli kaikkien näiden käyttäjien lambda-oikeuksien hallinta (ja nämä ovat kymmeniä AWS-tilejä). Toinen tärkeä ongelma oli "mikä oli ensin, kana vai muna?" -ongelma: se liittyi lambda-koodiin. Tämä toiminto itsessään on infrastruktuuria ja koodia, ja se tarvitsee seurantaa ja päivityksiä. Viimeinen naula arkkuun oli vaikeus semanttisesti päivittää lambda-koodimuutoksia; meidän oli myös varmistettava, että pinotoiminnot ilman suoraa komentoa eivät muutu ajojen välillä.
Muistan kerran, että halusin luoda Canary-sovelluksen Elastic Beanstalk -ympäristöön klassisella kuormituksen tasapainottimella. Helpoin tapa olisi tehdä toinen käyttöönotto EB:lle tuotantoympäristön rinnalle, mikä vie sitä askeleen pidemmälle: yhdistämällä automaattisesti skaalautuva Canary-käyttöönottoryhmä käyttöönotto-LB:hen tuotantoympäristöön. Ja koska Terraform käyttää , tämä vaatii 4 ylimääräistä koodiriviä Terraformissa. Kun kysyin, oliko CloudFormationissa vertailukelpoista ratkaisua, he osoittivat minut koko git-tietovarastoon, jossa oli käyttöönottoputki ja kaikki, kaiken sen vuoksi, mitä köyhät 4 riviä Terraform-koodia voisivat tehdä.
Se havaitsee ajautumisen paremmin
Varmista, että todellisuus vastaa odotuksia.
on erittäin tehokas kooditoiminto, koska se auttaa varmistamaan, että todellisuus vastaa odotuksia. Se on saatavana sekä CloudFormationin että Terraformin kanssa. Mutta kun tuotantopino kasvoi, CloudFormationin driftin etsiminen tuotti yhä enemmän vääriä havaintoja.
Terraformilla sinulla on paljon edistyneemmät elinkaaren koukut ajautumisen havaitsemiseen. Syötät esimerkiksi komennon suoraan ECS-tehtävämäärittelyssä, jos haluat ohittaa tietyn tehtävämäärittelyn muutokset jättämättä huomiotta koko ECS-käyttöönoton muutoksia.
CDK ja CloudFormationin tulevaisuus
CloudFormationia on vaikea hallita suurissa, infrastruktuurien välisissä mittakaavassa. Monet näistä vaikeuksista tunnistetaan ja työkalu tarvitsee sellaisia asioita , kehys pilviinfrastruktuurin määrittämiseen koodissa ja sen suorittamiseen AWS CloudFormationin kautta. On mielenkiintoista nähdä, mitä tulevaisuus tuo tullessaan aws-cdk:lle, mutta sen on vaikea kilpailla Terraformin muiden vahvuuksien kanssa; CloudFormationin päivittäminen edellyttää maailmanlaajuisia muutoksia.
Terraform ei petä
Tämä on "infrastruktuuri koodina", ei "tekstinä".
Ensivaikutelmani Terraformista oli melko huono. Luulen, että en vain ymmärtänyt lähestymistapaa. Melkein kaikki insinöörit näkevät sen tahattomasti tekstimuotona, joka on muutettava haluttuun infrastruktuuriin. ÄLÄ TEE SITÄ NÄIN.
Hyvän ohjelmistokehityksen totuus pätee myös Terraformiin.
Olen nähnyt monia hyvän koodin luomiseen omaksuttuja käytäntöjä, jotka jätetään huomiotta Terraformissa. Olet opiskellut vuosia tullaksesi hyväksi ohjelmoijaksi. Älä luovu tästä kokemuksesta vain siksi, että työskentelet Terraformin kanssa. Hyvän ohjelmistokehityksen totuus pätee Terraformiin.
Miten koodia ei voi dokumentoida?
Olen nähnyt valtavia Terraform-pinoja ilman mitään dokumentaatiota. Kuinka voit kirjoittaa koodia sivuille - ilman mitään asiakirjoja? Lisää asiakirjoja, jotka selittävät sinun koodi Terraform (korostus sanalla "koodi"), miksi tämä osio on niin tärkeä ja mitä teet.
Kuinka voimme ottaa käyttöön palveluita, jotka olivat kerran yksi suuri main()-toiminto?
Olen nähnyt erittäin monimutkaisia Terraform-pinoja yhtenä moduulina. Miksi emme ota ohjelmistoja käyttöön tällä tavalla? Miksi jaamme suuret funktiot pienempiin? Samat vastaukset koskevat Terraformia. Jos moduulisi on liian suuri, sinun on jaettava se pienempiin moduuleihin.
Eikö yrityksesi käytä kirjastoja?
Olen nähnyt, kuinka insinöörit keksivät uutta projektia Terraformilla, kopioivat typerästi valtavia paloja muista projekteista omiin omiinsa ja sitten puuhailivat niitä, kunnes se alkoi toimia. Työskenteletkö tällä tavalla "taistelukoodin" kanssa yrityksessäsi? Emme käytä vain kirjastoja. Joo, mutta missä olemme ilman yhteisiä kirjastoja periaatteessa?!
Etkö käytä PEP8:aa tai gofmt:tä?
Useimmilla kielillä on standardi, hyväksytty muotoilumalli. Pythonissa tämä on PEP8. In Go - gofmt. Terraformilla on oma: terraform fmt. Nauti siitä terveytesi vuoksi!
Käytätkö Reactia tuntematta JavaScriptiä?
Terraform-moduulit voivat yksinkertaistaa osaa luomastasi monimutkaisesta infrastruktuurista, mutta tämä ei tarkoita, etteikö sitä voisi käsitellä ollenkaan. Haluatko käyttää Terraformia oikein ymmärtämättä resursseja? Olet tuomittu: aika kuluu, etkä koskaan hallitse Terraformia.
Koodaatko singletonilla tai riippuvuusruiskeella?
Riippuvuuslisäys on tunnustettu paras käytäntö ohjelmistokehityksessä, ja se on suositeltavampi kuin singletons. Miten tämä on hyödyllistä Terraformissa? Olen nähnyt Terraform-moduuleja, jotka riippuvat etätilasta. Sen sijaan, että kirjoittaisit moduulit, jotka hakevat etätilan, kirjoita moduuli, joka ottaa parametrit. Ja sitten välitä nämä parametrit moduulille.
Tekevätkö kirjastosi kymmenen asiaa hyvin vai yhden asian hienosti?
Parhaiten toimivat kirjastot, jotka keskittyvät yhteen tehtävään, jonka he tekevät erittäin hyvin. Sen sijaan, että kirjoittaisit suuria Terraform-moduuleja, jotka yrittävät tehdä kaiken kerralla, rakenna niistä osia, jotka tekevät yhden asian hyvin. Ja sitten yhdistä ne tarpeen mukaan.
Kuinka teet muutoksia kirjastoihin ilman taaksepäin yhteensopivuutta?
Tavallisen Terraform-moduulin, kuten tavallisen kirjaston, on viestittävä muutoksista käyttäjille jotenkin ilman, että se on taaksepäin yhteensopiva. On ärsyttävää, kun näitä muutoksia tapahtuu kirjastoissa, ja se on yhtä ärsyttävää, kun Terraform-moduuleissa tehdään ei-takaisin yhteensopivia muutoksia. On suositeltavaa käyttää git-tageja ja semveriä käytettäessä Terraform-moduuleja.
Onko tuotantopalvelusi käynnissä kannettavalla tietokoneellasi vai konesalissa?
Hashicorpilla on työkaluja, kuten ajaaksesi terraformiasi. Nämä keskitetyt palvelut tekevät terraformin muutosten hallinnasta, tarkastamisesta ja hyväksymisestä helppoa.
Etkö kirjoita kokeita?
Insinöörit tiedostavat, että koodia on testattava, mutta he itse usein unohtavat testauksen työskennellessään Terraformin kanssa. Infrastruktuurin kannalta tämä on täynnä petollisia hetkiä. Neuvoni on "testata" tai "luoda esimerkki" pinoja käyttämällä moduuleja, jotka voidaan ottaa käyttöön oikein testausta varten CI/CD:n aikana.
Terraform ja mikropalvelut
Mikropalveluyritysten elämä ja kuolema riippuu uusien mikropalvelutyöpinojen nopeudesta, innovatiivisuudesta ja häiriöistä.
Yleisin mikropalveluarkkitehtuureihin liittyvä negatiivinen puoli, jota ei voida poistaa, liittyy työhön, ei koodiin. Jos ajattelet, että Terraform on vain tapa automatisoida vain mikropalveluarkkitehtuurin infrastruktuuripuoli, menetät järjestelmän todelliset edut. Nyt se on jo .
Lähde: will.com