Git deposundaki dosya düzeldiği hâlde uygulamanın düzelmemesi mümkündür. Denetleyici kaynağa erişemiyor, manifest üretemiyor veya hedef ortama uygulayamıyor olabilir. GitOps kullanırken iki ayrı durumu görmek gerekir: Git'te ne istiyoruz ve sistem şu anda ne yapıyor?
OpenGitOps yaklaşımı istenen durumun bildirime dayalı tanımlanmasını, sürümlü biçimde tutulmasını, ajanlar tarafından çekilmesini ve sürekli uzlaştırılmasını esas alır. Bu çerçeve OpenGitOps ilkelerinde açıkça tanımlanıyor. Git'e dosya koymak başlangıçtır; çalışma biçimini belirleyen, bu dosyayı izleyen uzlaştırma döngüsüdür.
Döngüyü küçük bir örnekle düşünmek
Bir uygulamanın üç örnek çalıştırmasını istediğimizi varsayalım. İstenen durum depoda tanımlıdır. Bir kişi canlı ortamda sayıyı geçici olarak değiştirirse denetleyici iki durum arasında fark görebilir. Bu farkın otomatik düzeltilmesi ise kullanılan araca ve etkin politikalara bağlıdır.
Argo CD'de otomatik senkronizasyon, kaynak silme ve self-heal davranışları ayrı seçeneklerdir. Otomatik senkronizasyonu açmak, diğer bütün davranışları açmış olmak anlamına gelmez. Git'ten kaldırılan kaynakların otomatik silinmesi için prune politikası ayrıca değerlendirilir. Canlı ortamda yapılan değişikliklerin düzeltilmesi de self-heal ayarına bağlıdır. Ayrıntılar Argo CD otomatik senkronizasyon belgesinde bulunuyor.
Bu ayrım uygulama sahipleri tarafından bilinmeli. Aksi hâlde ekip bir değişikliğin neden geri alındığını, bir kaynağın neden silinmediğini veya bir hatanın neden tekrarlandığını anlamakta zorlanır. Varsayılan ayarların sürümden sürüme aynı kalacağı da kabul edilmemeli.
Acil müdahaleyi önceden tarif etmek
Kesinti sırasında canlı ortamı elle değiştirme ihtiyacı olabilir. Böyle bir müdahalenin geçerli kalması için uzlaştırmanın o değişiklikle nasıl etkileşeceği bilinmelidir. Denetleyici değişikliği geri alıyorsa aynı komutu tekrar tekrar çalıştırmak çözüm üretmez.
Acil durum prosedürü; müdahale yetkisini, gerekiyorsa otomasyonun kontrollü durdurulmasını, değişikliğin kaydını ve Git'e geri taşınmasını kapsamalı. Otomasyon tekrar açılırken istenen durumun gerçekten doğru olduğu kontrol edilmeli. Geçici müdahalenin kalıcı ama görünmez bir istisnaya dönüşmesi engellenmeli.
Geri dönüşün sınırları
Önceki commit'e dönmek, uygulama tanımını önceki hâline getirebilir. Ancak uygulamanın yaptığı dış işlemleri veya veritabanı şema değişikliklerini otomatik tersine çevirmez. Bu nedenle sürüm geri dönüşü, yalnızca manifest geri dönüşü olarak planlanmamalı. Eski uygulamanın yeni veri yapısıyla uyumu ayrıca değerlendirilmelidir.
Başlangıç pilotunda düşük etkili tek bir uygulama seçilebilir. Başarılı senkronizasyonun yanında hatalı manifest, erişilemeyen depo ve elle oluşturulan fark senaryoları da denenmeli. Hangi olayın alarm üreteceği, alarmın kime gideceği ve müdahaleden sonra neyin doğrulanacağı yazılmalı.
Günlük görünürlükte son başarılı uzlaştırma, bekleyen fark ve uygulama sağlığı birlikte yer almalıdır. “Synced” göstergesi, kullanıcının işleminin başarılı olduğuna tek başına kanıt değildir. Denetleyicinin erişimi de uygulama kapsamıyla sınırlandırılmalıdır; bir uygulamadaki sorun bütün ortamın yönetim yetkisine dönüşmemeli. GitOps'un sürdürülebilir olması, değişiklik geçmişi kadar bu işletim sınırlarının da açık olmasına bağlıdır. Pilot sonunda uygulama ekibinin bu akışı yardım almadan takip edebilmesi de kabul koşullarından biri olmalı. Böylece sorunlar tek kişinin bilgisine bağlı kalmaz.
Yorumlar (0)
Henüz onaylanmış yorum yok.