Jakie istnieją rozwiązania umożliwiające stosowanie kontroli wersji plików konfiguracyjnych serwera? [Zamknięte]

W środowisku z wieloma administratorami systemu widzę kilka zalet dodawania plików konfiguracyjnych serwera do systemu kontroli wersji. Najbardziej godne uwagi są możliwość śledzenia zmian, kto je wprowadził, i oczywiście możliwość przywrócenia znanych konfiguracji.

Interesują mnie głównie rozwiązania Unix / Linux, ale byłbym również ciekawy implementacji Windows.

Od jakiegoś czasu testowałem to w domu (~ 3 hosty), próbując różnych scms (RCS, Subversion, git). Konfiguracja, która teraz działa dla mnie idealnie, to git z setgitpermshakiem.

Rzeczy, które należy wziąć pod uwagę:

Obsługa uprawnień do plików i własności

• RCS: robi to natywnie
• Subversion: ostatnio próbowałem, svnaby to zrobić , musisz mieć opakowanie
• git: setgitpermshak obsługuje to w przejrzysty sposób (wymaga jednak dość nowej wersji git z obsługą post-checkouthaków)

Ponadto, jeśli nie chcesz mieć wszystkich /etcpod kontrolą wersji, ale tylko pliki, które faktycznie zmodyfikowałeś (jak ja), potrzebujesz scm, który obsługuje ten rodzaj użycia.

• RCS: w każdym razie działa tylko na pojedynczych plikach.
• Subversion: Uważam, że to trudne.
• git: bez problemu, umieść „ *” w .gitignorepliku najwyższego poziomu i dodaj tylko te pliki, których chcesz używaćgit add --force

Wreszcie, istnieją pewne problematyczne katalogi pod /etcktórym pakiety mogą spaść fragmenty konfiguracyjnych, które są następnie odczytywane przez jakiegoś programu lub demona ( /etc/cron.d, /etc/modprobe.d, itd.). Niektóre z tych programów są wystarczająco inteligentne, aby ignorować pliki RCS (np. Cron), inne nie (np. Modprobe). To samo dotyczy .svn katalogów. Ponownie duży plus dla git (tworzy tylko jeden .git katalog najwyższego poziomu ).

Zrobiłem to nieformalnie za pomocą git, ale jest też projekt etckeeper , który jest bardziej kompletnym i szczegółowym wdrożeniem.

Inną opcją jest użycie narzędzia do automatycznej konfiguracji serwera, takiego jak Puppet lub Cfengine, do skryptu konfiguracji serwera w języku deklaratywnym.

Jest to dodatkowa praca w interfejsie, ale użycie narzędzia takiego jak Puppet pozwala automatycznie odbudować i skonfigurować serwer przy bardzo niewielkiej interwencji człowieka.

Eksperymentowałem z etckeeperem, który wydaje się działać całkiem dobrze. Nie wymagam scentralizowanego serwera, co może być ważne w niektórych sytuacjach. Możesz użyć kilku różnych backendów DVCS, dzięki czemu możesz wybrać ten, który znasz najbardziej. Wydaje mi się, że działa bardzo dobrze, ale jeszcze nie próbowałem uzyskać innych technologii, w których pracuję, aby zacząć z niego korzystać.

Ostatnio patrzyłem na szefa kuchni . Nie tylko zachowuje konfiguracje szablonów (.erb) w kontroli wersji, ale umożliwia wykonywanie działań (takich jak ponowne uruchomienie usługi po przesłaniu konfiguracji do węzła). Szef kuchni pomaga w zarządzaniu pakietami, dzięki czemu możesz zweryfikować zależności z dowolnym węzłem, z którym się komunikujesz (tj. Musi mieć zainstalowany pakiet sudo). Wygląda na to, że szef kuchni jest łatwo rozszerzalny w Ruby, więc jeśli masz jakieś niestandardowe procesy, możesz po prostu napisać skrypt w dostarczonych ramach.

Ale nadal tego nie próbowałem i musisz zainstalować Ruby na kliencie i serwerze z odpowiednimi klejnotami (to naprawdę nie jest takie trudne). Ogólnie zarządzanie wieloma serwerami jednocześnie wygląda naprawdę łatwo.

Jestem w trakcie wdrażania Puppet w całej naszej infrastrukturze i bardzo sprzyja utrzymywaniu danych w kontroli wersji.

Wolę Mercurial, ponieważ jest to tylko zbiór plików z niektórymi metadanymi przechowywanymi w ukrytych katalogach (łatwy w zarządzaniu, łatwy do zrozumienia, łatwy w użyciu).

Moje pliki Puppet znajdują się w katalogu / usr / local / etc / puppet / (FreeBSD 7.1). Wystarczyło dodać do niej Mercurial:

> cd /usr/local/etc/puppet
> hg init

Wszystkie zmiany są zatwierdzane za pomocą prostego „zatwierdzenia hg”. Jeśli zmiana coś węża, mogę przywrócić każdy serwer do określonej wersji pliku (powiedzmy sudoers) za pomocą jednego polecenia.

Świetne wprowadzenie do Mercurial

Korzystam z Subversion na zarządzanych przeze mnie serwerach. Działa w porządku. Skonfigurowałem również instancję Trac , więc mamy widok osi czasu, system biletowy, przeglądanie itp.

Używając dowiązań symbolicznych, crona i subversion, skonfigurowałem również automatyczną dystrybucję konfiguracji opartą na repozytorium subversion, gdzie każdy serwer Linux aktualizuje repozytorium za svn updatepomocą skryptów (np. Skryptów zapory ogniowej).

Oto prawdziwy przykład użycia: Używany Subversion do zarządzania plikami konfiguracyjnymi na 4 różnych serwerach. Polecam użycie kontroli wersji dla plików konfiguracyjnych z tego samego powodu, dla którego użyjesz ich z kodem - jest to kopia zapasowa i przycisk cofania w jednym. Gdybym zarządzał znacznie większą liczbą serwerów i były one znacznie bliższe konfiguracji, użyłbym czegoś takiego jak Puppet, jak podano szczegółowo w odpowiedzi Berbericha.

Chodzi o to, że możesz mieć jedno repozytorium, w którym możesz wyewidencjonować określone foldery na serwerach (np. / Var / named /), więc mam zarówno historię, jak i kopię zapasową plików konfiguracyjnych (kopia jest premią, jeśli popełnisz błąd korzystania z aplikacji do konfiguracji GUI, która wyciera ręcznie edytowane dodatki kaszel Server Admin w Mac OS X Server kaszel ). Następnie można łatwo przetestować go na serwerze testowym, a następnie zaktualizować serwer produkcyjny o pliki, które działają bez ręcznego kopiowania plików.

Kilka lat temu stworzyłem projekt, aby zrobić dokładnie to: Savon

Używa subversion do przechowywania plików i ma kilka dodatkowych funkcji, takich jak śledzenie własności, uprawnień i kontekst SELinux. Umożliwia także logiczne dzielenie zmian w systemie plików na warstwy, dzięki czemu można na przykład śledzić zmiany, które powinny osobno dotyczyć wszystkich serwerów sieciowych.

Subversion jest bardzo łatwe w konfiguracji i obsłudze, a zasobów jest wiele:

Podstawowe instrukcje

Książka SVN

Przegląd zarządzania dokumentami

Większość naszych zmian jest zarządzana za pomocą naszego systemu pomocy technicznej, nawet w przypadku rutynowych czynności konserwacyjnych. Powoli przenoszymy naszą dokumentację na wiki na własny użytek i to, co publikujemy użytkownikom końcowym. Publikowanie zmian w konfiguracji i dyskusja za nimi, miło jest mieć otwarty w naszym intranecie.

Przez wiele lat korzystałem z rcs do plików, które zacząłem modyfikować, ale kilka lat temu zacząłem kontrolować cały plik / etc pod kontrolą git. Wymaga trochę pracy, aby sprawdzić pliki w ziarnistych ilościach (czasami uciekam się do ogromnego sprawdzania „różnych aktualizacji”) i napisałem kilka skryptów, które by w tym pomogły, ale wspomniany etckeeper wydaje się bardzo interesujący, spróbuję natychmiast.