Czym NIE powinna zarządzać marionetka?

67

Uczę się, jak zarządzać konfiguracją w ogóle, aw szczególności za pomocą kukiełki. Zastanawiam się, jakie aspekty systemu, jeśli w ogóle, nie powinny być zarządzane za pomocą kukiełki?

Jako przykład zwykle przyjmujemy za pewnik, że nazwy hostów są już skonfigurowane przed wypożyczeniem systemu do zarządzania marionetką. Musi działać podstawowa łączność IP, przynajmniej w sieci używanej do uzyskania dostępu do puppetmaster. Używanie marionetki do automatycznego tworzenia plików strefy dns jest kuszące, ale wskaźniki zwrotne DNS powinny być już na miejscu przed uruchomieniem rzeczy, inaczej certyfikaty będą śmieszne.

Czy powinienem pominąć konfigurację adresu IP z kukiełki? Czy powinienem skonfigurować go przed pierwszym uruchomieniem marionetki, ale mimo to zarządzać adresami IP za pomocą marionetki? Co z systemami z wieloma adresami IP (np. Dla WAN, LAN i SAN)?

Co z IPMI ? Możesz skonfigurować większość, jeśli nie wszystkie, za pomocą ipmitool , oszczędzając ci dostępu do konsoli (fizyczny, szeregowy przez LAN, zdalny KVM, cokolwiek), dzięki czemu można go zautomatyzować za pomocą marionetki. Ale ponowne sprawdzanie jego stanu przy każdym uruchomieniu agenta marionetek nie brzmi dla mnie fajnie, a podstawowe wyłączanie dostępu do systemu to coś, co chciałbym mieć przed zrobieniem czegoś innego.

Kolejna cała historia dotyczy instalowania aktualizacji. Nie wchodzę w ten konkretny punkt, jest już wiele pytań na temat SF i wielu różnych filozofii między różnymi administratorami. Sam postanowiłem nie pozwalać marionetce aktualizować rzeczy (np. Tylko ensure => installed) i robić aktualizacje ręcznie, jak już jesteśmy przyzwyczajeni, pozostawiając automatyzację tego zadania do późniejszego dnia, kiedy będziemy bardziej pewni co do marionetki (np. Dodając MCollective do mieszanka).

To tylko kilka przykładów, które mam teraz na myśli. Czy jest jakiś aspekt systemu, który powinien być pozostawiony poza zasięgiem kukiełki? Lub, powiedziano inaczej, gdzie jest granica między tym, co należy skonfigurować w czasie udostępniania a „statycznie” skonfigurowanym w systemie, a tym, co jest obsługiwane przez scentralizowane zarządzanie konfiguracją?

Luke404
źródło
1
Miłe pytanie. Jestem ciekawy, czy jest coś innego niż konfiguracje specyficzne dla maszyny, do których nie powinieneś używać marionetki. Cóż, to i maszyny z systemem Windows.
HopelessN00b,
6
<vague> Nie powinieneś zarządzać rzeczami w marionetce, gdy lepiej / łatwiej jest nimi zarządzać w inny sposób. </vague>: p
Zoredache
1
W dzisiejszych czasach, gdy firmy używają Puppet, widzę, że pytanie to zyskuje dużą uwagę w ciągu najbliższych kilku lat
Daniel Li

Odpowiedzi:

24

Ogólna zasada: jeśli korzystasz z zarządzania konfiguracją, zarządzaj każdym aspektem konfiguracji, który możesz. Im bardziej scentralizujesz się, tym łatwiej będzie skalować środowisko.

Konkretne przykłady (wyciągnięte z pytania, wszystkie narracje „Oto dlaczego chcesz nim zarządzać”):


Konfiguracja sieci IP

OK, oczywiście, skonfigurowałeś adres / bramę / NS na maszynie przed upuszczeniem go do szafy. Mam na myśli, jeśli nie zrobiłbyś, jak uruchomić marionetkę, aby wykonać resztę konfiguracji?

Ale powiedz teraz, że dodajesz kolejny serwer nazw do swojego środowiska i musisz zaktualizować wszystkie swoje maszyny - czy nie chcesz, aby system zarządzania konfiguracją zrobił to za Ciebie?

Lub powiedzmy, że twoja firma została przejęta, a twoja nowa firma macierzysta wymaga zmiany adresu z 192.168.0.0/24 na 10.11.12.0/24, aby dopasować się do ich systemu numeracji.

Albo nagle dostajesz masową umowę rządową - Jedynym haczykiem jest, że musisz włączyć PRAWO DO POBRANIA IPv6 TERAZ albo umowa zostanie zawalona ....

Wygląda na to, że konfiguracja sieci to coś, czym chcielibyśmy zarządzać ...


Konfiguracja IPMI

Podobnie jak w przypadku adresów IP, jestem pewien, że skonfigurowałeś to przed umieszczeniem urządzenia w szafie - Po prostu dobrze jest włączyć IPMI, zdalną konsolę itp. Na dowolnej maszynie, która ma taką możliwość, a te konfiguracje nie nie zmienisz dużo ...

... Aż do tej hipotetycznej akwizycji, o której wspomniałem w powyższej konfiguracji IP - Powodem, dla którego zmuszono cię do opuszczenia tych adresów 192.168-net, jest to, że zgodnie z twoimi nowymi korporacyjnymi panami jest to ziemia IPMI i musisz zaktualizować wszystkie swoje karty IPMI TERAZ, ponieważ będą deptać czyjąś zarezerwowaną przestrzeń IP.

OK, tutaj jest trochę rozciągłości, ale jak powiedziałeś - wszystko to można zarządzać ipmitool, więc dlaczego nie uruchomić Puppet narzędzia i potwierdzić konfigurację, wykonując wszystkie inne czynności? Mam na myśli, że to nic nie zaszkodzi, więc równie dobrze możemy uwzględnić IPMI ...


Aktualizacje

Aktualizacje oprogramowania są bardziej szarym obszarem - w mojej organizacji oceniliśmy marionetkę do tego celu i stwierdziliśmy, że „bardzo jej brakuje”, więc używamy radminddo tego celu. Nie ma powodu, dla którego Puppet nie może wywołać radmind - w rzeczywistości, jeśli / kiedy przeprowadzimy migrację do Puppet w celu zarządzania konfiguracją, dokładnie to się stanie!

Ważne jest, aby wszystkie aktualizacje były instalowane w standardowy sposób (standardowy w całej organizacji lub standardowy na platformach) - Nie ma powodu, dla którego Puppet nie powinien uruchamiać procesu aktualizacji, o ile dokładnie go przetestowałeś wszystko po to, aby Puppet niczego nie zepsuł.
Nie ma również powodu, dla którego Puppet nie może przywołać narzędzia, które lepiej nadaje się do tego zadania, jeśli ustaliłeś, że Puppet nie jest w stanie samodzielnie wykonać dobrej roboty ...

voretaq7
źródło
Odp: Aktualizacje. Jedną z rzeczy, które mogą sprawić kłopoty z uruchomieniem aktualizacji przez marionetkę, jest załatanie krytycznej usługi, np .: mysql, apache - nie chcesz, aby te restartowały się z zachcianką. Puppet zapewnia sposoby na zablokowanie wersji tych pakietów, dlatego właśnie tego uniknąłem, ciesząc się ogólnymi aktualizacjami innych nakrętek i śrub.
cienki
@ cienkie To dobra uwaga, ale moim zwykłym kontrapunktem jest uderzanie ludzi w tył głowy i krzyczenie REDUNDANCY naprawdę bardzo głośno :-) (To gorsza sytuacja z radmindem, ponieważ to po prostu psuje system plików. Naszą zasadą jest moduł równoważenia obciążenia zwalnia połowę serwerów, abyśmy mogli je załatać / przetestować, a następnie przenosimy wszystkich na łatane komputery, abyśmy mogli zrobić drugą połowę. Działa dobrze, ale potrzebujesz wbudowanej nadmiarowości w swoim środowisku.)
voretaq7
10

Nie wymyślaj koła na nowo.

Tak, możesz mieć 50 marionetkowych wirtualnych zasobów użytkownika i realizować je w razie potrzeby w swoich modułach ... ale jeśli możesz, użyj LDAP.

Mówię z gorzkiego doświadczenia. Chociaż ldap nie jest tu jeszcze opcją.

Kolejnym przykładem jest wypychanie plików hostów, a nie tylko korzystanie z DNS.

Sirex
źródło
3
Rozumiem wszystkie te słowa, ale wciąż nie jestem pewien, co próbujesz powiedzieć.
Chris S
2
Próbuję powiedzieć; kukiełka jest centralnym miejscem „informacji”. Podobnie jak DNS i LDAP. Nie próbuj wykonywać swojej pracy z marionetką, to śmiecie ... Mówię, że widziałem, jak wielkie pliki / etc / hosts są wypychane z marionetką za każdym razem, gdy nowy host dołącza do sieci.
Sirex,
3
Czy ludzie naprawdę używają Puppet zamiast LDAP do zarządzania kontami użytkowników?
Joel E Salas
2
Każde narzędzie ma swoje miejsce, ale używanie marionetki do zarządzania kontami użytkowników lub LDAP do przechowywania plików to nadużycie .
Hubert Kario
1
Jest to z pewnością ab wykorzystanie ...
jldugger
9
  • Puppet nie jest systemem orkiestracji. W szczególności:
    • Marionetka nie jest dobrze przystosowana do aranżacji maszyn wirtualnych, ponieważ maszyny wirtualne mają własny cykl życia, którego należy przestrzegać.
    • Puppet nie nadaje się do zarządzania wydaniami aplikacji / złożonych aktualizacji. W tym celu można wykorzystać samodzielne przebiegi marionetek, ale przynajmniej nie kontroluje się Marionetka, zamiast tego są to twoje skrypty opakowania lub ludzki robot, co jest w porządku.
  • Puppet nie jest dobrym systemem zarządzania użytkownikami (aby zarządzać każdym wpisem, nawet użytkownikami usuniętymi). Znajdź inne rozwiązanie)
  • Puppet nie jest dobrą bazą danych konfiguracji (spójrz na użycie jakiejś zewnętrznej bazy danych oraz ENC, Hiera lub podobny klej)

Oczywiście wszystkie te rzeczy możesz zrobić za pomocą Puppet ... ale nie jest to dla nich najlepsze rozwiązanie. Czasami powinieneś odłożyć młotek i poszukać klucza.

Puppet jest jednak niezmiernie dobry w utrzymywaniu podstawowej konfiguracji komputera i instalowaniu narzędzi, które pozwalają ci wykonywać VM i zwalniać orkiestrację, zarządzanie użytkownikami itp.

Robert M. Thomson
źródło
Więcej sporów: Puppet można skonfigurować tak, aby dodawał i usuwał użytkowników z zarządzaniem każdym użytkownikiem lub bez niego . To powiedziawszy ... to trochę bezużyteczne, aby nie zarządzać każdym użytkownikiem i straszne w zarządzaniu każdym użytkownikiem. Używam marionetki do dodawania kont usług, ale nie kont użytkowników.
Art Hill,
2

W większości zgadzam się z voretaq7, ale z kilkoma zastrzeżeniami.

  • Rzadko kiedykolwiek konfiguruję adresowanie IP w marionetkach, chyba że system używa DHCP (zakładam, że robi to większość dużych dostawców „chmury”). Zdarzyło mi się, że zepsułem konfiguracje sieciowe za pomocą marionetki, ale nie mogłem ich poprawić za pomocą marionetki, ponieważ węzeł nie miał żadnego sposobu na skontaktowanie się z mistrzem marionetek.

  • Jestem przekonany, że zarządzanie aktualizacjami należy do narzędzi systemowych i nie uważam, aby używanie marionetki jako uwielbionego crona było ulepszeniem.

Paul Gear
źródło
1

W moim przypadku mam skrypt ładujący, który ładuje minimalną konfigurację systemu (Ubuntu): Ruby, Rubygems, build-essential, git itp. Moje manifesty Puppet są pod kontrolą wersji i po prostu klonuję repozytorium. Stamtąd mój skrypt bootstrap przyjmuje hostname --shortprawidłowe założenie i próbuje puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Odpowiedzieć na Twoje pytanie:

  • Moje skrypty zakładają podstawową łączność sieciową (DNS, IP) i nie zarządzają nimi ani ich nie zmieniają;
  • Moje skrypty zakładają, że tożsamość maszyny jest poprawna i nie zmieniaj jej;
  • Moje skrypty zakładać Ruby / rubygems / Git jest obecny, ale nie zarządzać później.
François Beausoleil
źródło
0

Myślisz, że nie potrzebujesz używać marionetki do konfiguracji sieci. Zwykle jest to raz skonfigurowane. Możesz także dostać bzdury, jeśli będziesz miał błąd (-y) z IP lub MAC lub coś podobnego, co spowoduje marionetka.

Evgenii Iablokov
źródło
2
Nigdy nie musiałeś ręcznie zmieniać domyślnej bramy na ponad 100 serwerach? Na szczęście;)
@EricDANNIELOU Przypuszczam, że można to potraktować jako +1 za umożliwienie marionetce zarządzania konfiguracją IP interfejsów sieciowych;)
Luke404,
@EricDANNIELOU Spróbuj to zrobić za pomocą bash, „for” i odpowiednich uprawnień użytkownika (sudo do rootowania lub rootowania bezpośrednio) oraz sed / perl / etc. :)
Evgenii Iablokov,
1
Nie sądzę, aby cykl bash „for” i brudne skrypty sed / awk / vi były bezpieczniejsze niż scm do konfiguracji sieci. A kiedy już skonfigurujesz marionetkę do wszystkiego innego, nie jest zbyt wygodne, aby pętla ssh „for” służyła tylko do konfiguracji sieci.