IaaC з terraform це круто і зручно, але в той же час і складно. В процесі роботи виникає багато проблем, рішення яких не очевидні і не описані в документації. Сьогодні я хочу поговорити про такі проблеми та як їх уникнути (на прикладі azure).
Мене звуть БМ, і я працюю з проектами, які стосуються різних варіацій IaaC більше двох років. Давайте починати.
Уявимо абстрактну компанію, яка використовує azure, та інфраструктура якої виглядає ось так
Пройтись по компонентам і зв*язкам
Компоненти можуть розроблятись і, відповідно, розгортають окремо, є сенс описувати кожен окремим модулем.
Але що робити у випадку, коли треба зчитати якесь значення, яке генерується в модуді бекенд, наприклад з модуля бекофіс.
Це значення може бути апі енндоінтом, ключем, сертифікатом і т д
Є два рішення
Тераформу необхідно зберігати дані про вашу інфраструктуру та конфігурацію. Стейт використовується тераформом для того щоб зберігати інформацію про зв*язок реальних ресурсів і ваших модулів, метадату та для інших цілей. Це означає, що всі динамічно згенеровані значення зберігаються в стейті, і цим можна скористатись.
Як виглядає в коді (Т)
Для цього потрібно описати датасорс
і окрім всього, може статись (Т)
Альтернатива цьому підходу – Key-Value шина
Підхід полягає в тому, щоб використовувати якийсь KV (приклад) для запису аутпутів і їх зчитування
Ось як виглядає (Т)
Без kv – великі vars файли в сорс контролі або костилі
З – централізований сторедж
уявіть що проект тільки стартує ....
(Т)
Давайте розглянемо приклад
Всі модулі приймають уніфікований список параметрів (решта в kv)
Бувають ситуації, коли потрібно розбивати на окремі модулі
Наприклад ...
Потрібно уніфіковано запускати
(Т)
Цю проблему можна вирішити за допомогою терагрант
Террагрант – це врапер, який дозволяє адекватно ...
Адекватний спосіб описувати georedundant серидовища
Зручно розділити ресурси по модулям
Ще одна проблема, яку може вирішити такий підхід до організації модулів – деплоймент стратегія для продакшн
Звісно, можна
Але
З вище описаною організацією модулів, можна зробити rolling update з можливістю протестувати перед тим, як повернути в балансувальник навантаження
Якщо інфраструктура описється кодом – деплоймент повинен бути такий же, як для коду
Одне з питань, яке може виникнути – хто повинен бути оунером коду , та кому можна контрібютити
Хашикорп рекомендує
Але хто ж
Невизначеність може привести до двох крайностей
Вихід є: Оунер той – хто найчастіше міняє
Хашикорп рекомендує
Різні види інфраструктури (легісі, cloud-native з функціями і т д, AKS)
Немає чіткого алгоритму
Оунер той – хто найчастіше міняє