Jak używać środowisk marionetek w Linux, aby bezpiecznie zaktualizować agenta

Cel

Utwórz i używaj środowisk marionetek, aby przetestować nową konfigurację przed aktualizacją systemu produkcji na żywo.

Wersje systemu operacyjnego i oprogramowania

• System operacyjny: Każdy główny rozkład Linuksa E.G. Ubuntu, Debian, centos
• Oprogramowanie: Mistrz marionetki i marionetki

Wymagania

Uprzywilejowany dostęp do serwera głównego marionetki i węzła klienta marionetki.

Konwencje

• # - Wymaga, aby podane polecenia Linux są wykonywane z uprawnieniami root bezpośrednio jako użytkownik root lub za pomocą sudo Komenda
• $ - Biorąc pod uwagę polecenia Linux, które mają być wykonywane jako zwykły użytkownik niepewny

Wstęp

Większość instalacji marionetkowych rozpoczyna życie jako serwer główny z pojedynczą gałęzią. Master zawiera wszystkie manifesty i inną konfigurację dla wszystkich agentów Puppet, które są z nim synchronizowane. Jest to dobre miejsce na rozpoczęcie, ale szybko nadejdzie czas, gdy aktualizacja wymaga pchania, która może potencjalnie złamać serwer produkcyjny. Mając nadzieję na najlepsze, nie jest najlepszym sposobem na kontynuację.

Puppet zapewnia narzędzia do oddzielenia całych gałęzi konfiguracji. Nazywane są środowiskami. Środowisko marionetkowe to sposób na dostarczenie odizolowanej grupy węzłów agentów z własną dedykowaną konfiguracją. Każde środowisko zawiera całe drzewo konfiguracyjne marionetek i może być uważane za osobny serwer Puppet Master.

Jak używane są środowiska marionetek?

Typowym scenariuszem dla środowisk i jest tym, który eksplorujemy w tym przewodniku, jest stworzenie środowiska testowego, obok środowiska produkcyjnego, w którym tworzona jest nowa konfiguracja marionetek.

Jednym ze sposobów przetestowania nowej konfiguracji w środowisku testowym jest aktualizacja kopii serwera produkcyjnego, takiej jak migawka VM. Wszelkie problemy będą obserwowane na komputerze testowym i konfiguracji marionetki zmodyfikowanej w celu poprawienia tego. Jednak nie zawsze możliwe jest posiadanie serwera testowego, aby sprawdzić zmiany w środowisku testowym.

Inną metodą i tą, którą zbadamy tutaj, jest ręczne uruchomienie agenta Puppet na serwerze produkcyjnym, ale użycie kilku opcji, które spowodują zsynchronizowanie agenta Puppet z środowiskiem testowym. To podkreśla wszelkie błędy, które miałyby miejsce w pełnej aktualizacji bez faktycznego wywoływania przestojów.

Tworzenie środowisk marionetkowych

W tym przewodniku utworzymy bardzo prostą instancję marionetkową z marionetką i węzłem agenta marionetki. Serwer Master Puppet zostanie skonfigurowany tak, aby miał dwa środowiska; Testowanie i rozwój.

Ten przewodnik zakłada, że ​​masz serwer Master Puppet i węzeł agenta marionetki, który jest w stanie połączyć się z Master Puppet Master.

Utworzymy dwa środowiska na Master Puppet i w tych środowiskach stworzymy bardzo prosty manifest marionetkowy, który tworzy plik tekstowy w węźle agenta.

Domyślna lokalizacja dla zmian konfiguracji Puppet w zależności. Na Ubuntu 18.04lts, wersja, która zostanie użyta w tym przewodniku, lokalizacja jest pod numerem /itp./Puppet. Inne dystrybucje (i oficjalna dokumentacja) mogą je umieścić na /etc/lalcela/. Jednak gdy znajdziesz się w głównym katalogu konfiguracji marionetek, wszystkie podwodne są takie same dla wszystkich rozkładów.

Instrukcje

Utwórz katalogi środowiska

Środowiska i ich konfiguracja istnieją pod /itp./Puppet/Code/ informator. Na Ubuntu 18.04 Ten katalog jest pusty podczas instalacji, więc będziemy musieli najpierw utworzyć dwa katalogi środowiska najwyższego poziomu za pomocą dwóch następujących poleceń:

# mkdir -p/etc/puppet/code/environments/testowanie # mkdir -p/etc/puppet/code/environments/rozwój 

Każdy nowy węzeł agenta będzie automatycznie połączyć się z rozwój środowisko, chyba że środowisko zmienna jest ustawiona na alternatywę w [agent] sekcja marionetka.conf plik w węźle agenta.

Tworzenie dwóch prostych witryn.PP manifestuje się

strona.pp Plik jest głównym manifestem, z którego agent marionetkowy zaczyna budować katalog pożądanego stanu maszyny. Stworzymy dwa bardzo proste strona.pp pliki w dwóch środowiskach, które tworzą ten sam plik w węźle agenta. Jedyną różnicą jest to, że umieścili inny tekst w pliku.

Pierwszy strona.pp Plik będzie środowiskiem produkcyjnym pod adresem:

/etc/puppet/code/środowiska/rozwój/manifesty/strona.pp

Ten plik powinien mieć następującą treść:

Plik '/tmp/przykład.txt ': Upewnij się => obecny, tryb => "0644", content => "z środowiska programistycznego \ n", 

Użyj swojego ulubionego edytora tekstu, aby utworzyć i wypełnić ten plik.

Ten manifest zapewnia obecność pliku w /tmp/przykład.tekst i zawiera tekst „ze środowiska programistycznego” („\ n” dodaje nową linię na końcu pliku, która jest dobrą praktyką i zatrzymuje marionetkę pokazującą komunikat ostrzegawczy, gdy nie jest obecny).

Drugi manifest będzie w środowisku testowym:

/etc/puppet/code/środowiska/testowanie/manifesty/strona.pp

Ten plik zawiera następujące:

Plik '/tmp/przykład.txt ': Upewnij się => obecny, tryb => "0644", content => "z środowiska testowania \ n", 

Jest to prawie identyczne z plikiem w środowisku programistycznym, z jedyną różnicą jest to, że tekst w pliku wskazuje, że pochodzi on z środowiska testowania.

Ocena nowej konfiguracji marionetek w środowisku testowym

Węzeł agenta będzie domyślnie zsynchronizować się tylko ze środowiskiem programistycznym. Najpierw ręcznie poinstruujemy agenta Puppet, aby zsynchronizował się z serwerem Master Puppet oraz utworzył i zastosować strona.pp że stworzyliśmy w środowisku programistycznym.

Odbywa się to z następującym poleceniem:

# agent marionetki -środowisko = produkcja -test 

--test Opcja sprawia, że ​​agent marionetkowy wykonuje katalog na pierwszym planie z rogowaniem w pełnym. Wszelkie aktualizacje lub zmiany zostaną zastosowane do węzła.

--Środowisko = produkcja Jest opcja, aby wyjaśnić, że synchronizujemy się ze środowiska produkcyjnego. Zwykle byłoby to skonfigurowane w głównej konfiguracji agenta marionetki i nie musiałoby być zawarte w poleceniu.

Po uruchomieniu powyższego polecenia otrzymujemy następujące dane wyjściowe:

 Informacje: Korzystanie z skonfigurowanego środowiska „Produkcja” Informacje: Odzyskiwanie wtyczek Informacje: Odzyskiwanie Wtyczek Informacje: Odzyskiwanie miejsc.Informacje netto: Stosowanie wersji konfiguracji „1527680694”.txt]/upewnij się: zdefiniowana treść jako 'MD5 59F9CE1D4AAD5FD155DB7CCCC2478A93B'.02 sekundy 

To wyjście wskazuje ten plik /tmp/przykład.tekst nie był obecny, więc agent marionetki utworzył go zgodnie z instrukcją strona.pp oczywisty. Kolejne biegi nie będą miały Ogłoszenie: linie jako /tmp/przykład.tekst Plik istnieje z poprawną zawartością.

Teraz, gdy państwo węzła agenta zgadza się z manifestą środowiska programistycznego, możemy sprawdzić, co by się stało, gdybyśmy zastosowali alternatywny manifest w środowisku testowym.

Aby przetestować i nie popełniać nowej konfiguracji, musimy uruchomić następujące polecenie:

# agent marionetki -środowisko = testowanie -test --noop 

Jak widać --środowisko Opcja została zmieniona na testowanie i uwzględniliśmy dodatkową opcję --Noop. Ta opcja sprawia, że ​​agent wykonuje suchy bieg. Oznacza to, że agent marionetkowy nie wprowadzi żadnych rzeczywistych zmian w węźle agenta, ale wytworzy wszystkie dane wyjściowe.

To pozwala nam ocenić, co by się stało, gdyby nowa konfiguracja została zastosowana do serwera. W takim przypadku wyjście powyższego polecenia wygląda jak:

 Informacje: Korzystanie z skonfigurowanego środowiska „Testowanie” INFORMACJE: Odzyskiwanie wtyczek INFORMACJE: Odzyskiwanie Wtyczek Informacje: Odzyskiwanie lokalizacji Informacje: Ładowanie FAKTÓW INFORMACJE: Zastosowanie konfiguracji wersja „1527683748”.txt]/content: ---/tmp/przykład.TXT 2018-05-30 12:19:16.205774048 +0000 +++ /TMP /Puppet-File20180530-21610-8ipzur 2018-05-30 12:35:48.740982652 +0000 @@ -1 +1 @@ -ZWIĄZANIE ŚRODOWISKA +Z ZWIĄTEK ZWIĘKSZENIA ŚRODOWEGO:/STAP [Main]/Main/File [/tmp/przykład.txt]/content: current_value 'MD5 59F9CE1D4AAD5FD155DB7CCC2478A93B', powinien być „MD5 ABBB8F68DF144A5673D 62AE6C4A036ED '(NOOP) wyzwalane „odświeżenie” od 1 Zawiadomienie o zdarzeniu: Katalog zastosowany w 0.04 sekundy 

Najciekawsze linie tutaj są następujące:

 -Z środowiska programistycznego +z środowiska testowego 

Wskazują one z symbolem minus ( -) co jest zmieniane z symbolu plus ( +) Co się zmieniam. W tym przykładzie jest to tekst w pliku.

Całe to wyjście wskazuje, że nowa konfiguracja zostałaby pomyślnie zastosowana, a zawartość /tmp/przykład.tekst zostałby zmodyfikowany. Jeśli jest to pożądany stan serwera produkcyjnego, to zmiany w strona.pp Plik można bezpiecznie wykonać w środowisku produkcyjnym.

Identyfikacja błędu

Nowa konfiguracja Puppet nie zawsze jest stosowana bez błędu i to jest powód, dla którego należy ją testować przed zastosowaniem do systemu produkcyjnego. W tym sytuacji wymusimy błąd, popełniając celowy błąd w testach strona.pp plik. Postaramy się ustawić uprawnienia pliku 0944 co nie jest prawidłowym pozwoleniem i spowoduje błąd.

Teraz, kiedy biegamy:

 # agent marionetki -środowisko = testowanie -test --noop 

Zobaczymy następujące dane wyjściowe:

 Informacje: Korzystanie z skonfigurowanego środowiska „Testowanie” INFORMACJE: Odzyskiwanie wtyczek INFORMACJE: Pobieranie Wtyczek Informacje: Odzyskiwanie lokalizacji Informacje: Ładowanie FAKTY Błąd: Nieudane zastosowanie katalogu: Tryb parametru nie powiódł się w pliku [/tmp/przykład.TXT]: Specyfikacja trybu pliku jest nieprawidłowa: „0944” (plik:/etc/puppetCode/Environments/Testing/Manifests/Site.PP, linia: 1) 

Poniższe przechwytywanie ekranu pokazuje to dane wyjściowe, ponieważ zostanie przedstawione w wierszu poleceń:

Kolory natychmiast poinformują nas, że wystąpiłby błąd w próbie użycia nowej konfiguracji marionetki w środowisku testowym. Jednak, jak używaliśmy --Noop Opcja Brak błędów na serwerze produkcyjnym.

Wniosek

Podczas uruchamiania systemów produkcyjnych zarządzanych przez Puppet zawsze ważne jest, aby przetestować każdą nową konfigurację przed zastosowaniem. Korzystanie z narzędzi, które zapewnia Puppet, aby stworzyć alternatywne środowiska, w których nowa konfiguracja można bezpiecznie tworzyć i ocenić w stosunku do systemów produkcyjnych, będzie oznaczać mniej błędów i mniej przestojów.

Powiązane samouczki Linux:

• Rzeczy do zainstalowania na Ubuntu 20.04
• Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
• Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
• Linux Pliki konfiguracyjne: Top 30 Najważniejsze
• Pobierz na żywo CD/DVD Linux
• Czy Linux może uzyskać wirusy? Badanie podatności Linuksa…
• Pobierz Linux
• Rzeczy do zrobienia po zainstalowaniu Ubuntu 22.04 JAMMY Jellyfish…
• Jak podwójnie rozruch Kali Linux i Windows 10
• Jak zaktualizować Firefox na Linux