Многу луѓе го знаат и користат Terraform во нивната секојдневна работа, но најдобри практики за него сè уште не се формирани. Секој тим треба да измисли свои пристапи и методи.
Вашата инфраструктура речиси сигурно започнува едноставно: неколку ресурси + неколку програмери. Со текот на времето, расте во сите видови на правци. Дали наоѓате начини да ги групирате ресурсите во модули на Terraform, да го организирате кодот во папки и што друго може да тргне наопаку? (познати последни зборови)
Времето минува и чувствувате дека вашата инфраструктура е вашето ново милениче, но зошто? Загрижени сте за необјасниви промени во инфраструктурата, се плашите да ја допрете инфраструктурата и кодот - како резултат на тоа, ја одложувате новата функционалност или го намалувате квалитетот...
По три години управување со колекцијата Terraform модули за заедницата за AWS на Github и долгорочно одржување на Terraform во производството, Антон Бабенко е подготвен да го сподели своето искуство: како да се напишат TF модули за да не боли во иднина.
До крајот на говорот, учесниците ќе бидат повеќе запознаени со принципите за управување со ресурси во Terraform, најдобрите практики поврзани со модулите во Terraform и некои принципи за континуирана интеграција поврзани со управувањето со инфраструктурата.
Општи услови: Забележувам дека овој извештај е датиран од ноември 2018 година - веќе поминаа 2 години. Верзијата на Terraform 0.11 за која се дискутираше во извештајот повеќе не е поддржана. Во текот на изминатите 2 години, беа објавени 2 нови изданија, кои содржат многу иновации, подобрувања и промени. Обрнете внимание на ова и проверете ја документацијата.
Референци:
- +
- — код и документација за автоматско форматирање
- — генератор на Terraform модули (WIP)
- — Генератор на Terraform код од визуелни дијаграми (WIP)
- www.terraform-best-practices.com
- (Новите објави се на мојата лична веб-страница www.antonbabenko.com/)
- @antonbabenko - Твитер, и еден куп различни Slacks
Јас се викам Антон Бабенко. Некои од вас веројатно го користеле кодот што го напишав. Сега ќе зборувам за ова со поголема самодоверба од кога било, бидејќи имам пристап до статистика.
Работам на Terraform и сум активен учесник и придонесувач на голем број проекти со отворен код поврзани со Terraform и Amazon од 2015 година.
Оттогаш напишав доволно код за да го ставам на интересен начин. И сега ќе се обидам да ви кажам за ова.
Ќе зборувам за сложеноста и спецификите на работата со Terraform. Но, тоа всушност не е тема на HighLoad. И сега ќе разберете зошто.
Со текот на времето, почнав да пишувам Terraform модули. Корисниците пишуваа прашања, јас ги препишував. Потоа напишав разни алатки за да го форматирам кодот со помош на кука за пред-поставување, итн.
Имаше многу интересни проекти. Ми се допаѓа генерирањето код затоа што сакам компјутерот да работи се повеќе и повеќе за мене и за програмерот, така што моментално работам на Terraform генератор на код од визуелни дијаграми. Можеби некои од вас ги виделе. Ова се прекрасни кутии со стрели. И мислам дека е одлично ако можете да кликнете на копчето „Извоз“ и да го добиете сето тоа како код.
Јас сум од Украина. Јас живеам во Норвешка многу години.
Исто така, информации за овој извештај беа собрани од луѓе кои го знаат моето име и ме наоѓаат на социјалните мрежи. Речиси секогаш го имам истиот прекар.
Како што споменав, јас сум главен одржувач на Terraform AWS модулите, кој е едно од најголемите складишта на GitHub каде што сме хостирани модули за најчестите задачи: VPC, Autoscaling, RDS.
А она што го слушна сега е најосновното. Ако се сомневате дека разбирате што е Terraform, тогаш подобро е да го поминете вашето време на друго место. Тука ќе има многу технички термини. И не се двоумев да го прогласам нивото на извештајот за највисоко. Тоа значи дека можам да зборувам користејќи ги сите можни термини без многу објаснување.
Terraform се појави во 2014 година како алатка која ви овозможи да пишувате, планирате и управувате со инфраструктурата како код. Клучниот концепт овде е „инфраструктурата како код“.
Целата документација, како што реков, е напишана во . Се надевам дека повеќето луѓе знаат за оваа страница и ја прочитале документацијата. Ако е така, тогаш сте на вистинското место.
Вака изгледа обичната конфигурациска датотека Terraform, каде прво дефинираме некои променливи.
Во овој случај дефинираме „aws_region“.
Потоа опишуваме кои ресурси сакаме да ги создадеме.
Извршуваме некои команди, особено „terraform init“ со цел да ги вчитаме зависностите и провајдерите.
И ја извршуваме командата „terraform apply“ за да провериме дали наведената конфигурација се совпаѓа со ресурсите што ги создадовме. Бидејќи досега не сме создале ништо, Terraform нè поттикнува да ги создадеме овие ресурси.
Ние го потврдуваме ова. Така создаваме кофа наречена морска ноква.
Исто така, постојат неколку слични комунални услуги. Многумина од вас кои користат Амазон знаат AWS CloudFormation или Google Cloud Deployment Manager или Azure Resource Manager. Секој од нив има своја имплементација на некој вид за управување со ресурси во секој од овие јавни даватели на облак. Terraform е особено корисен бидејќи ви овозможува да управувате со над 100 провајдери. (Повеќе детали )
Целите што Тераформ ги следи од самиот почеток:
- Terraform обезбедува единствен приказ на ресурсите.
- Ви овозможува да ги поддржувате сите модерни платформи.
- И Terraform беше дизајниран од самиот почеток како алатка која ви овозможува безбедно и предвидливо да ја менувате инфраструктурата.
Во 2014 година, зборот „предвидлив“ звучеше многу необично во овој контекст.
Terraform е универзална алатка. Ако имате API, тогаш можете да контролирате апсолутно сè:
- Можете да користите повеќе од 120 провајдери за да управувате со сè што сакате.
- На пример, можете да го користите Terraform за да го опишете пристапот до складиштата на GitHub.
- Можете дури и да креирате и затворате грешки во Jira.
- Може да управувате со метриката на New Relic.
- Можете дури и да креирате датотеки во dropbox ако навистина сакате.
Сето ова се постигнува со помош на провајдери на Terraform, кои имаат отворено API што може да се опише во Go.
Да речеме дека почнавме да користиме Terraform, прочитавме документација на страницата, гледавме видео и почнавме да пишуваме main.tf, како што покажав на претходните слајдови.
И сè е одлично, имате датотека што создава VPC.
Ако сакате да креирате VPC, тогаш ќе ги наведете приближно овие 12 линии. Опишете во кој регион сакате да креирате, кој cidr_block IP адреси да го користите. Тоа е се.
Нормално, проектот постепено ќе расте.
И таму ќе додавате куп нови работи: ресурси, извори на податоци, ќе се интегрирате со нови провајдери, одеднаш ќе сакате да го користите Terraform за да управувате со корисници во вашата сметка на GitHub, итн. Можеби ќе сакате да користите различни DNS провајдери, вкрстете сè. Terraform го олеснува ова.
Да го погледнеме следниот пример.
Постепено додавате internet_gateway затоа што сакате ресурсите од вашиот VPC да имаат пристап до интернет. Ова е добра идеја.
Резултатот е овој main.tf:
Ова е горниот дел од main.tf.
Ова е долниот дел од main.tf.
Потоа додавате подмрежа. До моментот кога сакате да додадете NAT порти, рути, табели за рутирање и куп други подмрежи, нема да имате 38 линии, туку приближно 200-300 линии.
Тоа е, вашата датотека main.tf постепено расте. И доста често луѓето ставаат сè во една датотека. 10-20 Kb се појавува во main.tf. Замислете дека 10-20 Kb е текстуална содржина. И сè е поврзано со сè. Со ова постепено станува тешко да се работи. 10-20 Kb е добар кориснички случај, понекогаш и повеќе. И луѓето не секогаш мислат дека ова е лошо.
Како и во редовното програмирање, т.е. не инфраструктурата како код, ние сме навикнати да користиме еден куп различни класи, пакети, модули, групирања. Terraform ви овозможува да го правите истото.
- Кодот расте.
- Зависноста меѓу ресурсите исто така расте.
И ние имаме голема, голема потреба. Ние разбираме дека не можеме повеќе да живееме вака. Нашиот код станува огромен. 10-20 Kb, се разбира, не е многу огромно, но зборуваме само за мрежниот оџак, односно сте додале само мрежни ресурси. Не зборуваме за Application Load Balancer, распоредување ES кластер, Kubernetes итн., каде лесно може да се вткаат 100 Kb. Ако го запишете сето ова, многу брзо ќе дознаете дека Terraform обезбедува Terraform модули.
Terraform модулите се самостојна конфигурација на Terraform која се управува како група. Тоа е се што треба да знаете за Terraform модулите. Воопшто не се паметни, не дозволуваат да правите никакви сложени врски во зависност од нешто. Сето ова паѓа на рамениците на програмерите. Односно, ова е само некаква конфигурација на Terraform што веќе сте ја напишале. И можете едноставно да го наречете како група.
Затоа, се обидуваме да разбереме како ќе го оптимизираме нашиот код од 10-20-30 Kb. Постепено сфаќаме дека треба да користиме некои модули.
Првиот тип на модули со кои се среќавате се модули за ресурси. Тие не разбираат што е вашата инфраструктура, што е вашиот бизнис, каде и какви се условите. Ова се токму модулите што јас, заедно со заедницата со отворен код, ги администрираме и кои ги поставуваме како првични градежни блокови за вашата инфраструктура.
Пример за модул за ресурси.
Кога повикуваме ресурсен модул, одредуваме од која патека треба да ја вчитаме неговата содржина.
Посочуваме која верзија сакаме да ја преземеме.
Таму пренесуваме еден куп аргументи. Тоа е се. Тоа е сè што треба да знаеме кога го користиме овој модул.
Многу луѓе мислат дека ако ја користат најновата верзија, сè ќе биде стабилно. Но не. Инфраструктурата мора да биде изменета; мора јасно да одговориме на која верзија е распоредена оваа или онаа компонента.
Еве го кодот што се наоѓа во овој модул. Модул за безбедносна група. Овде свитокот оди до 640-тата линија. Создавањето безбедносен-крупен ресурс во Амазон во секоја можна конфигурација е многу нетривијална задача. Не е доволно едноставно да креирате група за безбедност и да и кажете кои правила да ѝ ги пренесе. Би било многу едноставно. Во Амазон има милион различни ограничувања. На пример, ако користите VPC крајна точка, листа на префикси, разни API и се обидува да го комбинира сето ова со сè друго, тогаш Terraform не ви дозволува да го направите ова. И Amazon API не го дозволува ниту ова. Затоа, треба да ја скриеме сета оваа страшна логика во модул и да му дадеме на корисникот код кој изгледа токму вака.
Корисникот не треба да знае како е направен внатре.
Вториот тип на модули, кој се состои од модули за ресурси, веќе решаваат проблеми кои се поприменливи за вашиот бизнис. Често ова е место кое е продолжение за Terraform и поставува некои ригидни вредности за ознаки, за стандардите на компанијата. Можете исто така да додадете функционалност таму што Terraform моментално не ви дозволува да ја користите. Ова е токму сега. Сега верзијата 0.11, која ќе стане минато. Но, сепак, препроцесорите, jsonnet, cookiecutter и еден куп други работи се помошниот механизам што мора да се користи за целосна работа.
Следно ќе покажам неколку примери за ова.
Инфраструктурниот модул се повикува на ист начин.
Наведен е изворот од каде да се преземе содржината.
Еден куп вредности се пренесуваат и се пренесуваат во овој модул.
Следно, во овој модул, се повикуваат куп модули за ресурси за да се создаде VPC или Application Load Balancer, или да се создаде безбедносна група или за кластер за услуги на Elastic Container.
Постојат два типа на модули. Ова е важно да се разбере бидејќи повеќето од информациите што ги групирав во овој извештај не се запишани во документацијата.
И документацијата во Terraform во моментов е доста проблематична бидејќи само вели дека ги има овие функции, можете да ги користите. Но, таа не кажува како да ги користите овие функции, зошто е подобро да ги користите. Затоа, многу голем број луѓе пишуваат нешто со кое не можат да живеат.
Ајде да погледнеме како понатаму да ги напишеме овие модули. Потоа ќе видиме како да ги повикаме и како да работиме со кодот.
Terraform Registry -
Совет #0 е да не пишувате модули за ресурси. Повеќето од овие модули се веќе напишани за вас. Како што реков, тие се со отворен код, не содржат ништо од вашата деловна логика, немаат хардкодирани вредности за IP адреси, лозинки итн. Модулот е многу флексибилен. И најверојатно веќе е напишано. Има многу модули за ресурси од Амазон. Околу 650. А повеќето од нив се квалитетни.
Во овој пример, некој дојде кај вас и рече: „Сакам да можам да управувам со база на податоци. Направете модул за да можам да создадам база на податоци." Лицето не ги знае деталите за имплементацијата ниту на Амазон ниту на Тераформ. Тој едноставно вели: „Сакам да управувам со MSSQL“. Односно, мислиме дека ќе го повика нашиот модул, ќе го пренесе типот на моторот таму и ќе ја означи временската зона.
И човек не треба да знае дека ќе создадеме два различни ресурси во овој модул: еден за MSSQL, вториот за сè друго, само затоа што во Terraform 0.11 не можете да ги наведете вредностите на временската зона како изборни.
И на излезот од овој модул, едно лице ќе може едноставно да добие адреса. Тој нема да знае од која база на податоци, од кој ресурс го креираме сето ова внатрешно. Ова е многу важен елемент на прикривање. И ова се однесува не само на оние модули кои се јавни во отворен код, туку и на оние модули што ќе ги пишувате во вашите проекти и тимови.
Ова е вториот аргумент, кој е доста важен доколку сте го користеле Terraform некое време. Имате складиште во кое ги ставате сите ваши Terraform модули за вашата компанија. И сосема е нормално дека со текот на времето овој проект ќе порасне до големина од еден или два мегабајти. Ова е во ред.
Но, проблемот е како Terraform ги нарекува овие модули. На пример, ако повикате модул за креирање на секој поединечен корисник, Terraform прво ќе го вчита целото складиште, а потоа ќе отиде до папката каде што се наоѓа тој специфичен модул. На овој начин секој пат ќе преземате по еден мегабајт. Ако управувате со 100 или 200 корисници, тогаш ќе преземете 100 или 200 мегабајти, а потоа ќе отидете во таа папка. Така, нормално, не сакате да преземате многу работи секогаш кога ќе кликнете на „Terraform init“.
Постојат две решенија за овој проблем. Првиот е да се користат релативни патеки. На овој начин во кодот посочувате дека папката е локална (./). И пред да започнете било што, правите Git клон на ова складиште локално. На овој начин го правите тоа еднаш.
Има, се разбира, многу негативни страни. На пример, не можете да користите верзии. И со ова понекогаш е тешко да се живее.
Второ решение. Ако имате многу подмодули и веќе имате некој вид воспоставен гасовод, тогаш тука е проектот MBT, кој ви овозможува да соберете многу различни пакети од едно складиште и да ги поставите на S3. Ова е многу добар начин. Така, датотеката iam-user-1.0.0.zip ќе тежи само 1 Kb, бидејќи кодот за создавање на овој ресурс е многу мал. И ќе работи многу побрзо.
Ајде да разговараме за тоа што не може да се користи во модулите.
Зошто е ова зло во модулите? Најлошото нешто е да се претпостави корисник. Да претпоставиме дека корисникот е опција за автентикација на провајдер што може да ја користат различни луѓе. На пример, сите ќе ја асимилираме улогата. Ова значи дека Terraform ќе ја преземе оваа улога. И тогаш со оваа улога ќе врши други дејства.
А злото е што ако Васија сака да се поврзе со Амазон на еден начин, на пример, користејќи ја стандардната променлива на животната средина, а Петја сака да го користи својот заеднички клуч, кој го има на тајно место, тогаш не можете да ги наведете и двете во Тераформа. И за да не доживеат страдање, нема потреба да се означува овој блок во модулот. Ова мора да биде наведено на повисоко ниво. Односно, имаме ресурсен модул, инфраструктурен модул и состав на врвот. И ова треба да биде означено некаде повисоко.
Второто зло е снабдувачот. Овде злото не е толку тривијално, бидејќи ако пишуваш код и тој работи за тебе, тогаш може да мислиш дека ако функционира, тогаш зошто да го смениш.
Злото е што не секогаш контролирате кога ќе биде лансиран овој провајдер, прво. И второ, не контролираш што значи aws ec2, т.е сега зборуваме за Linux или Windows. Значи, не можете да напишете нешто што ќе работи исто на различни оперативни системи или за различни случаи на корисници.
Најчестиот пример, кој е наведен и во официјалната документација, е дека ако напишете aws_instance и наведете еден куп аргументи, тогаш нема ништо лошо во тоа ако го наведете провизорот „local-exec“ таму и го извршите вашиот ansible- игротека .
Всушност, да, нема ништо лошо во тоа. Но, буквално наскоро ќе сфатите дека оваа работа со локален-exec не постои, на пример, во launch_configuration.
И кога користите launch_configuration и сакате да креирате група за автоматско скалирање од еден пример, тогаш во launch_configuration нема концепт на „провизор“. Постои концепт на „кориснички податоци“.
Затоа, поуниверзално решение е да се користат кориснички податоци. И ќе се активира или на самата инстанца, кога инстанцата е вклучена, или во истите кориснички податоци, кога групата за автоматско скалирање ја користи оваа launch_configuration.
Ако сепак сакате да го извршите провизорот, бидејќи е компонента за лепење, кога ќе се креира еден ресурс, во тој момент треба да го извршите вашиот провизор, вашата команда. Има многу такви ситуации.
И најточниот ресурс за ова се нарекува null_resource. Null_resource е лажен ресурс кој всушност никогаш не се создава. Не допира ништо, нема API, нема автоматско скалирање. Но, тоа ви овозможува да контролирате кога да ја извршите командата. Во овој случај, командата се извршува за време на креирањето.
Линк
Постојат неколку знаци. Нема да навлегувам во сите знаци во многу детали. Постои статија за ова. Но, ако сте работеле со Terraform или сте користеле туѓи модули, тогаш често сте забележале дека многу модули, како и најголемиот дел од кодот во отворен код, се напишани од луѓе за нивни потреби. Еден човек го напишал и си го решил проблемот. Го заглавив во GitHub, нека живее. Ќе живее, но ако таму нема документација и примери, тогаш никој нема да го користи. И ако нема функционалност што ви овозможува да решите малку повеќе од нејзината специфична задача, тогаш никој нема да ја користи. Има толку многу начини да изгубите корисници.
Ако сакате да напишете нешто за луѓето да го користат, тогаш препорачувам да ги следите овие знаци.
Ова се:
- Документација и примери.
- Целосна функционалност.
- Разумни стандардни.
- Исчистете го кодот.
- Тестови.
Тестовите се поинаква ситуација бидејќи се доста тешки за пишување. Повеќе верувам во документација и примери.
Значи, погледнавме како да пишуваме модули. Има два аргументи. Првата, која е најважна, е да не пишуваш ако можеш, бидејќи еден куп луѓе веќе ги направиле овие задачи пред тебе. И второ, ако сепак одлучите, тогаш обидете се да не користите провајдери во модули и провизори.
Ова е сивиот дел од документацијата. Можеби сега размислувате: „Нешто е нејасно. Не сум убеден“. Но, ќе видиме за шест месеци.
Сега да разговараме за тоа како да ги повикаме овие модули.
Ние разбираме дека нашиот код расте со текот на времето. Веќе немаме една датотека, веќе имаме 20 досиеја. Сите тие се во една папка. Или можеби во пет папки. Можеби почнуваме некако да ги разложуваме по региони, по некои компоненти. Тогаш разбираме дека сега имаме некои зачетоци на синхронизација и оркестрација. Односно, мора да разбереме што треба да направиме ако смениме мрежни ресурси, што треба да правиме со остатокот од нашите ресурси, како да ги предизвикаме овие зависности итн.
Има две крајности. Првата крајност е се во едно. Имаме една главна датотека. Засега ова беше официјалната најдобра практика на веб-страницата Terraform.
Но сега е напишано како застарено и отстрането. Со текот на времето, заедницата на Terraform сфати дека тоа е далеку од најдобрата практика, бидејќи луѓето почнаа да го користат проектот на различни начини. И има проблеми. На пример, кога ги наведуваме сите зависности на едно место. Има ситуации кога кликнуваме на „Terraform plan“ и додека Terraform не ги ажурира состојбите на сите ресурси, може да помине многу време.
Многу време е, на пример, 5 минути. За некои ова е многу време. Сум видел случаи каде што биле потребни 15 минути. AWS API помина 15 минути обидувајќи се да открие што се случува со состојбата на секој ресурс. Ова е многу голема површина.
И, нормално, поврзан проблем ќе се појави кога сакате да промените нешто на едно место, потоа чекате 15 минути, а тоа ви дава платно од некои промени. Ти плукна, напиша „Да“ и нешто тргна наопаку. Ова е многу реален пример. Terraform не се обидува да ве заштити од проблеми. Односно, напишете што сакате. Ќе има проблеми - ваши проблеми. Додека Terraform 0.11 не се обидува да ви помогне на кој било начин. Има одредени интересни места во 0.12 што ви дозволуваат да кажете: „Васија, навистина го сакаш ова, можеш ли да се вразумиш?
Вториот начин е да се намали оваа област, односно повиците од едно место може да бидат помалку поврзани од друго место.
Единствениот проблем е што треба да напишете повеќе код, т.е. треба да опишете променливи во голем број датотеки и да го ажурирате ова. На некои луѓе тоа не им се допаѓа. Ова е нормално за мене. А некои луѓе мислат: „Зошто да го пишувам ова на различни места, ќе го ставам сето тоа на едно место“. Ова е можно, но ова е втората крајност.
Кој го има сето ова живеење на едно место? Еден, двајца, тројца луѓе, односно некој го користи.
И кој нарекува една одредена компонента, еден блок или еден инфраструктурен модул? Пет до седум луѓе. Ова е кул.
Најчестиот одговор е некаде во средината. Ако проектот е голем, тогаш често ќе имате ситуација кога никакво решение не е соодветно и не функционира сè таму, па завршувате со мешавина. Нема ништо лошо во ова, се додека разбирате дека и двете имаат предности.
Ако нешто се смени во стекот VPC и сакавте да ги примените овие промени на EC2, т.е. сакавте да ја ажурирате групата за автоматско скалирање затоа што имавте нова подмрежа, тогаш јас го нарекувам овој вид на оркестрација на зависност. Постојат неколку решенија: кој што користи?
Можам да предложам какви решенија има. Можете да го користите Terraform за да ја направите магијата или можете да користите мејкфајлови за да користите Terraform. И видете дали нешто се променило таму, можете да го стартувате овде.
Како ви се допаѓа оваа одлука? Дали некој верува дека ова е кул решение? Гледам насмевка, очигледно сомнежите се вовлекоа.
Се разбира, не го пробувајте ова дома. Terraform никогаш не бил дизајниран да се води од Terraform.
На еден извештај ми рекоа: „Не, ова нема да функционира“. Поентата е дека не треба да работи. Иако изгледа толку импресивно кога можете да го стартувате Terraform од Terraform, а потоа Terraform, не треба да го правите тоа. Terraform секогаш треба да започне многу лесно.
Ако ви треба оркестрација на повици кога нешто се променило на едно место, тогаш тука е Terragrunt.
Terragrunt е алатка, додаток на Terraform, која ви овозможува да ги координирате и оркестрирате повиците до инфраструктурните модули.
Типична конфигурациска датотека Terraform изгледа вака.
Вие одредувате кој конкретен модул сакате да го повикате.
Какви зависности има модулот?
И кои аргументи ги прифаќа овој модул. Тоа е сè што треба да се знае за Terragrunt.
Документацијата е таму, а на GitHub има 1 ѕвезди. Но, во повеќето случаи ова е она што треба да го знаете. И ова е многу лесно за имплементација во компании кои штотуку почнуваат да работат со Terraform.
Значи, оркестрацијата е Terragrunt. Има и други опции.
Сега да разговараме за тоа како да работиме со кодот.
Ако треба да додадете нови функции на вашиот код, во повеќето случаи тоа е лесно. Пишувате нов ресурс, сè е едноставно.
Ако имате некој ресурс што сте го создале однапред, на пример, сте научиле за Terraform откако сте отвориле сметка на AWS и сакате да ги користите ресурсите што веќе ги имате, тогаш би било соодветно да го проширите вашиот модул на овој начин, така што го поддржува користењето на постоечките ресурси.
И го поддржа создавањето на нови ресурси користејќи го блок-ресурсот.
На излезот секогаш го враќаме излезниот ID во зависност од тоа што е користено.
Вториот многу значаен проблем во Terraform 0.11 е работата со списоци.
Тешкотијата е во тоа што ако имаме таква листа на корисници.
И кога ги создаваме овие корисници користејќи блок-ресурс, тогаш сè оди добро. Ја поминуваме целата листа, создавајќи датотека за секоја од нив. Се е во ред. И тогаш, на пример, корисникот3, кој е во средината, треба да се отстрани од овде, тогаш сите ресурси што се создадени по него ќе се рекреираат бидејќи индексот ќе се промени.
Работа со списоци во државна средина. Што е државна средина? Ова е ситуација кога се создава нова вредност кога се создава овој ресурс. На пример, AWS Access Key или AWS Secret Key, т.е. кога создаваме корисник, добиваме нов пристап или таен клуч. И секогаш кога ќе избришеме корисник, овој корисник ќе има нов клуч. Но, ова не е фенг шуи, бидејќи корисникот нема да сака да биде пријател со нас ако му создаваме нов корисник секој пат кога некој ќе го напушти тимот.
Ова е решението. Ова е код напишан во Jsonnet. Jsonnet е јазик за шаблони од Google.
Оваа команда ви овозможува да го прифатите овој шаблон и како излез враќа json датотека што е направена според вашиот шаблон.
Шаблонот изгледа вака.
Terraform ви овозможува да работите и со HCL и со Json на ист начин, па ако имате можност да генерирате Json, тогаш можете да го внесете во Terraform. Датотеката со наставката .tf.json ќе биде успешно преземена.
И тогаш работиме со него како и обично: terraform init, terramorm применуваат. И создаваме двајца корисници.
Сега не се плашиме ако некој си замине од тимот. Само ќе ја уредиме датотеката json. Васија Пупкин замина, Петја Пјаточкин остана. Петја Пјаточкин нема да добие нов клуч.
Интегрирањето на Terraform со други алатки всушност не е работа на Terraform. Terraform е создаден како платформа за создавање ресурси и тоа е тоа. И сè што ќе се појави подоцна не е грижа на Тераформ. И нема потреба да го плетете таму. Постои Ansible, кој прави се што ви треба.
Но, се појавуваат ситуации кога сакаме да го прошириме Terraform и да повикаме некоја команда откако нешто ќе заврши.
Првиот начин. Ние создаваме излез каде што ја пишуваме оваа команда.
И тогаш ја повикуваме оваа команда од излезот на shell terraform и ја одредуваме вредноста што ја сакаме. Така, командата се извршува со сите заменети вредности. Тоа е многу удобно.
Втор начин. Ова е користење на null_resource во зависност од промените во нашата инфраструктура. Можеме да го повикаме истиот локален exe штом ќе се промени ID на некој ресурс.
Секако, сето ова е мазно на хартија, бидејќи Амазон, како и сите други јавни провајдери, има еден куп свои рабови.
Најчестиот случај на работ е дека кога отворате сметка на AWS, важно е кои региони ги користите; дали оваа функција е овозможена таму; можеби сте го отвориле по декември 2013 година; можеби користите стандардно во VPC итн. Има многу ограничувања. И Амазон ги расфрли низ документацијата.
Има неколку работи што препорачувам да ги избегнувате.
За почеток, избегнувајте ги сите нетајни аргументи во планот Terraform или Terraform CLI. Сето ова може да се стави или во датотека tfvars или во променлива на околината.
Но, не треба да ја запаметите целата оваа магична команда. Terraform plan – var и тргнуваме. Првата променлива е var, втората променлива е var, третата, четвртата. Најважниот принцип на инфраструктурата како код што најчесто го користам е дека само со гледање на кодот треба да имам јасно разбирање за тоа што е распоредено таму, во каква состојба и со какви вредности. И затоа не морам да ја читам документацијата или да го прашам Васија кои параметри ги користел за да го создаде нашиот кластер. Треба само да отворам датотека со наставката tfvars, која често се совпаѓа со околината и да погледнам се таму.
Исто така, не користете целни аргументи за да го намалите опсегот. За ова е многу полесно да се користат мали инфраструктурни модули.
Исто така, нема потреба од ограничување и зголемување на паралелизмот. Ако имам 150 ресурси и сакам да го зголемам паралелизмот на Амазон од стандардните 10 на 100, тогаш најверојатно нешто ќе тргне наопаку. Или сега може да оди добро, но кога Амазон ќе каже дека правите премногу повици, ќе бидете во неволја.
Terraform ќе се обиде да ги рестартира повеќето од овие проблеми, но нема да постигнете речиси ништо. Паралелизам=1 е важна работа што треба да ја користите ако наидете на некоја грешка во AWS API или внатре во провајдерот Terraform. И тогаш треба да наведете: паралелизам=1 и почекајте додека Terraform заврши еден повик, потоа вториот, па третиот. Ќе ги лансира еден по еден.
Луѓето често ме прашуваат: „Зошто мислам дека работните простори на Terraform се лоши? Верувам дека принципот на инфраструктурата како код е да се види каква инфраструктура е создадена и со какви вредности.
Работните простори не беа креирани од корисници. Ова не значи дека корисниците напишале во проблемите на GitHub дека не можеме да живееме без работните простори на Terraform. Не не вака. Terraform Enterprise е комерцијално решение. Terraform од HashiCorp одлучи дека ни требаат работни простори, па го поднесовме. Многу ми е полесно да го ставам во посебна папка. Потоа ќе има уште малку датотеки, но ќе биде појасно.
Како да работите со кодот? Всушност, работата со списоци е единствената болка. И полесно земете го Terraform. Ова не е она што ќе направи се што е одлично за вас. Нема потреба таму да се бута се што пишува во документацијата.
Темата на извештајот беше напишана „за иднината“. Ќе зборувам за ова многу кратко. За во иднина, тоа значи дека 0.12 ќе излезе наскоро.
0.12 е еден тон нови работи. Ако доаѓате од редовно програмирање, тогаш пропуштате секакви динамични блокови, циклуси, правилни и условни операции за споредба, каде што левата и десната страна не се пресметуваат истовремено, туку во зависност од ситуацијата. Многу ти недостига, па 0.12 ќе ти реши.
Но! Ако пишувате помалку и поедноставно, користејќи готови модули и решенија од трети страни, тогаш нема да мора да чекате и да се надевате дека 0.12 ќе дојде и ќе ви поправи сè.
Ви благодариме за извештајот! Зборувавте за инфраструктурата како код и буквално кажавте еден збор за тестовите. Дали се потребни тестови во модулите? Чија е ова одговорност? Дали треба сам да го напишам или тоа е одговорност на модулите?
Следната година ќе биде исполнета со извештаи дека решивме се да тестираме. Што да се тестира е најголемото прашање. Има многу зависности, многу ограничувања од различни провајдери. Кога јас и ти разговараме и велиш: „Ми требаат тестови“, тогаш прашувам: „Што ќе тестираш?“ Велите дека ќе тестирате во вашиот регион. Тогаш велам дека ова не функционира во мојот регион. Тоа е, ние дури и нема да можеме да се договориме за ова. Да не зборуваме дека има многу технички проблеми. Односно, како да се напишат овие тестови за да бидат соодветни.
Активно ја истражувам оваа тема, односно како автоматски да генерирам тестови врз основа на инфраструктурата што ја напиша. Тоа е, ако го напишавте овој код, тогаш треба да го стартувам, врз основа на ова можам да креирам тестови.
е една од најчесто споменуваните библиотеки што ви овозможува да пишувате тестови за интеграција за Terraform. Ова е една од комуналните услуги. Го претпочитам типот DSL, на пример, rspec.
Антон, благодарам за извештајот! Јас се викам Валери. Да поставам малку филозофско прашање. Има, условно, обезбедување, има распоредување. Обезбедувањето ја создава мојата инфраструктура, при распоредувањето ја пополнуваме со нешто корисно, на пример, сервери, апликации, итн. ви овозможува да инсталирате nginx, Postgres. Но, во исто време, се чини дека Ansible дозволува обезбедување, на пример, ресурси на Amazon или Google. Но, Terraform исто така ви овозможува да распоредите некој софтвер користејќи ги неговите модули. Од ваша гледна точка, дали постои некаква граница што се протега помеѓу Terraform и Ansible, каде и што е подобро да се користи? Или на пример мислиш дека Ansible е веќе ѓубре, треба да пробаш да користиш Terraform за се?
Добро прашање, Валери. Верувам дека Terraform не е променет во однос на намената од 2014 година. Се создаде за инфраструктура и умре за инфраструктура. Сè уште имавме и ќе имаме потреба од Ansible за управување со конфигурации. Предизвикот е што има кориснички податоци во launch_configuration. И таму го влечеш Ансибл, итн. Ова е стандардната разлика што најмногу ми се допаѓа.
Ако зборуваме за убава инфраструктура, тогаш постојат комунални услуги како Packer кои ја собираат оваа слика. И тогаш Terraform го користи изворот на податоци за да ја пронајде оваа слика и да ја ажурира нејзината launch_configuration. Односно, на овој начин цевководот е дека прво го влечеме Tracker, а потоа го влечеме Terraform. И ако се случи изградба, тогаш се случува нова промена.
Здраво! Ви благодариме за извештајот! Моето име е Миша, компанија RBS. Можете да го повикате Ansible преку провизор кога креирате ресурс. Ansible има и тема наречена динамичен инвентар. И прво можете да го повикате Terraform, а потоа да повикате Ansible, кој ќе земе ресурси од државата и ќе го изврши. Што е подобро?
Луѓето ги користат и двете со еднаков успех. Ми се чини дека динамичниот инвентар во Ansible е погодна работа, ако не зборуваме за група за автоматско скалирање. Затоа што во групата за автоматско скалирање веќе имаме сопствена алатка, која се нарекува launch_configuration. Во launch_configuration снимаме се што треба да се стартува кога создаваме нов ресурс. Затоа, со Амазон, користењето динамичен инвентар и читањето на датотеката Terraform ts, според мое мислење, е претерано. И ако користите други алатки каде што нема концепт за „група за автоматско скалирање“, на пример, користите DigitalOcean или некој друг провајдер каде што нема група за автоматско скалирање, тогаш таму ќе треба рачно да го повлечете API, да пронајдете IP адреси, да креирате динамична датотека со инвентар , и Ansible веќе ќе талка низ неа. Односно за Амазон има launch_configuration, а за се друго има динамичен инвентар.
Извор: www.habr.com