Çok sayıda yapılandırılmış yapılandırma / özellik dosyasını işlemek için en iyi uygulamalar

Çok sayıda sunucusu olan bir sistem düşünün. Her birinin bir dizi ayarı vardır:

• Bazıları sunucuya özgü
• Bazıları bölgeye özgü
• Bazıları ortak
• Belki bazı özel gruplamalarınız olabilir, örneğin bu sunucu grubu sadece okumak içindir
• vb.

Aklımdaki mevcut uygulama, yetenekleri geçersiz kılan basit bir özellik yapısıdır.

Örnek olarak Google sunucularını ele alalım. Her birinin yüklenecek ayarların bir listesi vardır.

Örneğin, Londra sunucusunda şunlar olabilir:

rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.properties, Vs.

Her dosya bir dizi özellik içeriyorsa ve yükleme sırası özellikleri geçersiz kılmanıza izin verirse, daha da ileri gidersiniz.

Örneğin: rootsettings.propertiesgerekebilir accessible=falsevarsayılan olarak, ancak değiştirileceğini searchengine.propertiesileaccessible=true

Bu yapı ile ilgili yaşadığım sorun kontrolden çıkmak çok kolay. Hiç yapılandırılmamış, yani herhangi bir seviyede herhangi bir mülkü tanımlayabilirsiniz ve birçok öğe eski olabilir.

Ayrıca, çok sayıda sunucuyu etkilediğiniz için ağ büyüdükçe orta seviyeyi değiştirmek imkansız hale gelir.

Son olarak, her bir örneğin 1 özel özelliğe ihtiyacı olabilir, yani ağacınız her sunucu için bir yapılandırma ile sonuçlanır, bu da onu en uygun çözüm değildir.

Daha iyi bir yapılandırma yönetimi mimarisi hakkında herhangi bir öneriniz / fikriniz varsa çok memnun oluruz.

Önce kendinize bazı sorular sormanız ve bazı noktaları açıklığa kavuşturmanız gerektiğini düşünüyorum, o zaman sorununuzu nasıl çözeceğinize daha iyi karar verebilirsiniz.

Birincisi: sunucular üzerinde kimin kontrolü olacak?

• Yüzlerce sunucuyu kontrol edecek tek bir yönetici mi? Ardından yapılandırmayı olabildiğince merkezi hale getirmeniz gerekir.

• Yoksa her sunucu, ayarlarının merkezi bir yapılandırma tarafından geçersiz kılınmasını veya denetlenmesini istemeyen bireysel bir yöneticinin kontrolü altında mıdır? O zaman merkezi olmayan yapılandırmaya odaklanmalısınız. Her yöneticinin yönetmesi gereken az sayıda sunucu varsa, bu yine de elle yönetilebilir.

İkincisi: Tonlarca yapılandırma seçeneğine gerçekten ihtiyacınız var mı yoksa numarayı birkaçına kadar tutabilir misiniz? Hepsini ve her şeyi "her ihtimale karşı" yapılandırılabilir yapmak yerine, kendinizi sisteminizin gerçekten ihtiyaç duyduğunu bildiğiniz seçeneklerle daha iyi sınırlandırın. Bu, örneğin,

• yazılımınızı biraz daha akıllı hale getirme (örneğin, program çevreye sorarak otomatik olarak ne belirleyebilir)?

• katı bir şekilde "yapılandırma konvansiyonu" nu takip etmek - örneğin, belirli adlandırma kuralları oluşturmak veya bazı seçenekleri varsayılan olarak diğer seçeneklerden türetmek

Üçüncüsü: gerçekten yazılıma kodlanmış hiyerarşik bir yapılandırma düzeyi ister misiniz? Kaç tane sunucu olacağını önceden bilmediğinizi, ağaç benzeri bir hiyerarşi gerçekten onlar için en iyi yapı olduğunu veya ağacın kaç seviyeye sahip olması gerektiğini bilmediğinizi düşünün. Düşünebileceğim en basit çözüm, hiçbir merkezi yapılandırma sağlayarak, sunucu başına yalnızca bir yapılandırma dosyası sağlayarak ve sorumlu sunucu yöneticilerinin birden çok sunucunun yapılandırmalarını yönetme sorununu nasıl çözdüklerine karar vermelerine izin vermektir .

Örneğin, yöneticiler merkezi bir yapılandırma dosyasını bir grup farklı sunucuya dağıtan ve her kopyada bazı küçük değişiklikler yapan jeneratör komut dosyaları yazabilir. Bu şekilde, önceden "sunucu dağıtım topolojisi" hakkında herhangi bir varsayım yapmanız gerekmez, topoloji herhangi bir zamanda gerçek dünya gereksinimlerine göre ayarlanabilir. Dezavantajı, Perl, Python, Bash veya Powershell gibi bir dilde komut dosyası yazma konusunda bilgi sahibi yöneticilere ihtiyacınız var.

Ben şahsen yapılandırma dosyasını devralmayı hiç sevmedim. Bir yükleme sırasına sahip olduğunuzdan, bunun nasıl tanımlandığından veya türetildiğinden emin değilsiniz. Belki de, dosyaları içine koyduğunuz veya dosya adlarına eklediğiniz bir dizin yapısında yansıtarak diziyi açık hale getirmeye yardımcı olur.

rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties

Bu, bir bölgeye hizalanmayan yapılandırma değerlerinin toplamına sahip olduğunuz bir noktaya kadar çalışacaktır. Bu yüzden seçtiğiniz organizasyon eksenini düşünmelisiniz.

Ne gibi daha fazla kendi yapılandırma dosyalarına yapılandırma değerlerinin toplama izole ve (yaprak) yapılandırma dosyası birine işaret var.

Bir örnek:

bigcity.searchsettings.properties
regional.searchsettings.properties

İçeride londonsettings.propertiesşöyle bir değer olabilir:

searchsettings:bigcity.searchsettings.properties

Bu, daha fazla serbestlik derecesi veya ek bir serbestlik sağlar.

Ben de aynı sorunu yaşadım ve açık kaynaklı çözümümü. Kaynak kodu burada bulabilirsiniz https://github.com/Bikeman868/Urchin

Her sunucuda birden fazla uygulama ve birden çok ortam bulunan çok sayıda sunucuya sahip büyük bir sistem için kullanıyorum. Yapılandırmayı yönetmek için Dart'da yazılmış bir kullanıcı arayüzü içerir.

Yerden kalkmak için yardıma ihtiyacınız olursa doğrudan benimle iletişime geçebilirsiniz.

Uyguladığım çözüm kurallara dayalı. Genel olarak tüm yapılandırmalar için geçerli olan bir kuralla başlarsınız ve "bu ortamdaki tüm makineler bu UNC yoluna günlük dosyaları oluşturur" gibi kurallar ekleyebilirsiniz. Kurallar bir ortama, bir uygulamaya, bir makineye veya uygulamanın bir örneğine özgü olabilir. Kurallar, bu uygulamanın bu belirli sunucuda çalışan yalnızca bu özel örneğinde olduğu gibi daha spesifik olabilir.

Kurallar, en belirgin olana en az spesifik sırada uygulanır ve sonraki kurallar, önceki kurallarda belirtilen değerleri geçersiz kılabilir. Bu, örneğin, belirli bir uygulama için geçerli olan bir kural oluşturabileceğiniz, ardından belirli bir makine veya uygulamanın belirli bir örneği için farklı bir değerle geçersiz kılabileceğiniz anlamına gelir.

Sunucu REST + JSON arabirimine sahiptir, bu nedenle çoğu geliştirme sistemiyle çalışır ve ayrıca .Net uygulamaları için uygun bir istemci kitaplığına sahiptir.

Bu tür ayarlar yönetmek için bir kabus. Yazılım bileşenlerinizi tüm durumları ele alarak bunları mümkün olduğunca azaltmaya çalışmak en iyisidir.

yani bir bölge için bir api sunucusu kurmak yerine, bölgeyi api çağrısı ile geçirin ve tek bir sunucu kurulumunun tüm bölgeleri ele almasına izin verin.

Ancak, bulunduğunuz durumda olduğunuz göz önüne alındığında. Yapılandırma ayarları oluşturmak için bir sistem kurmamanızı tavsiye ederim. Yalnızca zaten karmaşık bir soruna karmaşıklık katar.

Bunun yerine, ayarları sunucu türüne göre dağıtım aracınızda saklayın. (ahtapot dağıtım ayarları, teamcity dosyası yeniden yazma işlemleri vb.) Bu, yazılımı yükselttiğinizde en son yaptığınız yapılandırma ayarlarını uyguladığınızdan emin olmanızı sağlar ve değişiklikler üzerinde hassas kontrol sağlar.

Meta-config dosyalarınızda değişiklik yaptığınız durumda olmak istemezsiniz ve ardından çeşitli bölgelerinizde / sunucularınızda / özel gruplamalarınızda hangi yapılandırma dosyasının üretildiğini test etmek zorunda kalmazsınız.

Araştırma yok; tüm kişisel görüş, 30+ BT deneyimi. Çok sayıda kullanıcıyla hızlı bir şekilde değişebilen / değiştirilebilen karmaşık bir veri yapısı gibi geliyor.

Her kullanıcı için ayrı yapılandırma dosyaları üreten özel ayıklama işlemleriyle, verileri yapılandırmak için bir veritabanı havuzu (ör. SQL) düşünün. Bir değişikliğin uygulanmadan önce etkisini belirlemek için veritabanının sorgusunu kullanabilirsiniz; yinelenen olayları bulma vb. Bireysel düz dosyalar sorunun bir parçasıdır. Ayrıca değişiklik günlükleri ve kurtarma / yeniden oluşturma desteği alabilirsiniz. Veritabanı kontrolü ile, yapılandırma devralma sorununu ortadan kaldırabilirsiniz. Bu tür bir çözüm ek veritabanı yapısı gerektirecektir. Doğru kompozit anahtar yapısı çok önemlidir.

Benim önerim bu.

Bu tür bir hizmeti uygulayan bazı çok pahalı satıcı sistemi güvenlik ve kontrol sistemlerine bakabilirsiniz. Onları düşünün. Genel olarak çevreye bağımlı olacaklardır.