S-ar părea că dezvoltatorii Terraform oferă cele mai bune practici destul de convenabile pentru lucrul cu infrastructura AWS. Există doar o nuanță. În timp, numărul de medii crește, fiecare având propriile caracteristici. În regiunea vecină apare aproape o copie a stivei de aplicații. Și codul Terraform trebuie copiat și editat cu atenție în conformitate cu noile cerințe sau transformat într-un fulg de zăpadă.
Raportul meu despre modelele din Terraform pentru a combate haosul și rutina manuală pe proiecte mari și lungi.
video:
Am 40 de ani, sunt în IT de 20 de ani. Lucrez pentru Ixtens de 12 ani. Suntem angajați în dezvoltarea bazată pe comerțul electronic. Și practic practicile DevOps de 5 ani.
Povestea mea va fi despre experiența mea într-un proiect într-o companie al cărei nume nu-l voi spune, ascunzându-se în spatele unui acord de confidențialitate.
Numerele de pe diapozitiv sunt indicate pentru a înțelege amploarea proiectului. Și tot ceea ce voi spune în continuare este legat de Amazon.
M-am alăturat acestui proiect acum 4 ani. Și refactorizarea infrastructurii era în plină desfășurare pentru că proiectul creștea. Iar modelele care au fost folosite nu mai erau potrivite. Și având în vedere toată creșterea planificată a proiectului, a fost necesar să se vină cu ceva nou.
Mulțumim lui Matvey, care ieri ne-a povestit ce s-a întâmplat la Dodo Pizza. Asta s-a întâmplat aici acum 4 ani.
Au venit dezvoltatorii și au început să facă cod de infrastructură.
Motivele cele mai evidente pentru care acest lucru a fost necesar a fost momentul introducerii pe piață. A fost necesar să se asigure că echipa DevOps nu a fost un blocaj în timpul lansării. Și, printre altele, Terraform și Puppet au fost folosite chiar la primul nivel.
Terraform este un proiect open source de la HashiCorp. Și pentru cei care nici măcar nu știu ce este asta, următoarele diapozitive.
Infrastructura ca cod înseamnă că ne putem descrie infrastructura și le putem cere unor roboți să se asigure că primim resursele pe care le-am descris.
De exemplu, avem nevoie de o mașină virtuală. Vom descrie și adăuga câțiva parametri necesari.
După aceasta, vom configura accesul la Amazon în consolă. Și vom cere planul Terraform. Planul Terraform va spune: „Bine, putem face aceste lucruri pentru resursa ta”. Și cel puțin o resursă va fi adăugată. Și nu sunt de așteptat schimbări.
Odată ce ești mulțumit de tot, poți cere Terraform să aplice și Terraform va crea o instanță pentru tine și vei primi o mașină virtuală în cloud.
În continuare proiectul nostru se dezvoltă. Adăugăm câteva modificări acolo. Solicităm mai multe exemple, adăugăm 53 de intrări.
Și repetăm. Vă rugăm să planificați. Vedem ce schimbări sunt planificate. Aplicam. Și așa crește infrastructura noastră.
Terraform folosește ceva numit fișiere de stare. Adică, toate modificările care ajung la Amazon sunt salvate într-un fișier în care pentru fiecare resursă pe care ați descris-o, există resurse corespunzătoare care au fost create în Amazon. Astfel, atunci când descrierea unei resurse se modifică, Terraform știe exact ce trebuie schimbat în Amazon.
Aceste fișiere de stat au fost inițial doar fișiere. Și le-am stocat în Git, ceea ce a fost extrem de incomod. Cineva a uitat mereu să facă schimbări și au apărut multe conflicte.
Acum este posibil să utilizați backend-ul, adică Terraform este specificat în ce găleată și cu ce cheie ar trebui salvat fișierul de stare. Și Terraform însuși se va ocupa de obținerea acestui fișier de stare, de a face toată magia și de a pune înapoi rezultatul final.
Infrastructura noastră este în creștere. Iată codul nostru. Și acum nu vrem doar să creăm o mașină virtuală, vrem să avem un mediu de testare.
Terraform vă permite să creați un astfel de lucru ca un modul, adică să descrieți același lucru într-un folder.
Și, de exemplu, la testare, apelați acest modul și obțineți același lucru ca și cum am fi executat aplicația Terraform în modulul în sine. Pentru testare va exista acest cod.
Pentru producție, putem trimite unele modificări acolo, deoarece în testare nu avem nevoie de instanțe mari; în producție, instanțele mari sunt doar utile.
Și apoi mă voi întoarce la proiect. A fost o sarcină dificilă, infrastructura planificată era foarte mare. Și a fost necesar să plasăm cumva tot codul astfel încât să fie convenabil pentru toată lumea: atât pentru cei care fac întreținere pe acest cod, cât și pentru cei care fac modificări. Și a fost planificat ca orice dezvoltator să poată merge și să repare infrastructura după cum este necesar pentru partea sa din platformă.
Acesta este un arbore de directoare care este recomandat de HashiCorp însuși dacă aveți un proiect mare și este logic să împărțiți întreaga infrastructură în câteva bucăți mici și să descrieți fiecare piesă într-un folder separat.
Având o bibliotecă extinsă de resurse, puteți apela aproximativ același lucru în testare și în producție.
În cazul nostru, acest lucru nu a fost pe deplin potrivit, deoarece stiva de teste pentru dezvoltatori sau pentru testare trebuia obținută cumva mai simplu. Dar nu am vrut să parcurg folderele și să le aplic în secvența necesară și să-mi fac griji că baza de date va crește, iar apoi instanța care utilizează această bază de date va crește. Prin urmare, toate testele au fost lansate dintr-un singur folder. Acolo au fost numite aceleași module, dar totul s-a făcut într-o singură cursă.
Terraform are grijă de toate dependențele. Și creează întotdeauna resurse în secvență, astfel încât să puteți obține o adresă IP, de exemplu, de la o instanță nou creată și să obțineți această adresă IP în înregistrarea route53.
În plus, platforma este foarte mare. Și lansarea unei stive de testare, chiar dacă pentru o oră, chiar dacă pentru 8 ore, este o întreprindere destul de costisitoare.
Și am automatizat această chestiune. Iar slujba lui Jenkins ne-a permis să conducem stiva. În acesta, a fost necesar să se lanseze o cerere de extragere cu modificările pe care dezvoltatorul dorește să le testeze, să specifice toate opțiunile, componentele și dimensiunile necesare. Dacă dorește testarea performanței, atunci poate lua mai multe cazuri. Dacă trebuie doar să verifice dacă se deschide un formular, atunci ar putea începe cu salariul minim. Și, de asemenea, indicați dacă un cluster este necesar sau nu etc.
Și apoi Jenkins a împins un script shell, care a modificat ușor codul din folderul Terraform. Am eliminat fișierele inutile și am adăugat fișierele necesare. Și apoi, cu o aplicație Terraform, stiva a fost ridicată.
Și apoi au fost și alți pași în care nu vreau să merg.
Datorită faptului că pentru testare aveam nevoie de puțin mai multe opțiuni decât în producție, a trebuit să facem copii ale modulelor pentru ca în aceste copii să putem adăuga acele caracteristici care erau necesare doar pentru testare.
Și s-a întâmplat că în testare vreau să testez acele modificări care vor intra în final în producție. Dar, de fapt, un lucru a fost testat, iar unul ușor diferit a fost folosit în producție. Și a existat o mică pauză în tiparul că în producție toate modificările au fost aplicate de echipa de operare. Și uneori s-a dovedit că acele modificări care trebuiau să treacă de la testare la producție au rămas într-o altă versiune.
În plus, a existat o astfel de problemă încât a fost adăugat un nou serviciu, care era ușor diferit de unul deja existent. Și în loc să modificăm un modul existent, a trebuit să facem o copie a acestuia și să adăugăm modificările necesare.
În esență, Terraform nu este un limbaj real. Aceasta este o declarație. Dacă trebuie să declarăm ceva, atunci îl declarăm. Și totul funcționează.
La un moment dat, când se discuta una dintre solicitările mele de atragere, unul dintre colegii mei a spus că nu este nevoie să creez fulgi de zăpadă. M-am întrebat ce a vrut să spună. Există un fapt științific că nu există doi fulgi de nea identici în lume, toți sunt ușor diferiți. Și de îndată ce am auzit asta, am simțit imediat toată greutatea codului Terraform. Pentru că atunci când a fost necesar să treceți de la o versiune la alta, Terraform a necesitat schimbări de lanț de rupere, adică codul nu mai era compatibil cu următoarea versiune. Și a trebuit să facem un pull request, care acoperea aproape jumătate din fișierele din infrastructură, pentru a aduce infrastructura la următoarea versiune de Terraform.
Și după ce a apărut un astfel de fulg de nea, tot codul Terraform pe care îl transformasem într-un morman mare, mare de zăpadă.
Pentru un dezvoltator extern care se află în afara operațiunii, acest lucru nu contează foarte mult pentru el, pentru că a făcut o cerere de pull, a început resursa. Și asta e tot, nu mai este preocuparea lui. Și echipa DevOps, care se asigură că totul este în regulă, trebuie să facă toate aceste modificări. Și costul acestor modificări a crescut foarte, foarte mult cu fiecare fulg de zăpadă suplimentar.
Există o poveste despre cum un student la un seminar desenează două cercuri perfecte cu cretă pe tablă. Și profesorul este surprins de cum a reușit să deseneze atât de ușor fără busolă. Elevul răspunde: „Foarte simplu, am petrecut doi ani în armată, transformând o mașină de tocat carne”.
Și din cei patru ani în care am fost implicat în acest proiect, fac Terraform de aproximativ doi ani. Și, bineînțeles, am câteva trucuri, câteva sfaturi despre cum să simplific codul Terraform, să lucrez cu el ca un limbaj de programare și să reduc povara dezvoltatorilor care trebuie să țină acest cod la zi.
Primul lucru cu care aș dori să încep este Symlinks. Terraform are o mulțime de coduri repetitive. De exemplu, apelul către furnizor în aproape fiecare punct în care creăm o infrastructură este același. Și este logic să îl puneți într-un folder separat. Și oriunde este necesar ca furnizorul să facă legături simbolice către acest fișier.
De exemplu, în producție utilizați rolul de asumare, care vă permite să obțineți drepturi de acces la un cont extern Amazon. Și după ce au schimbat un fișier, toate cele rămase din arborele de resurse vor avea drepturile necesare, astfel încât Terraform să știe ce segment Amazon să acceseze.
Unde eșuează linkurile simbolice? După cum am spus, Terraform are dosare de stat. Și sunt foarte, foarte cool. Dar lucrul este că Terraform inițializează backend-ul în primul rând. Și nu poate folosi nicio variabilă în acești parametri; ele trebuie să fie întotdeauna scrise în text.
Și, ca rezultat, atunci când cineva face o nouă resursă, el copiază o parte din cod din alte foldere. Și poate greși cu cheia sau cu găleata. De exemplu, el face un lucru cu nisip din sandbox și apoi îl face în producție. Și astfel se poate dovedi că găleata în producție va fi folosită din cutia de nisip. Desigur, o vor găsi rapid. Va fi posibil să remediați acest lucru cumva, dar cu toate acestea este o pierdere de timp și, într-o oarecare măsură, de resurse.
Ce putem face în continuare? Înainte de a lucra cu Terraform, trebuie să-l inițializați. La inițializare, Terraform descarcă toate pluginurile. La un moment dat, s-au despărțit de la un monolit la o arhitectură mai microservicii. Și întotdeauna trebuie să faceți Terraform init, astfel încât să tragă în sus toate modulele, toate pluginurile.
Și puteți folosi un script shell, care, în primul rând, poate obține toate variabilele. Scriptul shell nu este limitat în niciun fel. Și, în al doilea rând, cărările. Dacă folosim întotdeauna calea care se află în depozit ca cheie pentru fișierul de stare, atunci, în consecință, eroarea de aici va fi eliminată.
De unde pot obține datele? Fișier JSON. Terraform vă permite să scrieți infrastructura nu numai în hcl (HashiCorp Configuration Language), ci și în JSON.
JSON este ușor de citit dintr-un script shell. În consecință, puteți pune fișierul de configurare cu găleată într-un loc. Și utilizați această găleată atât în codul Terraform, cât și în scriptul shell pentru inițializare.
De ce este important să aveți o găleată pentru Terraform? Pentru că există fișiere de stare la distanță. Adică, atunci când ridic o resursă, pentru a spune Amazon: „Vă rugăm să ridicați instanța”, trebuie să specific o mulțime de parametri necesari.
Și acești identificatori sunt stocați în alt folder. Și pot să mă duc și să spun: „Terraform, te rog să mergi la fișierul de stat al acelei resurse și adu-mi acești identificatori.” Și astfel apare o anumită unificare între diferite regiuni sau medii.
Nu este întotdeauna posibil să utilizați un fișier de stare la distanță. De exemplu, ați creat manual un VPC. Și codul Terraform care creează VPC-ul creează VPC-uri atât de diferite încât va dura foarte mult timp și va trebui să vă ajustați unul la celălalt, astfel încât să puteți folosi următorul truc.
Adică, faceți un modul care pare să facă un VPC și, așa cum ar fi, vă oferă identificatori, dar de fapt există pur și simplu un fișier cu valori codificate, care poate fi folosit pentru a crea aceeași instanță.
Nu este întotdeauna necesar să salvați fișierul de stare în cloud. De exemplu, atunci când testați module, puteți utiliza inițializarea backend, unde fișierul va fi pur și simplu salvat pe disc în momentul testării.
Acum puțin despre testare. Ce poți testa în Terraform? Probabil că multe sunt posibile, dar voi vorbi despre aceste 4 lucruri.
HashiCorp înțelege cum ar trebui formatat codul Terraform. Iar Terraform fmt vă permite să formatați codul pe care îl editați în funcție de această credință. În consecință, testele trebuie să verifice în mod necesar dacă formatarea corespunde cu ceea ce a lăsat moștenire HashiCorp, astfel încât să nu fie nevoie să se schimbe locația parantezelor etc.
Următorul este Terraform validate. Nu face altceva decât să verifice sintaxa - ala, dacă toate parantezele sunt împerecheate. Ce este important aici? Infrastructura noastră este foarte extinsă. Există o mulțime de tătici diferiți în ea. Și în fiecare trebuie să rulați Terraform validate.
În consecință, pentru a accelera testarea, rulăm mai multe procese în paralel folosind paralel.
Paralelul este un lucru foarte tare, folosește-l.
Dar de fiecare dată când Terraform se inițializează, acesta merge la HashiCorp și întreabă: „Care sunt cele mai recente versiuni de plugin? Și pluginul pe care îl am în cache – este cel corect sau cel greșit?” Și acest lucru a încetinit la fiecare pas.
Dacă îi spui lui Terraform unde sunt pluginurile, atunci Terraform va spune: „Bine, acesta este probabil cel mai recent lucru care există. Nu voi merge nicăieri, voi începe imediat să vă validez codul Terraform.”
Pentru a umple folderul cu pluginurile necesare, avem un cod Terraform foarte simplu care trebuie doar inițializat. Aici, desigur, trebuie să specificați toți furnizorii care participă cumva la codul dvs., altfel Terraform va spune: „Nu cunosc un anumit furnizor pentru că nu se află în cache”.
Urmează planul Terraform. După cum am spus, dezvoltarea este ciclică. Facem modificări la cod. Și apoi trebuie să aflați ce schimbări sunt planificate pentru infrastructură.
Și atunci când infrastructura este foarte, foarte mare, puteți schimba un modul, puteți repara un mediu de testare sau o anumită regiune și puteți sparge unul învecinat. Prin urmare, planul Terraform ar trebui realizat pentru întreaga infrastructură și să arate ce schimbări sunt planificate.
Puteți face acest lucru inteligent. De exemplu, am scris un script Python care rezolvă dependențele. Și în funcție de ceea ce a fost schimbat: un modul Terraform sau doar o componentă specifică, face planuri pentru toate folderele dependente.
Planurile Terraform trebuie realizate la cerere. Cel puțin asta facem.
Desigur, este bine să faci teste pentru fiecare schimbare, pentru fiecare comitere, dar planurile sunt destul de costisitoare. Și într-o cerere de tragere spunem: „Vă rog să-mi dați planurile”. Robotul pornește. Și trimite comentarii sau atașează toate planurile care sunt așteptate de la modificările tale.
Un plan este un lucru destul de costisitor. Este nevoie de timp pentru că Terraform merge la Amazon și întreabă: „Există încă această instanță? Această scalare automată are exact aceiași parametri?” Și pentru a accelera acest lucru, puteți utiliza un parametru precum refresh=false. Aceasta înseamnă că Terraform va descărca starea de pe S3. Și va crede că statul se va potrivi exact cu ceea ce este în Amazon.
Un astfel de plan Terraform merge mult mai repede, dar starea trebuie să corespundă infrastructurii dvs., adică undeva, cândva trebuie să înceapă reîmprospătarea Terraform. Terraform refresh face exact asta: starea se potrivește cu ceea ce este în infrastructura actuală.
Și trebuie să vorbim despre siguranță. Aici trebuia să începem. Acolo unde rulați Terraform și Terraform rulează pe infrastructura dvs., există o vulnerabilitate. Adică, în esență, executați codul. Și dacă cererea de extragere conține un fel de cod rău intenționat, atunci acesta poate fi executat pe o infrastructură care are prea mult acces. Așa că aveți grijă unde rulați planul Terraform.
Următorul lucru despre care aș dori să vorbesc este testarea datelor utilizatorului.
Ce sunt datele utilizatorului? În Amazon, atunci când creăm o instanță, putem trimite o anumită scrisoare cu instanța - metadate. Când pornește instanța, de obicei cloud init este întotdeauna prezent în aceste instanțe. Cloud init citește această scrisoare și spune: „OK, astăzi sunt echilibrantul de încărcare.” Și în conformitate cu aceste legăminte, el efectuează unele acțiuni.
Dar, din păcate, atunci când facem planul Terraform și se aplică Terraform, datele utilizatorului arată ca acest tip de zburătoare de numere. Adică pur și simplu îți trimite hașul. Și tot ce vă puteți uita în plan este dacă vor exista modificări sau dacă hash-ul va rămâne același.
Și dacă nu acordați atenție acestui lucru, atunci un fișier text rupt poate ajunge pe Amazon, pe infrastructura reală.
Alternativ, la executare, puteți specifica nu întreaga infrastructură, ci doar șablonul. Și în cod spune: „Vă rugăm să afișați acest șablon pe ecranul meu”. Și, ca rezultat, puteți obține o imprimare a cum vor arăta datele dvs. pe Amazon.
O altă opțiune este utilizarea unui modul pentru a genera date utilizator. Veți aplica acest modul. Primești fișierul pe disc. Comparați-l cu cel de referință. Și astfel, dacă un tip decide să corecteze puțin datele utilizatorului, atunci testele tale vor spune: „OK, sunt câteva modificări ici și colo - acest lucru este normal.”
Următorul lucru despre care aș dori să vorbesc este aplicarea automată Terraform.
Desigur, este destul de înfricoșător să se aplice Terraform automat, pentru că cine știe ce schimbări au apărut acolo și cât de distructive pot fi acestea pentru infrastructura vie.
Pentru un mediu de testare, totul este normal. Adică, o muncă care creează un mediu de testare este ceea ce au nevoie toți dezvoltatorii. Și o expresie precum „totul a funcționat pentru mine” nu este o meme amuzantă, ci o dovadă că o persoană s-a încurcat, a ridicat o stivă și a făcut niște teste pe această stivă. Și s-a asigurat că totul este bine acolo și a spus: „Bine, codul pe care îl lansez a fost testat”.
În producție, sandbox și alte medii care sunt mai critice pentru afaceri, puteți utiliza parțial unele resurse în siguranță, deoarece nu duce la moartea pe nimeni. Acestea sunt: grupuri autoscale, grupuri de securitate, roluri, ruta53, iar lista de acolo poate fi destul de mare. Dar fiți cu ochii pe ce se întâmplă, citiți rapoartele automate ale aplicațiilor.
Acolo unde este periculos sau înfricoșător să aplicați, de exemplu, dacă acestea sunt niște resurse persistente dintr-o bază de date, atunci primiți rapoarte că există modificări neaplicate într-o anumită parte a infrastructurii. Iar inginerul, sub supraveghere, începe joburi pentru a aplica sau o face din consola lui.
Amazon are așa ceva ca Terminate protecția. Și poate proteja în unele cazuri de modificările care nu sunt necesare pentru dvs. Adică, Terraform a mers la Amazon și a spus: „Trebuie să omor această instanță pentru a face alta”. Și Amazon spune: „Îmi pare rău, nu astăzi. Avem protecție Terminate.”
Iar cireașa de pe tort este optimizarea codului. Când lucrăm cu cod Terraform, trebuie să transmitem un număr foarte mare de parametri la modul. Aceștia sunt parametrii necesari pentru a crea un fel de resursă. Și codul se transformă în liste mari de parametri care trebuie să fie transmise de la modul la modul, de la modul la modul, mai ales dacă modulele sunt imbricate.
Și este foarte greu de citit. Este foarte greu să revizuim asta. Și de foarte multe ori se dovedește că unii parametri sunt supuși revizuirii și nu sunt exact ceea ce este necesar. Și asta costă timp și bani pentru a remedia mai târziu.
Prin urmare, vă sugerez să utilizați așa ceva ca un parametru complex care include un anumit arbore de valori. Adică, aveți nevoie de un fel de folder în care aveți toate valorile pe care ați dori să le aveți într-un mediu oarecare.
Și apelând acest modul, puteți obține un arbore care este generat într-un modul comun, adică într-un modul comun care funcționează la fel pentru întreaga infrastructură.
În acest modul puteți face câteva calcule folosind o funcție atât de recentă în Terraform ca localnici. Și apoi, cu o singură ieșire, dați un parametru complex, care poate include hash-uri de matrice etc.
Aici s-au încheiat toate cele mai bune descoperiri pe care le-am avut. Și aș vrea să spun o poveste despre Columb. Când a căutat bani pentru expediția sa de a descoperi India (cum credea el atunci), nimeni nu l-a crezut și au crezut că este imposibil. Apoi a spus: „Asigură-te că oul nu cade”. Toți bancherii, oameni foarte bogați și probabil deștepți, au încercat să pună cumva oul, iar acesta a tot căzut. Apoi Columb a luat oul și l-a presat puțin. Coaja s-a mototolit și oul a rămas nemișcat. Ei au spus: „Oh, e prea ușor!” Și Columb a răspuns: „Da, este prea simplu. Și când voi deschide India, toată lumea va folosi această rută comercială.”
Și ceea ce tocmai ți-am spus sunt probabil lucruri destul de simple și banale. Și când înveți despre ele și începi să le folosești, este în ordinea lucrurilor. Așa că profită. Și dacă acestea sunt lucruri absolut normale pentru tine, atunci măcar știi să așezi oul ca să nu cadă.
Să rezumăm:
- Încercați să evitați fulgii de zăpadă. Și cu cât sunt mai puțini fulgi de zăpadă, cu atât mai puține resurse veți avea nevoie pentru a face modificări în infrastructura dumneavoastră mare.
- Schimbări constante. Adică, atunci când apar unele modificări în cod, trebuie să vă aduceți infrastructura în conformitate cu aceste modificări cât mai repede posibil. Nu ar trebui să existe o situație în care cineva să vină să se uite la Elasticsearch două sau trei luni mai târziu, să facă un plan Terraform și există o grămadă de schimbări la care nu se aștepta. Și este nevoie de mult timp pentru a pune totul la loc.
- Teste și automatizări. Cu cât codul dvs. este acoperit mai mult de teste și funcții, cu atât aveți mai multă încredere că faceți totul corect. Și livrarea automată vă va crește încrederea de multe ori.
- Codul pentru mediile de testare și de producție ar trebui să fie aproape același. Practic, pentru că producția este încă puțin diferită și vor exista în continuare câteva nuanțe care vor depăși mediul de testare. Dar, cu toate acestea, în plus sau în minus, acest lucru poate fi asigurat.
- Și dacă aveți o mulțime de cod Terraform și este nevoie de mult timp pentru a menține acest cod la zi, atunci nu este niciodată prea târziu pentru a refactoriza și a-l pune în formă.
- Infrastructură imuabilă. Livrare AMI la program.
- Structura pentru route53 atunci când aveți o mulțime de intrări și doriți ca acestea să fie într-o ordine consecventă.
- Combaterea limitelor ratei API. Acesta este momentul în care Amazon spune: „Asta este, nu mai pot accepta alte cereri, vă rog să așteptați”. Și jumătate din birou așteaptă până își poate lansa infrastructura.
- Instanțe identificate. Amazon nu este un eveniment ieftin și spoturile vă permit să economisiți destul de mult. Și acolo poți spune un întreg raport despre asta.
- Roluri de securitate și IAM.
- În căutarea resurselor pierdute, atunci când aveți cazuri de origine necunoscută în Amazone, ei mănâncă bani. Chiar dacă cazurile costă 100-150 USD pe lună, aceasta înseamnă mai mult de 1 USD pe an. Găsirea unor astfel de resurse este o afacere profitabilă.
- Și instanțe rezervate.
Asta e tot pentru mine. Terraform este foarte tare, îl folosești. Mulțumesc!
întrebări
Multumesc pentru raport! Fișierul dvs. de stare este în S3, dar cum rezolvați problema că mai multe persoane pot lua acest fișier de stare și pot încerca să se extindă?
În primul rând, nu ne grăbim. În al doilea rând, există steaguri, în care raportăm că lucrăm la o bucată de cod. Adică, în ciuda faptului că infrastructura este foarte mare, asta nu înseamnă că cineva folosește în mod constant ceva. Și când a fost o fază activă, aceasta a fost o problemă; am stocat fișierele de stare în Git. Acest lucru era important, altfel cineva ar face un fișier de stat și trebuia să le adunăm manual pentru ca totul să continue. Acum nu există o astfel de problemă. În general, Terraform a rezolvat această problemă. Și dacă ceva se schimbă în mod constant, atunci poți folosi încuietori, care împiedică ceea ce ai spus.
Folosești open source sau enterprise?
Fără întreprindere, adică tot ce poți merge și descărca gratuit.
Numele meu este Stanislav. Am vrut să fac o mică completare. Ați vorbit despre o caracteristică Amazon care vă permite să faceți o instanță invalidabilă. Acest lucru este și în Terraform propriu-zis; în blocul Life Second puteți specifica o interdicție de modificare sau o interdicție de distrugere.
Timpul era limitat. Buna observatie.
Am vrut să întreb și eu două lucruri. În primul rând, ai vorbit despre testare. Ați folosit vreun instrument de testare? Am auzit de pluginul Test Kitchen. Poate mai este ceva. Și aș dori să întreb și despre valorile locale. Prin ce diferă ele în mod fundamental de variabilele de intrare? Și de ce nu pot parametriza ceva doar prin Valori Locale? Am încercat să-mi dau seama de acest subiect, dar cumva nu am reușit să-l rezolv singur.
Putem vorbi mai detaliat în afara acestei camere. Instrumentele noastre de testare sunt complet create de sine. Nu e nimic de testat acolo. În general, există opțiuni când testele automate preiau infrastructura de undeva, verifică dacă este OK și apoi distrug totul cu un raport că infrastructura ta este încă în stare bună. Nu avem acest lucru deoarece stivele de teste sunt rulate în fiecare zi. Și asta e de ajuns. Și dacă ceva începe să se rupă, va începe să se rupă fără ca noi să-l verificăm în altă parte.
În ceea ce privește Valorile Locale, să continuăm conversația în afara sălii.
Buna ziua! Multumesc pentru raport! Foarte informativ. Ați spus că aveți o mulțime de același tip de cod pentru a descrie infrastructura. Te-ai gândit să generezi acest cod?
Superba intrebare, multumesc! Ideea este că atunci când folosim infrastructura ca cod, presupunem că ne uităm la cod și înțelegem ce infrastructură se află în spatele codului respectiv. Dacă se generează cod, atunci trebuie să ne imaginăm ce cod va fi generat pentru a înțelege ce fel de infrastructură va fi acolo. Fie generăm cod, îl comităm și, în esență, se întâmplă același lucru. Așa că am urmat calea pe care am scris-o, am primit-o. Plus generatoarele au apărut puțin mai târziu când am început să le facem. Și era deja prea târziu să se schimbe.
Ai auzit ceva despre jsonnet?
Nu.
Uite, acesta este un lucru foarte tare. Văd un caz specific în care îl puteți aplica și genera o structură de date.
Generatoarele sunt bune când le ai, ca în gluma despre o mașină de bărbierit. Adică prima dată fața este diferită, dar apoi toată lumea are aceeași față. Generatoarele functioneaza foarte bine. Dar, din păcate, fețele noastre sunt ușor diferite. Aceasta este o problemă.
Uită-te. Mulțumesc!
Numele meu este Maxim, sunt de la Sberbank. Ai vorbit puțin despre cum ai încercat să aduci Terraform la echivalentul unui limbaj de programare. Nu este mai ușor să folosești Ansible?
Acestea sunt lucruri foarte diferite. Puteți crea resurse în Ansible, iar Puppet poate crea resurse în Amazon. Dar Terraform este ascuțit direct.
Ai doar Amazon?
Nu este că avem doar Amazon. Avem aproape doar Amazon. Dar caracteristica cheie este că Terraform își amintește. În Ansible, dacă spui: „Dă-mi 5 cazuri”, atunci se va ridica, iar apoi spui: „Și acum am nevoie de 3”. Iar Terraform va spune: „Bine, voi omorî 2”, iar Ansible va spune: „Bine, iată 3 pentru tine”. Total 8.
Buna ziua! Mulțumesc pentru raport! A fost foarte interesant să aud despre Terraform. Aș dori să fac imediat un mic comentariu despre faptul că Terraform încă nu are o versiune stabilă, așa că tratați Terraform cu mare prudență.
O lingură bună pentru cină. Adică dacă ai nevoie de o soluție, atunci uneori amâni ceea ce este instabil etc., dar funcționează și ne-a ajutat.
Întrebarea este aceasta. Folosești backend la distanță, folosești S 3. De ce nu folosești backend-ul oficial?
Oficial?
Terraform Cloud.
Când a apărut?
acum 4 luni.
Dacă ar fi apărut acum 4 ani, atunci probabil că ți-aș fi răspuns la întrebare.
Există deja o funcție încorporată și blocări și puteți stoca un fișier de stare. Incearca. Dar nici eu nu l-am testat.
Călătorim cu un tren mare care se deplasează cu viteză mare. Și nu poți să iei doar câteva mașini și să le arunci.
Ai vorbit despre fulgi de nea, de ce nu ai folosit ramura? De ce nu a mers așa?
Abordarea noastră este ca întreaga infrastructură să fie într-un singur depozit. Terraform, Puppet, toate scripturile care sunt cumva legate de asta, toate sunt într-un singur depozit. În acest fel, ne putem asigura că modificările incrementale sunt testate una după alta. Dacă ar fi o grămadă de ramuri, atunci un astfel de proiect ar fi aproape imposibil de întreținut. Trec șase luni și diferă atât de mult încât este doar un fel de pedeapsă. De asta am vrut să scap înainte de refactorizare.
Deci nu merge?
Acest lucru nu funcționează deloc.
În ramură am decupat slide-ul folderului. Adică, dacă o faci pentru fiecare stivă de testare, de exemplu, echipa A are propriul folder, echipa B are propriul folder, atunci nici acest lucru nu funcționează. Am creat un cod de mediu de testare unificat care a fost suficient de flexibil pentru a se potrivi tuturor. Adică am servit un singur cod.
Buna ziua! Numele meu este Yura! Multumesc pentru raport! Întrebare despre module. Spui că folosești module. Cum rezolvi problema dacă s-au făcut modificări unui modul care nu sunt compatibile cu modificarea altei persoane? Versiune cumva modulele sau încerci să aduci un wunderwaffle pentru a îndeplini două cerințe?
Aceasta este o mare problemă a grămezilor de zăpadă. De asta suferim atunci când o schimbare inofensivă poate distruge o parte a infrastructurii. Și acest lucru va fi vizibil abia după o perioadă lungă de timp.
Adică nu s-a rezolvat încă?
Faci module universale. Evitați fulgii de zăpadă. Și totul se va rezolva. A doua jumătate a raportului este despre cum să evitați acest lucru.
Buna ziua! Multumesc pentru raport! as vrea sa clarific. În culise era o grămadă mare pentru care am venit. Cum sunt integrate distribuția Puppet și rol?
Datele utilizatorului.
Adică doar scuipi fișierul și cumva îl executi?
Datele utilizatorului sunt o notă, adică atunci când facem o clonă a imaginii, Daemon se ridică acolo și, încercând să-și dea seama cine este, citește nota că este un echilibrator de încărcare.
Adică, acesta este un fel de proces separat care este dat?
Nu noi l-am inventat. Îl folosim.
Buna ziua! Am doar o întrebare despre utilizator - date. Ai spus că acolo sunt probleme, că cineva ar putea trimite ceva în locul nepotrivit. Există vreo modalitate de a stoca datele utilizatorului în același Git, astfel încât să fie întotdeauna clar la ce se referă datele utilizatorului?
Generam date utilizator din șablon. Adică, un anumit număr de variabile sunt folosite acolo. Iar Terraform generează rezultatul final. Prin urmare, nu puteți doar să vă uitați la șablon și să spuneți ce se va întâmpla, deoarece toate problemele sunt legate de faptul că dezvoltatorul crede că trece un șir în această variabilă, dar acolo este folosită o matrice. Și el - bam și eu - așa și așa, așa și așa, următorul rând, și totul s-a rupt. Dacă aceasta este o resursă nouă și o persoană o preia și vede că ceva nu funcționează, atunci este rezolvată rapid. Și dacă acest grup de autoscale este actualizat, atunci la un moment dat, instanțele din grupul de autoscale încep să fie înlocuite. Și pai, ceva nu funcționează. Doare.
Se pare că singura soluție este testarea?
Da, vedeți problema, adăugați pași de testare acolo. Adică, ieșirea poate fi și testată. Poate că nu este atât de convenabil, dar puteți pune, de asemenea, niște semne - verificați dacă datele utilizatorului sunt fixate aici.
Numele meu este Timur. Este foarte bine că există rapoarte despre cum să organizați corect Terraform.
Nici măcar nu am început.
Cred că poate la următoarea conferință va exista. Am o întrebare simplă. De ce codificați valoarea într-un modul separat în loc să utilizați tfvars, adică de ce este un modul cu valori mai bun decât tfvars?
Adică, ar trebui să scriu aici (diapozitiv: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork și stvars – pot obține același lucru?
Exact asta facem. Ne referim la modulul sursă de setare, de exemplu.
În esență, acestea sunt astfel de tfvars. Tfvars este foarte convenabil într-un mediu de testare. Am tfvar-uri pentru instanțe mari, pentru cele mici. Și am aruncat un fișier în folder. Și am primit ceea ce îmi doream. Când tăiem infrastructura, dorim să fie posibil să privim și să înțelegem imediat totul. Și așa se dovedește că trebuie să te uiți aici, apoi să te uiți la tfvars.
Este posibil să ai totul într-un singur loc?
Da, tfvars este atunci când aveți un cod. Și este folosit în mai multe locuri diferite, cu diferite nuanțe. Apoi aruncai tfvar-uri și primeai nuanțele tale. Și suntem infrastructură ca cod în forma sa cea mai pură. M-am uitat si am inteles.
Buna ziua! Ați întâlnit situații în care furnizorul de cloud interferează cu ceea ce ați creat Terraform? Să presupunem că edităm metadatele. Există chei ssh. Și Google își pune în mod constant metadatele și cheile acolo. Iar Terraform scrie mereu că are schimbări. După fiecare rulare, chiar dacă nimic nu se schimbă, el spune mereu că va actualiza acest câmp acum.
Cu chei, dar da, o parte a infrastructurii este afectată de acest lucru, adică Terraform nu poate schimba nimic. Nici cu mâinile noastre nu putem schimba nimic. Vom trăi cu ea deocamdată.
Adică ați întâlnit așa ceva, dar nu ați venit cu nimic, cum o face și cum o face el însuși?
Din pacate, da.
Buna ziua! Numele meu este Starkov Stanislav. Poștă. ru Group. Cum rezolvi problema generării unei etichete pe..., cum o treci înăuntru? După cum am înțeles, prin User - date pentru a specifica numele gazdei, setați Puppet? Și a doua parte a întrebării. Cum rezolvi această problemă în SG, adică atunci când generezi SG, sute de instanțe de același tip, care este numele corect pentru ele?
Acele cazuri care sunt foarte importante pentru noi, le denumim frumos. Cele care nu sunt necesare, există o notă că acesta este un grup de autoscale. Și, teoretic, poți să-l pui în cuie și să iei unul nou.
În ceea ce privește problema cu eticheta, nu există o astfel de problemă, dar există o astfel de sarcină. Și folosim foarte, foarte mult etichetele, deoarece infrastructura este mare și costisitoare. Și trebuie să ne uităm la unde se duc banii, așa că etichetele ne permit să defalcăm ceea ce a mers unde. Și, în consecință, căutarea a ceva care înseamnă o mulțime de bani este cheltuită aici.
Despre ce altceva era întrebarea?
Când SG creează sute de instanțe, trebuie să fie distinse cumva?
Nu, nu. În fiecare instanță există un agent care raportează că am o problemă. Dacă un agent raportează, atunci agentul știe despre el și, cel puțin, adresa lui IP există. Poți deja să fugi. În al doilea rând, folosim Consul for Discovery, unde Kubernetes nu este. Și Consul arată și adresa IP a instanței.
Adică, vă concentrați în mod special pe IP și nu pe numele gazdei?
Este imposibil să navigați după numele gazdei, adică sunt multe. Există identificatori de instanță - AE, etc. Îl puteți găsi undeva, îl puteți arunca în căutare.
Buna ziua! Mi-am dat seama că Terraform este un lucru bun, adaptat pentru nori.
Nu numai.
Tocmai aceasta este întrebarea care mă interesează. Dacă decideți să vă mutați, să zicem, la Bare Metal în masă cu toate instanțele dvs.? Vor fi probleme? Sau va trebui să folosiți în continuare alte produse, de exemplu, același Ansible care a fost menționat aici?
Ansible este puțin despre altceva. Adică, Ansible funcționează deja când instanța a pornit. Și Terraform funcționează înainte ca instanța să înceapă. Trecerea la Bare Metal - nr.
Nu acum, dar afacerile vor veni și vor spune: „Hai”.
Trecerea la alt nor - da, dar există un truc ușor diferit aici. Trebuie să scrieți codul Terraform în așa fel încât să puteți trece la alt nor cu mai puțin efort.
Inițial, sarcina a fost stabilită ca întreaga noastră infrastructură să fie agnostică, adică orice cloud ar trebui să fie potrivit, dar la un moment dat afacerea a renunțat și a spus: „Bine, în următorii N ani nu vom merge nicăieri, putem folosi servicii. de la Amazon "
Terraform vă permite să creați joburi Front-End, să configurați PagerDuty, document de date etc. Are o mulțime de cozi. El poate controla practic întreaga lume.
Multumesc pentru raport! De asemenea, folosesc Terraform de 4 ani. În stadiul unei tranziții fără probleme la Terraform, la infrastructură, la o descriere declarativă, ne-am confruntat cu o situație în care cineva făcea ceva manual, iar tu încercai să faci un plan. Și am primit un fel de eroare acolo. Cum te descurci cu astfel de probleme? Cum găsiți resursele pierdute care au fost listate?
În principal cu mâinile și cu ochii noștri, dacă vedem ceva ciudat în raport, atunci analizăm ce se întâmplă acolo sau pur și simplu ucidem. În general, solicitările de tragere sunt un lucru comun.
Dacă există o eroare, faceți rollback? Ai încercat să faci asta?
Nu, aceasta este decizia unei persoane în momentul în care vede o problemă.
Sursa: www.habr.com