Monet ihmiset tuntevat ja käyttävät Terraformia päivittäisessä työssään, mutta parhaita käytäntöjä siihen ei ole vielä muodostettu. Jokaisen joukkueen on keksittävä omat lähestymistapansa ja menetelmänsä.
Infrastruktuurisi alkaa melkein varmasti yksinkertaiselta: muutama resurssi + muutama kehittäjä. Ajan myötä se kasvaa kaikkiin suuntiin. Löydätkö tapoja ryhmitellä resursseja Terraform-moduuleiksi, järjestää koodia kansioihin ja mikä muu voi mennä pieleen? (kuuluisat viimeiset sanat)
Aika kuluu ja sinusta tuntuu, että infrastruktuurisi on uusi lemmikkisi, mutta miksi? Olet huolissasi infrastruktuurin selittämättömistä muutoksista, pelkäät koskea infrastruktuuriin ja koodiin - seurauksena viivyttelet uusia toimintoja tai alentaa laatua...
Hallittuaan kolme vuotta Terraform-yhteisömoduulien kokoelmaa AWS:lle Githubissa ja pitkään jatkuneen Terraformin tuotannon ylläpidon jälkeen Anton Babenko on valmis jakamaan kokemuksensa: kuinka kirjoittaa TF-moduuleja niin, ettei se haittaa tulevaisuudessa.
Puheen loppuun mennessä osallistujat tuntevat paremmin Terraformin resurssienhallinnan periaatteet, Terraformin moduuleisiin liittyvät parhaat käytännöt ja eräät infrastruktuurin hallintaan liittyvät jatkuvan integroinnin periaatteet.
Disclaimer: Huomautan, että tämä raportti on päivätty marraskuussa 2018 – 2 vuotta on jo kulunut. Raportissa käsiteltyä Terraform 0.11 -versiota ei enää tueta. Viimeisten 2 vuoden aikana on julkaistu 2 uutta julkaisua, jotka sisältävät paljon innovaatioita, parannuksia ja muutoksia. Huomioi tämä ja tarkista asiakirjat.
viitteet:
- +
- — automaattisesti muotoiltu koodi ja asiakirjat
- — Terraform-moduulien generaattori (WIP)
- - Terraform-koodigeneraattori visuaalisista kaavioista (WIP)
- www.terraform-best-practices.com
- (Uudet viestit ovat henkilökohtaisella verkkosivustollani www.antonbabenko.com/)
- @antonbabenko - Twitter ja joukko erilaisia housuja
Nimeni on Anton Babenko. Jotkut teistä luultavasti käyttivät kirjoittamaani koodia. Puhun tästä nyt enemmän luottavaisin mielin kuin koskaan, koska minulla on pääsy tilastoihin.
Työskentelen Terraformilla ja olen ollut aktiivinen osallistuja ja avustaja useissa Terraformiin ja Amazoniin liittyvissä avoimen lähdekoodin projekteissa vuodesta 2015 lähtien.
Siitä lähtien olen kirjoittanut tarpeeksi koodia esittääkseni sen mielenkiintoisella tavalla. Ja yritän kertoa sinulle tästä nyt.
Puhun Terraformin kanssa työskentelyn monimutkaisuudesta ja erityispiirteistä. Mutta se ei todellakaan ole HighLoadin aihe. Ja nyt ymmärrät miksi.
Ajan myötä aloin kirjoittaa Terraform-moduuleja. Käyttäjät kirjoittivat kysymyksiä, minä kirjoitin ne uudelleen. Sitten kirjoitin erilaisia apuohjelmia koodin muotoiluun käyttämällä pre-commit-koukkua jne.
Oli monia mielenkiintoisia projekteja. Pidän koodin luomisesta, koska pidän siitä, että tietokone tekee yhä enemmän työtä minulle ja ohjelmoijalle, joten työskentelen tällä hetkellä Terraform-koodigeneraattorin parissa visuaalisista kaavioista. Ehkä jotkut teistä ovat nähneet ne. Nämä ovat kauniita laatikoita nuolilla. Ja mielestäni on hienoa, jos voit napsauttaa "Vie" -painiketta ja saada kaikki koodina.
Olen Ukrainasta. Olen asunut Norjassa monta vuotta.
Lisäksi tiedot tätä raporttia varten kerättiin ihmisiltä, jotka tietävät nimeni ja löytävät minut sosiaalisista verkostoista. Minulla on melkein aina sama lempinimi.
Kuten mainitsin, olen Terraform AWS -moduulien pääylläpitäjä, joka on yksi suurimmista GitHubin arkistoista, jossa isännöimme moduuleja yleisimpiin tehtäviin: VPC, Autoscaling, RDS.
Ja se, mitä kuulit nyt, on alkeellisinta. Jos epäilet ymmärtäväsi mitä Terraform on, on parempi viettää aikasi jossain muualla. Tässä tulee olemaan paljon teknisiä termejä. Ja en epäröinyt julistaa raportin tasoa korkeimmaksi. Tämä tarkoittaa, että voin puhua kaikilla mahdollisilla termeillä ilman paljon selityksiä.
Terraform ilmestyi vuonna 2014 apuohjelmana, jonka avulla voit kirjoittaa, suunnitella ja hallita infrastruktuuria koodina. Avainkäsite tässä on "infrastruktuuri koodina".
Kaikki asiakirjat, kuten sanoin, on kirjoitettu sisään . Toivon, että useimmat ihmiset tietävät tästä sivustosta ja ovat lukeneet asiakirjat. Jos näin on, olet oikeassa paikassa.
Tältä näyttää tavallinen Terraform-määritystiedosto, jossa määritetään ensin joitain muuttujia.
Tässä tapauksessa määrittelemme "aws_region".
Sitten kuvailemme, mitä resursseja haluamme luoda.
Suoritamme joitain komentoja, erityisesti "terraform init" ladataksemme riippuvuuksia ja palveluntarjoajia.
Ja suoritamme "terraform apply" -komennon tarkistaaksemme, vastaako määritetty kokoonpano luomiamme resursseja. Koska emme ole luoneet mitään aiemmin, Terraform kehottaa meitä luomaan nämä resurssit.
Vahvistamme tämän. Näin luomme ämpärin nimeltä Seanail.
Vastaavia apuohjelmia on myös useita. Monet teistä Amazonin käyttäjistä tuntevat AWS CloudFormationin tai Google Cloud Deployment Managerin tai Azure Resource Managerin. Jokaisella niistä on jonkinlainen oma toteutus resurssien hallintaan kussakin näistä julkisista pilvipalveluntarjoajista. Terraform on erityisen hyödyllinen, koska sen avulla voit hallita yli 100 palveluntarjoajaa. (Lisätietoja )
Terraformin tavoitteet alusta asti:
- Terraform tarjoaa yhden näkymän resursseista.
- Mahdollistaa kaikkien nykyaikaisten alustojen tukemisen.
- Ja Terraform on suunniteltu alusta alkaen apuohjelmaksi, jonka avulla voit muuttaa infrastruktuuria turvallisesti ja ennustettavasti.
Vuonna 2014 sana "ennustettavissa oleva" kuulosti hyvin epätavalliselta tässä yhteydessä.
Terraform on universaali apuohjelma. Jos sinulla on API, voit hallita aivan kaikkea:
- Voit käyttää yli 120 palveluntarjoajaa hallitaksesi kaikkea mitä haluat.
- Voit esimerkiksi käyttää Terraformia kuvaamaan pääsyä GitHub-tietovarastoihin.
- Voit jopa luoda ja sulkea bugeja Jirassa.
- Voit hallita New Relic -mittareita.
- Voit jopa luoda tiedostoja dropboxissa, jos todella haluat.
Tämä kaikki saavutetaan käyttämällä Terraform-palveluntarjoajia, joilla on avoin API, joka voidaan kuvata Gossa.
Oletetaan, että aloimme käyttää Terraformia, luimme sivuston dokumentaatiota, katsoimme videota ja aloimme kirjoittaa main.tf-tiedostoa, kuten näytin edellisissä dioissa.
Ja kaikki on hienoa, sinulla on tiedosto, joka luo VPC:n.
Jos haluat luoda VPC:n, määritä noin 12 riviä. Kuvaile, millä alueella haluat luoda, mitä IP-osoitteiden cidr_blockia käytetään. Siinä kaikki.
Luonnollisesti hanke kasvaa vähitellen.
Ja lisäät sinne joukon uusia asioita: resursseja, tietolähteitä, integroidut uusiin palveluntarjoajiin, yhtäkkiä haluat käyttää Terraformia käyttäjien hallintaan GitHub-tililläsi jne. Saatat haluta käyttää erilaisia DNS-palveluntarjoajat ylittävät kaiken. Terraform tekee tämän helpoksi.
Katsotaanpa seuraavaa esimerkkiä.
Lisäät asteittain internet_gatewayn, koska haluat, että VPC:n resurssit saavat Internet-yhteyden. Tämä on hyvä idea.
Tuloksena on tämä main.tf:
Tämä on main.tf:n yläosa.
Tämä on main.tf:n alaosa.
Sitten lisäät aliverkon. Kun haluat lisätä NAT-yhdyskäytäviä, reittejä, reititystaulukoita ja joukon muita aliverkkoja, sinulla ei ole 38 riviä, vaan noin 200-300 riviä.
Main.tf-tiedostosi kasvaa asteittain. Ja melko usein ihmiset laittavat kaiken yhteen tiedostoon. Main.tf:ssä näkyy 10-20 kb. Kuvittele, että 10-20 kt on tekstisisältöä. Ja kaikki liittyy kaikkeen. Tämän kanssa työskentely on vähitellen vaikeaa. 10-20 Kb on hyvä käyttäjätapaus, joskus enemmänkin. Ja ihmiset eivät aina ajattele, että tämä on huono.
Kuten tavallisessa ohjelmoinnissa, eli ei infrastruktuuria koodina, olemme tottuneet käyttämään joukkoa erilaisia luokkia, paketteja, moduuleja, ryhmittelyjä. Terraformin avulla voit tehdä paljon saman asian.
- Koodi kasvaa.
- Myös resurssien väliset riippuvuudet kasvavat.
Ja meillä on suuri, suuri tarve. Ymmärrämme, että emme voi enää elää näin. Koodimme on tulossa valtavaksi. 10-20 Kb ei tietenkään ole kovin suuri, mutta puhumme vain verkkopinosta, eli olet vain lisännyt verkkoresursseja. Emme puhu Application Load Balancerista, käyttöönotto ES-klusterista, Kubernetesista jne., joihin 100 Kb voidaan helposti pudota. Jos kirjoitat kaiken tämän muistiin, huomaat hyvin pian, että Terraform tarjoaa Terraform-moduuleja.
Terraform-moduulit ovat itsenäinen Terraform-kokoonpano, jota hallitaan ryhmänä. Siinä kaikki, mitä sinun tarvitsee tietää Terraform-moduuleista. Ne eivät ole ollenkaan älykkäitä, ne eivät anna sinun tehdä monimutkaisia yhteyksiä jostakin riippuen. Tämä kaikki on kehittäjien harteilla. Eli tämä on vain jonkinlainen Terraform-kokoonpano, jonka olet jo kirjoittanut. Ja voit kutsua sitä yksinkertaisesti ryhmäksi.
Joten yritämme ymmärtää, kuinka optimoimme 10-20-30 kb koodimme. Ymmärrämme vähitellen, että meidän on käytettävä joitain moduuleja.
Ensimmäiset kohtaamasi moduulit ovat resurssimoduulit. He eivät ymmärrä, mistä infrastruktuurissasi on kyse, mistä yrityksesi on kyse, missä ja mitkä ehdot ovat. Nämä ovat juuri niitä moduuleja, joita minä yhdessä avoimen lähdekoodin yhteisön kanssa hallinnoin ja jotka esitimme infrastruktuurisi ensimmäisinä rakennuspalikoina.
Esimerkki resurssimoduulista.
Kun kutsumme resurssimoduulia, määritämme, mistä polusta meidän tulee ladata sen sisältö.
Ilmoitamme, minkä version haluamme ladata.
Käsittelemme siellä joukon argumentteja. Siinä kaikki. Se on kaikki, mitä meidän on tiedettävä, kun käytämme tätä moduulia.
Monet ihmiset ajattelevat, että jos he käyttävät uusinta versiota, kaikki on vakaata. Mutta ei. Infrastruktuuri on versioitava; meidän on vastattava selvästi, mihin versioon tämä tai tuo komponentti on otettu käyttöön.
Tässä on koodi, joka on tämän moduulin sisällä. Turvaryhmämoduuli. Tässä vieritys menee 640. riville. Turvallisuusryhmän resurssin luominen Amazonissa kaikissa mahdollisissa kokoonpanoissa on erittäin ei-triviaali tehtävä. Ei riitä, että luot vain turvaryhmän ja kerrot sille, mitkä säännöt sille välitetään. Se olisi hyvin yksinkertaista. Amazonissa on miljoona erilaista rajoitusta. Esimerkiksi jos käytät VPC-päätepiste, etuliiteluettelo, erilaiset API:t ja yrittää yhdistää kaiken tämän kaiken muun kanssa, niin Terraform ei salli sinun tehdä tätä. Ja Amazon API ei myöskään salli tätä. Siksi meidän on piilotettava kaikki tämä kauhea logiikka moduuliin ja annettava käyttäjäkoodi, joka näyttää juuri tältä.
Käyttäjän ei tarvitse tietää, miten se on valmistettu sisällä.
Toisen tyyppiset moduulit, jotka koostuvat resurssimoduuleista, ratkaisevat jo ongelmia, jotka soveltuvat paremmin yritykseesi. Usein tämä on paikka, joka on Terraformin laajennus ja asettaa joitain jäykkiä arvoja tunnisteille, yrityksen standardeille. Voit myös lisätä sinne toimintoja, joita Terraform ei tällä hetkellä salli sinun käyttää. Tämä on juuri nyt. Nyt versio 0.11, josta on tulossa menneisyyttä. Mutta silti esiprosessorit, jsonnet, cookiecutter ja joukko muita asioita ovat apumekanismi, jota on käytettävä täysimittaiseen työhön.
Seuraavaksi näytän muutamia esimerkkejä tästä.
Infrastruktuurimoduulia kutsutaan täsmälleen samalla tavalla.
Lähde, josta sisältö ladataan, ilmoitetaan.
Joukko arvoja välitetään ja siirretään tähän moduuliin.
Seuraavaksi tämän moduulin sisällä kutsutaan joukko resurssimoduuleita luomaan VPC tai Application Load Balancer tai luomaan suojausryhmä tai Elastic Container Service -klusteri.
Moduuleja on kahdenlaisia. Tämä on tärkeää ymmärtää, koska suurinta osaa tähän raporttiin ryhmittelemistäni tiedoista ei ole kirjoitettu dokumentaatioon.
Ja Terraformin dokumentaatio tällä hetkellä on melko ongelmallista, koska se vain sanoo, että nämä ominaisuudet ovat olemassa, voit käyttää niitä. Mutta hän ei kerro, kuinka näitä ominaisuuksia käytetään, miksi niitä on parempi käyttää. Siksi hyvin suuri joukko ihmisiä kirjoittaa jotain, jonka kanssa he eivät voi elää.
Katsotaanpa seuraavaksi näiden moduulien kirjoittamista. Sitten katsotaan, kuinka heille kutsutaan ja miten koodia käytetään.
Terraform-rekisteri -
Vihje #0 on olla kirjoittamatta resurssimoduuleja. Suurin osa näistä moduuleista on jo kirjoitettu sinulle. Kuten sanoin, ne ovat avoimen lähdekoodin, ne eivät sisällä mitään liiketoimintalogiikkaasi, niissä ei ole kovakoodattuja arvoja IP-osoitteille, salasanoille jne. Moduuli on erittäin joustava. Ja se on todennäköisesti jo kirjoitettu. Amazonista löytyy monia moduuleja resursseille. Noin 650. Ja useimmat ovat hyvälaatuisia.
Tässä esimerkissä joku tuli luoksesi ja sanoi: "Haluan pystyä hallitsemaan tietokantaa. Luo moduuli, jotta voin luoda tietokannan." Henkilö ei tiedä Amazonin tai Terraformin toteutustietoja. Hän sanoo yksinkertaisesti: "Haluan hallita MSSQL:ää." Tarkoitamme siis, että se kutsuu moduuliamme, välittää moottorityypin sinne ja ilmoittaa aikavyöhykkeen.
Eikä ihmisen pitäisi tietää, että luomme kaksi erilaista resurssia tämän moduulin sisään: yhden MSSQL:lle, toisen kaikelle muulle, vain siksi, että Terraform 0.11:ssä et voi määrittää aikavyöhykearvoja valinnaisiksi.
Ja tästä moduulista poistuessaan henkilö voi yksinkertaisesti vastaanottaa osoitteen. Hän ei tiedä mistä tietokannasta, mistä resurssista luomme kaiken tämän sisäisesti. Tämä on erittäin tärkeä osa salailua. Ja tämä ei koske vain niitä moduuleja, jotka ovat julkisia avoimessa lähdekoodissa, vaan myös niitä moduuleja, jotka kirjoitat projekteissasi ja ryhmissäsi.
Tämä on toinen argumentti, joka on varsin tärkeä, jos olet käyttänyt Terraformia jonkin aikaa. Sinulla on arkisto, johon sijoitat kaikki yrityksesi Terraform-moduulit. Ja on aivan normaalia, että ajan myötä tämä projekti kasvaa yhden tai kahden megatavun kokoiseksi. Tämä on hyvä.
Mutta ongelma on se, kuinka Terraform kutsuu näitä moduuleja. Jos esimerkiksi kutsut moduulia luodaksesi jokaisen yksittäisen käyttäjän, Terraform lataa ensin koko arkiston ja siirtyy sitten kansioon, jossa kyseinen moduuli sijaitsee. Tällä tavalla lataat yhden megatavun joka kerta. Jos hallitset 100 tai 200 käyttäjää, lataat 100 tai 200 megatavua ja siirryt sitten kyseiseen kansioon. Joten luonnollisesti et halua ladata joukkoa tavaraa joka kerta, kun painat "Terraform init".
Tähän ongelmaan on kaksi ratkaisua. Ensimmäinen on käyttää suhteellisia polkuja. Näin ilmoitat koodissa, että kansio on paikallinen (./). Ja ennen kuin käynnistät mitään, teet Git-klooni tästä arkistosta paikallisesti. Näin teet sen kerran.
Huonoja puolia on tietysti paljon. Et voi esimerkiksi käyttää versiointia. Ja tämän kanssa on joskus vaikea elää.
Toinen ratkaisu. Jos sinulla on paljon alimoduuleja ja sinulla on jo jonkinlainen vakiintunut putkisto, on olemassa MBT-projekti, jonka avulla voit kerätä monia erilaisia paketteja monoarkistosta ja ladata ne S3:een. Tämä on erittäin hyvä tapa. Siten iam-user-1.0.0.zip-tiedosto painaa vain 1 kt, koska tämän resurssin luomiseen tarvittava koodi on hyvin pieni. Ja se toimii paljon nopeammin.
Puhutaanpa siitä, mitä ei voida käyttää moduuleissa.
Miksi tämä paha on moduuleissa? Pahinta on olettaa käyttäjä. Oletetaan, että käyttäjä on palveluntarjoajan todennusvaihtoehto, jota eri ihmiset voivat käyttää. Esimerkiksi me kaikki omaksumme roolin. Tämä tarkoittaa, että Terraform ottaa tämän roolin. Ja sitten tällä roolilla se suorittaa muita toimintoja.
Ja pahuus on se, että jos Vasya haluaa muodostaa yhteyden Amazoniin jollakin tavalla, esimerkiksi oletusympäristömuuttujan avulla ja Petya käyttää jaettua avaintaan, joka hänellä on salassa, niin et voi määrittää molempia Terraform. Ja jotta he eivät kokeisi kärsimystä, tätä lohkoa ei tarvitse ilmoittaa moduulissa. Tämä on ilmoitettava korkeammalla tasolla. Eli meillä on päällä resurssimoduuli, infrastruktuurimoduuli ja kokoonpano. Ja tämä pitäisi ilmaista jonnekin korkeammalle.
Toinen paha on huolehtija. Tässä paha ei ole niin triviaali, koska jos kirjoitat koodia ja se toimii sinulle, saatat ajatella, että jos se toimii, niin miksi muuttaa sitä.
Paha on se, että et aina ensinnäkin hallitse milloin tämä provisio käynnistetään. Ja toiseksi, et hallitse mitä aws ec2 tarkoittaa, eli puhummeko nyt Linuxista vai Windowsista. Joten et voi kirjoittaa jotain, joka toimii samalla tavalla eri käyttöjärjestelmissä tai eri käyttötapauksissa.
Yleisin esimerkki, joka mainitaan myös virallisessa dokumentaatiossa, on se, että jos kirjoitat aws_instance ja määrität joukon argumentteja, siinä ei ole mitään vikaa, jos määrität sinne provisiointiohjelman "local-exec" ja suoritat mahdollisen- leikkikirja.
Itse asiassa, kyllä, siinä ei ole mitään väärää. Mutta kirjaimellisesti pian ymmärrät, että tätä local-exec-juttua ei ole olemassa esimerkiksi launch_configurationissa.
Ja kun käytät launch_configurationia ja haluat luoda automaattisen skaalauksen ryhmän yhdestä esiintymästä, launch_configurationissa ei ole käsitettä "provisioner". On olemassa käsite "käyttäjätiedot".
Siksi yleisempi ratkaisu on käyttää käyttäjätietoja. Ja se käynnistetään joko itse ilmentymässä, kun ilmentymä on päällä, tai samoissa käyttäjätiedoissa, kun automaattinen skaalausryhmä käyttää tätä launch_configurationa.
Jos haluat silti ajaa provisioijaa, koska se on liimauskomponentti, kun yksi resurssi luodaan, sinun on sillä hetkellä suoritettava hallintaohjelmasi, komentosi. Tällaisia tilanteita on monia.
Ja oikea resurssi tähän on null_resurssi. Null_resource on valeresurssi, jota ei koskaan luoda. Se ei kosketa mitään, ei APIa, ei automaattista skaalausta. Mutta sen avulla voit hallita, milloin komento suoritetaan. Tässä tapauksessa komento suoritetaan luomisen aikana.
Linkki
On olemassa useita merkkejä. En käsittele kaikkia merkkejä kovin yksityiskohtaisesti. Tästä on artikkeli. Mutta jos olet työskennellyt Terraformin kanssa tai käyttänyt muiden moduuleja, olet usein huomannut, että monet moduulit, kuten suurin osa avoimen lähdekoodin koodista, ovat ihmisten kirjoittamia omiin tarpeisiinsa. Mies kirjoitti sen ja ratkaisi ongelmansa. Laitoin sen GitHubiin, anna sen elää. Se elää, mutta jos siellä ei ole dokumentaatiota ja esimerkkejä, kukaan ei käytä sitä. Ja jos ei ole toiminnallisuutta, jonka avulla voit ratkaista hieman enemmän kuin sen tietty tehtävä, kukaan ei myöskään käytä sitä. On niin monia tapoja menettää käyttäjiä.
Jos haluat kirjoittaa jotain niin, että ihmiset käyttävät sitä, suosittelen seuraamaan näitä merkkejä.
Ne ovat:
- Dokumentaatio ja esimerkit.
- Täysi toiminnallisuus.
- Kohtuulliset oletusarvot.
- Puhdas koodi.
- Testeissä.
Testit ovat eri tilanne, koska niitä on melko vaikea kirjoittaa. Uskon enemmän dokumentaatioon ja esimerkkeihin.
Joten tarkastelimme kuinka moduulit kirjoitetaan. On olemassa kaksi argumenttia. Ensimmäinen, mikä on tärkeintä, on olla kirjoittamatta, jos voit, koska joukko ihmisiä on jo tehnyt nämä tehtävät ennen sinua. Ja toiseksi, jos päätät silti, yritä olla käyttämättä palveluntarjoajia moduuleissa ja provisioissa.
Tämä on dokumentaation harmaa osa. Saatat nyt ajatella: ”Jotain on epäselvää. Ei vakuuttunut." Mutta katsotaan kuuden kuukauden päästä.
Puhutaanpa nyt näiden moduulien kutsumisesta.
Ymmärrämme, että koodimme kasvaa ajan myötä. Meillä ei ole enää yhtä tiedostoa, meillä on jo 20 tiedostoa. Ne ovat kaikki yhdessä kansiossa. Tai ehkä viisi kansiota. Ehkä alamme jotenkin jakaa niitä alueittain, joidenkin komponenttien mukaan. Sitten ymmärrämme, että nyt meillä on joitain synkronoinnin ja orkestroinnin alkeita. Toisin sanoen meidän on ymmärrettävä, mitä meidän pitäisi tehdä, jos muutimme verkkoresursseja, mitä meidän pitäisi tehdä muilla resursseillamme, kuinka aiheuttaa näitä riippuvuuksia jne.
On olemassa kaksi ääripäätä. Ensimmäinen ääripää on kaikki yhdessä. Meillä on yksi perustiedosto. Tämä oli toistaiseksi virallinen paras käytäntö Terraformin verkkosivuilla.
Mutta nyt se on kirjoitettu vanhentuneeksi ja poistetuksi. Ajan myötä Terraform-yhteisö ymmärsi, että tämä oli kaukana parhaista käytännöistä, koska ihmiset alkoivat käyttää projektia eri tavoin. Ja ongelmia on. Esimerkiksi kun luettelemme kaikki riippuvuudet yhteen paikkaan. On tilanteita, jolloin napsautetaan "Terraform-suunnitelma" ja ennen kuin Terraform päivittää kaikkien resurssien tilat, voi kulua paljon aikaa.
Paljon aikaa on esimerkiksi 5 minuuttia. Joillekin tämä on paljon aikaa. Olen nähnyt tapauksia, joissa se kesti 15 minuuttia. AWS-sovellusliittymä käytti 15 minuuttia yrittääkseen selvittää, mitä kunkin resurssin tilassa tapahtui. Tämä on erittäin laaja alue.
Ja luonnollisesti siihen liittyvä ongelma ilmaantuu, kun haluat muuttaa jotain yhdessä paikassa, sitten odotat 15 minuuttia, ja se antaa sinulle pohjan muutamista muutoksista. Syljet, kirjoitit "Kyllä", ja jotain meni pieleen. Tämä on hyvin todellinen esimerkki. Terraform ei yritä suojella sinua ongelmilta. Eli kirjoita mitä haluat. Tulee ongelmia - sinun ongelmasi. Vaikka Terraform 0.11 ei yritä auttaa sinua millään tavalla. 0.12:ssa on tiettyjä mielenkiintoisia paikkoja, joiden avulla voit sanoa: "Vasya, sinä todella haluat tämän, voitko tulla järkiisi?"
Toinen tapa on pienentää tätä aluetta, eli puhelut yhdestä paikasta voidaan yhdistää vähemmän toisesta paikasta.
Ainoa ongelma on, että sinun on kirjoitettava enemmän koodia, eli sinun täytyy kuvata muuttujia suuressa määrässä tiedostoja ja päivittää tämä. Jotkut ihmiset eivät pidä siitä. Tämä on minulle normaalia. Ja jotkut ihmiset ajattelevat: "Miksi kirjoitat tätä eri paikkoihin, laitan sen kaikki yhteen paikkaan." Tämä on mahdollista, mutta tämä on toinen ääripää.
Kenellä tämä kaikki asuu yhdessä paikassa? Yksi, kaksi, kolme ihmistä, eli joku käyttää sitä.
Ja kuka kutsuu tiettyä komponenttia, lohkoa vai infrastruktuurimoduulia? Viidestä seitsemään henkilöä. Tämä on siistiä.
Yleisin vastaus on jossain puolivälissä. Jos projekti on suuri, joudut usein tilanteeseen, jossa mikään ratkaisu ei ole sopiva eikä kaikki toimi, joten päädyt sekoitukseen. Tässä ei ole mitään väärää, kunhan ymmärrät, että molemmilla on etuja.
Jos jotain muuttui pinossa VPC ja halusit ottaa nämä muutokset käyttöön EC2:ssa, eli halusit päivittää automaattisen skaalauksen ryhmän, koska sinulla oli uusi aliverkko, kutsun tällaista riippuvuusorganisaatiota. On olemassa joitakin ratkaisuja: kuka käyttää mitä?
Voin ehdottaa mitä ratkaisuja on olemassa. Voit käyttää Terraformia taikuuden tekemiseen, tai voit käyttää make-tiedostoja käyttääksesi Terraformia. Ja katso, jos jokin on muuttunut siellä, voit käynnistää sen täällä.
Mitä pidät tästä päätöksestä? Uskooko joku, että tämä on hyvä ratkaisu? Näen hymyn, ilmeisesti epäilykset ovat hiipineet sisään.
Älä tietenkään kokeile tätä kotona. Terraformia ei koskaan suunniteltu käytettäväksi Terraformista.
Eräässä raportissa he sanoivat minulle: "Ei, tämä ei toimi." Pointti on siinä, että sen ei pitäisi toimia. Vaikka se näyttää niin vaikuttavalta, kun voit käynnistää Terraformin Terraformista ja sitten Terraformista, sinun ei pitäisi tehdä niin. Terraformin pitäisi aina alkaa hyvin helposti.
Jos tarvitset soittoorkesterin, kun jokin on muuttunut yhdessä paikassa, niin siellä on Terragrunt.
Terragrunt on apuohjelma, Terraformin lisäosa, jonka avulla voit koordinoida ja organisoida puheluita infrastruktuurimoduuleille.
Tyypillinen Terraform-määritystiedosto näyttää tältä.
Voit määrittää, mihin moduuliin haluat soittaa.
Mitä riippuvuuksia moduulilla on?
Ja mitä argumentteja tämä moduuli hyväksyy. Siinä on kaikki mitä Terragruntista voi tietää.
Dokumentaatio on siellä, ja GitHubissa on 1 700 tähteä. Mutta useimmissa tapauksissa tämä on se, mitä sinun on tiedettävä. Ja tämä on erittäin helppo toteuttaa yrityksissä, jotka ovat vasta aloittamassa työskentelyä Terraformin kanssa.
Orkesteri on siis Terragrunt. Muitakin vaihtoehtoja on.
Puhutaanpa nyt siitä, kuinka koodia käytetään.
Jos sinun on lisättävä koodiisi uusia ominaisuuksia, se on useimmissa tapauksissa helppoa. Kirjoitat uutta resurssia, kaikki on yksinkertaista.
Jos sinulla on jokin etukäteen luomasi resurssi, esimerkiksi olet oppinut Terraformista AWS-tilin avaamisen jälkeen ja haluat käyttää jo olemassa olevia resursseja, niin moduulia kannattaa laajentaa tällä tavalla, jotta se tukee olemassa olevien resurssien käyttöä.
Ja tuki uusien resurssien luomista käyttämällä lohkoresurssia.
Tulostettaessa palautamme aina tulosteen id:n riippuen siitä, mitä on käytetty.
Toinen erittäin merkittävä ongelma Terraform 0.11:ssä on työskentely listojen kanssa.
Vaikeus on, että jos meillä on tällainen käyttäjäluettelo.
Ja kun luomme nämä käyttäjät lohkoresurssilla, kaikki menee hyvin. Käymme läpi koko luettelon ja luomme jokaiselle tiedoston. Kaikki on hyvin. Ja sitten esimerkiksi käyttäjä3, joka on keskellä, pitäisi poistaa täältä, sitten kaikki hänen jälkeensä luodut resurssit luodaan uudelleen, koska indeksi muuttuu.
Työskentely listojen kanssa tilatietoisessa ympäristössä. Mikä on valtiollinen ympäristö? Tämä on tilanne, jossa uusi arvo syntyy, kun tämä resurssi luodaan. Esimerkiksi AWS-käyttöavain tai AWS-salainen avain, eli kun luomme käyttäjän, saamme uuden pääsy- tai salaisen avaimen. Ja joka kerta kun poistamme käyttäjän, tällä käyttäjällä on uusi avain. Mutta tämä ei ole feng shui, koska käyttäjä ei halua ystävystyä kanssamme, jos luomme hänelle uuden käyttäjän joka kerta, kun joku lähtee tiimistä.
Tämä on ratkaisu. Tämä on Jsonnetissa kirjoitettu koodi. Jsonnet on Googlen mallikieli.
Tämän komennon avulla voit hyväksyä tämän mallin ja tulostaa se palauttaa json-tiedoston, joka on tehty mallisi mukaan.
Malli näyttää tältä.
Terraformin avulla voit työskennellä sekä HCL:n että Jsonin kanssa samalla tavalla, joten jos sinulla on kyky luoda Jsonia, voit sujauttaa sen Terraformiin. Tiedosto, jonka tunniste on .tf.json, ladataan onnistuneesti.
Ja sitten työskentelemme sen kanssa tavalliseen tapaan: terraform init, terramorm sovelletaan. Ja luomme kaksi käyttäjää.
Nyt emme pelkää, jos joku lähtee joukkueesta. Muokkaamme vain json-tiedostoa. Vasya Pupkin lähti, Petya Pyatochkin jäi. Petya Pyatochkin ei saa uutta avainta.
Terraformin integroiminen muihin työkaluihin ei todellakaan ole Terraformin tehtävä. Terraform luotiin alustaksi resurssien luomiseen ja siinä se. Ja kaikki, mitä myöhemmin tulee esiin, ei ole Terraformin huolenaihe. Eikä sitä sinne tarvitse kutoa. Siellä on Ansible, joka tekee kaiken mitä tarvitset.
Mutta tilanteita syntyy, kun haluamme laajentaa Terraformia ja kutsua komentoa, kun jokin on valmis.
Ensimmäinen tapa. Luomme tulosteen, johon kirjoitamme tämän komennon.
Ja sitten kutsumme tätä komentoa shell terraform -tulosta ja määritämme haluamasi arvon. Siten komento suoritetaan kaikilla korvatuilla arvoilla. Se on erittäin mukava.
Toinen tapa. Tämä on null_resurssin käyttöä infrastruktuurimme muutoksista riippuen. Voimme kutsua samaa local-exe-tiedostoa heti, kun joidenkin resurssien tunnus muuttuu.
Luonnollisesti tämä kaikki on sujuvaa paperilla, koska Amazonilla, kuten kaikilla muillakin julkisilla palveluntarjoajilla, on joukko omia reunakoteloita.
Yleisin reunatapaus on, että kun avaat AWS-tilin, sillä on merkitystä, mitä alueita käytät. onko tämä ominaisuus käytössä siellä; ehkä avasit sen joulukuun 2013 jälkeen; ehkä käytät oletusarvoa VPC:ssä jne. On monia rajoituksia. Ja Amazon levitti ne kaikkialle dokumentaatioon.
On muutamia asioita, joita suosittelen välttämään.
Aloita välttämällä kaikkia ei-salaisia argumentteja Terraform-suunnitelman tai Terraform CLI:n sisällä. Kaikki tämä voidaan laittaa joko tfvars-tiedostoon tai ympäristömuuttujaan.
Mutta sinun ei tarvitse muistaa tätä koko taikakäskyä. Terraformisuunnitelma – var ja lähdetään. Ensimmäinen muuttuja on var, toinen muuttuja on var, kolmas, neljäs. Useimmiten käyttämäni infrastruktuurin koodina tärkein periaate on, että jo pelkkä koodia katsomalla minulla pitäisi olla selkeä käsitys siitä, mitä siellä on käytössä, missä tilassa ja millä arvoilla. Ja siksi minun ei tarvitse lukea dokumentaatiota tai kysyä Vasyalta, mitä parametreja hän käytti klusterin luomiseen. Minun täytyy vain avata tiedosto tfvars-tunnisteella, joka usein vastaa ympäristöä, ja katsoa kaikkea siellä.
Älä myöskään käytä kohdeargumentteja laajuuden pienentämiseen. Tätä varten on paljon helpompaa käyttää pieniä infrastruktuurimoduuleja.
Ei myöskään ole tarvetta rajoittaa ja lisätä yhdensuuntaisuutta. Jos minulla on 150 resurssia ja haluan lisätä Amazonin rinnakkaisuutta oletusarvosta 10 100:aan, todennäköisesti jokin menee pieleen. Tai se voi mennä hyvin nyt, mutta kun Amazon sanoo, että soitat liian monta puhelua, olet vaikeuksissa.
Terraform yrittää käynnistää useimmat näistä ongelmista uudelleen, mutta et saavuta melkein mitään. Parallelism=1 on tärkeä asia käytettäväksi, jos törmäät johonkin bugiin AWS-sovellusliittymässä tai Terraform-palveluntarjoajan sisällä. Ja sitten sinun on määritettävä: parallelism=1 ja odotettava, kunnes Terraform lopettaa yhden puhelun, sitten toisen ja sitten kolmannen. Hän laukaisee ne yksitellen.
Ihmiset kysyvät minulta usein: "Miksi mielestäni Terraform-työtilat ovat pahoja?" Uskon, että infrastruktuurin koodina periaate on nähdä, mitä infrastruktuuria on luotu ja millä arvoilla.
Käyttäjät eivät ole luoneet työtiloja. Tämä ei tarkoita, että käyttäjät olisivat kirjoittaneet GitHub-ongelmiin, ettemme voi elää ilman Terraform-työtiloja. Ei, ei näin. Terraform Enterprise on kaupallinen ratkaisu. HashiCorpin Terraform päätti, että tarvitsemme työtiloja, joten arkistoimme sen. Minusta on paljon helpompi laittaa se erilliseen kansioon. Sitten tulee hieman enemmän tiedostoja, mutta se on selkeämpi.
Kuinka toimia koodin kanssa? Itse asiassa luetteloiden kanssa työskentely on ainoa kipu. Ja ota Terraform helpommin. Tämä ei tee kaikkea hyvää sinulle. Sinne ei tarvitse työntää kaikkea, mitä dokumentaatiossa on kirjoitettu.
Raportin aihe kirjoitettiin "tulevaisuutta varten". Puhun tästä hyvin lyhyesti. Tulevaisuudessa tämä tarkoittaa, että 0.12 julkaistaan pian.
0.12 on paljon uutta. Jos tulet tavallisesta ohjelmoinnista, niin kaipaat kaikenlaisia dynaamisia lohkoja, silmukoita, oikeita ja ehdollisia vertailuoperaatioita, joissa vasenta ja oikeaa puolta ei lasketa samanaikaisesti, vaan tilanteen mukaan. Kaipaat sitä paljon, joten 0.12 ratkaisee sen puolestasi.
Mutta! Jos kirjoitat vähemmän ja yksinkertaisemmin, käyttämällä valmiita moduuleja ja kolmannen osapuolen ratkaisuja, sinun ei tarvitse odottaa ja toivoa, että 0.12 tulee ja korjaa kaiken puolestasi.
Kiitos raportista! Puhuit infrastruktuurista koodina ja sanoit kirjaimellisesti yhden sanan testeistä. Tarvitaanko moduuleissa testejä? Kenen vastuulla tämä on? Pitääkö minun kirjoittaa se itse vai onko se moduulien vastuulla?
Ensi vuosi tulee olemaan täynnä raportteja siitä, että olemme päättäneet testata kaiken. Mitä testata, on suurin kysymys. On paljon riippuvuuksia, paljon rajoituksia eri palveluntarjoajilta. Kun sinä ja minä puhumme ja sanot: "Tarvitsen testejä", kysyn: "Mitä aiot testata?" Sanot, että testaat omalla alueellasi. Sitten sanon, että tämä ei toimi alueellani. Eli emme voi edes olla samaa mieltä tästä. Puhumattakaan siitä, että teknisiä ongelmia on paljon. Eli miten nämä testit kirjoitetaan niin, että ne ovat riittäviä.
Tutkin aktiivisesti tätä aihetta, eli kuinka luodaan automaattisesti testejä kirjoittamasi infrastruktuurin perusteella. Eli jos kirjoitit tämän koodin, minun on suoritettava se, tämän perusteella voin luoda testejä.
on yksi useimmin mainituista kirjastoista, jonka avulla voit kirjoittaa integraatiotestejä Terraformille. Tämä on yksi apuohjelmista. Pidän parempana DSL-tyyppiä, esimerkiksi rspec.
Anton, kiitos raportista! Nimeni on Valeri. Esitän pienen filosofisen kysymyksen. Ehdollisesti on varauksia, on käyttöönottoa. Provisioning luo infrastruktuurini, käyttöönotossa täytämme sen jollakin hyödyllisellä, esimerkiksi palvelimilla, sovelluksilla jne. Ja mielestäni Terraform on enemmän provisiointia varten ja Ansible enemmän käyttöönottoa varten, koska Ansible on myös fyysistä infrastruktuuria varten. voit asentaa nginx, Postgres. Mutta samalla Ansible näyttää sallivan esimerkiksi Amazonin tai Googlen resurssien tarjoamisen. Mutta Terraform antaa sinun myös ottaa käyttöön joitain ohjelmistoja sen moduuleilla. Meneekö Terraformin ja Ansiblen välillä sinun näkökulmastasi jokin raja, missä ja mitä on parempi käyttää? Vai esimerkiksi oletko sitä mieltä, että Ansible on jo roskaa, sinun pitäisi yrittää käyttää Terraformia kaikkeen?
Hyvä kysymys, Valeri. Uskon, että Terraformin tarkoitus ei ole muuttunut vuoden 2014 jälkeen. Se luotiin infrastruktuuria varten ja kuoli infrastruktuurin vuoksi. Meillä oli edelleen ja tulee olemaan Ansible-kokoonpanonhallinnan tarve. Haasteena on, että launch_configurationissa on käyttäjätietoja. Ja sieltä vedät Ansiblen jne. Tämä on tavallinen ero, josta pidän eniten.
Jos puhumme kauniista infrastruktuurista, on olemassa apuohjelmia, kuten Packer, jotka keräävät tämän kuvan. Ja sitten Terraform käyttää tietolähdettä löytääkseen tämän kuvan ja päivittääkseen sen launch_configuration. Eli tällä tavalla putkilinja on se, että vedämme ensin Trackerin, sitten vedämme Terraformin. Ja jos rakentaminen tapahtuu, tapahtuu uusi muutos.
Hei! Kiitos raportista! Nimeni on Misha, RBS-yhtiö. Voit soittaa Ansiblelle palveluntarjoajan kautta luodessasi resurssia. Ansiblella on myös aihe nimeltä dynaaminen inventointi. Ja voit ensin soittaa Terraformille ja sitten Ansiblelle, joka ottaa resursseja valtiolta ja suorittaa sen. Mikä on parempi?
Ihmiset käyttävät molempia yhtä menestyksekkäästi. Minusta näyttää siltä, että dynaaminen inventaario Ansiblessa on kätevä asia, jos emme puhu automaattisesta skaalauksesta. Koska automaattiskaalausryhmässä meillä on jo oma työkalupakki, jota kutsutaan launch_configurationiksi. Lausun_konfiguraatiossa tallennamme kaiken, mikä on käynnistettävä, kun luomme uutta resurssia. Siksi Amazonin kanssa dynaamisen inventaarion käyttäminen ja Terraform ts -tiedoston lukeminen on mielestäni ylivoimaista. Ja jos käytät muita työkaluja, joissa ei ole käsitettä "automaattinen skaalausryhmä", esimerkiksi käytät DigitalOceania tai jotain muuta palveluntarjoajaa, jossa ei ole automaattiskaalausryhmää, silloin sinun on vedettävä API manuaalisesti, etsittävä IP-osoitteita, luotava dynaaminen inventaariotiedosto , ja Ansible kulkee jo sen läpi. Eli Amazonissa on launch_configuration, ja kaikkeen muuhun on dynaaminen inventaario.
Lähde: will.com