Terraform iş akışını CI/CD hattına taşıma: plan ve apply otomasyonu

Neden Terraform'u pipeline'dan çalıştırmalı?

Terraform'u geliştiricinin kendi bilgisayarından çalıştırmak küçük denemelerde işe yarar, ama ekip büyüdükçe sorun çıkarır. Aynı kodu farklı sürümlerle çalıştıran farklı kişiler farklı sonuç alabilir, kimin neyi ne zaman uyguladığı görünmez olur, altyapıyı değiştirebilen kimlik bilgileri bireylerin makinelerine dağılır.

Pipeline bu sorunları tek yerde çözer. Değişiklik bir Git isteğiyle (pull request) önerilir, plan çıktısı otomatik üretilip incelemeye sunulur, onaydan sonra tek bir kontrollü ortamdan uygulanır. Böylece altyapı değişikliği, uygulama kodu gibi gözden geçirilir, kayıt altına alınır ve tekrarlanabilir hale gelir. Terraform'un kendi temel işleyişi (yazma, planlama, uygulama) aynı kalır; pipeline bunun etrafına disiplin ekler.

Pipeline'ın temel aşamaları

Sağlıklı bir Terraform hattı genellikle şu aşamalardan oluşur:

• Biçim ve doğrulama: kod biçimi kontrol edilir, yapılandırma sözdizimi ve iç tutarlılık açısından doğrulanır. Hızlı ve ucuz bir ilk filtredir.
• Statik denetim: güvenlik ve politika tarayıcıları (örneğin yanlış açık bırakılmış ağ kuralları, şifrelenmemiş depolama) yapılandırmayı uygulanmadan önce inceler.
• Plan: Terraform hangi kaynakları ekleyeceğini, değiştireceğini ya da sileceğini hesaplar. Çıktı pull request üzerinde yorum olarak gösterilir, böylece gözden geçiren kişi değişikliğin gerçek etkisini görür.
• Onay: Üretim ortamı için plan, yetkili bir kişi tarafından onaylanmadan uygulanmaz.
• Apply: Onaylanan planla aynı çıktı uygulanır. Yeniden plan üretmek yerine kaydedilmiş planı kullanmak, onaylanan ile uygulananın birebir aynı olmasını sağlar.
• Sonrası: Durum dosyası güncellenir, çıktılar kaydedilir, gerekirse bildirim gönderilir.

Bu akış GitHub Actions, GitLab CI ya da başka bir hat aracında aynı mantıkla kurulabilir; yalnızca yapılandırma dili değişir.

Durum yönetimi ve eşzamanlılık

Pipeline'ın en kritik bağımlılığı Terraform durum dosyasıdır (state). Durum dosyası yerel diskte kalırsa pipeline her çalıştığında altyapıyı sıfırdan kurmaya kalkar. Bu nedenle uzak bir arka uç (remote backend) kullanılır: nesne depolama, bulut sağlayıcının yönetilen servisi ya da Terraform'un kendi yönetim platformu gibi.

Uzak arka uçta bazı özellikler şarttır. Durum kilidi bunlardan biridir: aynı anda birden fazla pipeline aynı altyapıya yazamaz, sonra gelen iş beklemek ya da düşmek zorundadır. Bir diğeri şifreleme ve erişim kontrolü: durum dosyası hassas değerler içerebilir, bu yüzden okuma ve yazma yetkisi sınırlandırılır ve geçmiş sürümler saklanır.

Pipeline tarafında da eşzamanlılık düşünülmelidir. Aynı ortam için ardışık değişiklikler sıraya konur; farklı ortamlar (geliştirme, hazırlık, üretim) ayrı durum dosyaları ve ayrı çalışma alanlarıyla yönetilir. Büyük altyapı tek bir durum dosyasında toplanmaz; sorumluluk sınırlarına göre bölünür.

Kimlik bilgileri ve güvenlik

Pipeline altyapıyı değiştirebildiği için, ele geçirilirse en büyük riski taşıyan bileşenlerden biridir. Güvenli kurulumun ilkeleri şunlardır:

• Uzun ömürlü anahtarlar yerine kısa ömürlü kimlik bilgileri: Modern hat araçları, bulut sağlayıcıyla OIDC tabanlı kimlik federasyonu kurarak pipeline'a işlem başına geçici yetki verebilir. Depoda saklanan kalıcı anahtar ihtiyacı ortadan kalkar.
• En az yetki: Plan aşaması yalnızca okuma yetkisiyle çalışabilir. Apply aşamasının yetkisi yalnızca ilgili ortamla sınırlı olmalıdır.
• Ortam ayrımı: Üretim kimliğine yalnızca korumalı dal ve onaylı iş akışı erişebilir. Bir pull request'ten gelen fork kodu üretim yetkisi görmemelidir.
• Gizli bilgi yönetimi: Parolalar kodda değil, gizli bilgi yöneticisinde tutulur; plan çıktısında hassas değerlerin açığa çıkmadığı kontrol edilir.
• Denetim kaydı: Kim hangi planı onayladı, hangi sürüm uygulandı bilgisi saklanır.

Bu önlemler pipeline'ı kolaylaştırıcıdan çok, kontrol noktası haline getirir.

Örnek iş akışı: bir değişikliğin pull request'ten üretime yolculuğu

Örneğin ekip, bir uygulama için yeni bir veritabanı kaynağı tanımlamak istiyor. Geliştirici, yapılandırma dosyasını bir dalda değiştirip pull request açar. Pipeline otomatik olarak biçim ve doğrulama kontrolünü çalıştırır, güvenlik tarayıcısı şifrelemenin kapalı olduğunu bildirir. Geliştirici düzeltip tekrar gönderir.

Kontroller geçince pipeline plan üretir ve özetini pull request'e yorum olarak ekler: bir kaynak eklenecek, hiçbir şey silinmeyecek. Gözden geçiren kişi hem kod değişikliğini hem de gerçek etkiyi görür ve onaylar. Dal ana dala birleştirildiğinde hazırlık ortamı için plan ve apply otomatik çalışır. Üretim için ise yetkili bir onaycının manuel onayı beklenir; onay gelince kaydedilmiş plan uygulanır, sonuç kanala bildirilir.

Bu akışta hiç kimse kişisel makinesinden altyapıya dokunmaz ve her adımın kaydı vardır.

Sapma kontrolü ve sık yapılan hatalar

Altyapı, pipeline dışında biri tarafından elle değiştirildiğinde kod ile gerçek durum ayrışır. Buna sapma (drift) denir. Zamanlanmış bir iş, belirli aralıklarla yalnızca plan çalıştırıp fark çıkarsa uyarı gönderebilir. Böylece elle yapılan müdahaleler görünür olur.

Sık yapılan hatalar şunlardır:

• Otomatik apply'ı onaysız üretime bağlamak: Yanlış bir birleştirme, altyapıyı silebilir.
• Planı kaydetmeden apply'ı yeniden planlatmak: Onay anındaki plan ile uygulanan plan farklı olabilir.
• Durum dosyasını tek yerde toplamak: Küçük bir hata bütün altyapıyı etkiler, kilit çekişmesi artar.
• Sağlayıcı ve Terraform sürümlerini sabitlememek: Pipeline her gün farklı davranabilir.
• Yetkiyi geniş vermek: Plan ve apply aynı güçlü kimlikle çalışır.
• Yıkıcı değişiklikleri vurgulamamak: Silinecek kaynaklar plan özetinde açıkça görünmelidir.

Öğrenme yolu ve Mindset programlarındaki yeri

Önce Terraform'un temelini bilgisayarınızda öğrenin: HCL dili, kaynaklar, değişkenler, durum. Ardından uzak arka uç ve modül yapısına geçin. Sonraki aşamada küçük bir hat kurun: pull request'te biçim, doğrulama ve plan çalışsın. Son olarak onay kapıları, politika denetimleri ve sapma kontrolü eklenir.

Mindset kataloğunda Terraform ile Altyapı Otomasyonu eğitiminin müfredatında Durum Yönetimi ve Backend, Modüler Terraform Mimarisi, Politika ve Uyumluluk Otomasyonu ve CI/CD ile Terraform İş Akışları modülleri bulunur. CI/CD Pipeline Tasarımı (GitHub Actions) eğitiminde ise Yeniden Kullanılabilir İş Akışları ile Güvenlik ve Uyumluluk Entegrasyonu modülleri hat tarafını tamamlar. Altyapı, platform ve DevOps ekipleri bu başlıkları birlikte ele alıp kendi bulut düzenleri üzerinde uygulayabilir.