Претставувањето на инфраструктурата како код во повторлив текстуален формат е едноставна најдобра практика за системи кои не бараат макање со глувци. Оваа практика има име - , и досега има две популарни алатки за нејзино спроведување, особено во AWS: и .
Споредување на искуството со Terraform и CloudFormation
Пред да дојде до (Ака ) Работев и го користеше Terraform три години. На новото место, исто така, го користев Terraform со сите сили, а потоа компанијата ја турна транзицијата кон сè што е a la Amazon, вклучително и CloudFormation. Напорно развив најдобри практики за двете, и ги користев двете алатки во многу сложени работни текови на ниво на организација. Подоцна, откако внимателно ги разгледав импликациите од мигрирањето од Terraform во CloudFormation, се уверив дека Terraform е веројатно најдобриот избор за организацијата.
Тераформ Ужасно
Бета софтвер
Terraform сè уште не ја издаде верзијата 1.0, што е добра причина да не ја користите. Многу се смени откако јас првпат се обидов, но тогаш terraform apply често се распаѓаше по неколку ажурирања или едноставно по неколку години користење. Јас би рекол дека „сега сè е поинаку“, но... тоа е она што се чини дека сите велат, не? Има промени кои се некомпатибилни со претходните верзии, иако се соодветни, па дури се чини дека синтаксата и апстракциите на продавниците за ресурси сега се она што ни треба. Изгледа дека инструментот навистина стана подобар, но... :-0
Од друга страна, AWS направи добра работа за одржување на компатибилноста наназад. Ова е веројатно затоа што нивните услуги често се темелно тестирани во организацијата и дури потоа, преименувани, се објавуваат. Значи, „напорно се трудеа“ е потценување. Одржувањето на наназад компатибилност со API за систем толку разновиден и сложен како AWS е неверојатно тешко. Секој кој морал да одржува јавни API кои се користат толку широко колку што се, треба да разбере колку е тешко да се направи тоа толку многу години. Но, однесувањето на CloudFormation, во моето сеќавање, никогаш не се променило со текот на годините.
Запознајте ја ногата... тоа е куршум
Колку што знам, избришете го ресурсот аутсајдер Оџакот CloudFormation од вашиот оџак CF не е возможен. Истото важи и со Terraform. Тоа ви овозможува да увезете постоечки ресурси во вашиот стек. Функцијата може да се каже дека е неверојатна, но со голема моќ доаѓа и голема одговорност. Треба само да додадете ресурс во стекот и додека работите со вашиот стек, не можете да го избришете или промените овој ресурс. Еден ден се врати назад. Еден ден на Twitch, некој случајно увезол туѓа безбедносна група AWS во нивниот сопствен оџак Terraform без никакво зло. Внесов неколку команди и... групата за безбедност (заедно со дојдовниот сообраќај) исчезна.
Тераформи одлично
Закрепнување од нецелосни состојби
Понекогаш CloudFormation не успева целосно да премине од една во друга состојба. Во исто време, тој ќе се обиде да се врати на претходниот. Штета што ова не е секогаш изводливо. Може да биде доста страшно да се дебагира она што се случило подоцна - никогаш не знаете дали CloudFormation ќе биде среќен што е хакиран - дури и само да го поправите. Без разлика дали ќе биде можно да се врати во претходната состојба или не, тој навистина не знае како да утврди и, стандардно, виси со часови чекајќи чудо.
Terraform, од друга страна, има тенденција да се опорави од неуспешните транзиции многу пограциозно и нуди напредни алатки за дебагирање.
Појасни промени во состојбата на документот
„Во ред, балансер на оптоварување, се менуваш. Но како?"
— вознемирен инженер, подготвен да го притисне копчето „прифати“.
Понекогаш треба да направам некои манипулации со балансерот на оптоварување во оџакот CloudFormation, како што е додавање број на порта или промена на безбедносна група. ClouFormation прикажува слабо промени. Јас, на иглички, двапати ја проверувам датотеката yaml за да се уверам дека не сум избришал ништо неопходно и не сум додал ништо непотребно.
Terraform е многу потранспарентен во овој поглед. Понекогаш е дури и премногу транспарентен (читај: досаден). За среќа, најновата верзија вклучува подобрен приказ на промените, така што сега можете да видите што точно се менува.
Флексибилност
Напишете софтвер наназад.
Да се каже отворено, најважната карактеристика на долговечниот софтвер е способноста да се прилагоди на промените. Напишете кој било софтвер наназад. Најчесто правев грешки со тоа што земав „едноставна“ услуга, а потоа почнав да ставам сè во еден куп CloudFormation или Terraform. И, се разбира, месеци подоцна беше откриено дека сè сум разбрал погрешно, а услугата всушност не беше едноставна! И сега треба некако да скршам голем оџак на мали компоненти. Кога работите со CloudFormation, ова може да се направи само со прво создавање на постојниот стек, а јас не го правам тоа со моите бази на податоци. Terraform, од друга страна, овозможи да се сецира оџакот и да се распадне на поразбирливи помали делови.
Модули во git
Споделувањето Terraform код низ повеќе стекови е многу полесно отколку споделувањето на кодот CloudFormation. Со Terraform, можете да го ставите вашиот код во складиште за git и да пристапите до него користејќи контрола на семантичка верзија. Секој што има пристап до ова складиште може повторно да го користи споделениот код. Еквивалент на CloudFormation е S3, но ги нема истите бенефиции и нема причина зошто воопшто да го напуштиме git во корист на S3.
Организацијата порасна и способноста за споделување заеднички купови достигна критично ниво. Terraform го прави сето ова лесно и природно, додека CloudFormation ќе ве натера да скокате низ обрачите пред да успеете да постигнете нешто како ова да функционира.
Операции како код
„Ајде да го скриптираме и во ред“.
— инженер 3 години пред да го измисли велосипедот Terraform.
Кога станува збор за развој на софтвер, Go или Java програма не е само код.
Код како код
Тука е и инфраструктурата на која работи.
Инфраструктурата како код
Но, од каде е таа? Како да се следи? Каде живее вашиот код? Дали на програмерите им е потребна дозвола за пристап?
Операции како код
Да се биде развивач на софтвер не значи само пишување код.
AWS не е единствениот: веројатно користите други провајдери. SignalFx, PagerDuty или Github. Можеби имате внатрешен Jenkins сервер за CI/CD или внатрешна Grafana табла за следење. Infra as Code е избран од различни причини, и секоја е подеднакво важна за се што е поврзано со софтверот.
Кога работев во Twitch, ги забрзавме услугите во мешаните вградени и AWS системи на Amazon. Создадовме и поддржавме многу микроуслуги, зголемувајќи ги оперативните трошоци. Дискусиите одеа вака:
- Я: По ѓаволите, тоа се многу гестови за оверклокување на еден микросервис. Ќе морам да го искористам ова ѓубре за да создадам сметка AWS (ојдовме на 2 сметки микросервис), потоа оваа за поставување предупредувања, оваа за складиште за кодови и оваа за список со е-пошта, а потоа оваа...
- Олово: Ајде да го скриптираме и во ред.
- Я: Во ред, но самото сценарио ќе се промени. Ќе треба да се најде начин да се провери дали сите овие вградени Gizmos на Амазон се ажурирани.
- Олово: Звучи добро. И ние ќе напишеме сценарио за ова.
- Я: Одлично! И скриптата веројатно сè уште ќе треба да постави параметри. Дали ќе ги прифати?
- Олово: Нека однесе каде оди!
- Я: Процесот може да се промени и компатибилноста наназад ќе се изгуби. Ќе биде потребен некаков вид контрола на семантичката верзија.
- Олово: Одлична идеја!
- Я: Алатките може да се менуваат рачно, внатре во корисничкиот интерфејс. Ќе ни треба начин да го провериме и поправиме ова.
…3 години подоцна:
- Олово: И добивме тераформа.
Моралот на приказната е: дури и ако вие со глава во сè Амазон, сè уште користите нешто што не е од AWS и овие услуги имаат состојба што користи конфигурациски јазик за да ја одржува таа состојба синхронизирана.
CloudFormation ламбда наспроти git модули тераформни
ламбда е решението на CloudFormation за проблемот со приспособената логика. Со ламбда можете или . Овој пристап воведува дополнителни сложености кои не се присутни во семантичката верзија на git модулите на Terraform. За мене, најитниот проблем беше управувањето со дозволите за сите овие кориснички ламбди (и ова се десетици AWS сметки). Друг важен проблем беше „што дојде прво, пилешкото или јајцето?“: тоа беше поврзано со ламбда кодот. Оваа функција сама по себе е инфраструктура и код, а самата има потреба од мониторинг и ажурирања. Последната шајка во ковчегот беше тешкотијата во семантички ажурирање на промените на ламбда кодот; исто така, моравме да се погрижиме дејствата на стекот без директна команда да не се менуваат помеѓу стапките.
Се сеќавам дека еднаш сакав да создадам канаринско распоредување за околината Elastic Beanstalk со класичен баланс на оптоварување. Најлесно би било да се направи второ распоредување за EB веднаш до производната средина, одејќи чекор понатаму: комбинирање на групата за распоредување канари за автоматско скалирање со распоредување LB во производната средина. И бидејќи Terraform користи , ова ќе бара 4 дополнителни линии код во Terraform. Кога прашав дали има споредливо решение во CloudFormation, тие ми укажаа на целото git складиште со цевковод за распоредување и сè, сè заради нешто што би можеле да го направат сиромашните 4 линии Terraform код.
Подобро го открива наносот
Погрижете се реалноста да одговара на очекувањата.
е многу моќна операција како карактеристика на кодот бидејќи помага да се осигура дека реалноста одговара на очекувањата. Достапно е и со CloudFormation и со Terraform. Но, како што растеше производствениот оџак, пребарувањето за дрифт во CloudFormation произведуваше сè повеќе лажни откривања.
Со Terraform имате многу понапредни куки за животниот циклус за откривање на нанос. На пример, ја внесувате командата директно во дефиницијата на задачата ECS ако сакате да ги игнорирате промените на одредена дефиниција на задача без да ги игнорирате промените на целото ваше распоредување на ECS.
CDK и иднината на CloudFormation
CloudFormation е тешко да се управува на големи размери меѓу инфраструктурата. Многу од овие тешкотии се препознаени и на алатката и требаат работи како , рамка за дефинирање на облак инфраструктура во код и нејзино водење преку AWS CloudFormation. Ќе биде интересно да се види што носи иднината за aws-cdk, но ќе има тешко време да се натпреварува со другите силни страни на Terraform; за да се ажурира CloudFormation, ќе бидат потребни глобални промени.
За да не разочара Terraform
Ова е „инфраструктура како код“, а не „како текст“.
Мојот прв впечаток за Terraform беше прилично лош. Мислам дека едноставно не го разбрав пристапот. Речиси сите инженери неволно го доживуваат како формат на текст кој треба да се претвори во саканата инфраструктура. НЕ ПРАВИ ТОА ВАКА.
Смислата за добар развој на софтвер важат и за Terraform.
Сум видел многу практики усвоени за создавање добар код кои се игнорираат во Terraform. Сте учеле со години за да станете добар програмер. Не се откажувајте од ова искуство само затоа што работите со Terraform. Смислата за добар развој на софтвер се однесува на Terraform.
Како може кодот да не се документира?
Сум видел огромни купишта Terraform без апсолутно никаква документација. Како можете да напишете код на страници - без апсолутно никаква документација? Додадете документација што ја објаснува вашата код Terraform (акцент на зборот „шифра“), зошто овој дел е толку важен и што правите.
Како можеме да распоредиме услуги кои некогаш биле една голема main() функција?
Сум видел многу сложени купишта Terraform претставени како еден модул. Зошто не го распоредуваме софтверот на овој начин? Зошто ги делиме големите функции на помали? Истите одговори важат и за Terraform. Ако вашиот модул е премногу голем, треба да го поделите на помали модули.
Дали вашата компанија не користи библиотеки?
Сум видел како инженерите, вртејќи нов проект користејќи Terraform, глупаво копираат огромни делови од други проекти во своите, а потоа ги чепкаат додека не почне да работи. Дали би работеле вака со „борбен“ код во вашата компанија? Ние не користиме само библиотеки. Да, но каде сме без заеднички библиотеки во принцип?!
Да не користиш PEP8 или gofmt?
Повеќето јазици имаат стандардна, прифатена шема за форматирање. Во Python ова е PEP8. Во Го - гофмт. Terraform има свои: terraform fmt. Користете за здравје!
Дали ќе користите React без да знаете JavaScript?
Тераформските модули можат да поедностават дел од сложената инфраструктура што ја создавате, но тоа не значи дека воопшто не можете да ја чепкате. Сакате правилно да го користите Terraform без да ги разберете ресурсите? Вие сте осудени на пропаст: времето ќе помине и никогаш нема да го совладате Terraform.
Дали кодирате со синглови или инјекција на зависност?
Инјектирањето на зависност е призната најдобра практика за развој на софтвер и се претпочита во однос на единечните. Како е ова корисно во Terraform? Сум видел Terraform модули кои зависат од далечинска состојба. Наместо да пишувате модули кои враќаат оддалечена состојба, напишете модул што зема параметри. И потоа пренесете ги овие параметри на модулот.
Дали вашите библиотеки прават десет работи добро или една работа одлично?
Библиотеките кои најдобро функционираат се оние кои се фокусираат на една задача што ја извршуваат многу добро. Наместо да пишувате големи Terraform модули кои се обидуваат да направат сè одеднаш, изградете делови од нив кои добро прават една работа. И потоа соединете ги по потреба.
Како да направите промени во библиотеките без компатибилност наназад?
Заеднички Terraform модул, како обична библиотека, треба некако да ги пренесе промените на корисниците без да биде компатибилен наназад. Досадно е кога овие промени се случуваат со библиотеките, и исто толку е досадно кога се прават промени кои не се компатибилни со наназад во модулите на Terraform. Се препорачува да се користат git тагови и semver при користење на Terraform модули.
Дали вашата производствена услуга работи на вашиот лаптоп или во центар за податоци?
Hashicorp има алатки како да ја водите вашата тераформа. Овие централизирани услуги го олеснуваат управувањето, ревизијата и одобрувањето на тераформните промени.
Да не пишуваш тестови?
Инженерите признаваат дека кодот треба да се тестира, но тие самите често забораваат на тестирањето кога работат со Terraform. За инфраструктура, ова е полн со предавнички моменти. Мој совет е да „тестирате“ или да „создадете примероци“ со модули што можат правилно да се распоредат за тестирање за време на CI/CD.
Terraform и microservices
Животот и смртта на микросервисните компании зависи од брзината, иновативноста и нарушувањето на новите работни места за микросервис.
Најчестиот негативен аспект поврзан со архитектурите на микросервис и кој не може да се елиминира е поврзан со работата, а не со кодот. Ако мислите дека Terraform е само начин да се автоматизира само инфраструктурната страна на архитектурата на микросервисите, тогаш ги пропуштате вистинските придобивки од системот. Сега е веќе .
Извор: www.habr.com