Terraform dosyası üzerinde birkaç satırlık değişiklik, çalışan ortamda büyük bir işlem oluşturabilir. Bir alanın güncellenmesi kaynağı yerinde değiştirebilir; başka bir alanın güncellenmesi kaynağın yeniden oluşturulmasını gerektirebilir. Kod incelemesinin yanında plan incelemesi yapılmasının nedeni tam olarak budur.
Sağlıklı bir Infrastructure as Code akışı, kodun sürümünü, kullanılan değişkenleri, hedef ortamı ve uygulanacak işlemleri aynı bağlamda tutar. “Benim bilgisayarımda plan temizdi” cümlesi yerine, hangi planın kim tarafından onaylandığı ve nerede uygulandığı izlenebilmelidir.
Planı inceleme çıktısı olarak ele almak
Terraform plan, yapılandırma ve mevcut duruma bakarak önerilen işlemleri gösterir. Kaydedilmiş bir plan, daha sonra apply adımına verilebilir. İnceleme sırasında oluşturma ve silme sayılarının yanında replacement, bağımlılıklar ve beklenmeyen alan değişiklikleri okunmalı. Plan komutu belgesi bu çalışma biçimini ve seçeneklerin etkisini açıklıyor.
Önerilen sıra basit: biçim ve doğrulama kontrolleri, hedef ortamın teyidi, plan üretimi, insan incelemesi, yetkili uygulama ve sonuç kontrolü. Onaydan sonra yapılandırma veya değişkenler değiştiyse eski onay yeni işleme otomatik taşınmamalı. Uzun süre beklemiş planlar için de ortamın değişmiş olabileceği hesaba katılmalı.
Plan incelemesinde özellikle şu sorular sorulabilir: Silinen kaynak beklenen kaynak mı? Yeniden oluşturmanın kesinti etkisi var mı? Yeni bir yetki veya dış erişim oluşuyor mu? Beklenen değişikliğin yanında ilgisiz kaynaklar neden görünüyor? Son sorunun yanıtı alınmadan uygulamaya geçmemek, birçok hatayı erken yakalar.
State dosyasını sıradan çıktı saymamak
State, yapılandırmadaki kaynaklarla gerçek nesneler arasındaki eşlemeyi ve Terraform'un ihtiyaç duyduğu bilgileri tutar. Bu nedenle ortak ekip çalışmasında state'in kimin elinde olduğu belirsiz bırakılamaz. State açıklaması, dosyanın yalnızca geçmiş işlem kaydı olmadığını gösterir.
State ve kaydedilmiş plan dosyaları hassas değerler içerebilir. Bir değeri sensitive olarak işaretlemek her durumda onun state'te bulunmasını engellemez; çoğunlukla çıktıda gösterilmesini sınırlar. Yeni sürümlerdeki ephemeral veya write-only özelliklerin kullanılabilirliği Terraform ve provider desteğine bağlıdır. Hassas veri rehberi bu ayrımları açıklıyor. Dosyaları açık depolara, genel CI çıktısına veya sınırsız erişimli artefact alanlarına koymamak gerekir.
Eşzamanlı işlemi bilinçli yönetmek
Backend destekliyorsa state kilitlemesi, aynı state üzerinde çakışan yazma işlemlerini önlemeye yardım eder. Her backend'in aynı kilitleme yeteneğine sahip olduğu varsayılmamalı. Kilit sorunu çıktığında ilk çözüm kilidi zorla kaldırmak olmamalı; devam eden işlem ve kilidin sahibi araştırılmalı. Kilitleme belgesindeki uyarılar bu nedenle önemlidir.
İşlem tamamlandığında yalnızca komutun başarılı çıkmasına bakılmamalı. Değişen kaynağın beklenen davranışı, erişimi ve uygulama etkisi kontrol edilmeli. Ardından yeni bir planla açıklanamayan fark kalıp kalmadığı görülebilir. Elle yapılan acil değişiklikler varsa bunların kodla nasıl uzlaştırılacağı kaydedilmeli.
Başlangıç için tek bir ortamda bu akışı standartlaştırmak yeterlidir. Ekip, onaylanan değişiklik ile uygulanan değişiklik arasındaki bağı açıkça görebiliyorsa araçtan gerçek fayda almaya başlamış demektir.
Yorumlar (0)
Henüz onaylanmış yorum yok.