Zamierzam wdrożyć ~ 25 serwerów z systemem Debian . Maszyny będą miały różne role - serwery WWW, serwery Java, serwery proxy, skrzynki MySQL. Środowisko prawdopodobnie nie wzrośnie w przyszłości - może 2-5 więcej serwerów w ciągu najbliższych 2 lat.
Prawdopodobnie użyję Fai do instalacji systemu, ale nie jestem pewien, czy warto dodać do tak małej skali scentralizowane zarządzanie konfiguracją cfengine lub marionetką .
Czy zarządzanie konfiguracją ma sens w środowisku o takiej wielkości?
Odpowiedzi:
Polecam użycie mieszanki wstępnego uruchamiania Debiana, w której dajesz instalatorowi plik tekstowy, który odpowiada na wszystkie zadane pytania, oraz Puppet.
Powodem korzystania ze wstępnego siewu, a nie FAI, jest to, że nie musisz najpierw konfigurować obrazu i zajmować się jego aktualizacją. Skończysz z instalacją bardzo podobną do tej, którą miałbyś, gdybyś zrobił to wszystko ręcznie. Kiedy przyjdziesz zainstalować nową wersję, będziesz musiał zaktualizować plik konfiguracyjny ze zmianami, zamiast odbudowywać nowy obraz.
Narzędzie do zarządzania konfiguracją jest szczególnie przydatne, gdy masz kilka serwerów pełniących tę samą rolę i chcesz, aby były one identyczne, np. Klaster serwerów WWW. Mogą być jednak również przydatne do konfigurowania podstawowej instalacji wszystkich serwerów. Będziesz chciał zainstalować określone pakiety na wszystkich swoich serwerach, takich jak ntpd i MTA. Będziesz chciał zmienić plik konfiguracyjny na wszystkich swoich serwerach. Dodatkową korzyścią jest to, że możesz przechowywać swoje manifesty w coś takiego jak subversion i prowadzić rejestr tego, co zmieniło się na serwerze, kto to zrobił i dlaczego. Zarządzanie konfiguracją może również uratować życie w przypadku awarii serwera i trzeba go szybko odbudować. Zainstaluj system operacyjny (za pomocą FAI lub preseeding), zainstaluj marionetkę i odejdzie, zbudowana dokładnie tak, jak wcześniej. Oczywiście będziesz musiał przechowywać kopie zapasowe danych.
Zarządzanie konfiguracją wymaga poświęcenia, aby upewnić się, że wprowadzasz tylko zmiany przy jej użyciu i że będziesz musiał skonfigurować koszty początkowe, ale gdy już będziesz mieć działającą konfigurację, nie pożałujesz.
Marionetka jest bardziej nowoczesnym z dwóch wspomnianych narzędzi. Naprawdę polecam każdemu. Konfiguracja jest językiem deklaratywnym i łatwo jest budować konstrukcje wyższego poziomu. Wokół niego jest także bardzo duża społeczność i zawsze są ludzie mile widziani do pomocy na liście mailingowej lub kanale IRC.
Polecam CFengine dla każdego środowiska, które ma więcej niż 2-3 pudełka i gdzie masz jakieś pojęcie o „szablonach” lub serwerach wykonujących określone role.
Czemu? Mówiąc najprościej, redukuje liczbę błędów, masz narzędzie, które zapewni, że uprawnienia do plików / katalogów będą poprawne wszędzie w środowisku, a kiedy przyjdziesz na wdrożenie większej liczby serwerów, narzędzie obsługuje absolutnie wszystko i nigdy nie popełnia błędów.
Porównajmy się nawet z wykwalifikowanym administratorem systemu, który uruchamia serwer WWW pod koniec dwunastogodzinnej zmiany, gdy już coś poszło nie tak ... Czy oni prawdopodobnie pamiętają ten paskudny mały plik konfiguracyjny, który musi znaleźć się w / etc / random / location / foo / bar, w przeciwnym razie aplikacja po cichu nie zrobi czegoś raczej ważnego, np. klienci rachunków? :)
Narzędzia takie jak CFengine to także świetny sposób na przeprowadzanie aktualizacji bezpieczeństwa w całym środowisku. Upuszczenie konfiguracji Nagios (NRPE) na wszystkie pola to także unik. Niezależnie od tego czy mamy do czynienia z pięciu pól lub pięć sto skrzynek Ci będzie zaoszczędzić czas z cfengine.
Prawdopodobnie warto zauważyć, że moje środowisko jest nieco większe, jednak wdrożyłem również CFengine dla mniejszych środowisk niż zauważyłeś, stąd zalecenie!
Prawdopodobnie twoim następnym pytaniem będzie CFengine vs. Puppet? To trudniejsza decyzja i zawsze chodziłem na CFengine z powodu (na początku) niedojrzałości ze strony Puppet, szczególnie w związku z rejestrowaniem błędów ... w dzisiejszych czasach naprawdę nie jestem pewien - czy grasz? Patrząc wstecz na moje specyficzne problemy ze Puppet, były one związane z certyfikatem SSL, boleśnie pamiętam czas, który spędziłem 3 godziny diagnozując problemy z połączeniem serwera <-> klienta w irc.freenode.net/#puppet z kilkoma potężnymi RTFM i RTFS tylko po to, aby znaleźć błąd, brak zalogowania, a Luke powiedział: „Ach, to naprawdę trudne do naprawienia” i nigdy tego nie zrobił. :(
Oprócz cengengine i marionetki jest też szef kuchni . Zdecydowanie sugeruję użycie jednego z tych narzędzi, ponieważ rzeczy zawsze będą rosły w nieoczekiwanych kierunkach. Pomaga to zarządzać rzeczami w scentralizowanej lokalizacji.
Ważne jest, aby rozpoznać, że prawdopodobnie nie dostaniesz wszystkiego, ale jeśli możesz uzyskać co najmniej 90%, to początek. Poza tym jest fajna i na dłuższą metę ułatwi ci życie. Na koniec dobrze jest iść naprzód.
Używam cfengine od 5 lat do instalacji Debiana (od Woody'ego aż do Lenny'ego). Z etch buduję niestandardowy instalator Debiana. Dzięki preseed pojawia się jedno pytanie: „jaka jest nazwa hosta”. Po tym cfengine konfiguruje cały serwer (dns + dhcp z dnssec, samba, ntpd, domyślni (Samba) użytkownicy i hasła, ssh, openvpn, apache vHosts, tworzenie kopii zapasowych za pomocą rsnapshot na LVM, niestandardowe moduły webmin itp.).
Nawet gdy instaluję tylko jeden serwer, używam skryptów cfengine z mojego zestawu narzędzi w następujący sposób:
control:
Repository = ( $(CFREPO) )
IfElapsed = ( 0 )
Syslog = ( on )
actionsequence = ( editfiles shellcommands )
CPTYPE = ( sum )
editfiles:
{ /etc/sysctl.conf
# don't spam on tty:
BeginGroupIfNoSuchLine "kernel.printk.*=.*2 4 1 7"
DeleteLinesMatching "^kernel.printk.*=.*"
Append "kernel/printk=2 4 1 7"
EndGroup
# no E(xplicit?) C(ongestion) N(otification)
BeginGroupIfNoSuchLine "net.ipv4.tcp_ecn.*=.*0"
DeleteLinesMatching "^net.ipv4.tcp_ecn.*=.*"
Append "net/ipv4/tcp_ecn=0"
EndGroup
BeginGroupIfNoSuchLine "net.ipv4.ip_forward.*=.*1"
DeleteLinesMatching "^net.ipv4.ip_forward.*=.*"
Append "net/ipv4/ip_forward=1"
EndGroup
DefineClasses "configchange_sysctl"
}
shellcommands:
configchange_sysctl::
"/sbin/sysctl -p /etc/sysctl.conf"
# vim: set ts=2:
Lubię cfengine, ponieważ skrypty cf2 są nieco czytelne dla ludzi.
więc zdecydowanie warto pracować z narzędziami do automatycznego zarządzania konfiguracją.
/ thorsten
To musi być tego warte nawet dla małej witryny. Chodzi o spójność w miarę dorastania. I wiesz, że Twoja strona będzie się rozwijać. Najlepiej zacząć, gdy jesteś jeszcze mały. Cfengine jest niesamowity. Zwłaszcza wersja 3, która może obsłużyć wszystkich menedżerów pakietów w terenie, jest naprawdę lekka i bezpieczna i „po prostu działa”. Marionetka po prostu nie spełniła oczekiwań. Nie próbowałem szefa kuchni.
Zaletą cfengine w porównaniu z innymi jest to, że jest bardzo lekki, ale w rzeczywistości ma więcej możliwości. Jego bezpieczeństwo przypomina ssh, a nie certyfikaty sieciowe używane przez marionetkę. Kiedy powiedziałem mojemu szefowi o cfengine, pomyślał, że to science fiction :) Jeśli szukasz czegoś futurystycznego, spróbuj przeczytać kilka artykułów naukowych Marc Burgess. Fajne rzeczy.
Najważniejszym narzędziem, które chciałbym mieć podczas prowadzenia małej witryny, jest kompilacja „przycisku”. Ułatwia to łatanie, aktualizowanie i przebudowywanie, co może rozwiązać wiele innych problemów w przyszłości.
Brak ssh poprawnie zainstalowany na wszystkich urządzeniach? nie ma też curl / wget / vim? co z innymi wewnętrznymi narzędziami, które chcesz mieć na każdym pudełku?
Centralne zarządzanie serwerami jest jednym z pierwszych narzędzi, które powinieneś mieć, aby znacznie ułatwić przyszłe wysiłki.
Zgadzam się z każdym tutaj. Powinieneś zacząć uczyć się i konfigurować działającą infrastrukturę, gdy nie jesteś zbyt duży. Ponieważ wtedy jesteś przygotowany, gdy dorośniesz.
W zależności od tego, co chcesz uruchomić, wybrałbym FAI, cfengine i pre-seeding dla Debian / Ubuntu. FAI może pracować z wieloma różnymi narzędziami, więc jest to dobry początek dla każdej dystrybucji podobnej do Debiana. Dzięki kontrolowanej przez klasę konfiguracji FAI (i cfengine) możesz łatwo podzielić swoje instalacje na małe moduły, które następnie możesz wybrać, które będą używane dla każdej maszyny. W ten sposób przyda się, nawet jeśli masz wiele różnych maszyn. Jest to w rzeczywistości bardziej przydatne, ponieważ udokumentujesz swoją instalację za pomocą tych skryptów. A kiedy instalujesz na nowym komputerze, niczego nie zapomnisz.
Tak, powinieneś mieć kilka komputerów do przetestowania przed wdrożeniem zmian w instalacji na żywo. Ale dzięki takiemu skryptowi konfiguracyjnemu nie zapomnisz wykonać żadnego kroku w instalacji na żywo.