Czym NIE powinna zarządzać marionetka?

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ą?

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 ...

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.

• 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.

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.

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.

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.