Terraform vs CloudFormation

© pexels.com

Този въпрос се появява от време на време - защо да използвате инструмент на трети страни, ако AWS има услуга, която по същество прави същото?

Вероятно има по-малко убедителни причини, отколкото преди, тъй като CloudFormation се подобри значително през последните няколко години. Ако обаче днес трябваше да избирам отново, мисля, че все пак бих се придържал към Terraform. Ето някои от причините за това.

език

Terraform използва HCL (език за конфигуриране на HashiCorp), разработен за постигане на баланс между четене на хората и удобен за работа с машини.

CloudFormation, от друга страна, използва или JSON, или YAML.

Като цяло YAML е значително по-лесен за четене и автор от JSON, но все пак ви принуждава да имате множество вложени обхвати и всичко върви ужасно погрешно, ако смесите отстъпи някъде. За разлика от тях, HCL обикновено има само една или две области (под обхват имам предвид всичко, което влиза вътре в къдравите брекети) и налага някои основни хигиена за форматиране, вдъхновена от Go, която улеснява очите.

Terraform има богат набор от низови интерполации и вградени функции, включително условни и (за да бъдат поддържани от скоро) цикли, които позволяват моделиране на доста сложна логика в DSL, без да се налага да прибягвате до напълно развит език за програмиране (въпреки че това може да се направи прозрачно с външни източници на данни). Вътрешните функции на CloudFormation са забележимо ограничени в сравнение.

Друго нещо в полза на Terraform е, че той улеснява повторното използване на кода с помощта на модули и ви дава много свобода на действие при структурирането на вашите проекти по начина, по който има най-голям смисъл за вас. CloudFormation поддържа вложени стекове, но като цяло трябва да запазите целия си инфраструктурен код в гигантски файл (или няколко) в едно хранилище на проекта, докато с Terraform можете да нарязвате и зарязвате, колкото искате. За обикновените хора работата с няколко 100-редови файла обикновено е много по-лесна, отколкото с един единствен файл с над 5 000 реда. Модулите могат да се съхраняват в GitHub или публичен регистър на модулите на Terraform Module и да бъдат лесно обобщени и споделяни в множество проекти.

състояние

Terraform запазва състоянието си във файл. Този файл може да бъде съхраняван на диск, ангажиран с контрола на източника (не се препоръчва), или да се съхранява в S3 или някаква система за управление на конфигурацията. Каквото и да изберете, трябва да сте сигурни, че няма да загубите или повредите своя държавен файл или случайно да не използвате състояние от производствена среда, докато разполагате за тестване. По-трудно е да се стреляте в крака след въвеждането на работни пространства (наричани по-рано „среди“), но в първите дни получихме няколко бойни белези, отнасящи се до състоянието на Terraform.

За разлика от тях CloudFormation работи на AWS инфраструктура и управлява състоянието за вас, така че всъщност не ви пука как става това. За разлика от Terraform, CloudFormation също се опитва да върне промените, ако те не могат да бъдат приложени (добре, освен ако не се заседнат в състояние UPDATE_ROLLBACK_FAILED ...). В допълнение, CloudFormation резервен може да получава сигнали от вашите ресурси, което дава възможност за изключително полезна опция за конфигуриране на подвижни актуализации за група с автоматично мащабиране. CloudFormation също няма нищо против, ако машина, която задейства разгръщане внезапно падна (както може да се случи с гъвкави CI / CD сървъри), докато Terraform ще трябва да се възстанови от частична актуализация.

Така че, в лицето на това, това изглежда като случай, при който CloudFormation печели. Ако копаем малко по-дълбоко, въпреки че ще видим, че държавният файл на Terraform е много мощна концепция и една от основните му търговски точки. Тя ни позволява да внасяме, приемаме или да се движим около ресурси, което означава, че можем да рефактираме инфраструктурата си по желание, без да се налага да разрушаваме и пресъздаваме ресурси.

Друго, което е възможно в Terraform, е управлението на конфигурацията. Всеки път, когато изпълняваме 'план за термоформа', той извлича най-новото действително състояние на инфраструктурата и го сравнява с желаното състояние, дефинирано в конфигурационните файлове, и известното състояние, което отразява действителното състояние, когато за последно бяхме изпълнили 'Terraform apply' и се съхранява в държавния файл. Ако нашата инфраструктура вече не съответства на желаното състояние (обикновено поради някои промени извън лентата), Terraform ще изчисли разликата и ще предложи да я върне в съответствие с описаното в нашата конфигурация, като върне ръчните промени. Докато поддържаме безсилни разгръщания, изпълняването на периодични планове на Terraform е удобен начин за откриване и възстановяване на конфигурацията, и всъщност е нещо, което се прави по график в нашите тръбопроводи за осигуряване на инфраструктура.

Междувременно CloudFormation ще остане блажено не наясно с каквито и да било промени, направени извън държавата. Опитайте този бърз експеримент.

Първо, разгърнете нов стек в CloudFormation, за да създадете нов VPC и група за сигурност без правила за навлизане:

След това отидете на уеб конзолата и добавете ръчно ново правило за въвеждане. Например, нека отворим нашия SSH порт за света, за да направим истинско бързо отстраняване на грешки, няма голяма работа, нали?

Какво може да се обърка с правило като това.

След това опитайте да актуализирате стека си в CloudFormation. Какво ще получите е тази грешка:

Изпълняването на набор от промени също не би открило тази промяна. Що се отнася до CloudFormation, нашата инфраструктура не се е променила.

Конфигурация

Параметрите позволяват повторно използване на един и същ шаблон в различни среди. Например, може да искате да използвате по-евтини EC2 екземпляри във вашата тестова среда и нещо по-мощно в производството.

CloudFormation поддържа до 60 параметъра, които трябва да бъдат предоставени по време на изпълнение. Има няколко начина за това. Най-простият начин е просто да предавате параметри един по един и да ги задавате по подразбиране на нещо разумно. Като алтернатива можете да доставяте параметри в насипно състояние от файл (трябва да сте сигурни, че предавате правилния файл), да импортирате стойности от изхода на друг стек или да ги четете от магазина на параметрите. Можете също така да решите да използвате раздел за картографиране и да търсите параметри по някакъв ключ (например по околна среда).

Тераформата е значително по-гъвкава от тази. Той има концепция за източници на данни, които осигуряват само за четене представяне на някакъв ресурс, което ви позволява да получите достъп до неговите свойства, без да влияете на състоянието му. Източниците на данни отварят широк спектър от възможности за интегриране на свързани стекове лесно и избягване на твърдо кодиране на необходимите параметри. Например, можете да получите достъп до свойства на външно управлявани ресурси (напр. Да намерите най-новия AMI), да приемате изходи от стека на CloudFormation, да използвате повторно атрибутите, изложени от други стекове на Terraform (като крайна точка за база данни или DNS запис) и ако това е не е достатъчно, пуснете някои персонализирани скриптове, които осигуряват необходимите стойности. Има само един източник на истина и тази истина е текущото състояние на инфраструктурата, а не моментната й снимка от преди време, както често се случва с конфигурационните файлове. Всички промени в даден ресурс се разпространяват към всички други ресурси, които зависят от него по време на следващото изпълнение на Terraform, без възможността дублирана стойност да бъде забравена някъде и в същото време да поддържа ясно разделяне на проблемите. Друго предимство е, че можете да използвате един и същ CI / CD тръбопровод за управление на всичките си проекти на Terraform, без да се притеснявате да предадете правилния набор от аргументи на всеки ресурс.

Тъй като Terraform е облачно-агностичен, можете да съставяте инфраструктурата си от различни облачни доставчици, заедно с ресурси от услуги на трети страни, като PagerDuty или New Relic. По същество Terraform ви предоставя удобен начин да управлявате цялата си инфраструктура като код, без да се налага да научавате отделни инструменти и синтаксис на конфигурация за всяка платформа и услуга.

Качество за живот (известен още като miscellanea)

Terraform валидира конфигурационните файлове, преди да се опитате да стартирате актуализациите. Той проверява не само дали всички файлове използват правилния синтаксис (CloudFormation има подобно валидиране), но и дали всички параметри са достъпни и конфигурацията като цяло е валидна.

В Terraform можете да (и трябва) да изпълните стъпка „план“, преди да приложите промени. Тази стъпка ви казва точно какво ще се промени и защо (с хубави цветове за зареждане!).

Този план показва, че Terraform ще трябва да унищожи и пресъздаде две хранилища на ECR, а причината за това е промяната в техните имена.

CloudFormation поддържа набори за промени, които са значително по-малко удобни за хората и трудно да се осмислят.

Terraform може автоматично да форматира код, като спомага за поддържането на последователен стил на кода и прави заявките за изтегляне по-лесни за четене. Умората от JSON (или сега YAML), която порази разработчиците на CloudFormation, е трудно да си представим с Terraform.

Нито Terraform, нито CloudFormation не покриват 100% от наличните AWS ресурси, но като цяло е известно, че Terraform поддържа нови налични ресурси месеци по-рано, отколкото са предоставени в CloudFormation. Всички нови функционалности на AWS трябва да имат REST API и SDK поддръжка за основните езици при пускането му. Поддръжката на CloudFormation, от друга страна, не е задължителна. В този случай грее софтуерът с отворен код, тъй като разработчиците на Terraform бързо влизат, за да добавят функционалността, която искат да използват.

заключение

Значи, всичко това означава ли, че Terraform винаги е по-добър от CloudFormation? Не точно. Има някои случаи на използване, при които използването на CloudFormation има повече смисъл.

Един от тези случаи е управление на кофата S3, използвана за съхранение на състояния на Terraform файлове. Създаването му ръчно дори не бива да се счита за опция, тъй като в този случай един от най-важните кодове във вашата инфраструктура би бил по същество неуправляем и неприемлив. Разбира се, можете да го предоставите в Terraform, но изглежда веднага да се превърне в проблем с пилешко и яйце - къде ще съхранявате държавния файл на кофата, използвана за съхраняване на държавните файлове? Единият вариант е да го ангажирате към система за контрол на източници, която може да работи добре, ако не правите чести промени в този ресурс, но като цяло не е най-добрата идея. CloudFormation може да бъде убедителна опция за овладяване на тази кофа, тъй като тогава не е нужно да се притеснявате изцяло за състоянието на файла. Алтернативно, наистина можете да го създадете в Terraform, като използвате първоначално локално състояние, след което добавете S3 задния текст, сочещ към същата кофа, която току-що е създадена. След като реинициализирате проекта си, като стартирате 'Terraform init', Terraform ще мигрира състоянието на файла към S3.

Друг случай на използване е функционалността за подвижни актуализации за групите за автоматично мащабиране. За съжаление, той е достъпен само като част от API на CloudFormation, така че няма друга опция, освен да го управлявате с помощта на CloudFormation. Като решение можете да обвиете този ресурс от стекове на CloudFormation в Terraform, за да имате най-доброто от двата свята. Можете да прочетете повече за настройката на подвижни актуализации в предишната ми публикация за надстройките на ECS клъстери.