Marionetka w rzeczywistości nadaje się całkiem dobrze do środowisk z wieloma mistrzami, z pewnymi zastrzeżeniami. Główny? Wiele części Lalek lubi być scentralizowanych. Urząd certyfikacji, usługi związane z inwentaryzacją i pulpitem nawigacyjnym / raportowaniem, gromadzeniem plików i przechowywanymi konfiguracjami - wszystkie są w najlepszej formie (lub po prostu wymagają) konfiguracji, w której jest tylko jedno miejsce do rozmowy.
Jest jednak całkiem wykonalne, aby wiele ruchomych części pracowało w środowisku z wieloma wzorcami, jeśli nie masz nic przeciwko płynnej utracie niektórych funkcji po utracie głównej witryny.
Zacznijmy od podstawowej funkcji, aby węzeł raportował do mastera:
Moduły i manifesty
Ta część jest prosta. Kontrola wersji. Jeśli jest to rozproszony system kontroli wersji, po prostu scentralizuj i zsynchronizuj oraz odpowiednio zmodyfikuj przepływ push / pull w witrynie trybu failover. Jeśli jest to Subversion, prawdopodobnie będziesz chciał svnsyncrepozytorium na swojej stronie trybu failover.
Urząd certyfikacji
Jedną z opcji jest tutaj synchronizacja plików urzędu certyfikacji między wzorcami, aby wszystkie miały ten sam certyfikat główny i mogły podpisywać certyfikaty. Zawsze wydawało mi się, że „robię to źle”;
- Czy jeden master powinien naprawdę widzieć swój certyfikat prezentowany w autoryzacji klienta dla połączenia przychodzącego z innego master jako ważny?
- Czy to niezawodnie zadziała w przypadku usługi inwentaryzacji, deski rozdzielczej itp.?
- Jak dodać dodatkowe prawidłowe nazwy alternatywne DNS w dalszej części drogi?
Nie mogę szczerze powiedzieć, że dokładnie przetestowałem tę opcję, ponieważ wydaje się to okropne. Jednak wydaje się, że Puppet Labs nie chcą zachęcać do tej opcji, zgodnie z notatką tutaj .
Więc to, co pozostawia, to mieć centralnego mistrza CA. Wszystkie relacje zaufania działają nadal, gdy urząd certyfikacji jest wyłączony, ponieważ wszyscy klienci i inni mistrzowie buforują certyfikat urzędu certyfikacji i listę CRL (chociaż nie odświeżają listy CRL tak często, jak powinni), ale nie będzie można podpisywać nowych certyfikatów, dopóki odzyskujesz główną witrynę lub przywracasz główny urząd certyfikacji z kopii zapasowych w witrynie przełączania awaryjnego.
Wybierz jednego wzorca, który będzie pełnił rolę urzędu certyfikacji, i wyłącz wszystkie pozostałe wzorce:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Następnie chcesz, aby ten system centralny pobierał cały ruch związany z certyfikatem. Jest na to kilka opcji;
- Użyj obsługi nowego
SRVrekordu w 3.0, aby skierować wszystkie węzły agenta we właściwe miejsce dla urzędu certyfikacji -_x-puppet-ca._tcp.example.com
- Ustaw
ca_serveropcję konfiguracji we puppet.confwszystkich agentach
Proxy cały ruch dla żądań związanych z urzędami certyfikacji od agentów do właściwego wzorca. Na przykład, jeśli uruchamiasz wszystkie swoje serwery główne w Apache przez pasażera, skonfiguruj to na urządzeniach innych niż CA:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
I to powinno wystarczyć.
Zanim przejdziemy do usług pomocniczych, notatka dodatkowa;
Nazwy DNS dla certyfikatów głównych
Myślę, że właśnie tutaj jest najbardziej przekonujący powód przejścia na wersję 3.0. Powiedzmy, że chcesz wskazać węzeł na „dowolnego mistrza roboczego”.
W wersji 2.7 potrzebujesz ogólnej nazwy DNS puppet.example.com, a wszyscy mistrzowie potrzebują jej w swoim certyfikacie. Oznacza to ustawienie dns_alt_namesw ich konfiguracji, ponowne wystawienie certyfikatu, który mieli przed skonfigurowaniem go jako wzorca, ponowne wystawienie certyfikatu ponownie, gdy trzeba dodać nową nazwę DNS do listy (na przykład, jeśli chcesz wielu nazw DNS, aby agenci wolą mistrzów na swojej stronie) .. brzydkie.
W wersji 3.0 możesz używać SRVrekordów. Daj to wszystkim swoim klientom;
[main]
use_srv_records = true
srv_domain = example.com
Zatem nie są wymagane specjalne certyfikaty dla mistrzów - po prostu dodaj nowy rekord do swojego SRVRR na _x-puppet._tcp.example.comi jesteś gotowy, to mistrz na żywo w grupie. Co więcej, możesz łatwo uczynić logikę wyboru głównego bardziej wyrafinowaną; „dowolny stary mistrz pracy, ale wolisz ten w swojej witrynie”, ustanawiając różne zestawy SRVrekordów dla różnych witryn; nie dns_alt_namespotrzebne
Raporty / pulpit nawigacyjny
Ten działa najlepiej scentralizowany, ale jeśli możesz żyć bez niego, gdy Twoja podstawowa strona nie działa, nie ma problemu. Po prostu skonfiguruj wszystkich swoich mistrzów w odpowiednim miejscu do umieszczenia raportów.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
... i wszystko gotowe. Nieprzesłanie raportu nie jest krytyczne dla uruchomienia konfiguracji; po prostu przepadnie, jeśli toast serwera deski rozdzielczej.
Inwentaryzacja faktów
Kolejną miłą rzeczą, którą przykleiłem do deski rozdzielczej, jest usługa inwentaryzacji. Przy facts_terminusustawieniu na restzalecanym w dokumentacji spowoduje to przerwanie uruchamiania konfiguracji, gdy centralna usługa spisu jest wyłączona. Sztuczka polega na tym, aby użyć inventory_serviceterminala na nie-centralnych masterach, co pozwala na pełną wdzięku porażkę.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Ustaw centralny serwer zapasów w taki sposób, aby przechowywał dane zapasów za pośrednictwem ActiveRecord lub PuppetDB i powinien być na bieżąco, gdy usługa będzie dostępna.
Tak więc - jeśli nie masz nic przeciwko temu, aby przejść do całkiem przyzwoitego środowiska zarządzania konfiguracją, w którym nie możesz nawet użyć urzędu certyfikacji do podpisania certyfikatu nowego węzła, dopóki nie zostanie przywrócony, to może to działać dobrze - choć byłoby naprawdę fajnie jeśli niektóre z tych komponentów były nieco bardziej przyjazne dla dystrybucji .