Представляти інфраструктуру у вигляді коду в текстовому форматі, що повторюється, — проста найкраща практика для систем, з якою не потрібно мишевозити. За цією практикою закріпилася назва. , і поки що є два популярних інструменти для його реалізації, особливо в 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 - це не просто код.
Code as Code
Адже є ще інфраструктура, на якій вона працює.
Інфраструктура як код
Але звідки вона? Як це контролювати? Де живе ваш код? Чи потрібний розробникам дозвіл на доступ?
Операції як код
Бути розробником ПЗ – це вам не просто код писати.
AWS не єдиний: ви, ймовірно, використовуєте інших провайдерів. SignalFx, PagerDuty або Github. Можливо, у вас є внутрішній сервер Jenkins для CI/CD або внутрішня інформаційна панель Grafana для моніторингу. Інфра як код вибирається з різних причин, і кожна з них однаково важлива для всього, що стосується програмного забезпечення.
Коли я працював у Twitch, ми прискорювали послуги всередині змішаних вбудованих систем Amazon і AWS. Ми створили та підтримали багато мікросервісів, збільшивши операційні витрати. Дискусії проходили приблизно так:
- Я: Блін, це багато жестів для розгону одного мікросервісу. Мені доведеться використати це сміття, щоб створити обліковий запис AWS (ми перейшли до 2 облікових записів мікросервіс), потім цей для налаштування сповіщень, цей для сховища коду, а цей для списку електронної пошти, а потім цей...
- лід: Давайте напишемо сценарій і добре.
- Я: Лади, але сам скрипт зміниться Потрібен буде спосіб, як перевірити, що всі ці вбудовані штуковини Amazon мають актуальний стан.
- лід: Звучить непогано. І ми напишемо для цього сценарій.
- Я: Чудово! А скрипту, напевно, ще треба буде задати параметри. Чи прийме він їх?
- лід: Хай бере, куди йде!
- Я: Процес може змінитися, втратиться зворотна сумісність. Потрібен якийсь семантичний контроль версій.
- лід: Чудова ідея!
- Я: Інструменти можна змінити вручну, всередині інтерфейсу користувача. Нам буде потрібний спосіб, як це перевіряти і виправляти.
…3 роки потому:
- лід: І ми отримали тераформу.
Мораль байки така: навіть якщо ви в усьому Amazon, ви все ще використовуєте щось не з AWS, і ці служби мають стан, який використовує мову конфігурації, щоб синхронізувати цей стан.
CloudFormation lambda vs git modules terraform
lambda - це рішення CloudFormation для питання логіки користувача. З лямбда можна або . Такий підхід є додатковими складнощами, яких немає в семантичному контролі версій модулів git у Terraform. Для мене найнагальнішою проблемою стало управління дозволами для всіх цих lambda (а це десятки акаунтів AWS). Іншою за важливістю стала проблема типу "що було раніше - курка чи яйце?": вона була пов'язана з кодом lambda. Сама ця функція — інфраструктура та код, і вона сама потребує моніторингу та оновлення. Останнім цвяхом у труну стала труднощі у семантичному оновленні змін коду lambda; ще потрібно було зробити так, щоб дії стека без прямої команди не змінювалися між запусками.
Пам'ятаю, якось захотілося мені створити канарковий деплой для середовища Elastic Beanstalk із класичним балансувальником навантаження. Найпростіше було б зробити друге розгортання для EB поруч із виробничим середовищем, зробивши ще крок: об'єднавши автоматично масштабовану групу канаркового деплою з 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 tags та semver при використанні модулів Terraform.
Виробничий сервіс запущений у вас на ноутбуці чи в датацентрі?
Hashicorp має інструменти на кшталт щоб запустити свою тераформу. Ці централізовані сервіси полегшують управління, аудит та схвалення змін terraform.
Ви не пишете контрольні роботи?
Інженери визнають, що код потрібно тестувати, але самі часто забувають про тестування, працюючи з Terraform. Для інфраструктури це загрожує підступними моментами. Моя порада полягає в тому, щоб «тестувати» або «створити зразки» стеків, використовуючи модулі, які можна правильно розгорнути для тестування під час CI/CD.
Terraform і мікросервіси
Життя та смерть мікросервісних компаній залежить від швидкості, оновлення та руйнування нових мікросервісних робочих стеків.
Найпоширеніший негативний аспект, пов’язаний з архітектурою мікросервісів, і який неможливо усунути, пов’язаний з роботою, а не з кодом. Якщо ви думаєте про Terraform як про спосіб автоматизації лише інфраструктурної сторони архітектури мікросервісів, то ви втрачаєте справжні переваги системи. Зараз вже .
Джерело: habr.com