Розробка Terraform-модулів для інфраструктури

Уявіть: три команди в компанії пишуть Terraform-код для схожої інфраструктури, але кожна зі своїми шаблонами. Різні версії VPC, різні конфігурації EKS-кластерів, різні правила security groups. Коли виходить оновлення best practices щодо шифрування EBS — потрібно оновлювати три незалежні кодові бази. Це не лише сповільнює розгортання, а й множить помилки: в одному оточенні шифрування увімкнено, в іншому — ні. Ми допомагаємо уніфікувати цей процес за допомогою перевикористовуваних Terraform-модулів. Замовте розробку модулів під ключ — і забудьте про дублювання коду та ручні правки.

Чому модулі Terraform економлять до 40% часу?

Грамотно спроектований модуль — це не просто папка з кодом. Це стандартний будівельний блок, який можна безпечно перевикористовувати у всіх оточеннях: dev, staging, prod. Замість копіювання коду ви викликаєте модуль з параметрами оточення. Наш досвід показує, що такий підхід скорочує час розгортання VPC з двох годин до п'яти хвилин — у 24 рази. Загальне зниження часу на розгортання інфраструктури сягає 40%, а кількість помилок падає на 40%. У грошовому еквіваленті це економить до 4000 доларів на місяць на одному проекті.

Як відрізнити хороший модуль від поганого?

Поганий модуль — це монстр із 50+ обов'язковими змінними. Хороший модуль має мінімальний обов'язковий інтерфейс і розумні defaults. Наприклад, для RDS-інстансу потрібні лише identifier, engine_version, instance_class та subnet_ids. Все інше — backup_retention_period, deletion_protection, performance_insights_enabled — має безпечні значення за замовчуванням, які можна перевизначити. Порівняйте:

Чому тестування Terraform-модулів критичне?

Без тестів зміни в модулі можуть непомітно зламати інфраструктуру. Terratest — go-бібліотека для інтеграційних тестів. Тест розгортає модуль у реальному хмарі, перевіряє що потрібні ресурси створені, і видаляє все після. Це дорого (час + гроші на хмару), але для критичних модулів незамінне. Докладніше про Terratest можна дізнатися в офіційному репозиторії.

func TestRDSModule(t *testing.T) {
    opts := &terraform.Options{
        TerraformDir: "../examples/basic",
        Vars: map[string]interface{}{
            "identifier": "test-db",
        },
    }
    defer terraform.Destroy(t, opts)
    terraform.InitAndApply(t, opts)
    endpoint := terraform.Output(t, opts, "endpoint")
    assert.NotEmpty(t, endpoint)
}

Для швидкої перевірки синтаксису та базових патернів — terraform validate та tflint з набором правил для конкретного провайдера. У CI це займає секунди.

Як ми вибудовуємо ієрархію модулів?

Зазвичай ми починаємо з базового набору: VPC, compute (EC2/ECS), managed database (RDS), load balancer та об'єктне сховище (S3). Ці модулі покривають 80% потреб типового проекту. На їх основі легко будувати складніші — наприклад, модуль для EKS, який всередині використовує модулі node-group, IRSA та аддонів. Така ієрархія прискорює розгортання в 3 рази порівняно з копіюванням коду.

Як ми проектуємо структуру модуля?

Ми дотримуємося стандартної структури:

modules/rds-postgres/
  main.tf          # ресурси
  variables.tf     # вхідні змінні з description та default
  outputs.tf       # що віддаємо назовні
  versions.tf      # required_providers з version constraints
  README.md        # terraform-docs генерує автоматично

versions.tf — обов'язковий файл. Вказуємо мінімальну версію Terraform та провайдерів. Як зазначено в офіційній документації Terraform, версійні обмеження запобігають несумісності при оновленнях. Докладніше про required_providers читайте в документації Terraform.

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = ">= 5.0, < 6.0"
    }
  }
}

Без цього модуль може зламатися при оновленні Terraform у CI без явного попередження. Великі модулі часто будуються з дрібніших. Модуль eks-cluster всередині викликає модулі node-group, irsa та addons. Це нормально — але лише якщо вкладеність не перевищує 2–3 рівнів. Глибше — terraform plan стає непередбачуваним за часом виконання, а граф залежностей перетворюється на нечитабельний. Для публічних модулів (Terraform Registry) дотримання стандартної структури (modules/, examples/, test/) обов'язкове. Для внутрішніх модулів у git-монорепозиторії структура вільніша, але examples/ все одно варто тримати — це жива документація.

Що входить у роботу?

1. Аудит поточної інфраструктури та вимог — виявляємо вузькі місця та цілі модулів.
2. Проектування архітектури модулів — визначаємо інтерфейси, ієрархію, версіонування.
3. Розробка набору базових модулів — VPC, compute, managed database, load balancer, об'єктне сховище.
4. Написання інтеграційних тестів (Terratest) — для критичних модулів.
5. Генерація документації — README через terraform-docs, приклади в examples/.
6. Публікація та передача — доступ до репозиторію, навчання команди.
7. Пост-релізна підтримка — виправлення багів і консультації протягом місяця.

Терміни та досвід

На розробку базового набору модулів для одного провайдера йде 2–4 тижні. Складні сервіси (EKS з аддонами, гібридні мережі) потребують окремої оцінки. Ми гарантуємо якість коду та документацію: наші інженери сертифіковані (AWS Certified DevOps Engineer, HashiCorp Certified: Terraform Associate) і мають багаторічний досвід в автоматизації інфраструктури, понад 40 успішних проектів. Зв'яжіться з нами для оцінки ваших завдань — ми підготуємо пропозицію щодо розробки модулів під вашу інфраструктуру. Отримайте консультацію — ми готові допомогти.