Najlepszy sposób przechowywania plików konfiguracyjnych w SVN?

Question

Jaki jest najlepszy sposób przechowywania plików konfiguracyjnych (np. Httpd.conf, my.cnf, .bashrc ...) pod kontrolą wersji? W adition na korzyść wersjami, chcę rozwiązanie do pracy w charakterze kopii zapasowej, jak również tak, że mogę przynieść to nowy serwer i kasę (lub wywóz) pliki config z SVN bezpośrednio

Dobrym akcentem będzie do przechowywania oryginalnej ścieżki pliku konfiguracyjnego.

Answer 1

Robię to dla kilku maszyn, począwszy od starych Solaris 8 pudełek do systemu Mac OS X, a ja mam bardzo prosty układ:

W moim repozytorium Mam następujący:

<root>/common 
    /.emacs.d 
    /.bash_common 
    /scripts # platform-independent binary tools 

<root>/linux 
    .bashrc 
    .emacs 
    ... 

<root>/solaris 
    .bashrc 
    .emacs 
    ... 

<root>/osx 
    .bashrc 
    .emacs 
    ... 

Każdy w przypadku homedysów OS ma odniesienie svn: externals do .emacs.d, .bash_common i skryptów, więc nie są one duplikowane.

Ponadto mam .bash_hostconfig w katalogach linux i solaris z konfiguracją ścieżki specyficznej dla hosta i takie, ponieważ mam bardzo różne ustawienia w pracy niż w domu (FC5-8 i RHEL3-5, w zależności od tego, gdzie jestem).

Tak więc, pomiędzy tymi rzeczami, mam dość prosty proces uruchamiania i uruchamiania na nowej maszynie: Po prostu sprawdzam platformę/$ w katalogu tymczasowym, a następnie nadpisuję wszystko w $ HOME tymi plikami. Nie muszę przechowywać oryginalnej ścieżki, ponieważ w ten sposób zawsze odnosi się ona do $ HOME.

Answer 2

Steruję rewizją moich plików konfiguracyjnych, ale używam git zamiast svn (co jest łatwiejsze, gdy masz wiele maszyn). Mam skrypt bash (o nazwie install.sh), również w repozytorium, który albo kopiuje, albo dowiązuje symbolicznie pliki do ich odpowiedniej lokalizacji na komputerze.

Więc jeśli muszę skonfigurować na nowej maszynie, po prostu robię klon git repozytorium (który jest równoważny svn checkout) i uruchomić mój install.sh skonfigurować moje pliki konfiguracyjne w odpowiednich lokalizacjach. Posiadanie wartości install.sh oznacza, że ​​przechowuję oryginalną ścieżkę plików konfiguracyjnych, zgodnie z wolą użytkownika.

Answer 3

Używamy CVS do przechowywania konfiguracji w strukturze katalogów, która jest tak płaska, jak to możliwe. Ta technika jest łatwo rozszerzona na SVN.

to mamy Makefile skonfigurowany do korzystania z CVS eksport do:

1. utworzyć kopię struktury katalogów CVS bez elementów CV
2. utworzyć strukturę katalogów wymaganej dla maszyny docelowej w swojej katalog lokalny tak, jakbyś znajdował się w katalogu głównym na maszynie docelowej, np ./my_cvs_dir/etc/ .. i ./my_cvs_dir/usr/local/newapp/..,
3. skopiować pliki ze struktury CVS do docelowej struktury katalogów,
4. stworzyć archiwum dla struktury katalogu docelowego, i
5. wdrożyć tarball na maszynie docelowej.

Mamy również te tarby ustawione w rosnącej specjalizacji, np. Sol10, Apache, określone aplikacje itp.

HTH

okrzyki,

Rob

Answer 4

Cóż można przechowywać wszystkie pliki konfiguracyjne w ramach określonego drzewa katalogów, jeden sub-katalog na aplikację. Ponieważ większość aplikacji powinna mieć dyrektywę określającą ścieżkę do konfiguracji, to jest to jedyna rzecz, która ma zostać zmieniona (lub jeśli masz mocno zakodowane pliki konfiguracyjne, może coś takiego jest włączone) na serwer.

I to drzewo może zostać sprawdzone w dowolnym VCS, które lubisz.

Do wdrożenia można napisać skrypt powłoki lub coś, co inicjuje wszystko, aby użyć drzewa plików konfiguracyjnych.

Answer 5

To właśnie wdrożyliśmy:

Mam serwer, który nie rsync wszystkich configs w jednym katalogu (powiedzmy/data/configs/hostname/{etc, httpd}

mam. rsync działa co godzinę, aby przenieść zmiany. Gdy tylko rsync zostanie zakończony, istnieje skrypt svnautocommit, który automatycznie zatwierdza zmiany.W ten sposób mogę przywrócić dowolną zmianę lub dowolną wersję, którą chcę.Nie mogę cofnąć się do jakiejkolwiek zmiany lub dowolnej wersji, którą chcę.Tak,

Może być konieczne zaplanowanie struktury katalogów SVN w oparciu o Twoje wymagania:

Answer 6

Tak czy inaczej, chcecie sklepu centralnego, możecie wybrać coś nieco bardziej skomplikowanego, np. Slack. Zarządzasz i wersją kontrolujesz pliki na serwerze Push, a następnie synchronizujesz je z klientami. The explanation of subroles ma kilka przykładów na strukturę drzewa.