2026'da Ansible vs Terraform: Infrastructure as Code ve DevOps Mülakat Soruları

Ansible ve Terraform karşılaştırması: Infrastructure as Code perspektifinden temel farklar, pratik kullanım senaryoları ve 2026 DevOps mülakat soruları.

2026'da Ansible vs Terraform: Infrastructure as Code ve DevOps Mülakat Soruları

Ansible vs Terraform karşılaştırması DevOps mülakatlarında en sık sorulan sorulardan biridir, ancak sorunun kendisi bir yanlış anlamayı ortaya koymaktadır: bu araçlar farklı problemleri çözer. Ansible 2.20 konfigürasyon yönetimi ve uygulama dağıtımı ile ilgilenirken, Terraform 1.15 altyapı kaynaklarının provisioningini gerçekleştirir. Her birinin ne zaman üstün olduğunu, nerede örtüştüklerini ve nasıl birbirlerini tamamladıklarını anlamak, kıdemli DevOps mühendislerini henüz temelleri öğrenenlerden ayırır.

Temel Ayrım

Terraform altyapı durumunu deklaratif olarak yönetir (VM'ler, ağlar, veritabanları). Ansible bu altyapı üzerinde çalışanları prosedürel olarak yapılandırır (paketler, servisler, dosyalar). Çoğu üretim ortamı her ikisini birden kullanır.

Deklaratif vs Prosedürel: Temel Fark

Terraform deklaratif bir yaklaşım kullanır. Bir konfigürasyon dosyası istenen son durumu tanımlar ve Terraform buna ulaşmak için gerekli değişiklikleri hesaplar. Bu, bir bütün olarak oluşturulması, değiştirilmesi veya silinmesi gereken altyapı için iyi çalışır.

hcl
# 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 komutunu çalıştırmak, her iki kaynağı da yoksa oluşturur veya konfigürasyona uygun şekilde günceller. Değişiklik olmadan tekrar çalıştırmak hiçbir işlem üretmez: Terraform konfigürasyonu durum dosyasıyla karşılaştırır ve yapılacak bir şey bulamaz.

Ansible, görevlerin sırayla yürütüldüğü prosedürel bir yaklaşım kullanır. Ansible modülleri genellikle idempotent olsa da (iki kez çalıştırmak aynı sonucu üretir), playbook'un kendisi son durumu değil, bir eylem dizisini tanımlar.

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

Her görev sırayla çalışır. notify/handler kalıbı bazı deklaratif davranışlar sağlar: handler, kaç görev tetiklerse tetiklesin sonunda yalnızca bir kez çalışır.

Durum Yönetimi: Kritik Bir Mülakat Konusu

Terraform, konfigürasyonu gerçek kaynaklara eşleyen bir durum dosyası tutar. Bu durum, kaynak ID'lerini, bağımlılıkları ve meta verileri izler. Onsuz Terraform neyin var olduğunu veya neyin değişmesi gerektiğini belirleyemez.

ÖzellikTerraformAnsible
Durum depolamaGerekli (yerel dosya veya uzak backend)Varsayılan olarak yok
Drift tespititerraform plan ile yerleşikAçık kontroller gerektirir
Kaynak izlemeDurum üzerinden otomatikEnvanter tabanlı
RollbackDurumdan yok et ve yeniden oluşturYerleşik rollback yok

Ansible'da eşdeğer bir durum dosyası yoktur. Hedef sistemlere bağlanır ve görevleri yürütür, mevcut sistem durumuna ve modül idempotansına güvenir. Bu, Ansible'ı başlangıçta daha basit yapar ancak zaman içinde değişiklikleri izlemeyi zorlaştırır.

Yaygın bir mülakat sorusu durum dosyası güvenliği hakkındadır. Terraform durumu hassas veriler içerebilir: veritabanı şifreleri, API anahtarları, kaynak tanımlayıcıları. Üretim dağıtımları durumu şifreleme ve erişim kontrolleriyle uzaktan (S3, Azure Blob, Terraform Cloud) depolar.

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

DynamoDB tablosu kilitleme sağlayarak iki mühendisin aynı anda durumu değiştirmesini önler.

Her Aracı Ne Zaman Kullanmalı

Terraform bulut altyapısı provisioninginde üstündür: sanal makineler, yönetilen veritabanları, load balancer'lar, IAM rolleri, VPC'ler. Kaynaklar arasındaki bağımlılıkları otomatik olarak yönetir ve tutarlı HCL sözdizimi aracılığıyla tüm büyük bulut sağlayıcılarını destekler.

Ansible mevcut sistemlerin yapılandırılmasında üstündür: paket kurulumu, kullanıcı yönetimi, uygulama kodu dağıtımı, çok adımlı dağıtım orkestrasyonu. Hedef makinelerde ajan gerektirmeden SSH (veya Windows için WinRM) üzerinden bağlanır.

Örtüşme alanı kafa karışıklığına neden olur. Her iki araç da bir VM'ye yazılım yükleyebilir. Terraform, kaynak oluşturulduktan sonra betik çalıştırmak için provisioner'lar kullanabilir. Ansible, amazon.aws.ec2_instance gibi modüller aracılığıyla bulut kaynakları oluşturabilir. Ancak her aracı güçlü yanlarının dışında kullanmak bakım sorunlarına yol açar.

Kaçınılması Gereken Anti-Pattern

Konfigürasyon yönetimi için Terraform provisioner'larını yoğun şekilde kullanmak kırılgan altyapı oluşturur. Provisioner'lar yalnızca oluşturma sırasında çalışır, sonraki apply'larda değil. Altyapı için Terraform kullanın, ardından konfigürasyon için Ansible'a devredin.

Üretimde Birleşik İş Akışı

Çoğu kuruluş her iki aracı birlikte kullanır. Terraform altyapıyı provision eder ve bağlantı ayrıntılarını çıktı olarak verir. Ansible bu çıktıları sistemleri yapılandırmak için tüketir.

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

Bir CI/CD pipeline'ı önce Terraform'u çalıştırır, çıktıları yakalar, dinamik olarak bir Ansible envanteri oluşturur, ardından yeni altyapı üzerinde playbook'ları çalıştırır.

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

Bu dinamik envanter, instance'ları etiketlerine göre gruplandırarak doğrudan AWS'yi sorgular. Manuel IP yönetimi gerekmez.

DevOps mülakatlarında başarılı olmaya hazır mısın?

İnteraktif simülatörler, flashcards ve teknik testlerle pratik yap.

OpenTofu: Manzarayı Değiştiren Fork

HashiCorp, Ağustos 2023'te Terraform'u Business Source License (BSL) altında yeniden lisansladı. Topluluk, Terraform 1.5'i artık Linux Foundation altında barındırılan OpenTofu'ya fork ederek yanıt verdi.

Ağustos 2026 itibarıyla OpenTofu 1.11.6, çoğu Terraform iş akışı için drop-in replacement olmaya devam ediyor. Aynı HCL sözdizimi, aynı provider ekosistemi, aynı durum formatı. OpenTofu, Terraform'un açık kaynak ikili dosyasında bulunmayan özellikler ekledi: durum şifreleme, provider for_each ve erken değişken değerlendirmesi.

Mülakat hazırlığı için lisans ayrımını anlamak önemlidir. BSL dahili kullanıma izin verir ancak rakip ürünler oluşturmayı kısıtlar. Vendor lock-in konusunda endişeli veya belirli uyumluluk gereksinimleri olan kuruluşlar, OpenTofu'nun MPL 2.0 lisansını tercih edebilir. IBM'in Aralık 2024'te HashiCorp'u satın alması, satıcı ilişkileri tartışmalarına başka bir değişken ekledi.

Yaygın DevOps Mülakat Soruları

S: Ansible, Terraform'un yerini alabilir mi?

Etkili bir şekilde hayır. Ansible bulut kaynakları oluşturabilir, ancak durum yönetiminden yoksundur. Aynı playbook'u iki kez çalıştırmak yinelenen kaynaklar oluşturabilir. Terraform'un durum dosyası neyin var olduğunu izler ve minimum değişiklikleri hesaplar. Ansible'ı en iyi yaptığı şey için kullanın: konfigürasyon yönetimi.

S: Terraform'da secret'ları nasıl yönetirsiniz?

Secret'ları asla versiyon kontrolüne commit etmeyin. Ortam değişkenlerini, Vault entegrasyonunu veya bulut sağlayıcı secret manager'larını kullanın. Değişkenleri hassas olarak işaretleyerek log'larda görünmelerini önleyin:

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

S: Ansible idempotansı nedir?

İdempotent bir işlem, bir kez veya birden fazla kez çalıştırılsa da aynı sonucu üretir. state: present ile apt modülü, eksikse bir paket yükler ve zaten yüklüyse hiçbir şey yapmaz. İdempotent playbook'lar yazmak, sonraki çalıştırmalarda istenmeyen değişiklikleri önler.

S: Altyapı kodunu nasıl test edersiniz?

Terraform: terraform validate sözdizimini kontrol eder, terraform plan değişiklikleri önizler ve Terratest gibi araçlar entegrasyon testleri çalıştırır. Ansible: ansible-lint sorunları yakalar, --check modu dry run gerçekleştirir ve Molecule rolleri container'lara karşı test eder.

Daha derin Terraform mülakat hazırlığı için Terraform Interview Questions: Infrastructure as Code Complete Guide makalesine bakılabilir. Terraform Basics ve Ansible Configuration Management modülleriyle pratik yapılabilir.

Versiyon Uyumluluğu ve Ekosistem

Ağustos 2026 itibarıyla güncel kararlı versiyonlar:

AraçVersiyonYayın TarihiTemel Özellik
Ansible2.20.5Nisan 2026Geliştirilmiş koleksiyon yönetimi
Terraform1.15.8Temmuz 2026Windows ARM64 desteği, convert fonksiyonu
OpenTofu1.11.6Nisan 2026Durum şifreleme, provider for_each

Ansible'ın koleksiyon mimarisi, temel işlevselliği provider'a özgü modüllerden ayırır. amazon.aws koleksiyonu, Ansible çekirdeğinden bağımsız olarak güncellemeler alır. Bu, CI/CD pipeline'larında versiyon sabitleme için önemlidir.

Terraform'un provider versiyonlaması benzer prensipleri takip eder. Lock dosyaları (terraform.lock.hcl), ekip üyeleri ve CI sistemleri arasında tutarlı provider versiyonları sağlar.

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

Aralarında Seçim: Karar Çerçevesi

Soru nadiren Ansible mi yoksa Terraform mı şeklindedir. Soru, hangi aracın hangi sorumluluğu üstlendiğidir.

Kullanım DurumuÖnerilen Araç
VM, veritabanı, ağ provisioningiTerraform
İşletim sistemi yapılandırma, paket kurulumuAnsible
Kubernetes kaynak yönetimiTerraform veya kubectl/Helm
Uygulama kodu dağıtımıAnsible veya CI/CD native
IAM rol ve politika oluşturmaTerraform
Sunucularda kullanıcı hesabı yönetimiAnsible
İzleme altyapısı kurulumuTerraform (kaynak oluşturma) + Ansible (ajan yapılandırma)

Bu araçların modern dağıtım iş akışlarına nasıl uyduğunun tam resmi için CI/CD Pipeline Interview Questions makalesine bakılabilir.

Kıdemli Mühendislerin Ansible ve Terraform Hakkında Bilmesi Gerekenler

  • Terraform altyapı durumunu deklaratif olarak yönetir; Ansible sistemleri prosedürel olarak yapılandırır. Her ikisini birlikte kullanmak bakımı kolay altyapı üretir.
  • Durum dosyası güvenliği önemlidir. Terraform durumunu şifreleme ve kilitleme etkinleştirilmiş olarak uzaktan depolayın.
  • OpenTofu, ek özelliklerle Terraform'a MPL lisanslı bir alternatif sağlar. Çoğu iş akışı için geçiş kolaydır.
  • İdempotans otomatik değildir. Tekrarlanan çalıştırmalarda tutarlı sonuçlar üreten playbook'lar yazın.
  • Dinamik envanter manuel host yönetimini ortadan kaldırır. Güncel altyapı için bulut sağlayıcılarını doğrudan sorgulayın.
  • Versiyon sabitleme sürprizleri önler. Terraform'da provider versiyonlarını kilitleyin; Ansible'da koleksiyon versiyonlarını sabitleyin.
  • Altyapı kodu testi farklı yaklaşımlar gerektirir: değişiklikleri önizlemek için terraform plan, Ansible dry run'ları için --check modu, her ikisi için entegrasyon test çerçeveleri.

Pratik yapmaya başla!

Mülakat simülatörleri ve teknik testlerle bilgini test et.

Günün meydan okuması

DevOps kodundaki hatayı bulabilir misin?

Gerçek bir kod parçası, gizli bir hata, günde bir deneme. Denemek için hesap gerekmez.

Anthony Fillion-Maillet

Yazan:

Anthony Fillion-Maillet

SharpSkill kurucusu

10 yılı aşkın süredir fullstack geliştirici. SharpSkill’i yönetiyor ve burada yayımlanan her şeyden sorumlu.

22 Ağustos 2026 tarihinde güncellendi

Paylaş

İlgili makaleler