AWS CloudFormation і Terraform – не знаєте, що вибрати? Ця стаття допоможе вам прийняти розумне рішення.
Хмарні обчислення зробили революцію у світі DevOps. Це вже не просто модне слово; він тут, і він тут, щоб змінити спосіб розробки та підтримки наших програм. Хоча є незліченна кількість причин, чому ви повинні використовувати хмарні обчислення для будь-якого масштабу бізнесу, є невелике обмеження, ви повинні створити свою інфраструктуру вручну.
Ви повинні зайти на консолі своїх хмарних провайдерів і сказати їм, чого саме ви хочете. Це добре працює для невеликих випадків використання, але що, якщо різні люди вносять зміни в конфігурацію консолі. Ви можете отримати надскладну інфраструктуру, яку буде ставати все важче і важче підтримувати. Не існує ефективного способу співпраці чи відстеження змін інфраструктури в хмарі. Ну насправді є. Інфраструктура як код.
Інфраструктура як код є дуже популярним терміном у хмарних обчисленнях. Це процес керування вашою ІТ-інфраструктурою за допомогою коду. Так це правильно. Замість того, щоб йти на консоль і робити все вручну; Інфраструктура як код, вона ж IAAC або IAC, дозволяє писати файли конфігурації, які потім забезпечують вашу хмарну інфраструктуру. IAC дає нам такі переваги, як послідовність, просте та швидке обслуговування та відсутність місця для людських помилок.
Використання IAC з Amazon Web Services
AWS є провідною службою хмарних обчислень у світі, яка має вдвічі більшу частку ринку, ніж наступний після неї постачальник хмарних обчислень. На AWS є понад 200 сервісів, які можуть задовольнити сотні й тисячі випадків використання.
Починаючи використовувати IAC з AWS, ви часто звузите свій вибір до AWS CloudFormation і інструмент з відкритим кодом, Тераформа. Коли ви намагаєтесь зробити вибір між цими двома, розуміння безлічі функцій, які пропонують обидва інструменти, може бути досить важким. У цій статті ми розглянемо відмінності між AWS CloudFormation і Terraform, щоб допомогти вам вирішити, який інструмент краще відповідає вашим потребам.
Terraform проти AWS CloudFormation: відмінності
Модульність
При використанні IAC у великих організаціях модульність може бути важливим фактором для вибору правильного інструменту.
CloudFormation
CloudFormation не має вбудованої підтримки модулів. Це дозволяє вам використовувати те, що називається вкладеними стеками, як модулі.
Наприклад, ви можете мати стандартну конфігурацію того, як ви хочете підготувати відро S3 у вашій організації. Отже, ви створюєте стандартний шаблон CloudFormation, який створює сегменти S3. Тепер, коли кінцевий користувач хоче створити сегмент S3, він може використовувати цей шаблон CloudFormation як вкладений стек і створити стандартний сегмент S3.
Існує також менш відомий сервіс AWS, the Каталог послуг AWS які можуть допомогти вам із модульністю вашої AWS CloudFormation. Каталог послуг – це служба AWS, розроблена спеціально для організацій, які хочуть обмежити обсяг послуг AWS, щоб відповідати вимогам до відповідності, безпеки, вартості або продуктивності. І вгадайте що? AWS Service Catalog використовує шаблони CloudFormation у серверній частині.
Давайте швидко зрозуміємо це на прикладі. Відра S3, якщо вони не використовуються належним чином, незабаром можуть стати катастрофічними для ваших конфіденційних даних. Візьмемо той самий приклад, ви хочете мати стандартний спосіб використання S3 у вашій організації. Перший варіант — це створити шаблон вкладеного стеку, який можна використовувати в інших стеках CloudFormation і є таким же хорошим.
Якщо ви не хочете, щоб користувачі використовували цей стандартний шаблон як вкладений стек, ви можете скористатися каталогом послуг AWS. Каталог послуг дозволить користувачам використовувати цей стандартний шаблон з інтерфейсу користувача консолі та вказувати деякі параметри для невеликих налаштувань. Це дозволить вам контролювати, як інфраструктура надається у ваших облікових записах AWS, і запобігати будь-яким небажаним сценаріям.
Тераформа
Terraform має вбудовану підтримку модулів. Це дозволяє створювати стандартні конфігурації, схожі на AWS CloudFormation, і використовувати їх в інших конфігураціях terraform.
Оскільки Terraform є інструментом з відкритим вихідним кодом, ви також можете знайти та використовувати деякі готові модулі з відкритим кодом у реєстрі Terraform. Ви також можете створювати власні модулі з власними конфігураціями та розміщувати їх у приватному реєстрі модулів.
Особисто я волів би використовувати Terraform замість CloudFormation, якби модульність була великою вимогою.
Використовувати вкладений стек у CloudFormation не так просто, як використовувати модулі в Terraform. Основним фактором є те, що передача даних із шаблону CFN у вкладений стек може бути досить складною.
Немає стандартного місця, де можна було б поділитися шаблонами CloudFormation. У вас є каталог послуг AWS, але це лише спосіб застосувати деякі правила для створення інфраструктури через консоль. Ми всі про код. Під час використання Service Catalog, хоча деякі складні завдання інкапсульовані файлами CloudFormation, вам все одно доведеться виконувати завдання вручну, переходячи на консоль і вказуючи параметри для створення вашої інфраструктури.
Terraform, з іншого боку, має встановлений метод створення, підтримки та спільного використання модулів. Ви можете побачити точні вимоги до модулів у реєстрі модулів Terraform і дуже легко використовувати їх у своїх файлах terraform.
Контроль та управління інфраструктурою
Якщо ви хочете обмежити ресурси, які ваші співробітники можуть створювати у ваших облікових записах AWS: AWS CloudFormation і Terraform надають вам засоби для цього.
Давайте спочатку поговоримо про CloudFormation. CloudFormation сам по собі не пропонує жодного контролю над використанням шаблонів, але ви можете використовувати політики AWS IAM, щоб дозволити лише користувачам вашого облікового запису AWS використовувати лише стандартні шаблони CloudFormation для створення ресурсів. У нашому прикладі відра S3 ви можете обмежити всі дозволи «S3 Create» для користувачів і дозволити їм створювати відра S3 лише з каталогу послуг AWS або вкладених стеків.
Terraform дозволяє вам контролювати, які ресурси можуть створювати ваші користувачі, використовуючи політику як інструмент коду Вартовий. Sentinel дає змогу застосовувати чіткі, засновані на логіці політики, щоб дозволяти або забороняти дії користувача через Terraform. Наприклад, ви можете заборонити всі ресурси, які створюють сегменти S3, і дозволити користувачам створювати сегменти S3 лише зі стандартного модуля.
Державне управління
І AWS CloudFormation, і Terraform повинні відстежувати ресурси, які вони обслуговують.
Terraform зберігає стан вашої інфраструктури у файлі стану. Цей файл зберігається локально за замовчуванням, однак ви можете зберегти його на віддалених серверах, як-от S3, і дозволити кільком користувачам вносити зміни до одного набору інфраструктури.
CloudFormation не підтримує файл стану, принаймні той, який ми можемо побачити. CloudFormation є керованою службою, тому вона виконує всі функції підтримки стану та перевірки у фоновому режимі.
І AWS CloudFormation, і Terraform мають засоби, за допомогою яких ви можете перевірити, які зміни будуть внесені у вашу інфраструктуру. У Terraform ви можете запустити команду – «plan terraform» і дізнатися, як Terraform планує застосувати ваші зміни конфігурації. У CloudFormation користувачі можуть переглядати цю інформацію через набори змін.
Мову
Terraform використовує мову конфігурації HashiCorp, HCL, мову, створену HashiCorp. Він дуже схожий на JSON з додатковими вбудованими функціями та можливостями.
Шаблони CloudFormation написані у форматах YAML або JSON
Логування та відкати
І AWS CloudFormation, і Terraform мають хороші можливості журналювання. З мого досвіду, помилки та проблеми були простими (здебільшого).
CloudFormation: за умовчанням CloudFormation відкочує всі ваші зміни у разі невдалої зміни стека. Це хороша функція, яку можна вимкнути для будь-яких цілей налагодження.
Terraform: Terraform не буде автоматично відкочувати ваші зміни в разі невдачі. Це не проблема, оскільки ви завжди можете запустити команду terraform delete, щоб видалити напівнадану конфігурацію та знову запустити Terraform.
Область застосування
Terraform не обмежується AWS Cloud. Найважливішим фактором при виборі між Terraform і CloudFormation є те, що Terraform підтримує інших хмарних провайдерів і сервісів.
Отже, якщо ви плануєте використовувати IAC для кількох хмарних платформ, Terraform — найкращий вибір. Хоча CloudFormation є потужним інструментом, він обмежений лише AWS. Використовуючи Terraform, ви можете налаштувати інфраструктуру та розгорнути свою програму на кількох хмарних платформах, тим самим зробивши вашу програму доступнішою та надійнішою.
Підтримка функцій
Зазвичай, оскільки AWS розгортає нові сервіси та функції, CloudFormation буде оновлено перед Terraform, оскільки це сервіс AWS. На даний момент обидва інструменти охоплюють більшість служб і функцій цих служб. Це може бути невеликим недоліком використання Terraform, однак у нас є рішення.
Ви також можете створити стек CloudFormation у своєму коді Terraform. Отже, якщо ви використовуєте Terraform і він не має функції, ви можете тимчасово налаштувати стек CloudFormation у своєму коді Terraform.
Технічна підтримка
Платний план технічної підтримки AWS також включає підтримку CloudFormation.
HashiCorp також оплачує технічну підтримку Terraform.
Висновок
І AWS CloudFormation, і Terraform є потужними та повністю розробленими інструментами. Наведені вище відмінності допоможуть вам прийняти зважене рішення щодо вибору інструменту відповідно до ваших вимог. Як особиста пропозиція: якщо ви плануєте використовувати кілька хмарних платформ у майбутньому або зараз використовуєте кілька хмар, вам слід використовувати Terraform як універсальний магазин для всіх ваших потреб. Якщо ви шукаєте інструмент IAC лише для AWS, AWS CloudFormation і Terraform — це чесна гра.
Якщо ви зацікавлені в навчанні Terraform, перегляньте ці онлайн-курси.