Najlepsze praktyki dotyczące obsługi dużej liczby uporządkowanych plików konfiguracji / właściwości

Wyobraź sobie system, który ma dużą liczbę serwerów. Każde z nich ma wiele ustawień:

• Niektóre specyficzne dla serwera
• Niektóre specyficzne dla regionu
• Niektóre wspólne dla wszystkich
• Być może możesz mieć niestandardowe grupy, na przykład ta grupa serwerów służy tylko do odczytu
• itp.

Obecna praktyka, o której myślę, to prosta struktura własności z nadrzędnymi zdolnościami.

Weźmy serwery Google na potrzeby tego przykładu. Każdy z nich ma listę ustawień do załadowania.

Na przykład serwer w Londynie może mieć:

rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.properties, Itd.

Gdzie każdy plik zawiera zestaw właściwości, a sekwencja ładowania pozwala na przesłonięcie właściwości, tym dalej.

Na przykład: rootsettings.propertiesmoże mieć accessible=falsedomyślnie, ale jest zastępowane searchengine.propertiesprzezaccessible=true

Problem z tą strukturą polega na tym, że bardzo łatwo jest wymknąć się spod kontroli. W ogóle nie ma struktury, co oznacza, że ​​możesz zdefiniować dowolną właściwość na dowolnym poziomie, a wiele przedmiotów może stać się nieaktualnych.

Co więcej, zmiana poziomu średniego staje się niemożliwa w miarę rozwoju sieci, ponieważ wpływasz teraz na bardzo dużą liczbę serwerów.

Na koniec, każda pojedyncza instancja może potrzebować 1 specjalnej właściwości, co oznacza, że ​​twoje drzewo i tak kończy się konfiguracją dla każdego serwera, co czyni go niezbyt optymalnym rozwiązaniem.

Byłbym bardzo wdzięczny, jeśli masz jakieś sugestie / pomysły dotyczące lepszej architektury zarządzania konfiguracją.

Myślę, że musisz najpierw zadać sobie kilka pytań i wyjaśnić kilka kwestii, a następnie lepiej zdecydować, jak rozwiązać problem.

Po pierwsze: kto będzie kontrolował serwery?

• Czy to jeden administrator będzie kontrolował setki serwerów? Następnie należy scentralizować konfigurację w jak największym stopniu.

• A może każdy serwer jest potencjalnie pod kontrolą pojedynczego administratora, który nie chce, aby jego ustawienia zostały unieważnione lub kontrolowane przez scentralizowaną konfigurację? Następnie powinieneś skupić się na konfiguracji zdecentralizowanej. Jeśli każdy administrator ma garść serwerów do zarządzania maksymalnie, nadal można to zarządzać ręcznie.

Po drugie: czy naprawdę potrzebujesz ton opcji konfiguracji, czy możesz ograniczyć liczbę do kilku? Zamiast konfigurować „wszystko na wszelki wypadek”, lepiej ograniczyć się do opcji, o których wiesz, że twój system naprawdę potrzebuje. Można to zrobić na przykład przez

• sprawiając, że twoje oprogramowanie jest trochę mądrzejsze (na przykład, co program może ustalić automatycznie, pytając środowisko)?

• sztywne przestrzeganie „konwencji o konfiguracji” - na przykład poprzez ustanowienie pewnych konwencji nazewnictwa lub wyprowadzenie niektórych opcji jako domyślnych z innych opcji

Po trzecie: czy naprawdę chcesz, aby hierarchiczny poziom konfiguracji był zapisany na stałe w oprogramowaniu? Wyobraź sobie, że nie wiesz z góry, ile będzie serwerów, czy hierarchia drzewiasta jest dla nich najlepszą strukturą lub ile poziomów musi mieć to drzewo. Najprostszym rozwiązaniem, jakie mogę wymyślić, jest brak scentralizowanej konfiguracji, tylko jednego pliku konfiguracyjnego na serwer i pozwolenie administratorom odpowiedzialnego serwera samodzielnie zadecydować, jak rozwiązać problem zarządzania konfiguracjami wielu serwerów.

Na przykład administratorzy mogą pisać skrypty generatora, które dystrybuują centralny plik konfiguracyjny do grupy różnych serwerów i wprowadzają drobne modyfikacje do każdej kopii. W ten sposób nie musisz wcześniej przyjmować żadnych założeń dotyczących „topologii dystrybucji serwerów”, topologię można w dowolnym momencie dostosować do rzeczywistych wymagań. Wadą jest to, że potrzebujesz administratorów z pewną wiedzą na temat pisania skryptów w języku takim jak Perl, Python, Bash lub Powershell.

Osobiście nigdy nie lubiłem dziedziczenia plików konfiguracyjnych. Wspominasz o sekwencji ładowania, a nie wiesz, jak to jest zdefiniowane lub wyprowadzone. Być może pomaga to uczynić sekwencję oczywistą, odzwierciedlając ją w strukturze katalogów, w której umieszczasz pliki lub włączając je w nazwach plików.

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

To będzie działać do tego stopnia, że ​​masz agregację wartości konfiguracji, które nie są wyrównane z regionem. Musisz więc wziąć pod uwagę wybraną oś organizacyjną.

Bardziej podoba mi się izolowanie agregatów wartości konfiguracyjnych do ich własnych plików i posiadanie pliku konfiguracyjnego (liścia) do jednego.

Przykład:

bigcity.searchsettings.properties
regional.searchsettings.properties

Wewnątrz londonsettings.propertiesmożesz mieć wartość:

searchsettings:bigcity.searchsettings.properties

Pozwala to na więcej stopni swobody lub dodatkowy.

Miałem ten sam problem i otwarte źródło mojego rozwiązania. Możesz znaleźć kod źródłowy tutaj https://github.com/Bikeman868/Urchin

Używam go do dużego systemu z wieloma serwerami, z kilkoma aplikacjami na każdym serwerze i wieloma środowiskami. Zawiera interfejs napisany w Dart do zarządzania konfiguracją.

Możesz skontaktować się ze mną bezpośrednio, jeśli potrzebujesz pomocy w zejściu z ziemi.

Wdrożone przeze mnie rozwiązanie opiera się na regułach. Zasadniczo zaczynasz od jednej reguły, która ma zastosowanie do wszystkich konfiguracji, a następnie dodajesz reguły, takie jak: „wszystkie komputery w tym środowisku tworzą pliki dziennika do tej ścieżki UNC”. Reguły mogą być specyficzne dla środowiska, aplikacji, komputera lub instancji aplikacji. Reguły mogą być również bardziej szczegółowe, ponieważ tylko w tym konkretnym wystąpieniu tej aplikacji działającej na tym konkretnym serwerze.

Reguły są stosowane w kolejności od najmniej szczegółowej do najbardziej szczegółowej, a późniejsze reguły mogą zastępować wartości określone we wcześniejszych regułach. Oznacza to na przykład, że możesz utworzyć regułę, która ma zastosowanie do konkretnej aplikacji, a następnie zastąpić ją inną wartością dla określonej maszyny lub określonej instancji aplikacji itp.

Serwer ma interfejs REST + JSON, dzięki czemu współpracuje z większością systemów programistycznych, a także ma wygodną bibliotekę klientów dla aplikacji .Net.

Tego rodzaju ustawieniami są koszmarem do zarządzania. Najlepiej jest je maksymalnie ograniczyć, tak aby komponenty oprogramowania obsługiwały wszystkie przypadki.

tzn. zamiast konfigurowania serwera interfejsu API dla regionu, przekaż region z wywołaniem interfejsu API i pozwól, aby konfiguracja jednego serwera obsługiwała wszystkie regiony.

Jednak biorąc pod uwagę, że jesteś w stanie, w jakim się znajdujesz. Odradzam konfigurowanie systemu do generowania ustawień konfiguracji. To tylko zwiększa złożoność i tak już złożonego problemu.

Zamiast tego należy zapisać ustawienia w narzędziu do wdrażania dla każdego typu serwera. (ustawienia wdrażania ośmiornicy, przepisywanie plików teamcity itp.) Dzięki temu możesz mieć pewność, że wdrażasz te same ustawienia konfiguracji, co podczas ostatniej aktualizacji oprogramowania i dajesz dokładną kontrolę nad zmianami.

Nie chcesz znajdować się w sytuacji, gdy wprowadzasz zmiany w plikach meta-konfiguracji, a następnie musisz przetestować plik konfiguracyjny, który tworzy się w różnych regionach / serwerach / niestandardowych grupach

Brak badań; wszystkie osobiste opinie, ponad 30 doświadczenie IT. Brzmi jak skomplikowana struktura danych, którą można szybko zmieniać / modyfikować, z dużą liczbą użytkowników.

Rozważ repozytorium bazy danych (np. SQL), aby ustrukturyzować dane, z niestandardowymi procesami wyodrębniania, które tworzą indywidualne pliki konfiguracyjne dla każdego użytkownika. Możesz użyć zapytania do bazy danych, aby określić wpływ zmiany przed jej wdrożeniem; znaleźć zduplikowane wystąpienia itp. Pojedyncze pliki płaskie są częścią problemu. Dodatkowo możesz uzyskać dzienniki zmian i wsparcie odzyskiwania / odbudowy. Dzięki kontroli bazy danych można wyeliminować problem z dziedziczeniem konfiguracji. Tego rodzaju rozwiązanie będzie wymagało dodatkowej struktury bazy danych. Prawidłowa struktura klucza kompozytowego jest bardzo ważna.

To moja sugestia.

Możesz przyjrzeć się bardzo drogim systemom bezpieczeństwa i kontroli systemów dostawców, które wdrażają tego rodzaju usługi. Rozważ je. Zasadniczo będą one zależne od środowiska.