Terraform vs. Ansible: Który z nich naprawdę potrzebujesz?

Osoby nowe w Infrastructure as Code zwykle pytają na jeden z dwóch sposobów: "które narzędzie powinienem się nauczyć pierwszy" lub "dlaczego zespoły używają obu". Krótka odpowiedź to taka, że Terraform i Ansible rozwiązują różne problemy, a większość setupów produkcyjnych używa ich razem zamiast wybierać jeden.

Do czego Terraform jest naprawdę

Terraform to narzędzie do provisjoningu. Deklaruje, jaka infrastruktura powinna istnieć: VPC, trzy instancje EC2, baza danych RDS, bucket S3 z określoną polityką. Piszesz HCL opisujący stan końcowy, uruchamiasz terraform plan, aby zobaczyć, co się zmieni, a następnie terraform apply, aby to wykonać. Terraform przechowuje plik stanu (lokalnie lub w backendzie, takim jak bucket S3 z blokowaniem DynamoDB), który mapuje twoją konfigurację na rzeczywiste identyfikatory zasobów u dostawcy chmury.

Siła tutaj leży w rozwiązywaniu zależności między dostawcami. Jeśli powiesz Terraform, aby utworzył grupę bezpieczeństwa, a następnie przypisał ją do instancji EC2, sam określi porządek. Działa również na AWS, Azure, GCP, Cloudflare, Datadog i dziesiątkach innych dostawców przez ten sam workflow, co ma znaczenie, gdy infrastruktura obejmuje więcej niż jednego dostawcę.

Terraform nie radzi sobie z niczym, co dzieje się wewnątrz maszyny po jej utworzeniu. Nie instaluje pakietów, nie edytuje plików konfiguracyjnych ani nie restartuje usług w żaden znaczący trwały sposób. Provisioners, takie jak remote-exec, istnieją, ale sam HashiCorp rekomenduje ich unikać dla czegokolwiek poza bootstrappingiem.

Do czego Ansible jest naprawdę

Ansible to narzędzie do zarządzania konfiguracją. Łączy się przez SSH (lub WinRM dla Windows) i uruchamia zadania na maszynach, które już istnieją: instaluje nginx, aplikuje plik konfiguracyjny, tworzy użytkownika, restartuje usługę, egzekwuje, aby cron job był obecny. Playbooki to YAML, a moduły są idempotentne z projektu, więc uruchomienie tego samego playbooку dwukrotnie nie powinno zmienić niczego za drugim razem, jeśli system już odpowiada żądanemu stanowi.

Ansible nie potrzebuje agentów zainstalowanych na hostach docelowych, tylko Python i dostęp SSH, co ułatwia przyłączenie go do istniejącej infrastruktury. Radzi sobie też z zadaniami orkestracyjnymi, które nie są ściśle "provisioningiem" — stopniowe restartowanie na całej floty, etapy blue-green deploymentu, uruchomienie migracji bazy danych na jednym hoście, a następnie aktualizacja load balancera.

Gdzie się nakładają i gdzie ludzie się mylą

Oba narzędzia technicznie mogą robić trochę pracę drugiego. Ansible ma moduły chmurowe (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine), które mogą uruchomić infrastrukturę. Terraform ma provisioners, które mogą uruchamiać polecenia powłoki na nowej instancji. Ale użycie Ansible do provisioningu oznacza rezygnację ze śledzenia stanu Terraform i workflow plan/diff, a użycie Terraform provisioners do konfiguracji oznacza rezygnację z idempotentnego, powtarzalnego zarządzania konfiguracją.

Praktyczny podział, na który większość zespołów przychodzi:

• Terraform buduje infrastrukturę: sieci, instancje obliczeniowe, load balancery, zarządzane bazy danych, role IAM.
• Ansible konfiguruje, co jest na jej szczycie: instalacje oprogramowania, użytkownicy, pliki konfiguracyjne, stan usług, kroki deploymentu aplikacji.

Konkretny przykład przekazania

Powiedzmy, że stosujesz trzy serwery web za load balancerem na AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform tworzy instancje i wypisuje ich IP-y. Możesz podać to wyjście do dynamicznego inwentarza Ansible (plugin inwentarza amazon.aws.aws_ec2 odczytuje tagi EC2 bezpośrednio, bez ręcznego kopiowania) i następnie uruchomić:

ansible-playbook -i aws_ec2.yml site.yml

gdzie site.yml instaluje nginx, umieszcza konfigurację aplikacji i uruchamia usługę. Terraform nigdy nie dotyka nginx. Ansible nigdy nie dotyka VPC. Każde narzędzie pozostaje na swoim terenie, a każde ma swój własny model stanu/idempotencji, który nie koliduje z modelem drugiego.

Typowe błędy warte uniknięcia

Przechowywanie stanu Terraform w git to najczęstszy błąd na początku — pliki stanu mogą zawierać sekrety w postaci zwykłego tekstu i powodować konflikty merge, które uszkadzają twój model infrastruktury. Używaj backendów zdalnych od pierwszego dnia.

W Ansible błędem jest pisanie playbooków, które nie są faktycznie idempotentne — używanie modułów shell lub command do rzeczy, które mają właściwy moduł (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd), który już prawidłowo obsługuje logikę sprawdzania i działania.

Jeśli decydujesz, co się nauczyć pierwszy: naucz się Terraform, jeśli robisz provisioning chmury i setupy wielośrodowiskowe, naucz się Ansible, jeśli zarządzasz config driftem na serwerach, które już masz. Większość ról DevOps oczekuje znajomości obu w ciągu pierwszego roku.

Aby dowiedzieć się więcej o zarządzaniu stanem, dynamicznych inwentarzach i budowaniu pełnego potoku CI/CD wokół tych narzędzi, sprawdź powiązane segmenty DevOps i Cloud na Korra Studio.