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ı.

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.
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.
# 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.
# 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: restartedHer 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.
| Özellik | Terraform | Ansible |
|---|---|---|
| Durum depolama | Gerekli (yerel dosya veya uzak backend) | Varsayılan olarak yok |
| Drift tespiti | terraform plan ile yerleşik | Açık kontroller gerektirir |
| Kaynak izleme | Durum üzerinden otomatik | Envanter tabanlı |
| Rollback | Durumdan yok et ve yeniden oluştur | Yerleş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.
# 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.
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.
# 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.
# 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:
# 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ç | Versiyon | Yayın Tarihi | Temel Özellik |
|---|---|---|---|
| Ansible | 2.20.5 | Nisan 2026 | Geliştirilmiş koleksiyon yönetimi |
| Terraform | 1.15.8 | Temmuz 2026 | Windows ARM64 desteği, convert fonksiyonu |
| OpenTofu | 1.11.6 | Nisan 2026 | Durum ş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.
# 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ğ provisioningi | Terraform |
| İşletim sistemi yapılandırma, paket kurulumu | Ansible |
| Kubernetes kaynak yönetimi | Terraform veya kubectl/Helm |
| Uygulama kodu dağıtımı | Ansible veya CI/CD native |
| IAM rol ve politika oluşturma | Terraform |
| Sunucularda kullanıcı hesabı yönetimi | Ansible |
| İzleme altyapısı kurulumu | Terraform (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--checkmodu, her ikisi için entegrasyon test çerçeveleri.
Pratik yapmaya başla!
Mülakat simülatörleri ve teknik testlerle bilgini test et.
DevOps kodundaki hatayı bulabilir misin?
Gerçek bir kod parçası, gizli bir hata, günde bir deneme. Denemek için hesap gerekmez.

Yazan:
Anthony Fillion-MailletSharpSkill 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

2026'da Kubernetes Secrets Yönetimi: External Secrets, Vault ve Mülakat Soruları
External Secrets Operator ve HashiCorp Vault ile Kubernetes secrets yönetiminde uzmanlaşma rehberi. Güvenli kalıplar, en iyi uygulamalar ve DevOps mülakat soruları.

Docker Compose 2026: Çok Konteynerli Uygulamalar, Ağ Yapılandırması ve DevOps Mülakat Soruları
2026 yılında Docker Compose için kapsamlı rehber. Çok konteynerli mimari, ağ yapılandırması, health check mekanizmaları, secret yönetimi ve DevOps mülakat soruları.

2026'da Kubernetes Helm Charts: Paketleme, Dağıtım ve Mülakat Soruları
Kubernetes için Helm charts konusunda uzmanlaşın: chart yapısı, şablonlama, bağımlılıklar, dağıtım stratejileri ve DevOps mühendisleri için sık sorulan mülakat soruları.