Інфраструктура, яка живе у git, а не в чиїйсь голові

Terraform, Terragrunt та рев'юабельні зміни інфраструктури — повторювані між середовищами і провайдерами.

Надсилаючи форму, ви погоджуєтесь на комунікацію щодо вашого DevOps проєкту.

Infrastructure as Code для безпечних і повторюваних змін у хмарі

Infrastructure as Code має робити кожну зміну пояснюваною ще до того, як вона потрапить у хмару. Проте багато команд мають Terraform файли, але досі застосовують їх з ноутбуків, ділять state без володіння і виправляють drift у консолі провайдера.

Ми складаємо карту наявних ресурсів, акаунтів, середовищ і стейтів. Створену вручну інфраструктуру імпортуємо поетапно, а не знищуємо і створюємо заново. Ви отримуєте план міграції, який захищає production під час переведення інфраструктури під контроль версій.

Проєктуємо Terraform код, яким команда може володіти

Єдиний state-файл і роздутий root-модуль стають вузьким місцем із зростанням інфраструктури. Ми ділимо код за межами володіння і відмов: мережа, дані, Kubernetes, спільні сервіси та інфраструктура застосунків — відповідно до узгодженої DevOps архітектури.

Перевикористовувані Terraform модулі мають зрозумілі inputs і outputs. Версії провайдерів і модулів зафіксовані, оновлення проходять рев'ю, lock-файли комітяться. Документація живе поруч із кодом і пояснює призначення та залежності.

Ставимося до state як до production даних

Terraform state може містити топологію і чутливі значення. Ми налаштовуємо зашифровані віддалені бекенди з версіонуванням, контролем доступу, бекапами і підтримуваним локом.

Окремі стейти обмежують радіус ураження між середовищами та доменами інфраструктури. CI-джоби отримують обмежені короткоживучі хмарні креденшели замість постійних ключів. Процедури відновлення і force-unlock задокументовані для перерваних запусків.

Використовуємо Terragrunt там, де повторення стає ризиком

Terragrunt допомагає, коли ті самі модулі обслуговують кілька акаунтів, регіонів і середовищ. Ми використовуємо його, щоб централізувати конфігурацію remote-state, налаштування провайдерів і спільні inputs, залишаючи значення середовищ явними.

Залежності лишаються читабельними, а не перетворюються на ланцюжки скриптів. Ви отримуєте розкладку конфігурації, яка зменшує copy-paste без абстракцій, які ніхто не може відлагодити.

Перетворюємо кожну зміну на перевірювані докази

GitLab CI/CD або GitHub Actions запускає форматування, валідацію і TFLint перед формуванням Terraform plan — як частину вашої CI/CD автоматизації. Checkov або policy-правила можуть блокувати публічні сховища, необмежений мережевий доступ, відсутнє шифрування чи незатверджені класи ресурсів.

План додається до pull request, тож рев'юери бачать реальний вплив. Apply виконується з контрольованого пайплайна після апруву. Зміни в production більше не залежать від ноутбука з потрібними креденшелами.

Виявляємо drift до того, як він стане інцидентом

Заплановані плани порівнюють задекларовану конфігурацію з реальним станом хмари. Неочікувані зміни створюють findings, а не тихо стають новою нормою — і потрапляють у той самий потік моніторингу й алертів, за яким уже стежить команда.

Кожен пункт drift відкочується, імпортується або приймається через переглянуту зміну. Це зберігає аудитоване джерело правди й водночас дозволяє узгодити аварійні дії.

Що постачає V3 DevOps

Ви отримуєте Terraform модулі, конфігурацію Terragrunt, архітектуру remote-state, CI/CD воркфлоу, policy-перевірки, виявлення drift, документацію та runbooks для відновлення. Ми перевіряємо налаштування, змінюючи реальне non-production середовище перед передачею.

Результат — Infrastructure as Code, який ваша команда може рев'ювати і розвивати: середовища з'являються через змерджений pull request, зміни в хмарі відстежувані, а знання про інфраструктуру лишаються в Git, а не в голові одного інженера.

Terraform

  • Проєктування та структура модулів
  • Управління state та backend'ами
  • Дисципліна версій провайдерів
  • Виявлення drift

Terragrunt

  • DRY-описи середовищ
  • Remote state та блокування
  • Multi-account та multi-region конфігурації

Часті питання

Бо apply досі виконується з ноутбуків, state ділиться без володіння, а drift правиться в консолі провайдера. IaC означає, що кожна зміна пояснювана до потрапляння в хмару: рев'ю в Git, план у CI і apply з контрольованого пайплайна.

Готові зменшити хаос в інфраструктурі?

Почніть з DevOps аудиту або короткої консультації.