Представянето на инфраструктурата под формата на код в повторяем текстов формат е проста, но най-добра практика за системи, при която не е необходимо да се мишкува. Тази практика е получила името - , и засега, за да бъде осъществима, особено в 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 — например, да добавя номер на порт или да променя групата за защита. CloudFormation показва промените неясно. Аз обаче, като на игли, проверявам файла yaml десетина пъти, за да се уверя, че не съм изтрила нищо важно и не съм добавила излишно.
Terraform в това отношение е много по-прозрачен. Понякога е дори прекалено прозрачен (чети: досаден). За щастие, в последната версия бе добавено подобрено отразяване на промените — сега е ясно какво точно се променя.
Гъвкавост
Пишете софтуер от обратното.
Говоря направо, най-важната отличителна черта на дълговечното софтуерно решение е способността му да се адаптира към промените. Пишете всяко софтуерно решение от обратната страна. Често съм се провалял, когато взимах "простичка" услуга и след това се опитвах да я вмъкна в единен стек CloudFormation или Terraform. И разбира се, след месеци разбирах, че не съм разбрал правилно, и услугата всъщност не е проста! Трябваше ми по някакъв начин да разделя голямия стек на малки части. Когато работите с CloudFormation, това е възможно само след предварително възстановяване на съществуващия стек, а аз с моите бази данни не правя това. Terraform обаче позволява отделяне на стека и разчленяване на по-ясни и по-малки части.
Модули в git
Споделянето на код на Terraform между многобройни стека е много по-лесно, отколкото споделянето на код на CloudFormation. С Terraform можете да поставите кода в git репозиторий и да се свържете с него, използвайки семантичен контрол на версиите. Всеки, който има достъп до този репозиторий, може да използва общия код отново. Аналогът на CloudFormation е S3, но той няма същите предимства и няма причина да се отказваме от git в полза на S3.
Организацията растеше и способността да се споделят общи стека достигна критично ниво. С Terraform всичко това се получава лесно и естествено, в докато CloudFormation ще ви накара да преминете през много препятствия, преди да получите нещо подобно.
Operations as code
"Да напишем скрипт и да приключим."
— инженер три години преди да изобрети велосипеда 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 срещу git-модули terraform
lambda е решението на CloudFormation за проблема с потребителската логика. С помощта на lambda можете или . Този подход представя допълнителни трудности, които не съществуват в семантичния контрол на версиите на модулите git в Terraform. За мен най-належащият проблем стана управлението на разрешенията за всички тези потребителски lambda (а това са десетки AWS акаунти). Другият важен проблем беше този 'какво беше първо — яйцето или кокошката?' — свързан с кода на lambda. Самата функция е инфраструктура и код, и им е нужна мониторинг и актуализации. Последният трън в очите се оказа трудността при семантичното обновяване на промените в кода на lambda; нужно беше също така да се направи така, че действията на стека да не се променят между стартиранията без директна команда.
Помня, веднъж ми се прииска да създам канаречен деплой за среда Elastic Beanstalk с класически балансировчик на натоварване. Най-лесно би било да направя второ разгръщане за EB до производствената среда, като направя още една стъпка: да свържа автоматично мащабируемата група на канаречния деплой с LB разгръщането в производствената среда. A тъй като 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 тагове и semver при използване на модули на Terraform.
Работи ли производствената услуга на вашия лаптоп или в центъра за данни?
Hashicorp предлага инструменти като за стартиране на вашия terraform. Тези централизирани услуги улесняват управлението, одита и одобрението на промените в terraform.
Вие ли не пишете тестове?
Инженерите признават, че кодът трябва да се тества, но често пренебрегват проверки, работейки с Terraform. За инфраструктурата това може да доведе до подводни камъни. Препоръчвам да "тестирате" или "създавате примери" за стекове с използване на модули, които могат да бъдат коректно внедрени за проверка по време на CI/CD.
Terraform и микросервиси
Животът и смъртта на компаниите, основаващи се на микросервиси, зависят от скоростта, обновлението и разрушаването на нови работни стекове с микросервиси.
Най-широко разпространеното негативно усещане, свързано с микросервисните архитектури и от което никога не успяваме да се избавим, е свързано с работата, а не с кода. Ако разглеждате Terraform само като начин за автоматизиране на инфраструктурната страна на микросервисната архитектура, лишавате се от истинските предимства на тази система. Вече .
Източник: habr.com
