Представянето на инфраструктура като код в повтарящ се текстов формат е проста най-добра практика за системи, които не изискват работа с мишки. Тази практика има име - и досега има два популярни инструмента за прилагането му, особено в AWS: и .
Сравняване на опит с Terraform и CloudFormation
Преди да дойде на (Известен още като ) Работих и използва Terraform в продължение на три години. На новото място също използвах Terraform с всички сили, а след това компанията натисна прехода към всичко а-ла Amazon, включително CloudFormation. Усърдно съм разработил най-добри практики и за двете и съм използвал и двата инструмента в много сложни работни процеси в цялата организация. По-късно, след внимателно претегляне на последиците от миграцията от Terraform към CloudFormation, се убедих, че Terraform вероятно е най-добрият избор за организацията.
Terraform Horrible
Бета софтуер
Terraform все още дори не е пуснал версия 1.0, което е добра причина да не я използвате. Промени се много, откакто го опитах за първи път, но тогава terraform apply често се разваля след няколко актуализации или просто след няколко години употреба. Бих казал, че „сега всичко е различно“, но... изглежда това казват всички, нали? Има промени, които са несъвместими с предишни версии, въпреки че са подходящи и дори изглежда, че синтаксисът и абстракциите на хранилищата на ресурси са това, от което се нуждаем. Изглежда, че инструментът наистина е станал по-добър, но... :-0
От друга страна, AWS свърши добра работа, поддържайки обратна съвместимост. Това вероятно е така, защото техните услуги често се тестват щателно в организацията и едва след това, преименувани, се публикуват. Така че „те се опитаха много“ е подценяване. Поддържането на обратна съвместимост с API за толкова разнообразна и сложна система като AWS е невероятно трудно. Всеки, който е трябвало да поддържа публични API, които се използват толкова широко, колкото са, трябва да разбере колко трудно е да се прави това толкова много години. Но поведението на CloudFormation, според мен, никога не се е променило през годините.
Запознайте се с крака... това е куршум
Доколкото знам, изтрийте ресурса аутсайдер CloudFormation стек от вашия CF стек не е възможен. Същото е и с Terraform. Тя ви позволява да импортирате съществуващи ресурси във вашия стек. Може да се каже, че функцията е невероятна, но с голямата мощност идва и голяма отговорност. Просто трябва да добавите ресурс към стека и докато работите с вашия стек, не можете да изтриете или промените този ресурс. Един ден се оказа обратен ефект. Един ден в Twitch някой случайно импортира нечия друга AWS група за сигурност в собствения си стек Terraform, без да прави никакви пакости. Въведох няколко команди и... групата за сигурност (заедно с входящия трафик) изчезна.
Terraform Great
Възстановяване от непълни състояния
Понякога 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 като код е избран по различни причини и всяка от тях е еднакво важна за всичко, свързано със софтуера.
Когато работех в Twitch, ускорихме услугите в смесените вградени и AWS системи на Amazon. Изработихме и подкрепихме много микроуслуги, увеличавайки оперативните разходи. Дискусиите протекоха по следния начин:
- Я: По дяволите, това са много жестове за овърклок на една микроуслуга. Ще трябва да използвам този боклук, за да създам акаунт в AWS (преминахме към 2 акаунта на микроуслуга), след това този за настройка на предупреждения, този за хранилище на кодове и този за имейл списък и след това този...
- Водя: Нека го напишем и добре.
- Я: Добре, но самият сценарий ще се промени. Ще ни трябва начин да проверим дали всички тези вградени gizmos на Amazon са актуални.
- Водя: Звучи добре. И ние ще напишем скрипт за това.
- Я: Страхотен! И скриптът вероятно ще трябва да зададе параметри. Ще ги приеме ли?
- Водя: Оставете го да вземе, където отиде!
- Я: Процесът може да се промени и обратната съвместимост ще бъде загубена. Ще бъде необходим някакъв вид семантичен контрол на версията.
- Водя: Великолепна идея!
- Я: Инструментите могат да се променят ръчно, в потребителския интерфейс. Ще ни трябва начин да проверим и поправим това.
…3 години по-късно:
- Водя: И имаме тераформа.
Поуката на историята е: дори ако вие до уши във всичко Amazon, все още използвате нещо, което не е от AWS, и тези услуги имат състояние, което използва език за конфигурация, за да поддържа това състояние в синхрон.
CloudFormation ламбда срещу git модули terraform
lambda е решението на CloudFormation за проблема с персонализираната логика. С ламбда може или . Този подход въвежда допълнителни сложности, които не присъстват в семантичната версия на Git модулите на Terraform. За мен най-належащият проблем беше управлението на разрешенията за всички тези потребителски ламбда (а това са десетки AWS акаунти). Друг важен проблем беше „какво дойде първо, кокошката или яйцето?“: той беше свързан с ламбда кода. Самата тази функция е инфраструктура и код и самата тя се нуждае от наблюдение и актуализации. Последният пирон в ковчега беше трудността при семантичното актуализиране на промените в ламбда кода; ние също трябваше да се уверим, че действията на стека без директна команда не се променят между изпълненията.
Спомням си, че веднъж исках да създам внедряване на Canary за средата Elastic Beanstalk с класически балансьор на натоварването. Най-лесното нещо, което можете да направите, би било да направите второ внедряване за EB до производствената среда, като направите крачка напред: комбиниране на групата за разгръщане на canary с автоматично мащабиране с 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. В Go - gofmt. Terraform има свои собствени: terraform fmt. Насладете му се за ваше здраве!
Ще използвате ли React без да знаете JavaScript?
Модулите Terraform могат да опростят част от сложната инфраструктура, която създавате, но това не означава, че изобщо не можете да се занимавате с нея. Искате да използвате Terraform правилно, без да разбирате ресурси? Вие сте обречени: времето ще мине и никога няма да овладеете Terraform.
Кодирате ли със сингълтони или инжектиране на зависимости?
Инжектирането на зависимости е призната най-добра практика за разработка на софтуер и се предпочита пред сингълтоните. Как е полезно това в Terraform? Виждал съм модули Terraform, които зависят от отдалеченото състояние. Вместо да пишете модули, които извличат отдалечено състояние, напишете модул, който приема параметри. И след това предайте тези параметри на модула.
Вашите библиотеки правят ли десет неща добре или едно нещо страхотно?
Библиотеките, които работят най-добре, са тези, които се фокусират върху една задача, с която се справят много добре. Вместо да пишете големи модули Terraform, които се опитват да направят всичко наведнъж, изградете части от тях, които правят едно нещо добре. И след това ги комбинирайте според нуждите.
Как правите промени в библиотеките без обратна съвместимост?
Един общ модул Terraform, подобно на обикновена библиотека, трябва по някакъв начин да съобщи промените на потребителите, без да е обратно съвместим. Досадно е, когато тези промени се случват в библиотеки, и е също толкова досадно, когато в модулите на Terraform се правят промени, които не са съвместими с обратна версия. Препоръчително е да използвате git тагове и semver, когато използвате модули Terraform.
Вашата производствена услуга работи ли на вашия лаптоп или в център за данни?
Hashicorp има инструменти като за да управлявате вашата тераформа. Тези централизирани услуги улесняват управлението, проверката и одобряването на промените в тераформата.
Не пишеш ли контролни?
Инженерите признават, че кодът трябва да бъде тестван, но самите те често забравят за тестването, когато работят с Terraform. За инфраструктурата това е изпълнено с коварни моменти. Моят съвет е да „тествате“ или „създавате примерни“ стекове, като използвате модули, които могат да бъдат разгърнати правилно за тестване по време на CI/CD.
Terraform и микроуслуги
Животът и смъртта на компаниите за микроуслуги зависи от скоростта, иновациите и прекъсването на новите работни стекове за микроуслуги.
Най-често срещаният негативен аспект, свързан с архитектурите на микросервизи и който не може да бъде елиминиран, е свързан с работата, а не с кода. Ако мислите за Terraform просто като за начин за автоматизиране само на инфраструктурната страна на архитектурата на микроуслуги, тогава пропускате истинските предимства на системата. Сега вече е .
Източник: www.habr.com