Представянето на инфраструктурата като код в повтарящ се текстов формат е проста, но най-добра практика за системи, с която не е нужно да се трудите. Тази практика е позната като , и за реализацията й, особено в 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.
Морала на баснята е следният: дори ако си по уши в целия AWS, все пак използваш нещо, което не е от AWS, и тези услуги имат състояние, което използва език за конфигурация, за да синхронизира това състояние.
CloudFormation lambda срещу 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 тагове и semver при използване на модулите Terraform.
Производственият сервиз ли е стартиран на вашия лаптоп или в датацентъра?
Hashicorp предлага инструменти като за стартиране на вашия terraform. Тези централизирани услуги улесняват управлението, одита и одобрението на измененията в terraform.
Не пишете ли тестове?
Инженерите признават, че кодът трябва да бъде тестван, но често пренебрегват проверките, работейки с Terraform. За инфраструктурата това може да има коварни последици. Препоръчвам да "тествате" или "създавате примери" за стекове с използване на модули, които могат да бъдат успешно внедрени за проверка по време на CI/CD.
Terraform и микросервиси
Животът и смъртта на компаниите с микросервиси зависят от бързината, обновленията и разрушаването на нови микросервизни работни стекове.
Най-разпространеният негативен момент, свързан с микросервисни архитектури и от който не може да се избегне, е свързан с работата, а не с кода. Ако приемете Terraform само като начин за автоматизиране на инфраструктурната страна на микросервисната архитектура, вие си отнемате истинските предимства на тази система. Вече е .
Източник: habr.com
