Ansible vs Terraform у 2026: Infrastructure as Code та питання на співбесідах DevOps

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

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

Terraform використовує декларативний підхід. Конфігураційний файл описує бажаний кінцевий стан, а Terraform обчислює необхідні зміни для його досягнення. Це добре працює для інфраструктури, яку потрібно створювати, модифікувати або видаляти як єдине ціле.

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

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

Ansible використовує процедурний підхід із завданнями, що виконуються послідовно. Хоча модулі Ansible часто ідемпотентні (виконання їх двічі дає той самий результат), сам playbook описує послідовність дій, а не кінцевий стан.

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Кожне завдання виконується послідовно. Патерн notify/handler забезпечує певну декларативну поведінку: handler виконується лише один раз наприкінці, незалежно від того, скільки завдань його викликали.

Керування станом: критична тема для співбесід

Terraform підтримує файл стану, який відображає конфігурацію на реальні ресурси. Цей стан відстежує ідентифікатори ресурсів, залежності та метадані. Без нього Terraform не може визначити, що існує чи що потребує зміни.

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

Поширене питання на співбесіді стосується безпеки файлу стану. Стан Terraform може містити конфіденційні дані: паролі до баз даних, API-ключі, ідентифікатори ресурсів. Production-розгортання зберігають стан віддалено (S3, Azure Blob, Terraform Cloud) із шифруванням та контролем доступу.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Таблиця DynamoDB забезпечує блокування, запобігаючи одночасній модифікації стану двома інженерами.

Коли використовувати кожен інструмент

Terraform найкраще підходить для provisioning хмарної інфраструктури: віртуальних машин, керованих баз даних, load balancer'ів, IAM-ролей, VPC. Він автоматично обробляє залежності між ресурсами та підтримує всіх основних хмарних провайдерів через узгоджений синтаксис HCL.

Ansible найкраще підходить для конфігурації існуючих систем: встановлення пакетів, керування користувачами, розгортання коду застосунків, оркестрації багатоетапних deployment'ів. Він підключається через SSH (або WinRM для Windows) без необхідності встановлювати агенти на цільових машинах.

Зона перетину викликає плутанину. Обидва інструменти можуть встановлювати програмне забезпечення на VM. Terraform може використовувати provisioner'и для виконання скриптів після створення ресурсу. Ansible може створювати хмарні ресурси через модулі на кшталт amazon.aws.ec2_instance. Проте використання кожного інструмента поза його сильними сторонами призводить до проблем із підтримкою.

Об'єднаний workflow у production

Більшість організацій використовують обидва інструменти разом. Terraform створює інфраструктуру та виводить деталі підключення. Ansible споживає ці виводи для конфігурації систем.

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

CI/CD pipeline спочатку запускає Terraform, захоплює виводи, динамічно генерує inventory Ansible, а потім виконує playbook'и на новій інфраструктурі.

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Цей динамічний inventory безпосередньо запитує AWS, групуючи instance'и за їхніми тегами. Ручне керування IP-адресами не потрібне.

OpenTofu: форк, що змінив ландшафт

HashiCorp перелiцензував Terraform під Business Source License (BSL) у серпні 2023 року. Спільнота відповіла форком Terraform 1.5 у OpenTofu, тепер розміщений під Linux Foundation.

Станом на серпень 2026 року OpenTofu 1.11.6 залишається drop-in replacement для більшості workflow Terraform. Той самий синтаксис HCL, та сама екосистема provider'ів, той самий формат стану. OpenTofu додав функції, відсутні у бінарному файлі open-source Terraform: шифрування стану, provider for_each та раннє обчислення змінних.

Для підготовки до співбесіди важливо розуміти різницю в ліцензуванні. BSL дозволяє внутрішнє використання, але обмежує створення конкурентних продуктів. Організації, стурбовані vendor lock-in або з певними вимогами compliance, можуть віддати перевагу ліцензії MPL 2.0 OpenTofu. Придбання HashiCorp компанією IBM у грудні 2024 року додало ще одну змінну до обговорень відносин із постачальниками.

Поширені питання на співбесідах DevOps

П: Чи може Ansible замінити Terraform?

Не ефективно. Ansible може створювати хмарні ресурси, але йому бракує керування станом. Виконання того самого playbook'а двічі може створити дубльовані ресурси. Файл стану Terraform відстежує, що існує, та обчислює мінімальні зміни. Ansible найкраще використовувати для керування конфігурацією.

П: Як обробляти secrets у Terraform?

Ніколи не комітьте secrets до системи контролю версій. Використовуйте змінні середовища, інтеграцію з Vault або менеджери secrets хмарних провайдерів. Позначайте змінні як sensitive, щоб вони не з'являлися в логах:

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

П: Що таке ідемпотентність Ansible?

Ідемпотентна операція дає той самий результат незалежно від того, виконується вона один раз чи багаторазово. Модуль apt зі state: present встановлює пакет, якщо він відсутній, і не робить нічого, якщо вже встановлений. Написання ідемпотентних playbook'ів запобігає ненавмисним змінам при повторних виконаннях.

П: Як тестувати код інфраструктури?

Terraform: terraform validate перевіряє синтаксис, terraform plan переглядає зміни, а інструменти на кшталт Terratest виконують інтеграційні тести. Ansible: ansible-lint виявляє проблеми, режим --check виконує dry run, а Molecule тестує ролі на контейнерах.

Для глибшої підготовки до співбесід щодо Terraform рекомендується ознайомитися з Terraform Interview Questions: Infrastructure as Code Complete Guide. Практику можна отримати з модулями Terraform Basics та Ansible Configuration Management.

Сумісність версій та екосистема

Поточні стабільні версії станом на серпень 2026:

Архітектура колекцій Ansible відокремлює базову функціональність від модулів, специфічних для provider'ів. Колекція amazon.aws отримує оновлення незалежно від ядра Ansible. Це важливо при фіксації версій у CI/CD pipeline'ах.

Версіонування provider'ів Terraform слідує аналогічним принципам. Lock-файли (terraform.lock.hcl) забезпечують узгодженість версій provider'ів між членами команди та CI-системами.

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Вибір між ними: структура прийняття рішень

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

Повну картину того, як ці інструменти вписуються в сучасні workflow розгортання, представлено в статті CI/CD Pipeline Interview Questions.

Що повинні знати досвідчені інженери про Ansible та Terraform

• Terraform керує станом інфраструктури декларативно; Ansible конфігурує системи процедурно. Використання обох разом дає інфраструктуру, яку легко підтримувати.
• Безпека файлу стану має значення. Зберігайте стан Terraform віддалено з увімкненим шифруванням та блокуванням.
• OpenTofu забезпечує альтернативу Terraform з ліцензією MPL та додатковими функціями. Міграція проста для більшості workflow.
• Ідемпотентність не автоматична. Playbook'и повинні давати узгоджені результати при повторних виконаннях.
• Динамічний inventory усуває ручне керування хостами. Запитуйте хмарних провайдерів безпосередньо для отримання поточної інфраструктури.
• Фіксація версій запобігає сюрпризам. Блокуйте версії provider'ів у Terraform; фіксуйте версії колекцій в Ansible.
• Тестування коду інфраструктури вимагає різних підходів: terraform plan для перегляду змін, режим --check для dry run Ansible, фреймворки інтеграційного тестування для обох.