Temat: Soft do centralnego zarzadzania - jaki/opinie
Ja mam dwie instalacje puppeta. Jedna na 100 maszyn, druga na 4 fizyczne + ~20 wirtualek. Opisanych 47 usług (od aktualizacji /etc/pf.conf i "restartu" firewalli po mysql czy monitoring).
Start z puppetem był dość cieżki. Robiłem chyba ze 3-4 podejścia zanim zdecydowałem się uruchomić produkcyjnie. Teraz uważam że sprawdza się bardzo dobrze.
Maksymalnie ułatwia konfigurowanie wszystkie co ma być dla danej usługi (np.: jeżeli jest mysql, to odrazu niech skonfiguruje backupy + backup server do ich przyjmowania, taski maintanance'owe (np.: mysqlcheck -a -A czy mysqlcheck -a -A -o), dodanie do nagiosa, dodanie graphów itd. Można też uprościć sobie konfiguracje service load-balancerów. U mnie puppet po dodaniu usługi do maszyny automatycznie dodaje ją do HAproxy. Fajna też jest możliwość automatycznego restartu usług po zmianie plików konfiguracyjnych (np.: dodajesz coś w configu apache a puppet sam go restartuje)
W miarę nieźle jest zrobiona obsługa różnych systemów operacyjnych (używam Ubuntu,RedHat,CentOS,FreeBSD,OpenBSD). Co prawda napisanie uniwersalnych modułów trochę zajmuje i zazwyczaj parę razy testować zanim się uda, ale jak już zadziała to się trzyma.
Dla mnie też jest zaletą że po wprowadzeniu lokalnych zmian, puppet i tak nadpisze konfiguracją z repo. Nawet jeżeli komuś się ręka omsknie to puppet poprawi (co czasem może być uciążliwe jak zapomnisz go wyłączyć a coś chcesz przetestować).
Pod FreeBSD kiepsko działa zarządzanie pakietami (przez porty). Albo trzeba budować własne paczki, albo oprogramowywać ręcznie skrypty. No chyba że chcesz rozszerzyć puppeta o własny wrapper dla package providera.
Po pewnym czasie używania, moduły są na tyle dojrzałe że gdy masz gdzieś zainstalować jakaś usługę to jedyne co robisz to
include <usluga>
i zapominasz. O ile config puppeta jest dobrze napisany, sam zrobi za Ciebie całą robotę.
Niestety puppet ma też kilka wad. Ja miałem stosunkowo duże problemy z wejściem w niego. Manual niby jest ok, Best Practices opisane ale jakoś nie mogłem załapać idei pisania konfigów tak aby było fajnie i wygodnie. Na początku trochę rzeczy porobiłem inaczej niż doktryna puppeta przyjmuje ale działa i powoli przepisuję to na "puppet-way".
Druga sprawa jest taka że czasami trzeba się strasznie napracować żeby coś zrobić tak jak my chcemy - puppet jest dość rygorystyczny pod tym względem. Np.: nie zawsze można nadpisać zmienną, czasem trzeba używać rozszerzenia (extlookup) żeby to przeskoczyć. Największym - moim zdaniem - problemem jest obsługa usług "odbiegających od normy". Trzymanie np.: 10 konfigów różniących się jakimiś ustawieniami może być uciążliwe (np.: snmpd.conf i exec. Wiem że można użyć extend żeby mieć unikalne OIDy, ale jak już ktoś raz zrobił exec i jakiś monitoring się o to odpytuje to ciężko to zmieniać). Można to obejść robiąc "ify", ale plik wtedy może się zrobić nieczytelny. Ew. jeżeli różnią się tylko wartości pół w konfigu to extlookup + template pliku powinny wystarczyć.
"And last but not least" - moim zdaniem jest pewien narzut na pracę nad puppetem. Napisanie dobrych manifestów (opisów usług) na początku jest dość pracochłonne i możliwe że zrobiłbyś to nawet szybciej ręcznie. Jednak z czasem narzut jest coraz mniejszy zaś zysk z jednolitej, automatycznej, "o niczym nie zapominającej" konfiguracji pokrywa nakład poniesiony na początku.
PS. Możesz się też zainteresować
Chef. Powstał jako konkurencja dla Puppeta i miał omijać jego ograniczenia. Jak wdrażałem już puppeta, obejrzałem Chefa i jakoś nie zachwycił mnie na tyle żeby zmieniać. Była też kiepska dokumentacja, ale ponieważ trochę czasu upłynęło to pewnie jest lepiej.
пропозиції роботи
