Terraform vs. Ansible: Hangisine Gerçekten İhtiyacın Var?

Infrastructure as Code'a yeni başlayanlar bunu genellikle iki şekilde sorarlar: "önce hangi aracı öğrenmeliyim" veya "neden takımlar her ikisini de kullanıyor." Kısa cevap şu: Terraform ve Ansible farklı sorunları çözer ve çoğu production ortamında birini seçmek yerine ikisini birlikte kullanır.

Terraform gerçekten ne için var

Terraform bir provisioning aracıdır. Hangi altyapının mevcut olması gerektiğini beyan eder: bir VPC, üç EC2 instance'ı, bir RDS veritabanı, belirli bir policy'ye sahip bir S3 bucket. HCL'de son durumu tanımlar, değişecekleri görmek için terraform plan çalıştırırsınız, sonra bunu gerçekleştirmek için terraform apply çalıştırırsınız. Terraform konfigürasyonunuzu cloud sağlayıcısındaki gerçek kaynak ID'lerine eşleyen bir state dosyası tutar (yerel olarak veya DynamoDB locking'i olan S3 bucket gibi bir backend'de).

Buradaki güç, sağlayıcılar arasında dependency resolution'dır. Terraform'a bir security group oluşturmasını ve ardından bunu bir EC2 instance'a eklemesini söylerseniz, sırayı otomatik olarak belirler. Ayrıca AWS, Azure, GCP, Cloudflare, Datadog ve düzinelerce başka sağlayıcı arasında aynı workflow'da çalışır, bu da altyapınız birden fazla vendor'ı kapsadığında önemlidir.

Terraform, makine var olduktan sonra içinde gerçekleşen her şeyde zayıftır. Package yüklemez, config dosyalarını düzenlemez veya hizmetleri anlamlı bir şekilde yeniden başlatmaz. remote-exec gibi provisioner'lar var ama HashiCorp kendisi bootstrap'in ötesinde hiç bir şey için bunlardan kaçınılmasını tavsiye eder.

Ansible gerçekten ne için var

Ansible bir configuration management aracıdır. SSH üzerinden (Windows için WinRM) bağlanır ve zaten mevcut olan makinelere karşı görevler çalıştırır: nginx kurmak, bir config dosyasını şablonlaştırmak, bir kullanıcı oluşturmak, bir hizmeti yeniden başlatmak, bir cron işinin mevcut olduğunu uygulamak. Playbook'lar YAML'dir ve modüller tasarım gereği idempotent'tir, bu nedenle aynı playbook'u iki kez çalıştırmak sistem zaten istenen durumla eşleşiyorsa ikinci sefer hiç bir şeyi değiştirmemelidir.

Ansible'ın hedef hostlara kurulu aracılara ihtiyacı yoktur, sadece Python ve SSH erişimi gerekir, bu da onu mevcut altyapıya eklemeyi kolaylaştırır. Ayrıca kesinlikle "provisioning" olmayan orchestration görevlerinde de iyidir — bir filo genelinde rolling restarts, blue-green deploy adımları, bir host'ta database migration çalıştırıp ardından bir load balancer'ı güncellemek.

Çakıştıkları ve insanları kafa karıştırdığı yerler

Her iki araç da teknik olarak biraz diğerinin işini yapabilir. Ansible'ın altyapı döndürebilen cloud modülleri vardır (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine). Terraform'ın yeni bir instance'da shell komutları çalıştırabilen provisioner'ları vardır. Ancak provisioning için Ansible kullanmak, Terraform'un state tracking'ini ve plan/diff workflow'unu terk etmek anlamına gelir ve configuration için Terraform provisioner'larını kullanmak, idempotent ve tekrarlanabilir configuration management'i terk etmek anlamına gelir.

Çoğu takımın başvurduğu pratik bölüm:

• Terraform altyapıyı oluşturur: ağlar, compute instance'ları, load balancer'lar, managed veritabanları, IAM roller.
• Ansible üzerine olanları yapılandırır: yazılım kurulumları, kullanıcılar, config dosyaları, hizmet durumu, uygulama deployment adımları.

Devir işleminin somut bir örneği

AWS'de bir load balancer'ın arkasında üç web server kurduğunuzu varsayın.

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 instance'ları oluşturur ve IP'lerini çıkarır. Bu output'u dinamik bir Ansible inventory'sine aktarabilirsiniz (amazon.aws.aws_ec2 inventory plugin'i EC2 etiketlerini doğrudan okur, manuel copy-paste'e gerek yok) ve ardından şunu çalıştırabilirsiniz:

ansible-playbook -i aws_ec2.yml site.yml

burada site.yml nginx kurar, uygulama config'ini koyar ve hizmeti başlatır. Terraform asla nginx'e dokunmaz. Ansible asla VPC'ye dokunmaz. Her araç kendi şeridinde kalır ve her biri diğerinin çatışmayan kendi state/idempotency modeline sahiptir.

Kaçınılması gereken yaygın hatalar

Terraform state'i git'de saklamak en yaygın erken hatadır — state dosyaları secret'lar içerebilir plaintext'te ve merge conflict'lerine neden olabilir ve altyapı modelinizi bozabilir. Birinci günden itibaren remote backend kullanın.

Ansible ile hata, aslında idempotent olmayan playbook'lar yazmaktır — uygun bir modüle sahip şeyler için shell veya command modüllerini kullanmak (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) zaten check-then-act logic'ini doğru şekilde işler.

Neyi öğreneceğine karar veriyorsan: cloud provisioning ve multi-environment kurulumları yapıyorsan Terraform'u öğren, zaten sahip olduğun server'lardaki config drift'i yönetiyorsan Ansible'ı öğren. Çoğu DevOps rolü ilk yıl içinde her ikisine de aşinalık bekler.

State management, dynamic inventory'ler ve bu araçların etrafında tam bir CI/CD pipeline kurmak hakkında daha fazla bilgi için Korra Studio'da ilgili DevOps ve Cloud segmentlerini kontrol edin.