Питання "Ansible чи Terraform" виникає у кожного, хто вперше автоматизує розгортання серверів. Коротка відповідь: це різні інструменти для різних завдань, і в реальних проєктах вони майже завжди працюють разом. Terraform створює інфраструктуру — сервер, диск, мережу, а Ansible налаштовує те, що вже створено. Розберемо, де проходить межа і як зібрати з двох інструментів один робочий конвеєр.

Чим принципово відрізняються Ansible і Terraform

Terraform — інструмент для керування інфраструктурою як кодом. Він описує кінцевий стан: скільки потрібно серверів, з якими дисками, в якій мережі, і сам вирішує, що створити, змінити або видалити, щоб прийти до цього стану. Ansible — інструмент конфігураційного керування. Він не створює сервери сам по собі, а виконує на вже наявних машинах послідовність кроків: поставити пакет, покласти файл, перезапустити службу.

Межа проста: Terraform відповідає на питання "скільки серверів і які" — VDS, диски, приватна мережа, правила фаєрволу у провайдера. Ansible відповідає на питання "що всередині сервера" — який веб-сервер, яка версія PHP, які користувачі та cron-завдання.

Коли обирати Terraform

Terraform потрібен, якщо інфраструктура описується через API хмарного провайдера: замовлення VDS, прив'язка плаваючої IP, налаштування приватної мережі між серверами, створення балансувальника навантаження. Якщо завтра потрібно підняти другий такий самий кластер серверів в іншому регіоні, Terraform зробить це за одну команду.

Замовлення та видалення серверів через API провайдера без ручних кліків у панелі
Версіювання інфраструктури в git — зміни видно в diff перед застосуванням
Відтворюваність: staging і production збираються з одного набору файлів

Коли обирати Ansible

Ansible потрібен там, де сервери вже існують і їх треба привести до однакового стану: встановити nginx і PHP-FPM, розгорнути SSH-ключі, налаштувати firewall на рівні ОС, застосувати оновлення безпеки. Йому не важливо, звідки взявся сервер — з Terraform, з ручного замовлення в панелі ZevsHost чи зі старого парку заліза.

Налаштування ПЗ і служб на серверах, які вже існують
Масове застосування змін на десятках серверів однією командою
Завдання, які не описуються терміном "інфраструктура": деплой коду, ротація логів, оновлення сертифікатів

Декларативний і процедурний підхід: різниця на практиці

Terraform декларативний: файл описує бажаний стан, а не перелік кроків. Запустили terraform apply двічі поспіль без змін у файлах — вдруге нічого не станеться. Ansible процедурний за структурою плейбука, але ідемпотентний по кожному модулю: модуль apt не перевстановить вже встановлений пакет, а модуль copy не перезапише файл з тим самим вмістом.

Критерій	Terraform	Ansible
Що описує	Ресурси хмари: сервери, диски, мережі	Стан ОС і застосунків на сервері
Модель	Декларативна, з файлом стану	Послідовність завдань за інвентарем
Зберігання стану	state-файл, зазвичай у S3 чи Terraform Cloud	Стан не зберігається, перевіряється під час кожного запуску
Швидкість правки одного параметра	Вимагає apply, може перестворити ресурс	Точковий запуск playbook на потрібний хост

Як пов'язати Terraform і Ansible в одному конвеєрі

Стандартна схема: Terraform створює сервер і виводить його IP-адресу через output, Ansible бере цю адресу як inventory і налаштовує сервер. Провайдер VDS для прикладу — Hetzner Cloud, але схема працює з будь-яким провайдером, у якого є API.

resource "hcloud_server" "web" {
  name        = "web-01"
  server_type = "cx22"
  image       = "ubuntu-24.04"
  ssh_keys    = [hcloud_ssh_key.main.id]
}

output "web_ip" {
  value = hcloud_server.web.ipv4_address
}

Далі динамічний inventory для Ansible збирається з виводу Terraform однією командою, а сам плейбук ставить базовий набір пакетів:

- hosts: web
  become: true
  tasks:
    - name: Встановити nginx і PHP-FPM
      apt:
        name: ["nginx", "php-fpm"]
        state: present
        update_cache: true
    - name: Запустити і увімкнути nginx
      service:
        name: nginx
        state: started
        enabled: true

Далі процес — від замовлення сервера до готового до роботи середовища — зазвичай оформляють окремим етапом у конвеєрі GitLab CI: спочатку джоба з terraform apply, потім джоба з ansible-playbook, яка отримує адресу з артефактів першого кроку. Детальніше про спільний опис інфраструктури в коді дивіться у статті про Terraform для VPS.

Поширені помилки при спільному використанні

Перша помилка — дублювання відповідальності: частину налаштування сервера прописують через cloud-init всередині Terraform, а частину — через Ansible, і за півроку ніхто не пам'ятає, де що міняти. Друга — зберігання state-файлу Terraform локально на ноутбуці розробника без резервної копії: при втраті файлу Terraform перестає розуміти, що вже створено, і намагається створити ресурси заново.

Змішування завдань налаштування ОС між cloud-init і Ansible в одному проєкті
Локальний state-файл Terraform без віддаленого бекенду і блокувань
Запуск Ansible без попередньої перевірки playbook у режимі --check

Підсумок: короткий чекліст вибору

Якщо треба керувати серверами, дисками і мережами у провайдера — беріть Terraform. Якщо треба налаштувати те, що вже працює, — беріть Ansible. У більшості проєктів обидва інструменти використовуються разом, кожен у своїй зоні відповідальності.

Інфраструктура хмари та її версії в git — Terraform
Пакети, конфіги і служби всередині сервера — Ansible
State Terraform зберігати віддалено, з блокуванням
Пов'язувати обидва кроки одним конвеєром CI, а не запускати вручну

Ansible чи Terraform: що обрати і коли поєднувати