Näyttää siltä, että Terraform-kehittäjät tarjoavat varsin käteviä parhaita käytäntöjä työskennellä AWS-infrastruktuurin kanssa. Siinä on vain vivahde. Ajan myötä ympäristöjen määrä kasvaa, ja jokaisessa näkyy ominaisuuksia. Näkyy melkein kopiona naapurialueen sovelluspinosta. Ja Terraform-koodi on kopioitava ja muokattava huolellisesti uusien vaatimusten mukaisesti tai lumihiutaleen tekemiseksi.
Raporttini käsittelee Terraformin malleja kaaoksen ja manuaalisten rutiinien torjumiseksi suurissa ja pitkissä projekteissa.
Video:
Olen 40-vuotias, IT-alalla 20 vuotta. Olen työskennellyt Ixtensillä 12 vuotta. Olemme mukana verkkokauppalähtöisessä kehittämisessä. Ja olen harjoitellut DevOps-käytäntöjä 5 vuotta.
Tarinani tulee olemaan kokemuksesta projektissa yrityksessä, jonka nimeä en kerro salassapitosopimuksen takana.
Dialla olevat numerot on annettu projektin laajuuden ymmärtämiseksi. Ja kaikki, mitä aion sanoa seuraavaksi, liittyy Amazoniin.
Liityin tähän projektiin 4 vuotta sitten. Ja infrastruktuurin refaktorointi oli täydessä vauhdissa, koska projekti oli kasvanut. Ja ne kuviot, joita käytettiin, ne eivät enää sovi. Ja ottaen huomioon projektin suunnitellun kasvun, oli tarpeen keksiä jotain uutta.
Kiitos Matveylle, joka kertoi meille eilen, mitä Dodo Pizzassa tapahtui. Näin kävi meille 4 vuotta sitten.
Kehittäjät tulivat ja alkoivat tehdä infrastruktuurikoodia.
Ilmeisin syy siihen, miksi tätä vaadittiin, oli markkinoilletulon aika. Oli tarpeen varmistaa, että DevOps-tiimi ei ollut pullonkaula käyttöönoton yhteydessä. Ja muun muassa Terraformia ja Puppetia käytettiin aivan ensimmäisellä tasolla.
Terraform on HashiCorpin avoimen lähdekoodin projekti. Ja niille, jotka eivät tiedä mitä se on, seuraavat muutamat diat.
Infrastruktuuri koodina tarkoittaa, että voimme kuvata infrastruktuurimme ja pyytää joitain robotteja varmistamaan, että saamme kuvailemamme resurssit.
Tarvitsemme esimerkiksi virtuaalikoneen. Kuvaamme, lisäämme muutaman pakollisen parametrin.
Tämän jälkeen määritämme pääsyn Amazoniin konsolissa. Ja kysy Terraform-suunnitelmaa. Terraform-suunnitelmassa lukee: "Ok, resurssillesi voimme tehdä nämä asiat." Ja ainakin yksi resurssi lisätään. Eikä muutoksia ole odotettavissa.
Kun kaikki sopii sinulle, voit pyytää Terraformia hakemaan ja Terraform luo sinulle ilmentymän ja saat virtuaalikoneen pilvellesi.
Lisäksi projektimme kehittyy. Lisäämme siihen joitain muutoksia. Pyydämme lisää esiintymiä, lisäämme 53 merkintää.
Ja toistamme. Ole hyvä ja suunnittele. Katsotaan mitä muutoksia on suunnitteilla. Käytä. Ja niin infrastruktuurimme kasvaa.
Terraform käyttää sellaista asiaa kuin tilatiedostoja. Toisin sanoen se tallentaa kaikki Amazoniin menevät muutokset tiedostoon, jossa jokaiselle kuvailemasi resurssille on vastaavat Amazonissa luodut resurssit. Siten resurssin kuvausta muuttaessaan Terraform tietää tarkalleen, mitä Amazonissa on muutettava.
Nämä tilatiedostot olivat alun perin vain tiedostoja. Ja säilytimme ne Gitissä, mikä oli erittäin hankalaa. Jatkuvasti joku unohti tehdä muutoksia, ja konflikteja oli monia.
Nyt on mahdollista käyttää taustaosaa, eli Terraformista ilmoitetaan, mihin kauhaan, millä avaimella tilatiedosto tulee tallentaa. Ja Terraform itse huolehtii tämän tilatiedoston hankkimisesta, tekee kaiken taian ja palauttaa lopullisen tuloksen.
Infrastruktuurimme kasvaa. Tässä on koodimme. Ja nyt emme halua luoda vain virtuaalikoneita, haluamme testiympäristön.
Terraformilla voit tehdä sellaisen moduuliksi, eli kuvata saman asian jossain kansiossa.
Ja esimerkiksi testaamalla kutsu tämä moduuli ja saat saman asian kuin jos tekisimme Terraform-sovellusta itse moduulissa. Tässä koodi testausta varten.
Tuotantoa varten voimme lähettää sinne muutoksia, koska testauksessa emme tarvitse suuria instansseja, tuotannossa suuret esiintymät tulevat tarpeeseen.
Ja sitten palaan projektiin. Se oli vaikea tehtävä, infrastruktuuri oli suunniteltu erittäin suureksi. Ja kaikki koodi oli jotenkin sijoitettava niin, että se olisi kätevä kaikille: niille, jotka suorittavat tämän koodin huoltoa, ja niille, jotka tekevät muutoksia. Ja suunniteltiin, että kuka tahansa kehittäjä voisi mennä korjaamaan infrastruktuuria tarpeen mukaan omalle alustalleen.
Tämä on hakemistopuu, jota HashiCorp suosittelee, jos sinulla on suuri projekti ja on järkevää jakaa koko infrastruktuuri pieniin osiin ja kuvata jokainen osa erilliseen kansioon.
Kun sinulla on laaja resurssikirjasto, voit soittaa samaan asiaan testauksessa ja tuotannossa.
Meidän tapauksessamme tämä ei ollut täysin sopiva, koska testipino kehittäjille tai testaukseen piti saada jotenkin yksinkertaisemmin. Enkä halunnut käydä kansioita läpi ja hakea oikeassa järjestyksessä ja olla huolissani siitä, että kanta nousee ja sitten tätä kantaa käyttävä ilmentymä nousee. Siksi kaikki testit käynnistettiin yhdestä kansiosta. Sinne kutsuttiin samat moduulit, mutta kaikki meni läpi yhdellä kertaa.
Terraform huolehtii kaikista riippuvuuksista. Ja se luo aina resursseja kyseisessä järjestyksessä, jotta voit saada IP-osoitteen esimerkiksi juuri luodusta ilmentymästä ja saada tämän IP-osoitteen route53-merkinnässä.
Lisäksi alusta on erittäin suuri. Ja testipinon suorittaminen, vaikka tunnin, vaikka 8 tunnin ajan, on melko kallista.
Ja olemme automatisoineet tämän liiketoiminnan. Ja Jenkinsin työ antoi pinon pyöriä. Siinä piti käynnistää vetopyyntö, jossa oli muutoksia, joita kehittäjä haluaa testata, määrittää kaikki tarvittavat vaihtoehdot, komponentit ja koot. Jos hän haluaa suorituskykytestauksen, hän voi ottaa useampia tapauksia. Jos hänen tarvitsee vain tarkistaa, että jokin lomake aukeaa, hän voisi aloittaa minimipalkasta. Ilmoita myös, tarvitaanko klusteria vai ei jne.
Ja sitten Jenkins työnsi shell-skriptin, joka muokkasi hieman Terraform-kansion koodia. Poistettu tarpeettomat tiedostot, lisätty tarvittavat tiedostot. Ja sitten yhdellä Terraform-sovelluksella pino nousi.
Ja sitten oli muita vaiheita, joihin en halua mennä.
Koska testaukseen tarvitsimme hieman enemmän vaihtoehtoja kuin tuotannossa, jouduimme kopioimaan moduuleista, jotta näihin kopioihin voisi lisätä niitä ominaisuuksia, joita vain testauksessa tarvitaan.
Ja niin tapahtui, että testauksessa näyttää siltä, että haluat testata niitä muutoksia, jotka lopulta siirtyvät tuotantoon. Mutta itse asiassa yhtä asiaa testattiin ja tuotannossa käytettiin vähän erilaista. Ja kuviossa oli pieni katkos, että tuotannossa kaikki muutokset toteutettiin käyttötiimin toimesta. Ja joskus kävi ilmi, että ne muutokset, joiden piti siirtyä testauksesta tuotantoon, ne jäivät toiseen versioon.
Lisäksi oli sellainen ongelma, että lisättiin uusi palvelu, joka poikkesi hieman jostain olemassa olevasta. Ja sen sijaan, että muuttaisit olemassa olevaa moduulia, sinun piti tehdä siitä kopio ja lisätä tarvittavat muutokset.
Itse asiassa Terraform ei ole oikea kieli. Tämä on julistus. Jos meidän täytyy ilmoittaa jotain, niin me julistamme sen. Ja kaikki toimii.
Jossain vaiheessa, kun keskustelimme yhdestä vetopyynnöstäni, eräs kollegani sanoi, ettei lumihiutaleita tarvitse tuottaa. Mietin, mitä hän tarkoitti. On olemassa sellainen tieteellinen tosiasia, että maailmassa ei ole kahta identtistä lumihiutaletta, ne ovat kaikki hieman, mutta erilaisia. Ja heti kun kuulin tämän, tunsin heti Terraform-koodin täyden painon. Koska versiosta toiseen siirryttäessä Terraform vaati ketjun katkaisua, eli koodi ei enää ollut yhteensopiva seuraavan version kanssa. Ja minun piti tehdä vetopyyntö, joka kattoi lähes puolet infrastruktuurin tiedostoista, jotta infrastruktuuri saataisiin Terraformin seuraavaan versioon.
Ja kun tällainen lumihiutale ilmestyi, kaikki Terraform-koodi, jonka olimme muuttaneet suureksi, suureksi lumikasaksi.
Ulkopuoliselle kehittäjälle, joka on toiminnan ulkopuolella, sillä ei ole paljon väliä, koska hän teki vetopyynnön, hänen resurssinsa alkoi. Ja siinä se, se ei ole hänen huolensa. Ja DevOps-tiimin, joka varmistaa, että kaikki on kunnossa, on tehtävä kaikki nämä muutokset. Ja näiden muutosten kustannukset nousivat erittäin, hyvin paljon jokaisen lisälumihiutaleen myötä.
On tarina siitä, kuinka opiskelija seminaarissa piirtää kaksi täydellistä ympyrää liitutaululle. Ja opettaja on yllättynyt, kuinka hän onnistui piirtämään niin sujuvasti ilman kompassia. Opiskelija vastaa: "Se on hyvin yksinkertaista, pyöritin lihamyllyä kaksi vuotta armeijassa."
Ja niistä neljästä vuodesta, jotka olen ollut tässä projektissa, olen tehnyt Terraformia noin kaksi vuotta. Ja tietysti minulla on joitain temppuja, vinkkejä kuinka yksinkertaistaa Terraform-koodia, työskennellä sen kanssa ohjelmointikielen tavoin ja vähentää kehittäjien taakkaa, joiden on pidettävä tämä koodi ajan tasalla.
Ensimmäinen asia, josta haluaisin aloittaa, on Symlinks. Terraformissa on paljon toistuvaa koodia. Esimerkiksi soittaminen palveluntarjoajalle melkein joka paikassa, jossa luomme infrastruktuurin, on sama. Ja on loogista laittaa se erilliseen isään. Ja missä tahansa palveluntarjoajan on tehtävä symbolilinkkejä tähän tiedostoon.
Käytät esimerkiksi olettaa roolia tuotannossa, jonka avulla voit saada käyttöoikeudet jollekin ulkoiselle Amazon-tilille. Ja kun muutat yhtä tiedostoa, kaikilla jäljellä olevilla resurssipuussa olevilla on tarvittavat oikeudet, jotta Terraform tietää, mihin Amazon-segmenttiin on pääsy.
Missä Symlinkit eivät toimi? Kuten sanoin, Terraformilla on tilatiedostoja. Ja ne ovat erittäin, erittäin siistejä. Mutta tosiasia on, että Terraform alustaa taustajärjestelmän aivan ensimmäisessä. Eikä hän voi käyttää muuttujia näissä parametreissa, ne on aina kirjoitettava tekstinä.
Tämän seurauksena, kun joku tekee uuden resurssin, hän kopioi osan koodista muista kansioista. Ja hän voi tehdä virheen avaimella tai ämpärillä. Hän esimerkiksi tekee hiekkalaatikosta hiekkalaatikkojutun ja tekee sen sitten tuotannossa. Ja niin voi käydä niin, että tuotannossa oleva ämpäri käytetään hiekkalaatikosta. Tietysti he löytävät sen nopeasti. Tämä on mahdollista jotenkin korjata, mutta siitä huolimatta se on ajan ja jossain määrin resurssien hukkaa.
Mitä voimme tehdä seuraavaksi? Ennen kuin työskentelet Terraformin kanssa, sinun on alustettava se. Alustushetkellä Terraform lataa kaikki laajennukset. Jossain vaiheessa ne murtuivat monoliitista mikropalveluarkkitehtuuriksi. Ja sinun on aina tehtävä Terraform-init, jotta se vetää ylös kaikki moduulit, kaikki lisäosat.
Ja voit käyttää shell-skriptiä, joka ensinnäkin voi saada kaikki muuttujat. Shell-skripti on rajoittamaton. Ja toiseksi tapa. Jos käytämme aina arkistossa olevaa polkua tilatiedoston avaimena, virhe jätetään vastaavasti pois täältä.
Mistä saa dataa? JSON-tiedosto. Terraformin avulla voit kirjoittaa infrastruktuurin paitsi hcl:llä (HashiCorp Configuration Language), mutta myös JSON:lla.
JSON on helppo lukea shell-skriptistä. Vastaavasti voit laittaa kokoonpanotiedoston johonkin paikkaan. Ja käytä tätä ämpäriä sekä Terraform-koodissa että komentosarjan alustuksessa.
Miksi on tärkeää, että sinulla on Terraform-kauha? Koska on olemassa sellainen asia kuin etätilan tiedostot. Eli kun nostan resurssia, jotta voin sanoa Amazonille: "Please nosta instanssi", minun on määritettävä paljon vaadittuja parametreja.
Ja nämä tunnisteet on tallennettu johonkin toiseen kansioon. Ja voin ottaa sen ja sanoa: "Terraform, ole hyvä ja juokse juuri tuon resurssin tilatiedostoon ja hanki minulle nämä tunnisteet." Ja siten eri alueiden tai ympäristöjen välillä on eräänlainen yhdistyminen.
Etätilatiedostoa ei aina ole mahdollista käyttää. Loit esimerkiksi manuaalisesti VPC:n. Ja VPC:n luova Terraform-koodi luo niin erilaisen VPC:n, että se kestää hyvin kauan ja joudut säätämään toisiaan, joten voit käyttää seuraavaa temppua.
Eli tehdä moduuli, joka ikään kuin tekee VPC:n ja antaa sinulle tunnisteita, mutta itse asiassa on vain tiedosto kovakoodatuilla arvoilla, jota voidaan käyttää saman esiintymän luomiseen.
Tilatiedostoa ei aina tarvitse tallentaa pilveen. Esimerkiksi moduuleita testattaessa voit käyttää taustaalustusta, jolloin tiedosto tallennetaan vain levylle testaushetkellä.
Nyt vähän testaamisesta. Mitä Terraformissa voi testata? Todennäköisesti paljon on mahdollista, mutta puhun näistä neljästä asiasta.
HashiCorpilla on käsitys Terraform-koodin muotoilusta. Ja Terraform fmt antaa sinun muotoilla muokkaamasi koodin tämän uskomuksen mukaan. Näin ollen testeissä on välttämättä tarkistettava, vastaako muotoilu HashiCorpin testamenttia, jotta sinun ei tarvitse muuttaa sulujen paikkaa jne.
Seuraava on Terraformin validointi. Se tekee hieman enemmän kuin syntaksin tarkistus - aha, ovatko kaikki hakasulkeet paritettuja. Mikä tässä on tärkeää? Meillä on erittäin ohut infrastruktuuri. Siinä on paljon erilaisia kansioita. Ja jokaisessa sinun on suoritettava Terraformin validointi.
Vastaavasti testauksen nopeuttamiseksi ajamme useita prosesseja rinnakkain rinnakkain.
Rinnakkais on erittäin hieno asia, käytä sitä.
Mutta joka kerta kun Terraform alustetaan, se menee HashiCorpille ja kysyy: "Mitä ovat uusimmat laajennukset? Ja liitännäinen, joka minulla on välimuistissa - onko se se vai ei? Ja se hidastui joka askeleella.
Jos Terraform kertoo, missä laajennukset ovat, Terraform sanoo: "OK, tämä on luultavasti tuorein asia mitä on olemassa. En mene minnekään, aloitan Terraform-koodisi vahvistamisen heti."
Kansion täyttämiseksi tarvittavilla laajennuksilla meillä on hyvin yksinkertainen Terraform-koodi, joka on vain alustettava. Täällä sinun on tietysti määritettävä kaikki palveluntarjoajat, jotka jollakin tavalla osallistuvat koodiisi, muuten Terraform sanoo: "En tunne ketään palveluntarjoajaa, koska se ei ole välimuistissa."
Seuraava on Terraform-suunnitelma. Kuten sanoin, kehitys on syklistä. Teemme koodin muutoksilla. Ja sitten sinun on selvitettävä, mitä muutoksia infrastruktuuriin on suunniteltu.
Ja kun infrastruktuuri on hyvin, hyvin suuri, voit vaihtaa yhtä moduulia, korjata testiympäristön tai tietyn alueen ja rikkoa jonkin viereisen. Siksi koko infrastruktuurille tulisi tehdä Terraform-suunnitelma ja näyttää, mitä muutoksia on suunniteltu.
Voit tehdä sen älykkäällä tavalla. Kirjoitimme esimerkiksi Python-skriptin, joka ratkaisee riippuvuudet. Ja riippuen siitä, mitä on muutettu: Terraform-moduuli tai vain tietty komponentti, se tekee suunnitelmat kaikille riippuvaisille kansioille.
Terraformisuunnitelma on tehtävä pyynnöstä. Ainakin me teemme niin.
Testejä on tietysti hyvä tehdä jokaiselle muutokselle, jokaiselle sitoumukselle, mutta suunnitelmat ovat melko kallista. Ja sanomme vetopyynnössä: "Anna minulle suunnitelmat." Robotti käynnistyy. Ja lähettää kommentteihin tai liittämään kaikki suunnitelmat, joita muutoksistasi odotetaan.
Suunnitelma on melko kallis asia. Se vie aikaa, koska Terraform menee Amazonille ja kysyy: "Onko tämä tapaus edelleen olemassa? Onko tällä automaattisella mittakaavalla täsmälleen samat parametrit?". Ja nopeuttaaksesi sitä, voit käyttää parametria, kuten refresh=false. Tämä tarkoittaa, että Terraform tyhjentää S3-tilan. Ja uskoo, että osavaltio vastaa täsmälleen Amazonin tilaa.
Tällainen Terraform-suunnitelma on paljon nopeampi, mutta tilan on vastattava infrastruktuuriasi, eli jossain, joskus Terraformin päivitys on aloitettava. Terraform refresh tekee juuri sen, jotta tila vastaa todellista infrastruktuuria.
Ja minun on sanottava turvallisuudesta. Tästä sen olisi pitänyt aloittaa. Jos käytät Terraformia ja Terraform toimii infrastruktuurisi kanssa, siellä on haavoittuvuus. Eli käytännössä suoritat koodia. Ja jos vetopyyntö sisältää jonkinlaisen haitallisen koodin, se voidaan suorittaa infrastruktuurissa, jolla on liian paljon pääsyä. Siksi ole varovainen, missä käynnistät Terraform-suunnitelman.
Seuraava asia, josta haluaisin puhua, on käyttäjätietojen testaus.
Mitä käyttäjätiedot ovat? Amazonissa, kun luomme ilmentymän, voimme lähettää ilmentymästä jonkinlaisen kirjeen - metadataa. Kun ilmentymä käynnistetään, yleensä pilvi-init on aina läsnä näissä ilmentymissä. Cloud init lukee tämän kirjeen ja sanoo: "OK, tänään olen kuormituksen tasapainottaja." Ja näiden ohjeiden mukaisesti hän suorittaa joitain toimia.
Mutta valitettavasti, kun käytämme Terraform-suunnitelmaa ja Terraformia, käyttäjätiedot näyttävät tältä numeroiden sekamelskaalta. Eli hän vain lähettää sinulle hashin. Ja suunnitelmasta näet vain, tuleeko muutoksia vai pysyykö hash ennallaan.
Ja jos et kiinnitä tähän huomiota, joku pahoinpidelty tekstitiedosto voi mennä Amazoniin, todelliseen infrastruktuuriin.
Vaihtoehtoisesti et voi määrittää koko infrastruktuuria suorituksen aikana, vaan vain mallin. Ja sano koodissa: "Näytä tämä malli minulle." Tämän seurauksena voit saada tulosteen siitä, miltä tietosi näyttävät Amazonissa.
Toinen vaihtoehto on käyttää moduulia käyttäjätietojen luomiseen. Käytät tätä moduulia. Hae tiedosto levylle. Vertaa sitä referenssiin. Ja näin ollen, jos joku jun päättää korjata vähän käyttäjätietoja, testit sanovat: "OK, siellä täällä on muutoksia - tämä on normaalia."
Seuraava asia, josta haluaisin puhua, on Terraformin automatisointi.
Tietenkin on pelottavaa tehdä Terraformia automaattitilassa, koska kuka tietää, mitä muutoksia siellä on tapahtunut ja kuinka haitallisia ne voivat olla elävälle infrastruktuurille.
Testiympäristössä tämä on kaikki kunnossa. Eli kaikki kehittäjät tarvitsevat työtä, joka luo testiympäristön. Ja sellainen ilmaus kuin "kaikki toimi minulle" ei ole hauska meemi, vaan todiste siitä, että henkilö hämmentyi, nosti pinoa, käynnisti joitain testejä tällä pinolla. Ja hän varmisti, että kaikki oli kunnossa ja sanoi: "OK, julkaisemani koodi on testattu."
Tuotannossa, hiekkalaatikossa ja muissa liiketoimintakriittisissä ympäristöissä on turvallista käyttää osittain resursseja, koska se ei aiheuta ketään kuolemaan. Nämä ovat: autoscale-ryhmät, suojausryhmät, roolit, route53 ja siellä lista voi olla melko suuri. Mutta pidä silmällä, mitä tapahtuu, lue automatisoitujen sovellusten raportit.
Missä on vaarallista tai pelottavaa käyttää, esimerkiksi jos nämä ovat pysyviä resursseja, tietokannasta, niin saat raportit, että jossain infrastruktuurin osassa on toteuttamattomia muutoksia. Ja insinööri jo valvoo työtehtäviä hakemista varten tai tekee sen konsolistaan.
Amazonilla on sellainen asia kuin Lopeta suojaus. Ja se voi joissain tapauksissa suojata muutoksilta, joita et vaadi sinulta. Joten Terraform meni Amazonille ja sanoi: "Minun täytyy tappaa tämä esimerkki tehdäkseni toisen". Ja Amazon sanoo: "Anteeksi, ei tänään. Meillä on Lopeta suojaus."
Ja kirsikka kakun päällä on koodin optimointi. Kun työskentelemme Terraform-koodin kanssa, meidän on välitettävä moduulille erittäin suuri määrä parametreja. Nämä ovat parametreja, joita tarvitaan jonkinlaisen resurssin luomiseen. Ja koodi muuttuu suuriksi luetteloiksi parametreista, jotka on siirrettävä moduulista moduuliin, moduulista moduuliin, varsinkin jos moduulit ovat sisäkkäisiä.
Ja se on erittäin vaikea lukea. Tätä on erittäin vaikea tarkistaa. Ja hyvin usein käy ilmi, että joitain parametreja tarkistetaan, eivätkä ne ole aivan niitä, joita tarvitaan. Ja sen korjaaminen myöhemmin vaatii aikaa ja rahaa.
Siksi ehdotan, että käytät sellaista kompleksina parametrina, joka sisältää tietyn arvopuun. Eli tarvitset jonkinlaisen kansion, jossa sinulla on kaikki arvot, jotka haluat jonkinlaisessa ympäristössä.
Ja kutsumalla tätä moduulia saat puun, joka luodaan yhdessä yhteisessä moduulissa, eli yhteisessä moduulissa, joka toimii samalla tavalla koko infrastruktuurille.
Tässä moduulissa voit tehdä joitain laskelmia käyttämällä Terraformin tuoretta ominaisuutta paikallisina. Ja sitten yhdessä lähdössä anna jonkinlainen monimutkainen parametri, joka voi sisältää tiivisteitä, taulukoita jne.
Tähän kaikki parhaat löydöt, jotka olen tehnyt. Ja haluaisin kertoa tarinan Kolumbuksesta. Kun hän etsi rahaa tutkimusmatkalleen Intian löytämiseksi (kuten hän silloin ajatteli), kukaan ei uskonut häntä ja uskoi, että se oli mahdotonta. Sitten hän sanoi: "Varmista, ettei muna putoa." Kaikki pankkiirit, hyvin rikkaita ja luultavasti älykkäitä ihmisiä, yrittivät laittaa munaa jollain tavalla, ja se putosi koko ajan. Sitten Kolumbus otti munan, painoi sitä hieman. Kuori rypistyy ja muna pysyi liikkumattomana. He sanoivat: "Voi, se on liian helppoa!" Ja Kolumbus vastasi: "Kyllä, se on liian yksinkertaista. Ja kun avaan Intian, kaikki käyttävät tätä kauppareittiä."
Ja se, mitä juuri kerroin, ovat luultavasti melko yksinkertaisia ja triviaaleja asioita. Ja kun otat niistä selvää ja alat käyttää niitä, se on asioiden järjestyksessä. Joten käytä sitä. Ja jos nämä ovat sinulle aivan normaaleja asioita, niin ainakin osaat laittaa munaa niin, ettei se putoa.
Yhteenvetona:
- Yritä välttää lumihiutaleita. Ja mitä vähemmän lumihiutaleita, sitä vähemmän resursseja tarvitset tehdäksesi muutoksia koko suureen infrastruktuuriisi.
- Jatkuva muutos. Eli kun koodissa on tapahtunut muutoksia, sinun on saatettava infrastruktuurisi näiden muutosten mukaiseksi mahdollisimman pian. Ei pitäisi olla sellaista tilannetta, että joku tulee kahden tai kolmen kuukauden kuluttua katsomaan Elasticsearchia, tekee Terraform-suunnitelman ja siellä on paljon muutoksia, joita hän ei odottanut. Ja kaiken palauttaminen järjestykseen vie paljon aikaa.
- Testit ja automaatio. Mitä enemmän koodisi on peitetty testeillä ja siruilla, sitä enemmän sinulla on luottamusta siihen, että teet kaiken oikein. Ja automaattinen toimitus lisää luottamustasi moninkertaisesti.
- Testi- ja tuotantoympäristön koodin pitäisi olla lähes sama. Käytännössä, koska loppujen lopuksi tuotanto on hieman erilaista ja silti tulee joitain vivahteita, jotka menevät testiympäristön ulkopuolelle. Mutta siitä huolimatta, plus tai miinus se voidaan tarjota.
- Ja jos sinulla on paljon Terraform-koodia ja tämän koodin pitäminen ajan tasalla vie paljon aikaa, ei ole koskaan liian myöhäistä muokata ja saattaa se hyvään kuntoon.
- muuttumaton infrastruktuuri. AMI toimitus aikataulussa.
- Reitin 53 rakenne, kun sinulla on paljon merkintöjä ja haluat niiden olevan johdonmukaisessa järjestyksessä.
- Taistele API-nopeusrajoituksia vastaan. Tällöin Amazon sanoo: "Siinä se on, en voi hyväksyä enempää pyyntöjä, odota." Ja puolet toimistosta odottaa, kunnes se voi käynnistää infrastruktuurinsa.
- spot-tapauksia. Amazon ei ole halpa tapahtuma ja spottien avulla voit säästää melko paljon. Ja siellä voit kertoa siitä koko raportin.
- Turvallisuus ja IAM-roolit.
- Etsi kadonneita resursseja, kun sinulla on tuntematonta alkuperää Amazonessa, ne syövät rahaa. Vaikka tapaukset maksavat 100–150 dollaria kuukaudessa, se on yli 1 000 dollaria vuodessa. Tällaisten resurssien löytäminen on tuottoisaa liiketoimintaa.
- Ja varatut tapaukset.
Siinä kaikki minulle. Terraform on erittäin siistiä, käytä sitä. Kiitos!
kysymykset
Kiitos raportista! Sinulla on tilatiedosto S3:ssa, mutta kuinka ratkaiset ongelman, että useat ihmiset voivat ottaa tämän tilatiedoston ja yrittää ottaa käyttöön?
Ensinnäkin meillä ei ole kiirettä. Toiseksi, on liput, joissa ilmoitamme, että työskentelemme jonkin koodin parissa. Eli huolimatta siitä, että infrastruktuuri on erittäin suuri, tämä ei tarkoita, että joku käyttää jatkuvasti jotain. Ja kun oli aktiivinen vaihe, tämä oli ongelma, säilytimme tilatiedostoja Gitissä. Tämä oli tärkeää, muuten joku tekisi tilatiedoston, ja meidän piti kerätä ne manuaalisesti kasaan jatkaaksemme eteenpäin. Nyt sellaista ongelmaa ei ole. Yleensä Terraform ratkaisi tämän ongelman. Ja jos jokin muuttuu jatkuvasti, voit käyttää lukkoja, jotka estävät sanomasi.
Käytätkö avointa lähdekoodia vai yritystä?
Ei yritystä, eli kaikkea, mitä voit ladata ilmaiseksi.
Nimeni on Stanislav. Halusin tehdä pienen lisäyksen. Puhuit Amazon-ominaisuudesta, jonka avulla voit tehdä instanssista tappamattoman. Tämä on myös itse Terraformissa, Life Second -lohkossa voit määrätä muutoskiellon tai tuhoamiskiellon.
Oli ajallisesti rajoitettu. Hyvä pointti.
Halusin myös kysyä kahta asiaa. Ensin puhuit testaamisesta. Oletko käyttänyt testaustyökaluja? Kuulin Test Kitchen -laajennuksesta. Ehkä on jotain muutakin. Ja haluaisin kysyä paikallisista arvoista. Miten ne pohjimmiltaan eroavat syöttömuuttujista? Ja miksi en voi parametroida jotain vain paikallisten arvojen kautta? Yritin käsitellä tätä aihetta, mutta jotenkin en keksinyt sitä itse.
Voimme puhua tarkemmin tämän salin takana. Testaustyökalut ovat täysin itse tehtyjä. Siellä ei ole mitään testattavaa. Yleensä on vaihtoehtoja, kun automaattiset testit nostavat infrastruktuurin jonnekin, tarkistavat sen olevan kunnossa ja tuhoavat sitten kaiken raportilla, että infrastruktuurisi on edelleen hyvässä kunnossa. Meillä ei ole sitä, koska testipinot toimivat joka päivä. Ja se riittää. Ja jos jokin alkaa rikkoutua, se alkaa rikkoutua ilman, että tarkistamme sen jostain muualta.
Paikallisista arvoista jatketaan keskustelua yleisön ulkopuolella.
Hei! Kiitos raportista! Erittäin informatiivinen. Sanoit, että sinulla on paljon samantyyppistä koodia infrastruktuurin kuvaamiseen. Oletko harkinnut tämän koodin luomista?
Hieno kysymys, kiitos! Asia on siinä, että kun käytämme infrastruktuuria koodina, oletamme, että katsomme koodia ja ymmärrämme, millainen infrastruktuuri tämän koodin takana on. Jos koodi luodaan, meidän on kuviteltava, mikä koodi luodaan, jotta voimme ymmärtää, millainen infrastruktuuri siellä on. Tai luomme koodin, sitoudumme sen ja itse asiassa saamme saman asian. Siksi menimme niin kuin kirjoitimme, saimme sen. Lisäksi generaattorit ilmestyivät hieman myöhemmin, kun aloimme valmistaa. Ja oli liian myöhäistä muuttaa.
Oletko kuullut jsonnetista?
Nro
Katso, tämä on todella siistiä tavaraa. Näen tietyn tapauksen, jossa voit käyttää sitä ja luoda tietorakenteen.
Generaattorit ovat hyviä, kun niitä on, kuten parranajokonetta koskevassa vitsissä. Eli ensimmäisen kerran kasvot ovat erilaiset, mutta sitten kaikilla on samat kasvot. Generaattorit ovat erittäin siistejä. Mutta valitettavasti kasvomme ovat hieman erilaiset. Tämä on ongelma.
Katso vain. Kiitos!
Nimeni on Maxim, olen Sberbankista. Sanoit hieman, että yritit tuoda Terraformin ohjelmointikielen analogin. Eikö Ansiblen käyttö ole helpompaa?
Nämä ovat hyvin erilaisia asioita. Ansible voi luoda resursseja ja Puppet voi luoda resursseja Amazonissa. Mutta Terraform on suorastaan terävä.
Onko sinulla vain Amazon?
Meillä ei ole vain Amazon. Meillä on melkein vain Amazon. Mutta tärkein ominaisuus on, että Terraform muistaa. Jos Ansiblessa sanot: "Ota minulle 5 tapausta", se nousee, ja sitten sanot: "Ja nyt tarvitsen 3". Ja Terraform sanoo: "Ok, tapan 2", ja Ansible sanoo: "Ok, tässä on 3 sinulle." Yhteensä 8.
Hei! Kiitos raportistasi! Oli erittäin mielenkiintoista kuulla Terraformista. Haluan vain tehdä pienen kommentin siitä, että Terraformilla ei vieläkään ole vakaata julkaisua, joten ole erittäin varovainen Terraformin kanssa.
Mukava lusikka illalliseksi. Eli jos tarvitset ratkaisua, niin joskus lykkäät epävakaata jne., mutta se toimii ja auttoi meitä.
Kysymys on. Käytät Remote-taustaohjelmaa, käytät S3:a. Miksi et käytä virallista taustaohjelmaa?
Virallinen?
Terraform pilvi.
Milloin hän ilmestyi?
4 kuukautta sitten.
Jos se olisi ilmestynyt 4 vuotta sitten, olisin todennäköisesti vastannut kysymykseesi.
Siellä on jo sisäänrakennettu toiminto ja lukot, ja voit tallentaa tilatiedoston. Kokeile. Mutta en ole testannutkaan.
Olemme suuressa junassa, joka kulkee suurella nopeudella. Etkä voi vain ottaa ja heittää pois muutamaa autoa.
Puhuit lumihiutaleista, miksi et käyttänyt oksaa? Miksei se mennyt niin?
Meillä on sellainen lähestymistapa, että koko infrastruktuuri on yhdessä arkistossa. Terraform, Puppet, kaikki käsikirjoitukset, jotka jotenkin liittyvät tähän, ne ovat kaikki yhdessä arkistossa. Näin voimme varmistaa, että inkrementaaliset muutokset testataan yksitellen. Jos se olisi joukko oksia, sellaista hanketta olisi lähes mahdoton ylläpitää. Kuluu kuusi kuukautta, ja ne eroavat niin paljon, että se on vain jonkinlainen rangaistus. Tätä halusin paeta ennen refaktorointia.
eli se ei toimi?
Se ei toimi ollenkaan.
Haarassa leikkasin kansiliuskan irti. Eli jos teet jokaiselle testipinolle, esimerkiksi joukkueella A on oma isä, joukkueella B on oma isä, tämäkään ei toimi. Teimme yhtenäisen testiympäristökoodin, joka oli tarpeeksi joustava sopimaan kaikille. Eli palvelimme yhden koodin.
Hei! Nimeni on Yura! Kiitos raportista! Kysymys moduuleista. Sanot, että käytät moduuleja. Miten ratkaiset ongelman, jos yhteen moduuliin tehtiin muutoksia, jotka eivät ole yhteensopivia toisen henkilön vaihdon kanssa? Versioidaanko moduuleja jotenkin tai yritetään saada ihmelapsi täyttämään kaksi vaatimusta?
Tämä on suuri lumikasaongelma. Tästä kärsimme, kun jokin harmiton muutos voi rikkoa osan infrastruktuurista. Ja sen huomaa vasta pitkän ajan kuluttua.
Eli sitä ei ole vielä päätetty?
Teet universaaleja moduuleja. Vältä lumihiutaleita. Ja kaikki järjestyy. Raportin toisella puoliskolla käsitellään sen välttämistä.
Hei! Kiitos raportista! Haluaisin selventää. Kulissien takana oli iso kasa, jota varten tulin. Miten Nukke- ja roolijako integroidaan?
käyttäjätiedot.
Eli syljetkö vain tiedoston ulos ja suoritat sen jollain tavalla?
User-data on muistiinpano, eli kun teemme kuvakloonin, Daemon nousee sinne ja yrittää selvittää kuka hän on, lukee huomautuksen, että hän on kuormituksen tasapainottaja.
Eli onko kyseessä jokin erillinen prosessi, joka annetaan pois?
Emme me keksineet sitä. Käytämme sitä.
Hei! Minulla on vain kysymys käyttäjätiedoista. Sanoit, että siellä on ongelmia, että joku saattaa lähettää jotain väärään paikkaan. Onko olemassa mitään tapaa tallentaa käyttäjätiedot samaan Gitiin, jotta on aina selvää, mihin User-data viittaa?
Luomme käyttäjätiedot mallista. Eli tietty määrä muuttujia turvautuu sinne. Ja Terraform luo lopputuloksen. Siksi et voi vain katsoa mallia ja sanoa, mitä tapahtuu, koska kaikki ongelmat liittyvät siihen, että kehittäjä luulee välittävänsä merkkijonon tässä muuttujassa, ja sitten käytetään taulukkoa. Ja hän - bang ja minä - niin ja niin, niin ja niin, seuraava rivi, ja kaikki meni rikki. Jos tämä on uusi resurssi ja henkilö nostaa sen esiin, näkee, että jokin ei toimi, niin asia ratkaistaan nopeasti. Ja jos tämä automaattinen skaalausryhmä on päivitetty, jossain vaiheessa automaattisen skaalauksen ryhmän esiintymät alkavat korvata. Ja taputtaa, jokin ei toimi. Se sattuu.
Osoittautuuko, että ainoa ratkaisu on testata?
Kyllä, näet ongelman, lisäät siihen testivaiheet. Eli ulostuloa voidaan myös testata. Ei ehkä niin kätevää, mutta voit myös laittaa merkkejä - tarkista, että käyttäjätiedot on naulattu tähän.
Nimeni on Timur. On erittäin hienoa, että on olemassa raportteja Terraformin asianmukaisesta järjestämisestä.
En edes aloittanut.
Luulen, että seuraavassa konferenssissa saattaa olla. Minulla on yksinkertainen kysymys. Miksi koodaat arvon erilliseen moduuliin sen sijaan, että käytät tfvarsia, eli onko moduuli, jonka arvot ovat parempia kuin tfvars?
Eli minun pitäisi kirjoittaa tähän (dia: Production/environment/settings.tf): domain = muuttuja, domain vpcnetwork, vpcnetwork muuttuja ja stvars - saatko saman asian?
Teemme juuri niin. Viitataan esimerkiksi asetuslähdemoduuliin.
Itse asiassa tämä on sellainen tfvars. Tfvars on erittäin kätevä testausympäristössä. Minulla on tfvars suuria tapauksia varten, pienille. Ja heitin yhden tiedoston kansioon. Ja sain mitä halusin. Kun näimme infrastruktuurin, haluamme nähdä ja ymmärtää kaiken välittömästi. Ja niin käy ilmi, että sinun täytyy katsoa täältä ja sitten etsiä tfvareista.
Kävikö ilmi, että kaikki oli yhdessä paikassa?
Kyllä, tfvars on, kun sinulla on yksi koodi. Ja sitä käytetään useissa eri paikoissa erilaisin vivahtein. Sitten heittäisit tfvareja ja saisit vivahteitasi. Ja olemme infrastruktuuri koodina puhtaimmassa muodossaan. Katsoi ja ymmärsi.
Hei! Oletko törmännyt tilanteisiin, joissa pilvipalveluntarjoaja häiritsee mitä olet tehnyt Terraformin kanssa? Oletetaan, että muokkaamme metatietoja. Siellä on ssh-avaimet. Ja Google liu'uttaa jatkuvasti metatietojaan, avaimiaan sinne. Ja Terraform kirjoittaa aina, että sillä on muutoksia. Jokaisen ajon jälkeen, vaikka mikään ei muutu, hän sanoo aina päivittävänsä tämän kentän nyt.
Avaimilla, mutta - kyllä, osa infrastruktuurista vaikuttaa sellaiseen, eli Terraform ei voi muuttaa mitään. Emme myöskään voi muuttaa mitään käsillämme. Niin kauan kuin elämme sen kanssa.
Eli törmäsit tähän, mutta et keksinyt mitään, miten hän tekee sen ja tekee sen itse?
Valitettavasti kyllä.
Hei! Nimeni on Stanislav Starkov. Mail. fi Ryhmä. Kuinka ratkaiset tunnisteen luomisen ongelman ..., kuinka välität sen sisään? Ymmärtääkseni käyttäjätietojen avulla voit määrittää isäntänimen, yllyttää Puppet? Ja kysymyksen toinen osa. Kuinka ratkaiset tämän ongelman SG:ssä, eli kun luot SG:n, sata samantyyppistä esiintymää, kuinka ne nimetään oikein?
Ne tapaukset, jotka ovat meille erittäin tärkeitä, nimeämme ne kauniisti. Ne, joita ei tarvita, on jälkikirjoitus, että tämä on automaattinen skaalattu ryhmä. Ja teoriassa se voidaan naulata ja saada uusi.
Mitä tulee tunnisteen ongelmaan, sellaista ongelmaa ei ole, mutta sellainen tehtävä on. Ja käytämme tunnisteita erittäin, erittäin voimakkaasti, koska infrastruktuuri on suuri ja kallis. Ja meidän on katsottava, mihin rahaa käytetään, joten tunnisteiden avulla voimme selvittää, mitä ja minne se meni. Ja vastaavasti jonkun etsimiseen täällä kuluu paljon rahaa.
Mistä muusta kysymys oli?
Kun SG luo sata esiintymää, pitääkö ne jotenkin erottaa?
Ei, älä. Jokaisella tapauksella on agentti, joka kertoo minulle, että minulla on ongelma. Jos agentti raportoi, niin agentti tietää hänestä ja ainakin hänen IP-osoitteensa on olemassa. Voit jo juosta. Toiseksi käytämme Consul for Discoveryä, jossa ei ole Kubernetesia. Ja Consul näyttää myös esiintymän IP-osoitteen.
Eli kohdistat tarkalleen IP-osoitteeseen, et isäntänimeen?
Isäntänimen perusteella on mahdotonta navigoida, eli niitä on paljon. Siellä on esiintymän tunnisteita - AE jne. Löydät sen jostain, voit heittää sen hakuun.
Hei! Tajusin, että Terraform on hyvä asia, räätälöitynä pilviin.
Ei vain.
Tämä on minua kiinnostava kysymys. Jos päätät muuttaa vaikkapa Bare Metaliin kaikkine esiintymisineen? Tuleeko mitään ongelmia? Vai pitääkö sinun silti käyttää muita tuotteita, esimerkiksi samaa Ansiblea, joka täällä mainittiin?
Ansible liittyy vähän muuhun. Toisin sanoen Ansible on jo käynnissä, kun ilmentymä on alkanut. Ja Terraform toimii ennen kuin ilmentymä on alkanut. Bare Metaliin vaihtaminen ei ole.
Ei nyt, mutta liike tulee ja sanoo: "Tule nyt."
Vaihtaminen toiseen pilveen - kyllä, mutta tässä on hieman erilainen ominaisuus. Sinun on kirjoitettava Terraform-koodi siten, että voit siirtyä johonkin toiseen pilveen, jossa on vähemmän verenvuodatusta.
Aluksi tehtävänä oli, että koko infrastruktuurimme on agnostinen, eli minkä tahansa pilven pitäisi olla kunnossa, mutta jossain vaiheessa yritys luovutti ja sanoi: "OK, seuraavan N vuoden aikana emme lähde minnekään, voit käyttää palveluita alkaen Amazon".
Terraformin avulla voit luoda Front-End-töitä, määrittää PagerDutyn, datadokumentteja jne. Siinä on paljon häntää. Hän voi käytännössä hallita koko maailmaa.
Kiitos raportista! Olen myös pyörittänyt Terraformia nyt 4 vuotta. Vaiheessa, jossa siirryttiin sujuvasti Terraformiin, infrastruktuuriin, deklaratiiviseen kuvaukseen, kohtasimme tilanteen, jossa joku teki jotain käsin ja sinä yritit tehdä suunnitelmaa. Ja siinä minulla oli virhe. Miten käsittelet tällaisia ongelmia? Miten löydät ilmoitetut kadonneet resurssit?
Useimmiten käsillämme ja silmillämme, jos näemme raportissa jotain outoa, niin analysoimme mitä siellä tapahtuu, tai vain tapamme sen. Yleensä vetopyynnöt ovat yleisiä.
Jos on virhe, peruutatko? Oletko kokeillut tehdä tätä?
Ei, tämä on ihmisen päätös sillä hetkellä, kun hän näkee ongelman.
Lähde: will.com