Ansible vs Terraform w 2026: Infrastructure as Code i pytania rekrutacyjne DevOps

Porównanie Ansible vs Terraform to jedno z najczęściej pojawiających się pytań na rozmowach rekrutacyjnych DevOps, jednak samo sformułowanie problemu ujawnia nieporozumienie: te narzędzia rozwiązują różne problemy. Ansible 2.20 obsługuje zarządzanie konfiguracją i wdrażanie aplikacji, podczas gdy Terraform 1.15 zajmuje się provisioningiem zasobów infrastruktury. Zrozumienie, kiedy każde z nich sprawdza się najlepiej, gdzie się pokrywają i jak się uzupełniają, odróżnia doświadczonych inżynierów DevOps od tych, którzy dopiero zgłębiają podstawy.

Podejście deklaratywne vs proceduralne: fundamentalna różnica

Terraform stosuje podejście deklaratywne. Plik konfiguracyjny opisuje pożądany stan końcowy, a Terraform oblicza niezbędne zmiany, aby go osiągnąć. Sprawdza się to doskonale w przypadku infrastruktury, która musi być tworzona, modyfikowana lub usuwana jako całość.

# 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"]
  }
}

Uruchomienie terraform apply tworzy oba zasoby, jeśli nie istnieją, lub aktualizuje je zgodnie z konfiguracją. Ponowne uruchomienie bez zmian nie wykonuje żadnych operacji: Terraform porównuje konfigurację ze swoim plikiem stanu i stwierdza, że nie ma nic do zrobienia.

Ansible stosuje podejście proceduralne z zadaniami wykonywanymi w określonej kolejności. Chociaż moduły Ansible są często idempotentne (uruchomienie ich dwukrotnie daje ten sam wynik), sam playbook opisuje sekwencję działań, a nie stan końcowy.

# 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

Każde zadanie wykonuje się kolejno. Wzorzec notify/handler zapewnia pewne zachowanie deklaratywne: handler uruchamia się tylko raz na końcu, niezależnie od tego, ile zadań go wyzwoli.

Zarządzanie stanem: kluczowy temat rekrutacyjny

Terraform utrzymuje plik stanu, który mapuje konfigurację na rzeczywiste zasoby. Stan ten śledzi identyfikatory zasobów, zależności i metadane. Bez niego Terraform nie może określić, co istnieje ani co wymaga zmiany.

Ansible nie posiada odpowiednika pliku stanu. Łączy się z systemami docelowymi i wykonuje zadania, polegając na bieżącym stanie systemu i idempotentności modułów. Sprawia to, że Ansible jest prostszy na początek, ale trudniej śledzić zmiany w czasie.

Częste pytanie rekrutacyjne dotyczy bezpieczeństwa pliku stanu. Stan Terraform może zawierać wrażliwe dane: hasła do baz danych, klucze API, identyfikatory zasobów. Wdrożenia produkcyjne przechowują stan zdalnie (S3, Azure Blob, Terraform Cloud) z szyfrowaniem i kontrolą dostępu.

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

Tabela DynamoDB zapewnia blokowanie, uniemożliwiając dwóm inżynierom jednoczesną modyfikację stanu.

Kiedy używać każdego narzędzia

Terraform sprawdza się w provisioningu infrastruktury chmurowej: maszyn wirtualnych, zarządzanych baz danych, load balancerów, ról IAM, VPC. Automatycznie obsługuje zależności między zasobami i wspiera wszystkich głównych dostawców chmury poprzez spójną składnię HCL.

Ansible sprawdza się w konfiguracji istniejących systemów: instalacji pakietów, zarządzaniu użytkownikami, wdrażaniu kodu aplikacji, orkiestracji wieloetapowych deploymentów. Łączy się przez SSH (lub WinRM dla Windows) bez konieczności instalowania agentów na docelowych maszynach.

Strefa pokrywania się powoduje zamieszanie. Oba narzędzia mogą instalować oprogramowanie na VM. Terraform może używać provisionerów do uruchamiania skryptów po utworzeniu zasobu. Ansible może tworzyć zasoby chmurowe przez moduły takie jak amazon.aws.ec2_instance. Jednak używanie każdego narzędzia poza jego mocnymi stronami prowadzi do problemów z utrzymaniem.

Połączony workflow w środowisku produkcyjnym

Większość organizacji używa obu narzędzi razem. Terraform provisionuje infrastrukturę i generuje dane wyjściowe połączenia. Ansible konsumuje te dane wyjściowe do konfiguracji systemów.

# 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"
}

Pipeline CI/CD uruchamia najpierw Terraform, przechwytuje dane wyjściowe, dynamicznie generuje inventory Ansible, a następnie uruchamia playbooki na nowej infrastrukturze.

# 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"

To dynamiczne inventory odpytuje AWS bezpośrednio, grupując instancje według ich tagów. Nie wymaga ręcznego zarządzania adresami IP.

OpenTofu: fork, który zmienił krajobraz

HashiCorp zmienił licencję Terraform na Business Source License (BSL) w sierpniu 2023 roku. Społeczność odpowiedziała forkiem Terraform 1.5 do OpenTofu, teraz hostowanego pod Linux Foundation.

Na sierpień 2026, OpenTofu 1.11.6 pozostaje drop-in replacement dla większości workflow Terraform. Ta sama składnia HCL, ten sam ekosystem providerów, ten sam format stanu. OpenTofu dodał funkcje nieobecne w binarce open-source Terraform: szyfrowanie stanu, provider for_each i wczesną ewaluację zmiennych.

W kontekście przygotowań do rozmowy rekrutacyjnej, należy rozumieć różnicę licencyjną. BSL pozwala na użycie wewnętrzne, ale ogranicza budowanie konkurencyjnych produktów. Organizacje zaniepokojone vendor lock-inem lub z określonymi wymaganiami compliance mogą preferować licencję MPL 2.0 OpenTofu. Przejęcie HashiCorp przez IBM w grudniu 2024 dodało kolejną zmienną do dyskusji o relacjach z vendorami.

Częste pytania rekrutacyjne DevOps

P: Czy Ansible może zastąpić Terraform?

Nie skutecznie. Ansible może tworzyć zasoby chmurowe, ale brakuje mu zarządzania stanem. Uruchomienie tego samego playbooka dwa razy może utworzyć duplikaty zasobów. Plik stanu Terraform śledzi, co istnieje i oblicza minimalne zmiany. Ansible najlepiej sprawdza się w zarządzaniu konfiguracją.

P: Jak obsługiwać sekrety w Terraform?

Nigdy nie commituj sekretów do kontroli wersji. Używaj zmiennych środowiskowych, integracji z Vault lub menedżerów sekretów dostawców chmury. Oznaczaj zmienne jako wrażliwe, aby nie pojawiały się w logach:

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

P: Czym jest idempotentność Ansible?

Operacja idempotentna daje ten sam wynik niezależnie od tego, czy zostanie uruchomiona raz czy wielokrotnie. Moduł apt ze state: present instaluje pakiet, jeśli go brakuje, i nie robi nic, jeśli jest już zainstalowany. Pisanie idempotentnych playbooków zapobiega niezamierzonym zmianom przy ponownych uruchomieniach.

P: Jak testować kod infrastruktury?

Terraform: terraform validate sprawdza składnię, terraform plan podgląda zmiany, a narzędzia takie jak Terratest uruchamiają testy integracyjne. Ansible: ansible-lint wyłapuje problemy, tryb --check wykonuje dry run, a Molecule testuje role na kontenerach.

Aby pogłębić przygotowanie do rozmów o Terraform, warto zapoznać się z Terraform Interview Questions: Infrastructure as Code Complete Guide. Praktykę można zdobyć z modułami Terraform Basics i Ansible Configuration Management.

Kompatybilność wersji i ekosystem

Aktualne stabilne wersje na sierpień 2026:

Architektura kolekcji Ansible oddziela podstawową funkcjonalność od modułów specyficznych dla providerów. Kolekcja amazon.aws otrzymuje aktualizacje niezależnie od rdzenia Ansible. Ma to znaczenie przy pinowaniu wersji w pipeline'ach CI/CD.

Wersjonowanie providerów Terraform działa na podobnych zasadach. Pliki lock (terraform.lock.hcl) zapewniają spójność wersji providerów między członkami zespołu i systemami CI.

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

Wybór między nimi: framework decyzyjny

Pytanie rzadko brzmi: Ansible czy Terraform. Pytanie brzmi: które narzędzie obsługuje którą odpowiedzialność.

Pełny obraz tego, jak te narzędzia wpisują się w nowoczesne workflow wdrożeniowe, przedstawia artykuł CI/CD Pipeline Interview Questions.

Co powinni wiedzieć doświadczeni inżynierowie o Ansible i Terraform

• Terraform zarządza stanem infrastruktury deklaratywnie; Ansible konfiguruje systemy proceduralnie. Używanie obu razem daje łatwą w utrzymaniu infrastrukturę.
• Bezpieczeństwo pliku stanu ma znaczenie. Stan Terraform należy przechowywać zdalnie z włączonym szyfrowaniem i blokowaniem.
• OpenTofu zapewnia alternatywę dla Terraform na licencji MPL z dodatkowymi funkcjami. Migracja jest prosta dla większości workflow.
• Idempotentność nie jest automatyczna. Playbooki powinny dawać spójne wyniki przy powtórnych uruchomieniach.
• Dynamiczne inventory eliminuje ręczne zarządzanie hostami. Odpytywanie dostawców chmury bezpośrednio zwraca bieżącą infrastrukturę.
• Pinowanie wersji zapobiega niespodziankom. Wersje providerów należy blokować w Terraform; wersje kolekcji pinować w Ansible.
• Testowanie kodu infrastruktury wymaga różnych podejść: terraform plan do podglądu zmian, tryb --check dla dry run Ansible, frameworki testów integracyjnych dla obu.