Kurulum · Bulut Altyapısı

Terraform Remote State: GCS, S3 ve Azure Blob Güvenli Kurulum

Terraform state kaynak kimliklerini ve bazı hassas değerleri içerir. Remote backend ekip paylaşımı sağlar; state kilidi eşzamanlı yazmayı önler, erişim kontrolü ise kimin okuyup…

Teknik gözden geçirme: 2026-10-06

Mimari ve çalışma modeli

Terraform state kaynak kimliklerini ve bazı hassas değerleri içerir. Remote backend ekip paylaşımı sağlar; state kilidi eşzamanlı yazmayı önler, erişim kontrolü ise kimin okuyup değiştireceğini belirler. Kilit gizlilik veya yedek yerine geçmez.

Önce state bucket/container’ını çalışma konfigürasyonundan bağımsız oluşturun. Şifreleme, sürümleme ve sınırlı CI kimliğini tanımlayın. Backend adresini kodda, kimlik bilgilerini güvenli ortamda tutun. init -migrate-state işlemi öncesi yerel state kopyasını güvenli saklayın ve aktif apply olmadığını doğrulayın.

GCS ve Azure backend’leri kendi kilitleme mekanizmalarını destekler; güncel S3 backend’de use_lockfile seçeneği vardır. Terraform sürümü ve IAM izinlerini ilgili backend belgesinden doğrulayın. Force-unlock yalnız kilit sahibinin gerçekten çalışmadığı kanıtlandıktan sonra yapılır.

1Backend ve kimlik
2State migration
3Kilitli plan/apply
4Sürümleme ve audit

Backend sürüm desteğini doğrulayın.

Tasarım parametreleri

State kapsamı: Ortamları ve yetki alanlarını ayrı state dosyalarında tutun; aşırı parçalama bağımlılık karmaşıklığı doğurabilir.
Kimlik: Mümkünse kısa ömürlü iş yükü kimliği kullanın; backend sırlarını plan dosyasına sızdırmayın.
Kurtarma: Sürümleme ve audit’i açın; eski state geri dönüşünü mevcut kaynaklarla mutabakat yapmadan uygulamayın.

Hesap ve uygulama örneği

İki CI işi aynı state üzerinde plan/apply denesin. Birinci kilidi tutarken ikinci kontrollü beklemeli veya hata vermelidir. Sırf CI yeşil olsun diye -lock=false kullanmayın. İş bittiğinde plan’ın beklenmedik silme veya yeniden oluşturma göstermediğini kontrol edin.

Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.

terraform {
  backend "s3" {
    bucket       = "lab-terraform-state"
    key          = "lab/network.tfstate"
    region       = "eu-central-1"
    use_lockfile = true
    encrypt      = true
  }
}
# Choose one backend: GCS uses bucket/prefix; Azure uses account/container/key.
# Run terraform init -migrate-state only after protected backup and lock coordination.

Hata teşhisi

Belirti	Olası neden / ayrım	Doğrulama
Kilit alınamıyor	Aktif iş, eksik izin veya eski kilit.	Kilit kimliği/zamanı ve CI durumunu karşılaştırın.
Migration sonrası yeniden oluşturma	Yanlış state key/workspace.	State içeriği ve gerçek kaynak kimliklerini eşleştirin.

Kabul ve doğrulama kontrolleri

Backend sürüm desteğini doğrulayın.
Sırları koddan ayrı tutun.
State’i güvenli yedekleyin.
Eşzamanlı kilit testini yapın.
Migration sonrası plan’ı inceleyin.
Sürüm kurtarmayı pilotta sınayın.

İlgili kavramlar

Kilit, bekleme ve deadlock

Eşzamanlı işlemler veri bütünlüğü için kilit veya sürümleme mekanizmaları kullanır. Uzun açık transaction, diğer işleri bekletebilir; deadlock ise birbirini bekleyen işlemler arasındaki döngüdür. Ürün bazı işlemlerden birini sonlandırabilir ve uygulamanın güvenli tekrar deneme yapması gerekebilir. Bekleyen sorgu ile onu bloke eden sorguyu birlikte inceleyin. İzolasyon seviyesini rastgele düşürmek veri tutarlılığını değiştirebilir. Transaction süresini kısaltma, tutarlı erişim sırası ve uygun indeks gibi seçenekleri aynı iş yükünde doğrulayın.

Şifreleme ve anahtarın yaşam döngüsü

Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.

Dosya izinleri ve servis kimliği

Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Kalıcılaştırma ve güç kaybı

Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi