Terraform ile Infrastructure as Code Mantığını Anlamak

Bir sunucuyu yönetim panelinden oluşturmak kolaydır. Altı ay sonra aynı ağ kurallarını, disk ayarlarını ve erişim ilişkilerini ikinci bir ortamda yeniden kurmak daha zordur. Infrastructure as Code, bu altyapı niyetini incelemeye ve tekrar üretmeye uygun dosyalarda ifade etmeyi sağlar.

Terraform bu yaklaşımın araçlarından biridir. Ancak onu “bir kez çalışan kurulum script'i” gibi düşünmek eksik kalır. Terraform yapılandırma, mevcut kaynaklar ve kendi state kaydı arasında ilişki kurarak değişiklik planlar.

Emir dizisi yerine istenen durum

Bir shell script'i “sunucuyu oluştur, portu aç, diski ekle” şeklinde adımlar tarif edebilir. Terraform yapılandırması ise kaynakların hangi özelliklere sahip olmasını istediğinizi belirtir. Provider, ilgili platformun API'siyle konuşur.

Bu model, sıra kavramının tamamen kaybolduğu anlamına gelmez. Bir kaynağın çıktısına referans veren başka kaynak bağımlılık oluşturur. Terraform bu ilişkilerden bir grafik çıkarır. Bağımsız işler paralel yürütülebilir; bağımlı işler uygun sırada ele alınır.

Plan sonucu mevcut kaynağı yerinde güncellemek veya silip yeniden oluşturmak olabilir. Özellikle “replace” kararı veri, IP adresi veya erişim sürekliliği üzerinde etkili olabilir. Kaynak davranışının çerçevesi Terraform resource belgelerinde açıklanır.

Bulut hesabı olmadan küçük bir deney

Aşağıdaki örnek Terraform 1.4 veya üzerindeki yerleşik terraform_data kaynağını kullanır. Gerçek sunucu oluşturmaz ve bir bulut hesabı gerektirmez; yapılandırma, plan ve state ilişkisini gözlemlemek içindir.

terraform {
  required_version = ">= 1.4.0"
}

variable "environment" {
  type    = string
  default = "development"
}

resource "terraform_data" "deployment" {
  input = {
    environment = var.environment
    replicas    = 2
  }
}

output "deployment_settings" {
  value = terraform_data.deployment.output
}

Dosyayı boş bir deneme dizininde main.tf olarak kaydedin:

terraform init
terraform fmt -check
terraform validate
terraform plan -out=reviewed.tfplan
terraform apply reviewed.tfplan

Sonra replicas değerini 3 yapıp yeniden plan alın. Değişikliği uygulamadan görebilirsiniz. Bu örnek, gerçek provider kaynaklarında görülecek tüm davranışları temsil etmez; gerçek API izinleri, kotalar ve platform hataları burada yoktur.

Plan bir inceleme noktasıdır

terraform plan, mevcut bilgiyle yapılması beklenen değişiklikleri gösterir. Kaydedilmiş planı uygulamak, incelediğiniz değişiklik setiyle çalışmanıza yardımcı olur. Ancak dış dünyadaki tüm değişkenleri dondurmaz. Yetki kaybı, kota dolması veya başka bir aktörün yaptığı değişiklik apply sırasında hataya yol açabilir.

Planı yalnızca “kaç kaynak eklenecek?” diye okumayın. Hangi kaynak değişiyor, hangi alan bilinmiyor, bir nesne replace ediliyor mu ve etkilenen veri nasıl korunacak sorularını sorun. Plan akışı belgesi plan dosyalarının çalışma biçimini açıklar.

Başarısız apply bütün adımları atomik biçimde geri almış kabul edilmemelidir. Bazı kaynaklar oluşturulmuş, diğerleri başarısız olmuş olabilir. Sonraki karar gözlenen duruma göre verilmelidir.

State: Terraform'un eşleştirme kaydı

State, yapılandırmadaki kaynak adreslerini gerçek altyapı nesneleriyle ilişkilendirir. State'i silmek altyapıyı silmek değildir; Terraform'un hangi nesneyi yönettiğine ilişkin bilgisini kaybetmek olabilir.

Takım halinde çalışırken erişim kontrolü, sürümleme ve eşzamanlı işlem koruması sağlayan uygun remote backend kullanmak önemlidir. Kilitleme desteği backend'e göre değişir. Aynı altyapıyı iki bağımsız state dosyasının yönetmesi sahiplik karmaşası yaratır. Bu sorumluluk Terraform state belgesinde ele alınır.

State ve plan dosyaları hassas değerler içerebilir. Bir değişkeni sensitive işaretlemek çoğunlukla ekrandaki gösterimi sınırlar; değerin state'te hiç tutulmadığı anlamına gelmez. Bu ayrım hassas veri rehberinde özellikle açıklanır.

Drift ve konsoldan yapılan değişiklikler

Bir ekip üyesi firewall kuralını panelden değiştirdiğinde yapılandırma ile gerçek durum farklılaşır. Buna drift denir. Sonraki plan bu farkı ortaya çıkarabilir; ancak hangi tarafın doğru olduğuna insanlar karar vermelidir.

Acil müdahaleyle yapılan bir değişiklik gerekli olabilir. Sonrasında yapılandırmayı güncellemezseniz bir sonraki apply bu müdahaleyi geri çevirebilir. Bu yüzden olay sonrası düzeltmelerin kod tabanına taşınması operasyonun parçasıdır.

Mevcut bir kaynağı import etmek de tüm istenen yapılandırmayı kendiliğinden doğru hale getirmez. Önce sahipliği ve state eşleşmesini kurar; sonraki planı dikkatle incelemek gerekir.

Modül ve ortam sınırlarını seçmek

Her kaynak için ayrı modül açmak tekrar kullanım sağlamayabilir. Birlikte değişen ve açık bir arayüz sunan parçaları modülleştirmek daha anlamlıdır. Ağ, veritabanı ve uygulama katmanlarının yaşam döngüleri farklıysa state sınırlarını da buna göre değerlendirin.

Production ve deneme ortamlarını yalnızca isim farkıyla ayırmak yetmez. Kimlik, erişim ve silme etkisi bakımından da sınır koyun. Öğrenme aşamasında plan çıktısını okuyabilmek, çok sayıda modül üretmekten daha değerlidir.

Terraform'un asıl kazancı altyapıyı görünür bir değişiklik sürecine sokmasıdır: hangi niyetin, hangi planla ve hangi sahiplik altında uygulandığı anlaşılır olur.