Уяўляць інфраструктуру ў выглядзе кода ў паўтараным тэкставым фармаце - простая лепшая практыка для сістэм, з якой не трэба мышавозіць. За гэтай практыкай замацавалася назва , і пакуль што для яе ажыццяўлення, асабліва ў AWS, ёсць два папулярных прылады: и .
Параўноўваю досвед працы з Terraform і CloudFormation
Да прыходу ў (Ён жа ) я працаваў і гады тры выкарыстоўваў Terraform. На новым месцы я таксама на ўсю моц выкарыстоўваў Terraform, а потым кампанія прадушыла пераход на ўсе а-ля Amazon, уключаючы CloudFormation. Я старанна распрацоўваў лепшыя практыкі і для таго, і для іншага, і абодва інструмента выкарыстоўваў у вельмі складаных працоўных працэсах у маштабах арганізацыі. Пазней, удумліва ўзважыўшы наступствы пераходу з Terraform на CloudFormation, я пераканаўся, што Terraform, мусіць, лепшы выбар для арганізацыі.
Terraform Жудасны
Бэта-версія ПЗ
У Terraform яшчэ нават не выйшла версія 1.0, і гэта важкі чыннік ім не карыстацца. З таго часу, як я сам яго ўпершыню апрабаваў, ён моцна змяніўся, але тады яшчэ terraform apply часта ламаўся пасля некалькіх абнаўленняў ці проста праз пару гадоў эксплуатацыі. Я б сказаў, што "зараз-то ўсё па-іншаму", але… так накшталт усё кажуць, не? Ёсць змены, несумяшчальныя з папярэднімі версіямі, хоць яны дарэчныя, і нават пачуццё такое, што сінтаксіс і абстракцыі сховішчаў рэсурсаў зараз што трэба. Інструмент як быццам праўда стаў лепш, але… :-0
З іншага боку, AWS добра пастаралася, падтрымліваючы сумяшчальнасць з папярэднімі версіямі. Усё, мусіць, таму, што іх сэрвісы часта добранька тэстуюць усярэдзіне арганізацый і толькі потым, пераназваўшы, публікуюць. Так што "добра пастараліся" гэта яшчэ слаба сказана. Падтрымліваць сумяшчальнасць з папярэднімі версіямі API для такой шматварыянтнай і складанай сістэмы, як AWS, неверагодна цяжка. Любы, каму даводзілася падтрымліваць агульнадаступныя API, якія выкарыстоўваюцца гэтак жа шырока, павінен разумець, як цяжка гэта рабіць на працягу гэтулькіх гадоў. А вось паводзіны CloudFormation на маёй памяці ні разу з гадамі не змяніліся.
Знаёмся, нага... гэта куля
Наколькі я ведаю, выдаліць рэсурс старонняга стэка CloudFormation са свайго стэка CF немагчыма. Прыкладна гэтак жа справа ідзе і з Terraform. Ён дазваляе імпартаваць існуючыя рэсурсы ў свой стэк. Функцыя, можна сказаць, узрушаючая, але з вялікай сілай прыходзіць і вялікая адказнасць. Варта толькі занесці рэсурс у стэк і, пакуль ты працуеш са сваім стэкам, выдаліць ці змяніць гэты рэсурс нельга. Аднойчы гэта гукнулася. Неяк на сайце Twitch хтосьці, не намышляючы нічога благога, выпадкова імпартаваў чыюсьці групу бяспекі AWS у свой уласны стэк Terraform. Увёў некалькі каманд і… група бяспекі (разам са ўваходным трафікам) знікла.
Terraform Вялікі
Аднаўленне з няпоўных станаў
Часам CloudFormation не можа цалкам перайсці з аднаго стану ў іншы. Пры гэтым ён паспрабуе вярнуцца да папярэдняга. Шкада, гэта не заўсёды здзяйсняльна. Адладжваць потым тое, што атрымалася, бывае страшнаваценька - ніколі не ведаеш, ці ўзрадуецца CloudFormation, што яго ўзломваюць - хай і для папраўкі. А атрымаецца ці не вярнуцца да папярэдняга стану, ён толкам вызначаць не ўмее і па змаўчанні гадзінамі вісіць у чаканні цуду.
Terraform жа, наадварот, схільны аднаўляцца пасля няўдалых пераходаў куды хупавей і прапануе пашыраны адладкавы інструментар.
Больш ясныя змены ў станы дакумента
«Добра, балансавальнік нагрузкі, ты мяняешся. Але як?"
-занепакоены інжынер, гатовы націснуць кнопку "прыняць".
Часам мне трэба прарабіць сякія-такія маніпуляцыі з балансавальнікам нагрузкі ў стэку CloudFormation - напрыклад, дадаць нумар порта або змяніць групу бяспекі. ClouFormation змены адлюстроўвае слаба. Я ж, як на іголках, разоў па дзесяць пераправяраю файл yaml, каб пераканацца, што нічога патрэбнага не сцёр, а лішняга - не дадаў.
Terraform у гэтым плане куды празрысцей. Часам ён нават занадта празрысты (чытай: дастае). На шчасце, у апошнюю версію ўключылі палепшанае адлюстраванне змен - зараз сапраўды відаць, што змяняецца.
Гнуткасць
Пішыце ПЗ ад зваротнага.
Гаворачы прама, самая важная адметная рыса доўгажывучых ПЗ - гэта здольнасць адаптавацца да змен. Любое ПЗ пішыце ад зваротнага. Я вось часцей за ўсё праколваўся на тым, што браў «прасценькі» сэрвіс, а потым прымаўся запіхваць усё ў адзіны стэк CloudFormation або Terraform. І вядома ж, праз месяцы выкрывалася, што я ўсё зразумеў не так, і сэрвіс-то насамрэч не просты! І вось мне трэба нейкім чынам разбіць вялікі стэк на малыя складнікі. Калі працуеш з CloudFormation, зрабіць гэта магчыма, толькі папярэдне узнавіўшы існы стэк, а гэтага я, са сваімі БД, не раблю. Terraform жа дазваляў прэпараваць стэк і расчляніць яго на больш зразумелыя меншыя часткі.
Модулі ў git
Дзяліцца кодам Terraform паміж шматлікімі стэкамі значна прасцей, чым кодам CloudFormation. З Terraform можна змясціць код у рэпазітар git і звяртацца да яго, выкарыстоўваючы семантычны кантроль версій. Любы, у каго ёсць доступ у гэты рэпазітар, можа зноўку выкарыстоўваць агульны код. Эквівалент ад CloudFormation – S3, але ў яго няма тых жа пераваг, і няма ніводнай прычыны, па якой нам наогул варта адмовіцца ад git у карысць S3.
Арганізацыя расла і здольнасць дзяліцца агульнымі стэкамі дасягнула крытычнага ўзроўню. З Terraform усё гэта атрымліваецца лёгка і натуральна, тады як CloudFormation прымусіць вас паскакаць праз кольцы, перш чым у вас заробіць нешта падобнае.
Operations as code
«Заскрыптуем і добра».
-інжынер за 3 гады да таго, як вынайсці ровар Terraform.
Калі гаворка аб распрацоўцы ПЗ, то Go або праграма на Java - гэта не проста код.
Code as Code
Ёсць яшчэ інфраструктура, на якой яна працуе.
Інфраструктура як кодэкс
Але адкуль яна тамака? Як яе маніторыць? Дзе насяляе ваш код? Ці трэба распрацоўнікам дазвол на доступ?
Operations as Code
Быць распрацоўшчыкам ПЗ - гэта вам не проста код пісаць.
Ня AWS адзіным: вы напэўна карыстаецеся паслугамі іншых пастаўшчыкоў. SignalFx, PagerDuty ці Github. Можа быць, у вас ёсць унутраны сервер Jenkins для CI/CD або ўнутраная панэль кіравання Grafana для маніторынгу. Infra as Code выбіраюць па розных прычынах, і любая аднолькава важная для ўсяго, звязанага з ПЗ.
Калі я працаваў у Twitch, мы паскаралі сэрвісы ўсярэдзіне змешаных убудаваных сістэм і сістэм AWS Amazon'а. Мы штампавалі і падтрымлівалі мноства мікрасэрвісаў, павялічваючы эксплуатацыйныя выдаткі. Абмеркаванні праходзілі прыкладна ў такім ключы:
- Я: Блін, зашмат рухаў цела для разгону аднаго мікрасэрвісу. Мне вось гэтую бздуру давядзецца выкарыстоўваць, каб стварыць AWS рахунак (мы ішлі да 2 акаўнтаў на мікрасэрвіс), потым гэтую - для налады абвестак, яшчэ гэтую - для рэпазітара кода, і гэтую - для спісу адрасоў электроннай пошты, ну і вось гэтую…
- Лід: Заскрыптуем і добра.
- Я: Лады, але сам скрыпт зменіцца. Патрэбны будзе спосаб, як праверыць, што ўсе гэтыя ўбудаваныя штуковіны amazon'а маюць актуальны стан.
- Лід: Гучыць нядрэнна. І для гэтага скрыпт напішам.
- Я: Выдатна! А скрыпту, напэўна, яшчэ трэба будзе задаць параметры. Прыме ён іх?
- Лід: Ды прыме, куды дзенецца!
- Я: Працэс можа змяніцца, згубіцца зваротная сумяшчальнасць. Запатрабуецца які-небудзь семантычна кантроль версій.
- Лід: Выдатная ідэя!
- Я: Інструменты можна змяніць уручную, унутры карыстацкага інтэрфейсу. Нам спатрэбіцца спосаб, як гэта правяраць і выпраўляць.
…3 гады праз:
- Лід: І атрымаўся ў нас terraform.
Мараль байкі такая: нават калі вы па вушы ва ўсім amazon'аўскім, вы ўсё роўна карыстаецеся чым-небудзь не ад AWS, і ў гэтых сэрвісаў ёсць стан, якое выкарыстоўвае мову для канфігурацыі, каб гэты стан сінхранізаваць.
CloudFormation lambda vs git-модулі terraform
lambda - гэта рашэнне CloudFormation для пытання карыстацкай логікі. З дапамогай lambda можна або . Такі падыход уяўляе дадатковыя складанасці, якіх няма ў семантычным кантролі версій модуляў git у Terraform. Для мяне самай надзённай праблемай стала кіраванне дазволамі для ўсіх гэтых карыстацкіх lambda (а гэта дзясяткі акаўнтаў AWS). Іншы па важнасці стала праблема тыпу "што было раней - курыца ці яйка?": яна была злучана з кодам lambda. Сама гэтая функцыя - інфраструктура і код, і яна сама мае патрэбу ў маніторынгу і абнаўленнях. Апошнім цвіком у труну стала цяжкасць у семантычным абнаўленні змен кода lambda; яшчэ трэба было зрабіць так, каб дзеянні стэка без прамой каманды не мяняліся паміж запускамі.
Памятаю, неяк захацелася мне стварыць канарэечны дэплой для асяроддзя Elastic Beanstalk з класічным балансавальнікам нагрузкі. Прасцей за ўсё было б зрабіць другое разгортванне для EB побач з вытворчым асяроддзем, зрабіўшы яшчэ крок: аб'яднаўшы аўтаматычна якая маштабуецца групу канарэечнага дэплою з LB разгортванні ў вытворчае асяроддзе. А раз Terraform выкарыстоўвае , гэта запатрабуе 4 лішнія радкі кода ў Terraform. Калі я пацікавіўся, ці няма супастаўнага рашэння ў CloudFormation, мне паказалі на цэлы рэпазітар у git з канвеерам разгортвання і іншым: і ўсё гэта дзеля таго, што маглі б зрабіць няшчасныя 4 радкі кода Terraform.
Ён лепш выяўляе дрэйф
Пераканайцеся, што рэальнасць адпавядае чаканням.
- Вельмі магутная функцыя operations as code, таму што дапамагае пераканацца, што рэальнасць адпавядае чаканням. Яна даступная і з 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. У Go - gofmt. У Terraform ёсць свой: terraform fmt. Карыстайцеся на здароўе!
Вы станеце карыстацца React, не ведаючы JavaScript?
Модулі Terraform могуць спрасціць нейкую частку стваранай вамі складанай інфраструктуры, але гэта яшчэ не значыць, што можна можна ў ёй наогул не мацаць. Жадаеце правільна выкарыстоўваць Terraform без разумення рэсурсаў? Вы асуджаныя: час будзе ісці, а вы так і не асвоіце Terraform.
Вы кадзіце сінглтанамі, або укараняючы залежнасці?
Укараненне залежнасцяў - прызнаная лепшая практыка для распрацоўкі ПЗ, якую аддаюць перавагу сінглтанам. Як гэта спатрэбіцца ў Terraform? Мне сустракаліся модулі Terraform, якія залежаць ад выдаленага стану. Замест таго, каб пісаць модулі, якія здабываюць з выдаленага стану, напішыце модуль, які прымае параметры. А потым перадайце гэтыя параметры ў модуль.
Вашы бібліятэкі робяць дзесяць рэчаў добра ці адну - выдатна?
Лепш за ўсё працуюць бібліятэкі, засяроджаныя на адной задачы, якую выконваюць на выдатна. Замест таго, каб пісаць буйныя модулі Terraform, якія спрабуюць рабіць усё і адразу, складзіце з іх часткі, якія добра робяць нешта адно. А потым ужо камбінуйце іх так, як трэба.
Як вы робіце змены ў бібліятэках без зваротнай сумяшчальнасці?
Агульнаму модулю Terraform, як і звычайнай бібліятэцы, трэба неяк паведамляць карыстальнікам аб зменах без зваротнай сумяшчальнасці. Калі адбываюцца такія змены ў бібліятэках, гэта ятрыць, і сапраўды гэтак жа раздражняе, калі змены без зваротнай сумяшчальнасці вырабляюцца ў модулях Terraform. Рэкамендуецца прымяняць git tags і semver пры выкарыстанні модуляў Terraform.
Вытворчы сэрвіс запушчаны ў вас на наўтбуку ці ў датацэнтры?
У Hashicorp ёсць прылады накшталт для запуску вашага terraform. Гэтыя цэнтралізаваныя сэрвісы палягчаюць кіраванне, аўдыт і ўхваленне змен terraform.
Няўжо вы не пішаце тэсты?
Інжынеры прызнаюць, што код трэба тэставаць, але самі пры гэтым часта забіваюць на праверкі, працуючы з Terraform. Для інфраструктуры гэта багата падступнымі момантамі. Я раю "тэставаць" ці "ствараць прыклады" стэкаў з выкарыстаннем модуляў, якія можна карэктна задэплоіць для праверкі падчас CI/CD.
Terraform і мікрасэрвісы
Жыццё і смерць мікрасэрвісных кампаній залежыць ад хуткасці, абнаўленні і разбурэнні новых мікрасэрвісных працоўных стэкаў.
Самы распаўсюджаны негатыўны момант, злучаны з мікрасэрвіснымі архітэктурамі і ад якога ніяк не пазбавяцца, злучаны з працай, а не з кодам. Калі ўспрымаць Terraform, толькі як спосаб аўтаматызаваць толькі інфраструктурны бок мікрасэрвіснай архітэктуры, тыя вы пазбаўляеце сябе сапраўдных пераваг гэтай сістэмы. Цяпер ужо .
Крыніца: habr.com