Użyj git dla wielu plików konfiguracyjnych serwera

Przeprowadziliśmy migrację wielu kodów źródłowych do git i jesteśmy bardzo zadowoleni z naszego obecnego rozwiązania. Chcielibyśmy, aby nasze pliki konfiguracyjne serwera były wersjonowane w tym samym systemie, ale jest kilka rzeczy, które nie działają tak, jak byśmy tego chcieli i mam nadzieję, że ktoś może podzielić się z nim swoimi doświadczeniami.

To pytanie jest podobne do korzystania z kontroli wersji plików konfiguracyjnych serwera? , ale mamy specjalne wymagania, które nie działają z sugestiami dotyczącymi tego pytania.

Obecna konfiguracja używa subversion do plików konfiguracyjnych. Odpowiednie repozytorium wygląda mniej więcej tak

 / # root repozytorium
 + - www.domain.com/ # konfiguracja dla www
 | \--itp/
 | \ - apache2 /
 + - dev.domain.com/ # konfiguracja dla dev
 | + - etc /
 | \--optować/
 | \ - app1 /         
 | \ - conf / # konfiguracja dla app1 na dev
 \ - staging.domain.com/ # konfiguracja do przemieszczania

Z subversion działałoby to dobrze, ponieważ możliwe jest po prostu pobranie podkatalogu repozytorium. Ponadto można użyć svn: externals, aby wskazać jedną wspólną strukturę dla kilku różnych konfiguracji. Musieliśmy mieć do czynienia tylko z plikami .svn we wszystkich wersjonowanych katalogach. Z drugiej strony Git nie ma svn: zewnętrzne i rzadkie kasy zawsze wymagają, aby ścieżka z katalogu głównego do rzeczywistego katalogu była taka sama.

Omawiając migrację do git, próbowałem zapisać główne wymagania dotyczące wersji konfiguracji serwera:

• chcemy tylko jednego repozytorium
• powinno być możliwe łatwe wprowadzanie zmian do centralnego pilota
• zestawy zmian powinny zawierać prawdziwego autora

Czy istnieje dobry sposób, aby mieć całą konfigurację w jednym repozytorium i mieć tylko ścieżkę pomocniczą jako kopię roboczą? Obecnie rozważam dwa podejścia, ale najpierw chciałem zadać to pytanie

1. Jeśli repozytorium .git znajduje się w stałej lokalizacji, np. Gdzieś w / var , możemy połączyć się z pod ścieżką z katalogu roboczego „docelowego”. Główny problem: nie wiedziałbym o sposobie „linkowania” z / etc do innego katalogu w celu importowania tylko zawartości, z wyjątkiem symlinkowania pojedynczych plików
2. Znalazłem inną alternatywę dla tego pytania SO , sugerując posiadanie wielu oddziałów w jednym repozytorium. Z pewnością zwiększyłoby to złożoność, ale widziałem, jak próbujemy w ten sposób.

Używanie git na jednym komputerze do zarządzania plikami konfiguracyjnymi działa dobrze, ale uważam, że musi być ktoś, kto używa go w sposób, w jaki chcielibyśmy go używać.

Dziękuję
Kariem

Użyłem już czegoś takiego; tak to działało.

Konfiguracja repozytorium

1. Utwórz repozytorium git, „etc_files”.
2. Utwórz gałąź dla każdego typu komputera, np. „Server / www”, „server / dev” itp.
   • git obsługuje ukośniki w nazwach gałęzi. To pomaga mi trzymać gałęzie prosto w głowie.
   • Jeśli masz mało komputerów, możesz zamiast tego mieć gałąź dla każdej maszyny.
3. Utwórz gałąź dla każdego elementu wspólnej infrastruktury, np. „Moduły / apache”, „moduły / kubki” itp.
   • Te gałęzie służą do przechowywania plików, które są takie same między wszystkimi komputerami, takich jak /etc/resolv.conf. Byłyby to pliki, które przechowujesz teraz w repozytoriach „svn: externals”.

Budowanie nowej maszyny

1. Na nowej maszynie sklonuj repozytorium git i sprawdź gałąź dla tego typu komputera.
   • Robię z tego klon tylko do odczytu, aby uniemożliwić ludziom dokonywanie zmian z maszyn produkcyjnych bez testowania.
2. Skonfiguruj zadanie crona, aby codziennie automatycznie git pulltworzyło repo.

Zmiana gałęzi maszyn

Zmiana kodu w pojedynczej gałęzi maszyny jest prosta; po prostu git checkoutodpowiednią gałąź w środowisku programistycznym, wprowadź zmiany i przekaż je z powrotem do centralnego repozytorium. Wszystkie komputery w tej gałęzi automatycznie otrzymają zmiany przy następnym uruchomieniu zadania cron.

Zmiana gałęzi modułów

Zmiana kodu gałęzi modułu jest tylko nieco trudniejsza, ponieważ obejmuje dwa etapy:

1. git checkout odpowiedni oddział modułu
2. Wprowadź zmiany i zatwierdź je na scentralizowanym serwerze.
3. git checkoutkażdą gałąź komputera, która korzysta z tej gałęzi modułu, a następnie scala z nią gałąź modułu. git zorientuje się, że wcześniej scaliłeś gałąź tego modułu i zauważysz tylko zmiany, które nastąpiły od czasu ostatniego wspólnego rodzica.

Ta metoda ma zarówno zalety, jak i wady. Jedną z korzyści jest to, że mogę dokonać zmiany w gałęzi modułu i zastosować ją do gałęzi maszyny, które jej potrzebują, co pozwala gałęziom maszyny, które nie pozostają w starszej wersji, dopóki nie będą gotowe. Wadą jest to, że musisz pamiętać o scaleniu gałęzi modułu z każdą gałęzią komputera, która może z niej korzystać. Używam skryptu, który przegląda drzewo zatwierdzeń i automatycznie dokonuje dla mnie scalenia, ale wciąż może być uciążliwe.

Alternatywnie, nowsze wersje git obsługują coś o nazwie „ submoduły ”:

Podmoduły pozwalają na osadzanie obcych repozytoriów w dedykowanym podkatalogu drzewa źródłowego, zawsze wskazanym na konkretny zatwierdzenie.

Pozwoliłoby to zbudować coś w rodzaju drzewa „svn: externals”, które można następnie zaktualizować w taki sam sposób, jak teraz.

Trochę nubu tutaj, ale wygląda na to, że hak odbierania postów mógłby wykonać zadanie

Repo master jest przechowywany w / var / master,
hak klonuje go do / var / localclone,
a następnie kopiuje dane specyficzne dla hosta
Konieczne byłoby skonfigurowanie haka .git / post-receive lokalnie na każdym serwerze (z odpowiednimi ustawieniami)

Wygląda na to, że chcesz czegoś bardziej podobnego do marionetki lub szefa kuchni niż git. Pozwoli to uruchomić git, aby centralnie zarządzać konfiguracjami i modułami, a puppet \ chef zarządza wdrażaniem i weryfikacją dla ciebie

oto krótka praca, o której pomyślałem:
1. Miej centralne repozytorium w powiedzmy /var/repo
2. Umieść pliki globalne we wszystkich domenach w tym katalogu.
3. Tworzenie oddziałów dla każdej subdomeny /var/repo/subdomain1, /var/repo/subdomain2itd.
4. Tworzenie hak pocztowy, gdzie każdy push gałęzi jest połączona z mastera.

Kiedy więc zmienisz konfigurację /var/repo/subdomain2, jest ona natychmiast łączona z masterem, dzięki czemu możesz całkowicie pobrać repo i mieć wszystkie pliki konfiguracyjne.
Jeśli chcesz pobrać pojedyncze konfiguracje subdomen, po prostu pociągnij odpowiednią gałąź.

Jak wkładasz pliki konfiguracyjne, /var/repo/*to zupełnie inna sprawa (zakładki cron, mogę wymyślić)

~ $