Изглежда, че разработчиците на Terraform предлагат доста удобни най-добри практики за работа с инфраструктурата на AWS. Само че има един нюанс. С течение на времето броят на средите се увеличава, във всяка се появяват функции. Появява се почти копие на стека на приложението в съседния регион. А кодът на Terraform трябва внимателно да се копира и редактира според новите изисквания или да се направи снежинка.
Моят доклад е за модели в Terraform за борба с хаоса и ръчната рутина при големи и дълги проекти.
Video:
На 40 съм, в ИТ съм от 20 години. Работя в Ixtens от 12 години. Ние се занимаваме с развитие, насочено към електронната търговия. И аз практикувам DevOps практики от 5 години.
Разказът ми ще бъде за опита в проект във фирма, чието име няма да казвам, криейки се зад споразумение за неразкриване.
Числата на слайда са дадени, за да се разбере обхватът на проекта. И всичко, което ще кажа по-нататък, е свързано с Amazon.
Присъединих се към този проект преди 4 години. И рефакторингът на инфраструктурата беше в разгара си, защото проектът се разрасна. И тези модели, които бяха използвани, те вече не пасват. И предвид целия планиран растеж на проекта, беше необходимо да се измисли нещо ново.
Благодаря на Матвей, който ни разказа вчера какво се случи в Dodo Pizza. Това се случи с нас преди 4 години.
Дойдоха разработчици и започнаха да правят инфраструктурен код.
Най-очевидната причина, поради която това беше необходимо, беше времето за пускане на пазара. Беше необходимо да се уверим, че екипът на DevOps не е тясно място при пускането. И между другото, Terraform и Puppet бяха използвани на първото ниво.
Terraform е проект с отворен код от HashiCorp. А за тези, които изобщо не знаят какво е, следващите няколко слайда.
Инфраструктурата като код означава, че можем да опишем нашата инфраструктура и да помолим някои роботи да се уверят, че получаваме описаните от нас ресурси.
Например имаме нужда от виртуална машина. Ще опишем, добавим няколко задължителни параметъра.
След това ще конфигурираме достъпа до Amazon в конзолата. И поискайте план за Terraform. Планът на Terraform ще каже: "Добре, за вашия ресурс, можем да направим тези неща." И поне един ресурс ще бъде добавен. И не се очакват промени.
След като всичко ви устройва, можете да помолите Terraform да кандидатства и Terraform ще създаде инстанция за вас и ще получите виртуална машина във вашия облак.
По-нататък нашият проект се развива. Добавяме някои промени там. Искаме още екземпляри, добавяме 53 записа.
И ние повтаряме. Моля, планирайте. Виждаме какви промени се планират. Приложи. И така нашата инфраструктура расте.
Terraform използва такова нещо като държавни файлове. Това означава, че запазва всички промени, които отиват в Amazon във файл, където за всеки ресурс, който сте описали, има съответните ресурси, които са създадени в Amazon. По този начин, когато променя описанието на даден ресурс, Terraform знае точно какво трябва да се промени в Amazon.
Тези държавни файлове първоначално са били само файлове. И ги съхранявахме в Git, което беше изключително неудобно. Постоянно някой забравяше да извърши промени и имаше много конфликти.
Вече е възможно да се използва бекенда, т.е. Terraform е посочено в коя кофа, с кой ключ трябва да се запише файлът на състоянието. И самият Terraform ще се погрижи да получи този файл със състоянието, да направи цялата магия и да върне крайния резултат.
Нашата инфраструктура се разраства. Ето нашия код. И сега не искаме просто да създадем виртуална машина, искаме да имаме тестова среда.
Terraform ви позволява да направите нещо като модул, т.е. да опишете същото в някаква папка.
И, например, при тестване, извикаме този модул и получаваме същото нещо, както ако правим Terraform apply в самия модул. Ето кода за тестване.
За производство можем да изпратим някои промени там, защото при тестване нямаме нужда от големи екземпляри, в производство големите екземпляри ще бъдат полезни.
И тогава ще се върна към проекта. Беше трудна задача, инфраструктурата беше планирана много голяма. И беше необходимо по някакъв начин да се постави целият код, така че да е удобен за всички: за тези, които извършват поддръжка на този код, и за тези, които правят промени. И беше планирано всеки разработчик да може да отиде и да поправи инфраструктурата, както е необходимо за неговата част от платформата.
Това е дърво на директории, което се препоръчва от HashiCorp, ако имате голям проект и има смисъл да разделите цялата инфраструктура на някои малки части и да опишете всяка част в отделна папка.
Разполагайки с обширна библиотека с ресурси, можете да извиквате приблизително едно и също нещо при тестване и в производство.
В нашия случай това не беше напълно подходящо, тъй като тестовият стек за разработчици или за тестване трябваше да бъде получен по някакъв начин по-прост. И не исках да минавам през папките и да прилагам в правилната последователност и да се притеснявам, че базата ще се повиши, а след това инстанцията, която използва тази база, ще се повиши. Следователно всички тестове бяха стартирани от една папка. Там бяха извикани същите модули, но всичко мина наведнъж.
Terraform се грижи за всички зависимости. И винаги създава ресурси в тази последователност, така че можете да получите IP адрес, например, от прясно създаден екземпляр и да получите този IP адрес в записа route53.
Освен това платформата е много голяма. И провеждането на тестов стек, дори и за час, дори и за 8 часа, е доста скъп бизнес.
И ние автоматизирахме този бизнес. И работата на Дженкинс позволи на стека да работи. В него беше необходимо да се стартира заявка за изтегляне с промените, които разработчикът иска да тества, да посочи всички необходими опции, компоненти и размери. Ако иска тестване на производителността, тогава може да вземе повече случаи. Ако просто трябва да провери дали се отваря някакъв формуляр, може да започне от минималната заплата. И също така посочете дали е необходим клъстер или не и т.н.
И тогава Дженкинс прокара шел скрипт, който леко модифицира кода в папката Terraform. Премахна ненужните файлове, добави необходимите файлове. И тогава, с едно пускане на Terraform apply, стекът се повиши.
И тогава имаше други стъпки, в които не искам да навлизам.
Поради факта, че за тестване се нуждаехме от малко повече опции, отколкото в производството, трябваше да направим копия на модулите, така че в тези копия да можем да добавим онези функции, които са необходими само при тестване.
И се случи така, че при тестването изглежда, че искате да тествате тези промени, които в крайна сметка ще отидат в производството. Но всъщност едно нещо беше тествано и малко по-различно беше използвано в производството. И имаше малко прекъсване в модела, че в производството всички промени бяха приложени от оперативния екип. И понякога се оказваше, че тези промени, които трябваше да преминат от тестване към производство, останаха в друга версия.
Освен това имаше такъв проблем, че беше добавена нова услуга, която беше малко по-различна от някои съществуващи. И вместо да модифицирате съществуващ модул, трябваше да направите негово копие и да добавите необходимите промени.
Всъщност Terraform не е истински език. Това е декларация. Ако трябва да декларираме нещо, тогава го декларираме. И всичко работи.
В един момент, когато обсъждахме една от моите заявки за изтегляне, един от моите колеги каза, че не е необходимо да произвеждаме снежинки. Чудех се какво има предвид. Има такъв научен факт, че в света няма две еднакви снежинки, всички те са малко, но различни. И щом чух това, веднага усетих цялата тежест на кода на Terraform. Тъй като когато се изискваше преминаване от версия към версия, Terraform изискваше прекъсваща промяна на веригата, т.е. кодът вече не беше съвместим със следващата версия. И трябваше да направя заявка за изтегляне, която покриваше почти половината от файловете в инфраструктурата, за да доведа инфраструктурата до следващата версия на Terraform.
И след като се появи такава снежинка, целият код на Terraform, който бяхме превърнали в голяма, голяма купчина сняг.
За външен разработчик, който е извън операция, това няма голямо значение за него, защото той направи заявка за изтегляне, неговият ресурс стартира. И това е, не е негова грижа. И екипът на DevOps, който гарантира, че всичко е наред, трябва да направи всички тези промени. И цената на тези промени нараства много, много с всяка следваща снежинка.
Има една история как студент на семинар начертава два перфектни кръга с тебешир върху черна дъска. И учителят е изненадан как е успял да рисува толкова гладко без компас. Студентът отговаря: „Много е просто, въртях месомелачка две години в армията.“
И от четирите години, през които съм в този проект, правя Terraform около две години. И, разбира се, имам някои трикове, някои съвети как да опростя кода на Terraform, да работя с него като език за програмиране и да намаля тежестта върху разработчиците, които трябва да поддържат този код актуален.
Първото нещо, с което бих искал да започна, са символните връзки. Terraform има много повтарящ се код. Например, обаждането на доставчик на почти всяка точка, където създаваме част от инфраструктурата, е едно и също. И е логично да го поставите в отделен татко. И навсякъде, където доставчикът трябва да направи символни връзки към този файл.
Например използвате поемане на роля в производството, което ви позволява да получите права за достъп до външен акаунт в Amazon. И като промените един файл, всички останали, които са в дървото на ресурсите, ще имат необходимите права, така че Terraform да знае до кой сегмент на Amazon да има достъп.
Къде символните връзки не работят? Както казах, Terraform има държавни файлове. И са много, много яки. Но факт е, че Terraform инициализира бекенда още в първия. И той не може да използва никакви променливи в тези параметри, те винаги трябва да бъдат написани в текст.
И в резултат на това, когато някой направи нов ресурс, той копира част от кода от други папки. И може да сгреши с ключа или с кофата. Например, той прави пясъчна кутия от пясъчна кутия и след това я прави в производство. И така може да се окаже, че кофата в производството ще се използва от пясъчника. Разбира се, че ще го намерят бързо. Ще бъде възможно по някакъв начин да се поправи това, но въпреки това е загуба на време и до известна степен ресурси.
Какво можем да направим след това? Преди да работите с Terraform, трябва да го инициализирате. По време на инициализацията Terraform изтегля всички добавки. В един момент те се счупиха от монолитна в по-микросервизна архитектура. И винаги трябва да правите Terraform init, така че да изтегли всички модули, всички добавки.
И можете да използвате shell скрипт, който, първо, може да получи всички променливи. Shell скриптът е неограничен. И, второ, начинът. Ако винаги използваме пътя, който е в хранилището, като ключ към държавния файл, тогава съответно грешката ще бъде изключена тук.
Къде да вземем данни? JSON файл. Terraform ви позволява да пишете инфраструктура не само на hcl (HashiCorp Configuration Language), но и на JSON.
JSON е лесен за четене от shell скрипт. Съответно можете да поставите конфигурационен файл с кофа на някое място. И използвайте тази кофа както в кода на Terraform, така и в скрипта на обвивката за инициализация.
Защо е важно да имате кофа Terraform? Защото има такова нещо като файлове за отдалечено състояние. Тоест, когато събера някакъв ресурс, за да кажа на Amazon: „Моля, повдигнете инстанция“, трябва да посоча много необходими параметри.
И тези идентификатори се съхраняват в друга папка. И мога да го взема и да кажа: "Terraform, моля, отидете до държавния файл на същия този ресурс и ми донесете тези идентификатори." И по този начин има един вид обединение между различни региони или среди.
Не винаги е възможно да се използва файл за отдалечено състояние. Например ръчно сте създали VPC. И кодът на Terraform, който създава VPC, създава толкова различен VPC, че отнема много време и трябва да коригирате един към друг, така че можете да използвате следния трик.
Тоест, да се направи модул, който като че ли прави VPC и ви дава идентификатори, но всъщност има само файл с твърдо кодирани стойности, които могат да се използват за създаване на същия екземпляр.
Не винаги е необходимо да запазвате държавния файл в облака. Например, когато тествате модули, можете да използвате бекенд инициализация, когато файлът ще бъде записан само на диска по време на тестване.
Сега малко за тестването. Какво може да се тества в Terraform? Вероятно много е възможно, но аз ще говоря за тези 4 неща.
HashiCorp разбира как да форматира кода на Terraform. И Terraform fmt ви позволява да форматирате кода, който редактирате според това убеждение. Съответно, тестовете задължително трябва да проверяват дали форматирането отговаря на завещаното от HashiCorp, за да не се налага да променяте местоположението на скоби и т.н.
Следващият е проверка на Terraform. Прави малко повече от проверка на синтаксиса - ала, всички скоби са сдвоени. Кое е важното тук? Имаме много тънка инфраструктура. Има много различни папки. И във всяка трябва да стартирате проверка на Terraform.
Съответно, за да ускорим тестването, изпълняваме няколко паралелни процеса, като използваме parallel.
Parallel е много готино нещо, използвайте го.
Но всеки път, когато Terraform се инициализира, той отива при HashiCorp и пита: „Кои са най-новите добавки? А плъгина, който имам в кеша - този ли е или не е? И се забавяше на всяка крачка.
Ако Terraform ви каже къде са плъгините, Terraform ще каже: „Добре, това е може би най-свежото нещо, което съществува. Няма да ходя никъде, веднага ще започна да валидирам вашия Terraform код.“
За да запълним папката с необходимите добавки, имаме много прост код на Terraform, който просто трябва да се инициализира. Тук, разбира се, трябва да посочите всички доставчици, които по някакъв начин участват във вашия код, в противен случай Terraform ще каже: "Не знам нито един доставчик, защото не е в кеша."
Следващият е планът Terraform. Както казах, развитието е циклично. Правим код с промени. И тогава трябва да разберете какви промени са планирани за инфраструктурата.
И когато инфраструктурата е много, много голяма, можете да промените един модул, да поправите тестова среда или определен регион и да разрушите някой съседен. Затова трябва да се направи план Terraform за цялата инфраструктура и да покаже какви промени се планират.
Можете да го направите по интелигентния начин. Например, написахме скрипт на Python, който разрешава зависимости. И в зависимост от това какво е променено: модул Terraform или просто конкретен компонент, прави планове за всички зависими папки.
Тераформен план трябва да се направи при поискване. Поне това правим ние.
Тестовете, разбира се, е добре да се правят за всяка промяна, за всеки ангажимент, но плановете са доста скъпо нещо. И казваме в заявката за изтегляне: "Моля, дайте ми плановете." Роботът започва. И изпраща към коментарите или за прикачване на всички планове, които се очакват от вашите промени.
Планът е доста скъпо нещо. Отнема време, защото Terraform отива в Amazon и пита: „Този екземпляр все още ли съществува? Това автоматично мащабиране има ли абсолютно същите параметри?”. И за да го ускорите, можете да използвате параметър като refresh=false. Това означава, че Terraform ще издуе състоянието S3. И ще повярва, че държавата ще съответства точно на това, което е в Amazon.
Такъв план на Terraform е много по-бърз, но състоянието трябва да съответства на вашата инфраструктура, т.е. някъде, понякога трябва да започне опресняването на Terraform. Terraform refresh прави точно това, така че състоянието да съответства на това, което е в реалната инфраструктура.
И трябва да кажа за безопасността. Ето откъде трябваше да започне. Там, където изпълнявате Terraform и Terraform работи с вашата инфраструктура, има уязвимост. Тоест вие по същество изпълнявате код. И ако заявката за изтегляне съдържа някакъв вид злонамерен код, тогава тя може да бъде изпълнена на инфраструктура, която има твърде много достъп. Затова внимавайте къде стартирате плана Terraform.
Следващото нещо, за което бих искал да говоря, е тестването на потребителски данни.
Какво представляват потребителските данни? В Amazon, когато създаваме екземпляр, можем да изпратим някакъв вид писмо от екземпляра - мета данни. Когато се стартира екземпляр, обикновено облачното инициализиране винаги присъства в тези екземпляри. Cloud init прочита това писмо и казва: „Добре, днес съм балансьор на натоварването.“ И в съответствие с тези предписания той извършва някои действия.
Но, за съжаление, когато правим план на Terraform и прилагаме Terraform, потребителските данни изглеждат като тази каша от числа. Тоест, той просто ви изпраща хеш. И всичко, което можете да видите в плана, е дали ще има промени или хешът ще остане същият.
И ако не обърнете внимание на това, тогава някой пребит текстов файл може да отиде в Amazon, в истинската инфраструктура.
Като алтернатива можете да посочите не цялата инфраструктура по време на изпълнение, а само шаблона. И в кода кажете: "Моля, покажете този шаблон за мен." И в резултат на това можете да получите разпечатка на това как ще изглеждат вашите данни в Amazon.
Друг вариант е да използвате модул за генериране на потребителски данни. Вие ще приложите този модул. Вземете файла на диска. Сравнете го с референтния. И по този начин, ако някой юний реши да поправи малко потребителски данни, тогава вашите тестове ще кажат: „Добре, има някои промени тук и там - това е нормално.“
Следващото нещо, за което бих искал да говоря, е Automate Terraform apply.
Разбира се, достатъчно е страшно да се прилага Terraform в автоматичен режим, защото кой знае какви промени са дошли там и колко пагубни могат да бъдат те за живата инфраструктура.
За тестова среда това е добре. Тоест работа, която създава тестова среда, е това, от което се нуждаят всички разработчици. И такъв израз като „всичко работи за мен“ не е забавен мем, а доказателство, че човек се е объркал, повдигнал стек, стартирал някои тестове на този стек. И той се увери, че там всичко е наред и каза: „Добре, кодът, който пускам, е тестван.“
В производствена, пясъчна среда и други среди, които са по-критични за бизнеса, е безопасно да използвате частично някои ресурси, защото това не причинява смърт на никого. Това са: групи за автоматично мащабиране, групи за сигурност, роли, route53 и там списъкът може да бъде доста голям. Но следете какво се случва, четете доклади за автоматизирани приложения.
Когато е опасно или страшно да се използва, например, ако това са някакви постоянни ресурси, от база данни, тогава получете отчети, че има неприложени промени в някаква част от инфраструктурата. И инженерът вече е наблюдаван, изпълнявайки задачи за кандидатстване или го прави от своята конзола.
Amazon има такова нещо като защита от прекратяване. И може да защити в някои случаи от промени, които не са необходими за вас. Така че Terraform отиде в Amazon и каза: „Трябва да убия този екземпляр, за да направя друг“. И Amazon казва: „Съжалявам, не днес. Имаме защита от прекратяване.“
И черешката на тортата е оптимизацията на кода. Когато работим с код на Terraform, трябва да предадем много голям брой параметри на модула. Това са параметрите, които са необходими, за да се създаде някакъв вид ресурс. И кодът се превръща в големи списъци с параметри, които трябва да се предават от модул на модул, от модул на модул, особено ако модулите са вложени.
И е много трудно за четене. Много е трудно да се прегледа това. И много често се оказва, че някои параметри се преглеждат и не са точно тези, които са необходими. И отнема време и пари, за да го поправите по-късно.
Затова ви предлагам да използвате такова нещо като сложен параметър, който включва определено дърво от стойности. Тоест, имате нужда от някаква папка, където имате всички стойности, които бихте искали да имате в някаква среда.
И като извикате този модул, можете да получите дърво, което се генерира в един общ модул, тоест в общ модул, който работи еднакво за цялата инфраструктура.
В този модул можете да направите някои изчисления, като използвате такава нова функция в Terraform като местните. И след това в един изход издайте някакъв сложен параметър, който може да включва хешове, масиви и т.н.
На това всички най-добри находки, които съм приключил. И бих искал да разкажа една история за Колумб. Когато търсеше пари за експедицията си да открие Индия (както си мислеше тогава), никой не му повярва и повярва, че това е невъзможно. Тогава той каза: "Внимавай да не падне яйцето." Всички банкери, много богати и вероятно умни хора, се опитваха да сложат яйцето по някакъв начин и то падаше през цялото време. Тогава Колумб взе яйцето, натисна го малко. Черупката се смачка и яйцето остана неподвижно. Те казаха: "О, това е твърде лесно!" И Колумб отговори: „Да, твърде е просто. И когато отворя Индия, всички ще използват този търговски път.
И това, което току-що ви казах, вероятно са доста прости и тривиални неща. И когато научите за тях и започнете да ги използвате, това е в реда на нещата. Така че използвайте го. И ако това са съвсем нормални неща за вас, то поне знаете как да сложите яйце, за да не падне.
Нека обобщим:
- Опитайте се да избягвате снежинките. И колкото по-малко снежинки, толкова по-малко ресурси ще са ви необходими, за да направите промени в цялата си голяма инфраструктура.
- Постоянна промяна. Тоест, когато са настъпили някои промени в кода, трябва да приведете инфраструктурата си в съответствие с тези промени възможно най-скоро. Не трябва да има ситуация, когато някой идва след два-три месеца да гледа Elasticsearch, прави план на Terraform и има много промени, които не е очаквал. И отнема много време, за да подредите всичко отново.
- Тестове и автоматизация. Колкото повече вашият код е покрит с тестове и чипове, толкова по-голяма увереност имате, че правите всичко правилно. А автоматичната доставка ще увеличи многократно доверието ви.
- Кодът за тестовата и производствената среда трябва да е почти еднакъв. Практически, защото все пак производството е малко по-различно и все пак ще има някои нюанси, които ще надхвърлят тестовата среда. Но въпреки това, плюс или минус може да се осигури.
- И ако имате много код на Terraform и отнема много време, за да поддържате този код актуален, тогава никога не е късно да го преработите и да го приведете в добра форма.
- неизменна инфраструктура. AMI доставка по график.
- Структура за route53, когато имате много записи и искате те да са в последователен ред.
- Борба срещу ограниченията на скоростта на API. Това е моментът, когато Amazon казва: „Това е, не мога да приема повече заявки, моля, изчакайте.“ И половината офис чака, докато може да пусне инфраструктурата си.
- спот екземпляри. Amazon не е евтино събитие и спотовете ви позволяват да спестите доста. И там можете да разкажете цял репортаж за това.
- Роли за сигурност и IAM.
- Търсете изгубени ресурси, когато имате екземпляри с неизвестен произход в Amazone, те ядат пари. Дори ако екземплярите струват $100-150 на месец, това е повече от $1 на година. Намирането на такива ресурси е доходоносен бизнес.
- И запазени екземпляри.
Това е всичко за мен. Terraform е много готин, използвайте го. Благодаря ти!
Въпроси
Благодаря за доклада! Имате файл със състояние в S3, но как решавате проблема, че няколко души могат да вземат този файл със състояние и да се опитат да разположат?
Първо, не бързаме. Второ, има флагове, в които съобщаваме, че работим върху някакъв код. Тоест, въпреки факта, че инфраструктурата е много голяма, това не означава, че някой постоянно използва нещо. И когато имаше активна фаза, това беше проблем, съхранявахме файлове със състояние в Git. Това беше важно, в противен случай някой щеше да направи файл на състоянието и трябваше ръчно да ги съберем на куп, така че всичко да продължи. Сега няма такъв проблем. Като цяло Terraform реши този проблем. И ако нещо постоянно се променя, тогава можете да използвате ключалки, които предотвратяват казаното от вас.
Използвате ли отворен код или корпоративно?
Без предприятие, тоест всичко, което можете да отидете и да изтеглите безплатно.
Казвам се Станислав. Исках да направя малко допълнение. Говорихте за функцията на Amazon, която ви позволява да направите екземпляр неубиваем. Това също е в самата Terraform, в блока Life Second, можете да предпишете забрана за промяна или забрана за унищожаване.
Беше ограничен във времето. Добра точка.
И аз исках да попитам две неща. Първо, говорихте за тестване. Използвали ли сте инструменти за тестване? Чух за приставката Test Kitchen. Може би има нещо друго. И бих искал да попитам за местните ценности. Как се различават основно от входните променливи? И защо не мога да параметризирам нещо само чрез Local Values? Опитах се да се занимавам с тази тема, но някак си не го разбрах.
Можем да говорим по-подробно зад тази зала. Инструментите за тестване са напълно направени от нас. Там няма нищо за тестване. Като цяло има варианти, когато автоматичните тестове повдигат инфраструктурата някъде, проверяват дали е наред и след това унищожават всичко с отчет, че инфраструктурата ви е все още в добро състояние. Ние нямаме това, защото тестовите стекове се изпълняват всеки ден. И това е достатъчно. И ако нещо започне да се счупи, тогава ще започне да се счупва, без да го проверяваме някъде другаде.
Относно местните ценности, нека продължим разговора извън публиката.
Здравейте! Благодаря за доклада! Много информативен. Казахте, че имате много от същия тип код за описание на инфраструктурата. Мислили ли сте да генерирате този код?
Страхотен въпрос, благодаря! Въпросът е, че когато използваме инфраструктура като код, предполагаме, че разглеждаме кода и разбираме какъв вид инфраструктура се крие зад този код. Ако кодът е генериран, тогава трябва да си представим какъв код ще бъде генериран, за да разберем какъв вид инфраструктура ще има. Или генерираме кода, ангажираме го и всъщност получаваме същото. Затова тръгнахме по начина, по който написахме, получихме го. Освен това генераторите се появиха малко по-късно, когато започнахме да правим. И беше твърде късно за промяна.
Чували ли сте за jsonnet?
Не.
Вижте, това е наистина готино нещо. Виждам конкретен случай, в който можете да го приложите и да генерирате структура от данни.
Генераторите са добри, когато ги има, като във вица за машината за бръснене. Тоест, първия път лицето е различно, но след това всички имат едно и също лице. Генераторите са много яки. Но, за съжаление, лицата ни са малко по-различни. Това е проблем.
Просто погледни. Благодаря ти!
Казвам се Максим, аз съм от Сбербанк. Казахте малко, че сте се опитали да приведете Terraform до аналог на език за програмиране. Не е ли по-лесно да се използва Ansible?
Това са много различни неща. Ansible може да създава ресурси, а Puppet може да създава ресурси в Amazon. Но Terraform е направо изострен.
Имате ли само Amazon?
Не че имаме само Amazon. Имаме почти само Amazon. Но ключовата характеристика е, че Terraform помни. В Ansible, ако кажете: „Вземете ми 5 инстанции“, тогава ще се повиши и след това кажете: „И сега имам нужда от 3“. И Terraform ще каже: "Добре, ще убия 2", а Ansible ще каже: "Добре, ето 3 за теб." Общо 8.
Здравейте! Благодаря за доклада! Беше много интересно да чуя за Terraform. Искам само да направя малък коментар относно факта, че Terraform все още няма стабилна версия, така че бъдете много внимателни с Terraform.
Хубава лъжица за вечеря. Тоест, ако имате нужда от решение, понякога отлагате това, което е нестабилно и т.н., но работи и ни помогна.
Въпросът е. Използвате отдалечения бекенд, използвате S 3. Защо не използвате официалния бекенд?
Официален?
Terraform Cloud.
Кога се появи?
преди 4 месеца.
Ако се беше появил преди 4 години, тогава вероятно щях да отговоря на въпроса ви.
Вече има вградена функция и ключалки и можете да съхранявате файл със състояние. Опитай. Но и аз не съм тествал.
Ние сме в голям влак, който се движи с висока скорост. И не можете просто да вземете и изхвърлите няколко коли.
Говорихте за снежинки, защо не използвахте клон? Защо не се получи така?
Имаме такъв подход, че цялата инфраструктура е в едно хранилище. Terraform, Puppet, всички скриптове, които по някакъв начин са свързани с това, всички те са в едно хранилище. По този начин можем да гарантираме, че постепенните промени се тестват една по една. Ако беше куп клонове, тогава подобен проект би бил почти невъзможен за поддръжка. Минават шест месеца и те се разминават толкова много, че това е просто някакво наказание. Това е, от което исках да избягам преди рефакторинг.
т.е. не работи?
Изобщо не става.
В клона изрязах слайда на папката. Тоест, ако направите за всеки тестов стек, например, отбор А има свой собствен баща, отбор Б има свой собствен баща, тогава това също не работи. Направихме унифициран код на тестова среда, който беше достатъчно гъвкав, за да отговаря на всички. Тоест обслужихме един код.
Здравейте! Казвам се Юра! Благодаря за доклада! Въпрос относно модулите. Казвате, че използвате модули. Как да разрешите проблема, ако в един модул са направени промени, които не са съвместими с промяната на друго лице? По някакъв начин модули за версии или се опитвате да донесете чудо, което да отговаря на две изисквания?
Това е проблемът с голямата снежна купчина. Това е, от което страдаме, когато някаква безобидна промяна може да счупи част от инфраструктурата. И ще се забележи едва след известно време.
Тоест още не е решено?
Правите универсални модули. Избягвайте снежинките. И всичко ще се получи. Втората половина на доклада е за това как да го избегнем.
Здравейте! Благодаря за доклада! Бих искал да изясня. Зад кулисите имаше голяма купчина, за която дойдох. Как са интегрирани Puppet и разпределението на роли?
потребителски данни.
Тоест, просто изплювате ли файла и го изпълнявате по някакъв начин?
Потребителските данни са бележка, т.е. когато направим клонинг на изображение, тогава Daemon се издига там и опитвайки се да разбере кой е той, прочита бележка, че той е load balancer.
Тоест, това е някакъв отделен процес, който се подарява?
Не сме го измислили ние. Ние го използваме.
Здравейте! Просто имам въпрос относно потребителските данни. Казахте, че там има проблеми, че някой може да изпрати нещо на грешното място. Има ли някакъв начин за съхраняване на потребителски данни в същия Git, така че винаги да е ясно за какво се отнасят потребителските данни?
Ние генерираме потребителски данни от шаблон. Тоест там се прибягват определен брой променливи. И Terraform генерира крайния резултат. Следователно не можете просто да погледнете шаблона и да кажете какво се случва, защото всички проблеми са свързани с факта, че разработчикът мисли, че предава низ в тази променлива и след това се използва масив. И той - дрън и аз - така и така, така и така, следващият ред и всичко се счупи. Ако това е нов ресурс и човек го повдигне, види, че нещо не работи, тогава това бързо се решава. И ако тази група за автоматично мащабиране е била актуализирана, тогава в даден момент екземплярите в групата за автоматично мащабиране започват да се заменят. И пляс, нещо не работи. Боли.
Излиза, че единственото решение е да тестваме?
Да, виждате проблема, добавяте тестови стъпки там. Тоест изходът също може да бъде тестван. Може би не е толкова удобно, но можете също да поставите някои маркировки - проверете дали потребителските данни са заковани тук.
Казвам се Тимур. Много е готино, че има доклади за това как правилно да организирате Terraform.
Дори не започнах.
Мисля, че на следващата конференция може би ще има. Имам един лесен въпрос. Защо кодирате твърдо стойността в отделен модул, вместо да използвате tfvars, т.е. дали модул със стойности е по-добър от tfvars?
Тоест, трябва да напиша тук (слайд: Production/environment/settings.tf): домейн = променлива, домейн vpcnetwork, vpcnetwork променлива и stvarс - получавате едно и също нещо?
Ние правим точно това. Позоваваме се например на модула източник на настройка.
Всъщност това е такъв tfvars. Tfvars е много удобен в среда за тестване. Имам tfvars за големи случаи, за малки. И хвърлих един файл в папката. И получих каквото исках. Когато видяхме инфраструктура, искаме да можем да видим и веднага да разберем всичко. И така се оказва, че трябва да погледнете тук, след това да погледнете в tfvars.
Оказва се, че всичко е било на едно място?
Да, tfvars е, когато имате един код. И се използва на няколко различни места с различни нюанси. Тогава ще хвърлите tfvars и ще получите своите нюанси. И ние сме инфраструктура като код в най-чистата й форма. Погледна и разбра.
Здравейте! Попадали ли сте в ситуации, в които доставчикът на облак се намесва в това, което сте направили с Terraform? Да кажем, че редактираме метаданните. Има ssh ключове. И Google постоянно измъква своите метаданни, своите ключове там. И Terraform винаги пише, че има промени. След всяко изпълнение, дори ако нищо не се промени, той винаги казва, че ще актуализира това поле сега.
С ключове, но - да, част от инфраструктурата е засегната от такова нещо, т.е. Terraform не може да промени нищо. Ние също не можем да променим нищо с ръцете си. Докато живеем с това.
Тоест попаднахте на това, но не измислихте нищо, как го прави и го прави сам?
За съжаление да.
Здравейте! Казвам се Станислав Старков. поща. en Група. Как решавате проблема с генерирането на етикет на ..., как го предавате вътре? Както разбирам, чрез потребителски данни, за да посочите името на хоста, подбуждате Puppet? И втората част на въпроса. Как решавате този проблем в SG, т.е. когато генерирате SG, сто екземпляра от същия тип, как да ги наименувате правилно?
Онези случаи, които са много важни за нас, ще ги назовем красиво. Тези, които не са необходими, има послепис, че това е група с автоматично мащабиране. И на теория може да бъде закован и да получите нов.
Колкото до проблема с тага, няма такъв проблем, но има такава задача. И ние използваме етикети много, много силно, защото инфраструктурата е голяма и скъпа. И ние трябва да погледнем за какво се харчат парите, така че етикетите ни позволяват да сортираме какво и къде са отишли. И съответно търсенето на нещо тук е много похарчени пари.
За какво друго беше въпросът?
Когато SG създаде сто екземпляра, трябва ли да бъдат разграничени по някакъв начин?
Не, недей. Всяка инстанция има агент, който ми казва, че имам проблем. Ако агентът докладва, значи агентът знае за него и поне неговият IP адрес съществува. Вече можете да бягате. Второ, използваме Consul за Discovery, където няма Kubernetes. И Consul също така показва IP адреса на инстанцията.
Тоест таргетирате точно IP-то, а не името на хоста?
Невъзможно е да се навигирате по име на хост, т.е. има много от тях. Има идентификатори на екземпляри - AE и т.н. Можете да го намерите някъде, можете да го хвърлите в търсенето.
Здравейте! Разбрах, че Terraform е добро нещо, съобразено с облаците.
Не само.
Това е въпросът, който ме интересува. Ако решите да преминете, да речем, към Bare Metal масово с всичките си инстанции? Ще има ли някакви проблеми? Или все пак трябва да използвате други продукти, например същия Ansible, който беше споменат тук?
Ansible е малко за нещо друго. Това означава, че Ansible вече работи, когато екземплярът е стартиран. И Terraform работи преди екземплярът да е стартирал. Преминаването към Bare Metal не е.
Не сега, но бизнесът ще дойде и ще каже: „Хайде“.
Преминаване към друг облак - да, но тук има малко по-различна функция. Трябва да напишете код на Terraform по такъв начин, че да можете да превключите към друг облак с по-малко кръвопролития.
Първоначално задачата беше цялата ни инфраструктура да е агностична, т.е. всеки облак трябва да е наред, но в един момент бизнесът се отказа и каза: „Добре, през следващите N години няма да отидем никъде, можете да използвате услуги от Amazon ".
Terraform ви позволява да създавате Front-End задачи, да конфигурирате PagerDuty, документи с данни и т.н. Има много опашки. Той на практика може да контролира целия свят.
Благодаря за доклада! Аз също въртя Terraform вече 4 години. На етапа на плавен преход към Terraform, към инфраструктура, към декларативно описание, бяхме изправени пред ситуация, в която някой правеше нещо на ръка, а вие се опитвахте да направите план. И получих някаква грешка там. Как се справяте с подобни проблеми? Как намирате изгубените ресурси, които бяха посочени?
Най-вече с ръцете и очите си, ако видим нещо странно в доклада, тогава анализираме какво се случва там или просто го убиваме. Като цяло заявките за изтегляне са нещо обичайно.
Ако има грешка, връщате ли се назад? Опитвал ли си да правиш това?
Не, това е решение на човек в момента, в който види проблема.
Източник: www.habr.com