Се чини дека програмерите на Terraform нудат прилично удобни најдобри практики за работа со AWS инфраструктура. Има само една нијанса. Со текот на времето, бројот на средини се зголемува, секоја со свои карактеристики. Речиси копија од оџакот на апликации се појавува во соседниот регион. И кодот Terraform треба внимателно да се копира и уредува според новите барања или да се направи снегулка.
Мојот извештај за моделите во Terraform за борба против хаосот и рачната рутина на големи и долги проекти.
Видео:
Имам 40 години, со ИТ се занимавам 20 години. Работам за Икстенс веќе 12 години. Ние сме ангажирани во развој на е-трговија. И јас практикувам DevOps практики веќе 5 години.
Мојата приказна ќе биде за моето искуство во проект во компанија чие име нема да го кажам, криејќи се зад договор за необјавување.
Броевите на слајдот се означени со цел да се разбере обемот на проектот. И се што ќе кажам понатаму е поврзано со Амазон.
Се приклучив на овој проект пред 4 години. И рефакторирањето на инфраструктурата беше во полн ек бидејќи проектот порасна. И обрасците што се користеа повеќе не беа соодветни. И со оглед на целиот планиран раст на проектот, беше неопходно да се излезе со нешто ново.
Благодарение на Матвеј, кој вчера ни кажа што се случило во пицата Додо. Еве што се случи овде пред 4 години.
Дојдоа програмери и почнаа да прават инфраструктурен код.
Најочигледните причини зошто тоа беше потребно беше време за пазар. Беше неопходно да се осигура дека тимот на DevOps не е тесно грло за време на пуштањето во употреба. И меѓу другото, Terraform и Puppet беа користени на прво ниво.
Terraform е проект со отворен код од HashiCorp. А за оние кои дури и не знаат што е ова, следните неколку слајдови.
Инфраструктурата како код значи дека можеме да ја опишеме нашата инфраструктура и да побараме од некои роботи да се уверат дека ги добиваме ресурсите што ги опишавме.
На пример, ни треба виртуелна машина. Ќе опишеме и додадеме неколку потребни параметри.
После ова, ќе го конфигурираме пристапот до Амазон во конзолата. И ќе бараме план за Тераформ. Планот на Terraform ќе каже: „Во ред, можеме да ги направиме овие работи за вашиот ресурс“. И ќе се додаде барем еден ресурс. И не се очекуваат промени.
Откако ќе бидете задоволни со сè, можете да побарате од Terraform да аплицира и Terraform ќе создаде пример за вас и ќе добиете виртуелна машина во вашиот облак.
Понатаму нашиот проект се развива. Додаваме некои промени таму. Бараме повеќе примероци, додаваме 53 записи.
И повторуваме. Ве молиме планирајте. Гледаме какви промени се планираат. Аплицираме. И вака нашата инфраструктура расте.
Terraform користи нешто што се нарекува државни датотеки. Односно, тој ги зачувува сите промени кои одат во Амазон во датотека каде што за секој ресурс што го опишавте, има соодветни ресурси кои беа креирани во Амазон. Така, кога се менува описот на ресурсот, Terraform точно знае што треба да се промени во Амазон.
Овие државни датотеки првично беа само датотеки. И ги складиравме во Git, што беше крајно незгодно. Некој секогаш забораваше да направи промени и се појавија многу конфликти.
Сега е можно да се користи заднината, т.е. Terraform е наведен во која корпа и со кој клуч треба да се зачува државната датотека. И самиот Terraform ќе се погрижи да ја добие оваа државна датотека, да ја направи целата магија и да го врати конечниот резултат.
Нашата инфраструктура расте. Еве го нашиот код. И сега не сакаме само да создадеме виртуелна машина, туку сакаме да имаме средина за тестирање.
Terraform ви овозможува да креирате нешто како модул, односно да го опишете истото во некоја папка.
И, на пример, при тестирање, повикајте го овој модул и добијте го истото како да сме извршиле Terraform application во самиот модул. За тестирање ќе има овој код.
За производство, можеме да испратиме некои промени таму, бидејќи при тестирањето не ни требаат големи примероци; во производството, големите примероци се само корисни.
И потоа ќе се вратам на проектот. Беше тешка задача, планираната инфраструктура беше многу голема. И беше неопходно некако да се постави целиот код за да биде погодно за секого: и за оние кои вршат одржување на овој код и за оние кои прават промени. И беше планирано секој развивач да може да оди и да ја поправи инфраструктурата колку што е потребно за неговиот дел од платформата.
Ова е дрво на директориуми што го препорачува самиот HashiCorp ако имате голем проект и има смисла да ја поделите целата инфраструктура на некои мали парчиња и да го опишете секое парче во посебна папка.
Имајќи широка библиотека со ресурси, можете да го повикате приближно истото при тестирање и во производство.
Во нашиот случај, ова не беше сосема соодветно, бидејќи тест-оџакот за програмери или за тестирање требаше да се добие некако поедноставно. Но, не сакав да одам низ папките и да ги применам во потребната низа и да се грижам дека базата на податоци ќе се зголеми, а потоа ќе се зголеми примерот што ја користи оваа база на податоци. Затоа, сите тестирања беа лансирани од една папка. Таму беа повикани истите модули, но сè беше направено во едно возење.
Terraform се грижи за сите зависности. И секогаш создава ресурси во низата за да можете да добиете IP адреса, на пример, од новосоздаден пример, и да ја добиете оваа IP адреса во записот route53.
Покрај тоа, платформата е многу голема. И лансирањето на тест оџак, дури и за еден час, дури и ако за 8 часа, е прилично скап потфат.
И ние го автоматизиравме ова прашање. И работата на Џенкинс ни дозволи да го водиме оџакот. Во него, беше неопходно да се изврши барање за повлекување со промените што развивачот сака да ги тестира, да ги наведе сите потребни опции, компоненти и димензии. Ако сака тестирање на перформансите, тогаш може да земе повеќе примери. Ако само треба да провери дали се отвора некаков формулар, тогаш може да почне со минимална плата. И, исто така, наведете дали е потребен кластер или не, итн.
И тогаш Џенкинс турна скрипта на школка, која малку го измени кодот во папката Terraform. Ги отстранив непотребните датотеки и ги додадов потребните датотеки. А потоа, со една употреба на Terraform, стекот беше подигнат.
А потоа имаше и други чекори во кои не сакам да навлегувам.
Поради фактот што за тестирање ни требаа малку повеќе опции отколку во производството, моравме да направиме копии од модулите за да можеме во овие копии да ги додадеме оние карактеристики кои беа потребни само за тестирање.
И така се случи што при тестирањето некако сакам да ги тестирам оние промени кои на крајот ќе влезат во производство. Но, всушност, една работа беше тестирана, а малку поинаква беше користена во производството. И имаше мала пауза во шемата дека во производството сите промени беа применети од оперативниот тим. И понекогаш се покажа дека тие промени што требаше да одат од тестирање до производство остануваат во друга верзија.
Покрај тоа, имаше таков проблем што беше додадена нова услуга, која беше малку поинаква од некоја веќе постоечка. И наместо да менуваме постоечки модул, моравме да направиме копија од него и да ги додадеме потребните промени.
Во суштина, Terraform не е вистински јазик. Ова е декларација. Ако треба нешто да се изјасниме, тогаш го изјавуваме. И сето тоа функционира.
Во одреден момент, кога се разговараше за едно од моите барања за повлекување, еден од моите колеги рече дека нема потреба да создавам снегулки. Се прашував што сака да каже. Постои научен факт дека не постојат две идентични снегулки во светот, сите тие се малку различни. И штом го слушнав ова, веднаш ја почувствував целата тежина на кодот Terraform. Бидејќи кога беше неопходно да се префрли од верзија во верзија, Terraform бараше промени во синџирот на прекин, односно кодот повеќе не беше компатибилен со следната верзија. И моравме да направиме барање за повлекување, кое опфати речиси половина од датотеките во инфраструктурата, за да ја доведеме инфраструктурата до следната верзија на Terraform.
И откако се појави таква снегулка, целиот Тераформски код што го имавме се претвори во големо, големо купче снег.
За надворешен програмер кој е надвор од операцијата, ова не му е многу важно, бидејќи тој направи барање за повлекување, неговиот ресурс започна. И тоа е се, тоа веќе не е негова грижа. И тимот на DevOps, кој се грижи дека сè е во ред, се бара да ги направи сите овие промени. И цената на овие промени се зголемуваше многу, многу со секоја дополнителна снегулка.
Има приказна за тоа како студент на семинар црта два совршени кругови со креда на таблата. И наставникот е изненаден како успеал да црта толку непречено без компас. Ученикот одговара: „Многу едноставно, поминав две години во војска вртејќи мелница за месо“.
И од четирите години колку што сум вклучен во овој проект, го работам Terraform околу две години. И, се разбира, имам неколку трикови, совети како да го поедноставите кодот Terraform, да работите со него како програмски јазик и да го намалите товарот на програмерите кои мора да го ажурираат овој код.
Првото нешто со кое би сакал да започнам е Symlinks. Terraform има многу повторувачки код. На пример, повикот до провајдерот во речиси секоја точка каде што создаваме дел од инфраструктурата е ист. И логично е да го ставите во посебна папка. И секаде каде што се бара од провајдерот да направи Symlinks до оваа датотека.
На пример, во производството користите улога на претпоставка, што ви овозможува да стекнете права за пристап до некоја надворешна сметка на Амазон. И откако смениле една датотека, сите преостанати во стеблото на ресурси ќе ги имаат потребните права за Terraform да знае до кој сегмент на Амазон да пристапи.
Каде Symlinks не успеваат? Како што реков, Terraform има државни датотеки. И тие се многу, многу кул. Но, работата е што Terraform на прво место го иницијализира задниот дел. И тој не може да користи никакви променливи во овие параметри; тие секогаш мора да бидат напишани во текст.
И како резултат на тоа, кога некој прави нов ресурс, тој копира дел од кодот од други папки. И може да згреши со клучот или со кофата. На пример, тој прави нешто со песок од песок, а потоа го прави во производство. И така може да испадне дека кофата во производството ќе се користи од песокот. Се разбира, брзо ќе го најдат. Ќе може некако да се поправи ова, но сепак е губење време и донекаде ресурси.
Што можеме да направиме следно? Пред да работите со Terraform, треба да го иницијализирате. При иницијализација, Terraform ги презема сите додатоци. Во одреден момент тие се поделија од монолитна на повеќе микросервисна архитектура. И секогаш треба да го направите Terraform init за да ги повлече сите модули, сите приклучоци.
И можете да користите скрипта за школка, која, прво, може да ги добие сите променливи. Скриптата на школка не е ограничена на кој било начин. И, второ, патеките. Ако секогаш ја користиме патеката што е во складиштето како клуч за државната датотека, тогаш, соодветно, грешката овде ќе биде елиминирана.
Каде можам да ги добијам податоците? JSON датотека. Terraform ви овозможува да пишувате инфраструктура не само во hcl (јазик за конфигурација на HashiCorp), туку и во JSON.
JSON лесно се чита од скрипта на школка. Според тоа, можете да ја ставите конфигурациската датотека со кофа на некое место. И користете ја оваа кофа и во кодот Terraform и во скриптата на школка за иницијализација.
Зошто е важно да имате кофа за Terraform? Бидејќи постои такво нешто како далечински државни датотеки. Односно, кога ќе подигнам некој ресурс, за да му кажам на Амазон: „Ве молам, подигнете го примерот“, треба да наведам многу потребни параметри.
И овие идентификатори се зачувани во некоја друга папка. И можам да одам и да кажам: „Terraform, те молам трчај до државната датотека на тој ресурс и земи ми ги овие идентификатори“. И така се појавува одредено обединување помеѓу различни региони или средини.
Не е секогаш можно да се користи датотека со далечинска состојба. На пример, рачно креиравте VPC. И Terraform кодот што го создава VPC создава толку различни VPC што ќе потрае многу долго и ќе треба да го прилагодите еден на друг, па можете да го користите следниов трик.
Односно, направете модул што изгледа дека прави VPC и, како што беше, ви дава идентификатори, но всушност има едноставно датотека со хардкодирани вредности што може да се користи за создавање на истиот пример.
Не е секогаш неопходно да се зачува државната датотека во облакот. На пример, кога тестирате модули, можете да користите иницијализација на заднината, каде што датотеката едноставно ќе се зачува на дискот за време на тестирањето.
Сега малку за тестирање. Што можете да тестирате во Terraform? Веројатно многу е можно, но јас ќе зборувам за овие 4 работи.
HashiCorp има разбирање за тоа како Terraform кодот треба да се форматира. И Terraform fmt ви овозможува да го форматирате кодот што го уредувате според ова верување. Според тоа, тестовите мора нужно да проверат дали форматирањето одговара на она што го остави HashiCorp, за да нема потреба да се менува локацијата на заградите итн.
Следниот е Terraform validate. Не прави нешто повеќе од проверка на синтаксата - ала, дали сите загради се спарени. Што е важно овде? Нашата инфраструктура е многу обемна. Во него има многу различни татковци. И во секој треба да извршите Terraform validate.
Според тоа, за да го забрзаме тестирањето, извршуваме повеќе процеси паралелно користејќи паралелно.
Паралелата е многу кул работа, искористете ја.
Но, секогаш кога Terraform иницијализира, оди во HashiCorp и прашува: „Кои се најновите верзии на приклучоци? И додатокот што го имам во кешот – дали е вистинскиот или погрешниот?“ И ова успоруваше на секој чекор.
Ако му кажете на Terraform каде се приклучоците, тогаш Terraform ќе каже: „Во ред, ова е веројатно најновото нешто што е таму. Нема да одам никаде, веднаш ќе почнам да го потврдувам вашиот Terraform код“.
За да ја пополниме папката со потребните додатоци, имаме многу едноставен Terraform код кој само треба да се иницијализира. Тука, се разбира, треба да ги наведете сите провајдери кои некако учествуваат во вашиот код, инаку Terraform ќе каже: „Не познавам одреден провајдер затоа што не е во кешот“.
Следен е планот Terraform. Како што реков, развојот е цикличен. Правиме промени во кодот. И тогаш треба да дознаете какви промени се планираат за инфраструктурата.
И кога инфраструктурата е многу, многу голема, можете да промените еден модул, да поправите некоја тест околина или некој специфичен регион и да разбиете некој сосед. Затоа треба да се направи планот Тераформ за целата инфраструктура и да покаже какви промени се планираат.
Можете да го направите ова паметно. На пример, напишавме Python скрипта што ги решава зависностите. И во зависност од тоа што е сменето: модул Terraform или само одредена компонента, прави планови за сите зависни папки.
Тераформните планови мора да се направат на барање. Барем така правиме.
Се разбира, добро е да се прават тестови за секоја промена, за секоја обврска, но плановите се прилично скапа работа. И во барањето за повлекување велиме: „Ве молам дајте ми ги плановите“. Роботот започнува. И испраќа во коментари или прикачете ги сите планови што се очекуваат од вашите промени.
Планот е прилично скапа работа. Потребно е време бидејќи Terraform оди во Амазон и прашува: „Дали овој пример сè уште постои? Дали оваа автоматска скала ги има токму истите параметри?“ И за да го забрзате ова, можете да користите параметар како refresh=false. Ова значи дека Terraform ќе ја преземе државата од S3. И ќе верува дека државата точно ќе одговара на она што е во Амазон.
Таков план на Terraform оди многу побрзо, но состојбата мора да одговара на вашата инфраструктура, односно некаде, некогаш мора да започне освежувањето на Terraform. Terraform refresh го прави токму тоа: состојбата одговара на она што е во вистинската инфраструктура.
И ние треба да зборуваме за безбедноста. Тука требаше да почнеме. Онаму каде што го извршувате Terraform и Terraform работи на вашата инфраструктура, постои ранливост. Тоа е, вие во суштина го извршувате кодот. И ако барањето за повлекување содржи некој вид злонамерен код, тогаш може да се изврши на инфраструктура која има премногу пристап. Затоа, внимавајте каде го извршувате планот Terraform.
Следното нешто за кое би сакал да зборувам е тестирање на кориснички податоци.
Што се кориснички податоци? Во Амазон, кога креираме инстанца, можеме да испратиме одредена буква со инстанцата - мета податоци. Кога ќе започне примерот, обично облак init е секогаш присутен на овие примероци. Cloud init го чита ова писмо и вели: „Во ред, денес јас сум балансерот на товарот“. И во согласност со овие завети тој врши некои дејства.
Но, за жал, кога правиме Terraform план и Terraform се применува, корисничките податоци изгледаат како овој вид на куп од броеви. Односно, тој едноставно ви го испраќа хашот. И сè што можете да погледнете во планот е дали ќе има некакви промени или дали хашот ќе остане ист.
И ако не обрнете внимание на ова, тогаш некоја скршена текстуална датотека може да заврши на Амазон, на вистинската инфраструктура.
Алтернативно, при извршувањето, можете да ја наведете не целата инфраструктура, туку само шаблонот. И во кодот кажете: „Ве молиме прикажете го овој образец на мојот екран“. И како резултат на тоа, можете да добиете отпечаток од тоа како ќе изгледаат вашите податоци на Амазон.
Друга опција е да се користи модул за генерирање на кориснички податоци. Ќе го примените овој модул. Ја добивате датотеката на дискот. Споредете го со референтниот. И така, ако некој реши малку да ги коригира корисничките податоци, тогаш вашите тестови ќе кажат: „Во ред, има некои промени тука и таму - ова е нормално“.
Следното нешто за кое би сакал да зборувам е Автоматизирајте ја апликацијата Terraform.
Се разбира, многу е страшно да се применува автоматски Terraform, бидејќи кој знае какви промени дојдоа таму и колку тие можат да бидат деструктивни за живата инфраструктура.
За средина за тестирање, сето тоа е нормално. Односно, работата што создава тест средина е она што им треба на сите програмери. И изразот како „сè ми функционираше“ не е смешен мем, туку доказ дека некоја личност се збунила, подигнала оџак и извршила неколку тестови на овој оџак. И тој се увери дека сè е во ред таму и рече: „Во ред, кодот што го објавувам е тестиран“.
Во производството, песокот и другите средини кои се покритични за бизнисот, можете делумно да користите некои ресурси сосема безбедно бидејќи тоа не резултира со смрт на некој. Тоа се: autoscale групи, безбедносни групи, улоги, рута53, а списокот таму може да биде доста голем. Но, внимавајте што се случува, прочитајте ги автоматските извештаи за апликациите.
Онаму каде што е опасно или страшно да се примени, на пример, ако тоа се некои постојани ресурси од базата на податоци, тогаш добивајте извештаи дека има неприменети промени во одреден дел од инфраструктурата. И инженерот, под надзор, започнува со работа за да аплицира или го прави тоа од неговата конзола.
Амазон има такво нешто како заштита од прекини. И може да заштити во некои случаи од промени кои не се потребни за вас. Односно, Тераформ отиде во Амазон и рече: „Треба да го убијам овој пример за да направам уште еден“. А Амазон вели: „Извинете, не денес. Имаме Terminate заштита“.
А шлагот на тортата е оптимизација на кодот. Кога работиме со Terraform код, мора да пренесеме многу голем број параметри на модулот. Ова се параметрите кои се неопходни за да се создаде некој вид на ресурс. И кодот се претвора во големи списоци на параметри кои треба да се пренесат од модул до модул, од модул до модул, особено ако модулите се вгнездени.
И многу е тешко да се прочита. Многу е тешко да се прегледа ова. И многу често излегува дека некои параметри се подложени на преглед и тие не се токму она што е потребно. И ова чини време и пари за да се поправи подоцна.
Затоа, предлагам да користите такво нешто како сложен параметар кој вклучува одредено дрво на вредности. Односно, потребен ви е некој вид папка каде што ги имате сите вредности што би сакале да ги имате во некоја средина.
И со повикување на овој модул, можете да добиете дрво што се генерира во еден заеднички модул, односно во заеднички модул што работи исто за целата инфраструктура.
Во овој модул можете да направите некои пресметки користејќи таква неодамнешна функција во Terraform како локални жители. И потоа, со еден излез, дајте некој сложен параметар, кој може да вклучува хашови на низи, итн.
Тука завршија сите најдобри наоди што ги имам. И јас би сакал да раскажам приказна за Колумбо. Кога бараше пари за неговата експедиција да ја открие Индија (како што мислеше тогаш), никој не му веруваше и мислеа дека тоа е невозможно. Потоа рече: „Погрижете се јајцето да не падне“. Сите банкари, многу богати и веројатно паметни луѓе, се обидоа некако да го постават јајцето и тоа постојано паѓаше. Потоа Колумбо го зеде јајцето и малку го притисна. Лушпата се стуткала, а јајцето останало неподвижно. Тие рекоа: "О, тоа е премногу лесно!" А Колумбо одговори: „Да, премногу е едноставно. И кога ќе ја отворам Индија, сите ќе ја користат оваа трговска рута“.
А тоа што ти го кажав се веројатно прилично едноставни и тривијални работи. И кога ќе научите за нив и ќе почнете да ги користите, тоа е во редот на работите. Затоа искористете ги предностите. А ако тоа се сосема нормални работи за вас, тогаш барем знаете како да го поставите јајцето за да не падне.
Ајде да сумираме:
- Обидете се да избегнете снегулки. И колку помалку снегулки, толку помалку ресурси ќе ви требаат за да направите какви било промени низ вашата голема инфраструктура.
- Постојани промени. Односно, кога ќе се појават некои промени во кодот, треба да ја усогласите вашата инфраструктура со овие промени што е можно побрзо. Не треба да има ситуација кога некој ќе дојде да го погледне Elasticsearch два или три месеци подоцна, да направи план за Terraform и има еден куп промени што тој не ги очекуваше. И потребно е многу време да се стави сè во ред.
- Тестови и автоматизација. Колку повеќе вашиот код е покриен со тестови и функции, толку повеќе имате доверба дека правите сè правилно. А автоматската испорака ќе ја зголеми вашата самодоверба многукратно.
- Кодот за тест и производствената средина треба да биде речиси ист. Практично, бидејќи производството е сè уште малку поинакво и сè уште ќе има некои нијанси кои ќе излезат подалеку од тест опкружувањето. Но, сепак, плус или минус, ова може да се обезбеди.
- И ако имате многу Terraform код и потребно е многу време за да го ажурирате овој код, тогаш никогаш не е доцна да го рефакторирате и да го доведете во добра форма.
- Непроменлива инфраструктура. АМИ испорака на распоред.
- Структура за route53 кога имате многу записи и сакате тие да бидат во конзистентен редослед.
- Борба со ограничувањата на стапката на API. Ова е кога Амазон вели: „Тоа е тоа, не можам да прифатам повеќе барања, ве молам почекајте“. И половина од канцеларијата чека додека не може да ја пушти својата инфраструктура.
- Точни случаи. Амазон не е евтин настан и спотови ви дозволуваат да заштедите доста. И таму можете да кажете цел извештај за тоа.
- Улоги за безбедност и IAM.
- Барајќи изгубени ресурси, кога имате случаи од непознато потекло во Амазон, тие јадат пари. Дури и ако примероците чинат 100-150 долари месечно, тоа е повеќе од 1 долари годишно. Наоѓањето такви ресурси е профитабилен бизнис.
- И резервирани примери.
Тоа е се за мене. Terraform е многу кул, вие го користите. Ви благодарам!
прашања
Ви благодариме за извештајот! Вашата државна датотека е во S3, но како да го решите проблемот што неколку луѓе можат да ја земат оваа состојба датотека и да се обидат да ја прошират?
Како прво, не брзаме. Второ, има знамиња, во кои известуваме дека работиме на некој код. Односно, и покрај тоа што инфраструктурата е многу голема, тоа не значи дека некој постојано нешто користи. И кога имаше активна фаза, ова беше проблем; ги складиравме државните датотеки во Git. Ова беше важно, инаку некој ќе направи државно досие, а ние моравме рачно да ги составиме за да продолжи се. Сега нема таков проблем. Во принцип, Terraform го реши овој проблем. И ако нешто постојано се менува, тогаш можете да користите брави, кои го спречуваат она што сте го кажале.
Дали користите отворен код или претпријатие?
Нема претпријатие, односно сè што можете да отидете и да преземете бесплатно.
Јас се викам Станислав. Сакав да направам мал додаток. Зборувавте за функцијата на Амазон која ви овозможува да направите пример непобитен. Ова е исто така во самиот Terraform; во блокот Life Second можете да наведете забрана за промени или забрана за уништување.
Времето беше ограничено. Добра поента.
И јас сакав да прашам две работи. Прво, зборувавте за тестирање. Дали користевте алатки за тестирање? Слушнав за додатокот Тест Кујна. Можеби има нешто повеќе. И јас би сакал да прашам и за локалните вредности. Како тие се фундаментално различни од влезните променливи? А зошто не можам да параметризам нешто само преку Local Values? Се обидов да ја разберам оваа тема, но некако сам не можев да ја сфатам.
Можеме да зборуваме подетално надвор од оваа соба. Нашите алатки за тестирање се целосно направени сами. Нема што да се тестира. Општо земено, постојат опции кога автоматизираните тестови ја собираат инфраструктурата некаде, проверуваат дали е во ред, а потоа уништуваат сè со извештај дека вашата инфраструктура сè уште е во добра форма. Ние го немаме ова затоа што тест купиштата се извршуваат секој ден. И тоа е доволно. И ако нешто почне да се крши, ќе почне да се крши без да го провериме на друго место.
Во врска со локалните вредности, да го продолжиме разговорот надвор од собата.
Здраво! Ви благодариме за извештајот! Многу информативно. Рековте дека имате многу ист тип на код за да ја опишете инфраструктурата. Дали размислувавте да го генерирате овој код?
Одлично прашање, благодарам! Поентата е дека кога користиме инфраструктура како код, претпоставуваме дека го гледаме кодот и разбираме каква инфраструктура се крие зад тој код. Ако се генерира код, тогаш треба да замислиме каков код ќе се генерира за да разбереме каква инфраструктура ќе има таму. Или ќе генерираме код, ќе го извршиме, и во суштина истото се случува. Така тргнавме по патот што го напишавме, го добивме. Плус генераторите се појавија малку подоцна кога почнавме да ги правиме. И веќе беше предоцна за промена.
Дали сте слушнале нешто за jsonnet?
Не
Види, ова е многу кул работа. Гледам конкретен случај каде што можете да го примените и да генерирате структура на податоци.
Генераторите се добри кога ги имате, како во шегата за машина за бричење. Односно, првиот пат лицето е различно, но тогаш сите имаат исто лице. Генераторите работат многу добро. Но, за жал, нашите лица се малку поинакви. Ова е проблем.
Само Погледни. Ви благодарам!
Моето име е Максим, јас сум од Сбербанк. Зборувавте малку за тоа како се обидувате да го доведете Terraform на еквивалент на програмски јазик. Зарем не е полесно да се користи Ansible?
Тоа се многу различни работи. Можете да креирате ресурси во Ansible, а Puppet може да создава ресурси во Amazon. Но, Terraform е директно наострен.
Дали имате само Амазон?
Не е дека го имаме само Амазон. Речиси го имаме само Амазон. Но, клучната карактеристика е тоа што Terraform памети. Во Ansible, ако кажете: „Дајте ми 5 примери“, тогаш ќе се подигне, а потоа ќе речете: „И сега ми требаат 3“. И Тераформ ќе рече: „Во ред, ќе убијам 2“, а Ансибл ќе рече: „Во ред, еве 3 за тебе“. Вкупно 8.
Здраво! Ви благодариме за вашиот извештај! Беше многу интересно да се слушне за Terraform. Би сакал веднаш да дадам мал коментар за фактот дека Terraform сè уште нема стабилно ослободување, затоа третирајте го Terraform со голема претпазливост.
Добра лажица за вечера. Односно, ако ви треба решение, тогаш понекогаш го одложувате она што е нестабилно итн., но тоа функционира и ни помогна.
Прашањето е ова. Вие користите Remote backend, користите S 3. Зошто не го користите официјалниот backend?
Официјално?
Тераформен облак.
Кога се појави?
Пред околу 4 месеци.
Да се појавише пред 4 години, тогаш веројатно ќе одговорев на твоето прашање.
Веќе има вградена функција и заклучува, а можете да зачувате државна датотека. Пробајте го. Ама и јас го немам тестирано.
Патуваме со голем воз кој се движи со голема брзина. И не можете само да земете неколку автомобили и да ги фрлите.
Зборувавте за снегулки, зошто не користевте гранка? Зошто не успеа така?
Нашиот пристап е дека целата инфраструктура е во едно складиште. Terraform, Puppet, сите сценарија кои се некако поврзани со ова, сите се во едно складиште. На овој начин можеме да се осигураме дека поединечните промени се тестираат една по друга. Да се работи за куп гранки, тогаш таков проект би бил речиси невозможен за одржување. Поминуваат шест месеци и толку многу се разидуваат што тоа е само некаква казна. Ова е она од што сакав да избегам пред да рефакторирам.
Значи не функционира?
Ова воопшто не функционира.
Во гранката го отсеков слајдот на папката. Односно, ако го направите тоа за секој тест куп, на пример, тимот А има своја папка, тимот Б има своја папка, тогаш ова исто така не функционира. Создадовме унифициран код на околина за тестирање кој беше доволно флексибилен за да одговара на сите. Односно, служевме еден код.
Здраво! Моето име е Јура! Ви благодариме за извештајот! Прашање за модулите. Велите дека користите модули. Како да го решите проблемот ако се направени промени на еден модул што не е компатибилен со промената на друго лице? Дали некако ги верзионирате модулите или се обидувате да донесете wunderwaffle за да исполните две барања?
Ова е голем проблем со снежните купови. Ова е она од што страдаме кога некоја безопасна промена може да скрши дел од инфраструктурата. И ова ќе биде забележливо дури по некое долго време.
Односно, сè уште не е решено?
Правиш универзални модули. Избегнувајте снегулки. И сè ќе успее. Втората половина од извештајот е за тоа како да се избегне ова.
Здраво! Ви благодариме за извештајот! Би сакал да појаснам. Зад сцената имаше голем куп за кој дојдов. Како се интегрирани куклата и дистрибуцијата на улоги?
Кориснички податоци.
Односно, само ја плукаш датотеката и некако ја извршуваш?
Корисничките податоци се белешка, т.е. кога правиме клон на сликата, таму се крева Демон и обидувајќи се да открие кој е тој, ја чита белешката дека е балансирач на оптоварување.
Односно, дали е ова некаков посебен процес што се дава?
Ние не го измисливме. Ние го користиме.
Здраво! Само имам прашање за кориснички податоци. Рековте дека таму има проблеми, дека некој може нешто да испрати на погрешно место. Дали има некој начин да се складираат корисничките податоци во истиот Git, за да е секогаш јасно на што се однесуваат податоците на корисникот?
Ние генерираме кориснички податоци од шаблон. Односно, таму се користат одреден број променливи. И Terraform го генерира конечниот резултат. Затоа, не можете само да го погледнете шаблонот и да кажете што ќе се случи, бидејќи сите проблеми се поврзани со фактот дека развивачот мисли дека пренесува низа во оваа променлива, но таму се користи низа. И тој - бам и јас - така-и-така, така-и-така, следниот ред, и сè пукна. Ако ова е нов ресурс и човек го земе и види дека нешто не работи, тогаш брзо се решава. И ако оваа група за автоматско размерување се ажурира, тогаш во одреден момент примероците во групата за автоматско скалило почнуваат да се заменуваат. И тресне, нешто не функционира. Боли.
Излегува дека единственото решение е да се тестира?
Да, го гледате проблемот, таму додавате тест чекори. Тоа е, излезот исто така може да се тестира. Можеби не е толку погодно, но можете да ставите и некои ознаки - проверете дали корисничките податоци се заковани овде.
Јас се викам Тимур. Многу е убаво што има извештаи за тоа како правилно да се организира Terraform.
Не сум ни почнал.
Мислам дека можеби на следната конференција ќе има. Имам едноставно прашање. Зошто ја кодирате вредноста во посебен модул наместо да користите tfvars, т.е. зошто модулот со вредности е подобар од tfvars?
Односно, дали треба да напишам овде (слајд: Production/environment/settings.tf): домен = променлива, домен vpcnetwork, променлива vpcnetwork и stvars – дали можам да го добијам истото?
Токму тоа го правиме. На пример, се повикуваме на изворниот модул за поставување.
Во суштина, ова се такви тфвари. Tfvars е многу удобен во средина за тестирање. Имам тфвари за големи примери, за мали. И фрлив една датотека во папката. И го добив тоа што го сакав. Кога ја сечеме инфраструктурата, сакаме да може да се погледне и веднаш да се разбере сè. И така испаѓа дека треба да погледнете овде, па да погледнете тфвари.
Дали е можно да има сè на едно место?
Да, tfvars е кога имате еден код. И се користи на неколку различни места со различни нијанси. Потоа би фрлале тфвари и би ги добивале вашите нијанси. И ние сме инфраструктура како код во нејзината најчиста форма. Гледав и разбрав.
Здраво! Дали сте наишле на ситуации каде што давателот на облак се меша со она што сте го направиле Terraform? Да речеме дека ги уредуваме метаподатоците. Има ssh клучеви. И Google постојано ги става своите метаподатоци и неговите клучеви таму. И Тераформ секогаш пишува дека има промени. По секое трчање, дури и ако ништо не се менува, тој секогаш вели дека сега ќе го ажурира ова поле.
Со клучеви, но да, дел од инфраструктурата е засегната од оваа работа, т.е Terraform не може ништо да промени. Ништо не можеме да промениме со нашите раце. Засега ќе живееме со него.
Односно, сте наишле на вакво нешто, но не сте смислиле ништо, како го прави тоа и го прави сам?
За жал да.
Здраво! Јас се викам Старков Станислав. Пошта. ru Група. Како да го решите проблемот со генерирање на ознака на..., како го пренесувате внатре? Како што разбирам, преку Корисник - податоци за да го одредите името на домаќинот, поставете го Puppet? И вториот дел од прашањето. Како го решавате ова прашање во SG, т.е. кога генерирате SG, стотици примероци од ист тип, кое е точното име за нив?
Оние примери кои ни се многу важни, убаво ги именуваме. Оние што не се потребни, има забелешка дека ова е група за автоматско скалило. И теоретски можете да го заковате и да добиете нов.
Што се однесува до проблемот со ознаката, нема таков проблем, но има таква задача. И ние ги користиме ознаките многу, многу, бидејќи инфраструктурата е голема и скапа. И ние треба да погледнеме каде одат парите, па ознаките ни дозволуваат да разложиме што отиде каде. И, соодветно, тука се троши потрагата по нешто што значи многу пари.
За што друго беше прашањето?
Кога СГ создава стотици примери, дали треба некако да се разликуваат?
Не, немој. На секој пример има агент кој известува дека имам проблем. Ако агентот пријави, тогаш агентот знае за него и, во најмала рака, неговата IP адреса постои. Веќе можеш да побегнеш. Второ, користиме Конзул за Дискавери, каде што Кубернетес не е. И конзулот ја покажува и IP адресата на примерот.
Односно, дали се фокусирате конкретно на IP, а не на името на хостот?
Невозможно е да се движите по име на домаќинот, односно има многу од нив. Има идентификатори на примери - AE, итн. Можете да го најдете некаде, можете да го фрлите во пребарувањето.
Здраво! Сфатив дека Terraform е добра работа, скроена за облаците.
Не само.
Токму ова е прашањето што ме интересира. Ако одлучите да се преселите, да речеме, во Bare Metal масовно со сите ваши инстанци? Дали ќе има некакви проблеми? Или сепак ќе треба да користите други производи, на пример, истиот Ansible што беше споменат овде?
Ansible е малку за нешто друго. Односно, Ansible веќе работи кога ќе започне инстанцата. И Terraform работи пред да започне примерот. Префрлување на гол метал - бр.
Не сега, но бизнисот ќе дојде и ќе рече: „Ајде“.
Префрлување на друг облак - да, но тука има малку поинаков трик. Треба да напишете Terraform код на таков начин што ќе можете да се префрлите на некој друг облак со помалку напор.
Првично беше поставена задачата дека целата наша инфраструктура е агностичка, односно секој облак треба да биде соодветен, но во одреден момент бизнисот се откажа и рече: „Во ред, во следните N години нема да одиме никаде, можеме да користиме услуги од Амазон“
Terraform ви овозможува да креирате Front-End работни места, да конфигурирате PagerDuty, data doc итн. Има многу опашки. Тој практично може да го контролира целиот свет.
Ви благодариме за извештајот! Јас исто така користам Terraform веќе 4 години. Во фаза на непречена транзиција кон Тераформ, кон инфраструктура, до декларативен опис, се соочивме со ситуација некој да прави нешто рачно, а вие се обидувате да направите план. И таму добив некаква грешка. Како се справувате со вакви проблеми? Како да ги пронајдете изгубените ресурси што се наведени?
Главно со раце и очи, ако видиме нешто чудно во извештајот, тогаш анализираме што се случува таму или едноставно убиваме. Општо земено, барањата за повлекување се вообичаена работа.
Ако има грешка, дали се враќате назад? Дали сте се обиделе да го направите ова?
Не, ова е одлука на човекот во моментот кога ќе види проблем.
Извор: www.habr.com