Selamün Aleyküm Arkadaşlar,
Serinin on dördüncü yazısında mikroservis sistemlerin ayar yönetimi kısmına odaklanıyor olacağız. Sistemlerin dayanıklı, ölçeklenebilir ve bağımsız olarak dağıtılabilmesi için gerekli ayarların nasıl tutulması gerektiği konusuna değineceğiz. Bunun için ne gibi yöntemler mevcut, kullanılan araçlar nelerdir gibi bazı sorulara da cevap arayacağız. Hazırsak başlayalım.
Diğer yazılarımızda olduğu gibi öncelikle monolit sistemlere bakalım. Uygulamaların farklı ortamlarda doğru bir şekilde ayağa kalkması her proje için kritik bir nokta ve bunun böyle olmadığı projelere sanırım denk gelmiyoruz artık. Daha önce de değindiğimiz gibi monolit sistemlerde meydana gelen tek hata sistemin tek başına düşmesine sebep olabilir. Bu yüzden belki de bazı ayarlamalar ve konular monolit sistemde çok daha önemli ve kritik olabiliyor. Ortamların tutarlı olması, dağıtım konularındaki risklerin azalması gibi faydalar sağlar. Araya girip bir anımı paylaşmak istiyorum. Üzerinde çalıştığımız mikroservis projesini canlıya çıkmak zorundaydık ve uygulamayı başka bir şirketten teslim almamız da gerektiği için bulut üzerinde sadece prod ortamımız vardı. Bu süreç yaklaşık 15 gün sürdü, ancak o dönemlerdeki stresi hatırladıkça karnım ağrıyor. Ekibin yaptığı bütün geliştirmeleri tek tek inceliyor, çok kontrollü bir şekilde canlıya çıkmamız gerekiyordu, ama sonuç olarak kod maalesef canlı ortamda test ediliyordu. Hem bizim geliştirme hızımızı düşürüyor, hem test ekibi tarafından test edilmeyen kodun canlıya gitmesine sebep oluyor hem de bize ağır sorumluluk biniyordu. Bu konunun varlığının nasıl bir nimet olduğunu tekrar hatırlamış olduk. Acı bir gülümsetti yine :)
Şimdi de mikroservis tarafına geçecek olursak, sistemde birçok servis olacağından en kolay işler bile zorlaşıyor diyebiliriz. O yüzden bu tarz ihtiyaç durumlarında ilk akla gelen şey bunların nasıl merkezileştirilmesi. Merkezileştirme dediğimizde de kendi çözümlerimizle birlikte bu konuda ortaya çıkan birçok araç vitrinlerdeki yerini almış oluyor.
Bulut tabanlı sistemler kullanıyorsanız her birinin kendine ait çözümleri var. Genelde "secret manager" olarak geçmektedir. Ayrıca Github'un kendi çözümü de mevcut. Proje veya kuruluş nezdinde bu değerleri verebiliyoruz. Ayrıca Vault ve Consul gibi bağımsız araçlar ile de bu hassas verileri yönetebilirsiniz. Özellikle prod ortamları için hiçbir hassas veriyi konfigürasyon dosyalarında tutmuyoruz, pipeline aracılığıyla bunları eziyoruz. Projenin hiçbir yerinde bu veriler tutulmamış oluyor.
Dev, test, preprod ve prod ortamlarının olması monolit yapılarda olduğu gibi mikroservis yapıda da kritik bir nokta. Farklı olarak bunu her projede yönetebildiğimiz gibi merkezi olarak da yönetebiliriz. Her iki yöntemin de kendine göre avantaj ve dezavantajları var. Global bilgileri merkezi olarak tutup, yerel verileri proje bazlı tutuyoruz. İhtiyaçlarınıza göre birini seçebilir veya hibrit çözüm geliştirebilirsiniz.
Konfigürasyon dosyalarında tutulan bilgiler değiştirildiğinde bunların projede algılanması için servislerin yeniden çalıştırılması gerekmektedir. Özellikle bulut sistemler geçişlerde kesintiyi minimize etse de bu bazen istenilen bir durum olmaktan çıkıyor. O yüzden "hot reload" dediğimiz bir yapı ile servisler yeniden başlatılmadan ayarların algılanıp değişikliğin yansıtılması da istenebilir. Bahsettiğimiz araçların bazıları buna yapabilmektedir. Direkt bu konuyla alakalı değil ancak YARP (reverse proxy) hot reload çalışarak konfigürasyonda yapılan değişikliği yeniden başlatılmaya ihtiyaç duymadan değişikliği algılar.
Özetle konfigürasyonların tutulması ve kullanılmasının farklı yöntemleri olsa da mikroservislerde bunları merkezileştirmenin önemi üzerinde durmaya çalıştık. Ayrıca farklı ortamlarda yapılan geliştirmelerin de süreçleri nasıl daha dayanıklı kıldığını görmüş olduk.
Yazıyı birer ayet-i kerime ve hadis-i şerif ile bitirelim.
"İyi amelleri en güzel şekilde yapın." (Müminun, 23:51)
"Bir grup insan, lider olmadan bir araya gelirse, şeytan onlara hükmeder." (İbn Mace, Hadis No: 3942)
Hiç yorum yok:
Yorum Gönder