Czy narzędzia do zarządzania konfiguracją (Puppet, Chef) są w stanie aktualizować zainstalowane pakiety?

Jest to prawdopodobnie proste pytanie dla tych z was, którzy już korzystają z narzędzi do zarządzania konfiguracją. Czy narzędzia do zarządzania konfiguracją, takie jak Puppet lub Chef, są właściwym podejściem do aktualizowania zainstalowanych pakietów?

Załóżmy, że uruchamiam wiele serwerów, głównie opartych na Debianie i Ubuntu. Czy narzędzia do zarządzania konfiguracją ułatwiają aktualizację pakietów zainstalowanych z repozytoriów, gdy pojawiają się aktualizacje zabezpieczeń lub poprawki błędów?

Obecnie uruchamiam „aktualizacje nienadzorowane”, aby systemy mogły automatycznie instalować aktualizacje zabezpieczeń, ale nadal muszę się łączyć z serwerami i uruchamiać aptitude update && aptitude safe-upgradeco jakiś czas. Naturalnie staje się to nudne, żmudne i podatne na błędy, im więcej jest serwerów.

Czy narzędzia takie jak Puppet lub Chef są właściwym podejściem do aktualizowania zainstalowanych pakietów? Czy ktoś z was korzysta z tych narzędzi, aby uniknąć ręcznego uruchamiania aptitudelub równoważności na 15 serwerach? Jestem pewien, że odpowiedź na te pytania brzmi: „Tak, oczywiście!”

Ale gdzie mogę znaleźć więcej informacji na temat tego konkretnego przypadku użycia? Nie miałem jeszcze czasu dogłębnego przestudiowania Puppet lub Chef, a przykładowe książki kucharskie lub klasy pokazują tylko mniej lub bardziej trywialne przykłady instalacji jednego konkretnego pakietu, takiego jak ssh. Czy masz jakieś zasoby do zarekomendowania, inne niż oficjalna dokumentacja (oczywiście zamierzam przestudiować dokumenty, gdy tylko będę wiedział, które z tych narzędzi są dla mnie odpowiednie).

Lalek (jestem całkiem pewien kucharz robi również) współdziała z apt-get / yum repozytoriów oprogramowania. Ponieważ robią ciężkie zniesienie dowiedzieć się, które pakiety są dostępne, to znaczy ensure => latestpo prostu działa na Ubuntu / CentOS / Debian itp. Tak długo, jak poprawnie skonfigurujesz odpowiednie pliki ( /etc/apt/sources.listitp.).

Możesz to zrobić marionetką, albo:

ensure => latest,

lub

ensure=> "1.0.2",

określić najnowszy / wymaganej wersji. to znaczy

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

To nie znaczy, przynajmniej można określić tę samą wersję we wszystkich systemach, jak również zapobieganie serwerów z (potencjalnie niebezpiecznie) automatycznie uaktualnienie siebie. Użyłem tej metody produkcji na kilku stronach, i to działa bardzo dobrze.

Uruchamianie nienadzorowanych aktualizacji trochę mnie przeraża, szczególnie jeśli aktualizują krytyczne pakiety, jądra, biblioteki mysql, apache itp. Zwłaszcza jeśli skrypt instalacyjny może chcieć zrestartować usługę!

Myślę, że to prawdopodobnie niewłaściwe pytanie. Z pewnością korzystanie z narzędzi do zarządzania konfiguracją, takich jak Puppet i Chef, do utrzymania infrastruktury to ogromny krok naprzód od próby zrobienia tego wszystkiego ręcznie. Problem utrzymywania aktualności i synchronizacji wersji pakietów nie jest tym, który którekolwiek z tych narzędzi rozwiązuje bezpośrednio. Aby to odpowiednio zautomatyzować, musisz sam kontrolować repozytoria pakietów.

Sposób, w jaki to robię, polega na utrzymywaniu dedykowanego repozytorium Yum (dla Redhat / Fedora / CentOS; repozytorium APT dla Debian / Ubuntu), które zawiera pakiety, którymi zależy mi na konkretnej stronie. Zasadniczo będą to zależności samej aplikacji (Ruby, PHP, Apache, Nginx, biblioteki itd.) I pakietów o krytycznym znaczeniu dla bezpieczeństwa.

Po skonfigurowaniu (zwykle możesz po prostu wykonać kopię lustrzaną wymaganych pakietów z repozytorium upstream na początek), możesz użyć składni Puppet „upewnij => najnowsza”, aby upewnić się, że wszystkie twoje maszyny będą na bieżąco z repozytorium.

Rozsądnie byłoby użyć repozytorium „testowego”, aby umożliwić testowanie zaktualizowanych wersji pakietów przed ich bezproblemowym wdrożeniem do produkcji. Można to łatwo zrobić za pomocą Puppet bez powielania kodu za pomocą szablonów repozytoriów.

Automatyzacja wersjonowania pakietów zdecydowanie zachęca do zsynchronizowania wszystkich systemów produkcyjnych, ponieważ utrzymywanie wielu repozytoriów i pakietów dla różnych dystrybucji systemu operacyjnego, wersji i architektury maszyn jest bardzo czasochłonne i może prowadzić do wszelkiego rodzaju niejasnych problemów i niezgodności.

Wszystkie te porady dotyczą w równym stopniu klejnotów Ruby, jajek Python i innych systemów pakietów, których możesz użyć.

Napisałem mały poradnik Puppet, który powinien pomóc ci szybko rozpocząć pracę z Puppet. Możesz wdrożyć niestandardową definicję repo na swoich komputerach, używając Puppet jako pierwszego kroku do kontrolowania wersji pakietów.

Choć Lalek / Chef to możliwe pretendentów do tej funkcji, aby je utrzymać wszystko w systemie up-to-date wymaga albo typy niestandardowe lub wymieniając każdy pakiet (włącznie bazowych bibliotek systemowych, takich jak libc6) jako środków z ensure => latest. W konkretnym przypadku automatycznych aktualizacji pakietów możesz zajrzeć do cron-aptpakietu, który robi to, co chcesz.

To pytanie jest stare, ale pomyślałem, że odpowiem w sposób aktualny, ponieważ dotychczasowa odpowiedź była wówczas niedostępna.

Jeśli używasz marionetki lub szefa kuchni, zajrzyj do mcollective. Jest to bardzo miłe narzędzie od facetów puppetlabs, które pozwala wysyłać polecenia do grup serwerów. http://docs.puppetlabs.com/mcollective/

Posiada również wtyczkę apt, której można użyć do przeprowadzenia aktualizacji apt na dowolnej liczbie serwerów: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

Zdaję sobie sprawę, że jest trochę za późno na twoje pierwotne pytanie, ale tutaj jest w duchu „lepiej późno niż nigdy”.

Używam Cfengine 3, aby to zrobić na kilku serwerach. Podaję jawną listę pakietów do automatycznej aktualizacji, unikając w ten sposób aktualizacji wszystkich pakietów, nie troszcząc się o to. Działa świetnie, a cfengine 3 jest bardzo lekki.

Oto fragment obietnicy z mojej konfiguracji cfengine:

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

Mam nadzieję że to pomoże.

Zgadzam się z Jonathanem. Podejście do Cfengine 3 jest dobre, ponieważ możesz kontrolować wszystkie aspekty zarządzania pakietami bez konieczności ponownego kodowania na niskim poziomie.

Używamy marionetki + apt-dater.

Możesz także użyć narzędzi do zarządzania pakietami, takich jak Canonicals Landscape, który jest przeznaczony do zarządzania i monitorowania systemów Ubuntu / Debian. Zarządza wieloma systemami, pozwala aktualizować je jednocześnie i zapewnia podstawowe funkcje monitorowania.

Aktualizacje bezpieczeństwa

Ogólnie myślę, że najłatwiej jest użyć Ansible lub podobnego do skonfigurowania solidnego pakietu aktualizacji nienadzorowanych dla Ubuntu / Debian (lub yum-crondla RHEL / CentOS). Możesz użyć Puppet, Chef lub innych narzędzi, ale omówię tutaj Ansible.

• unattended-upgrades można użyć do jednoczesnego dokonywania aktualizacji niezwiązanych z zabezpieczeniami, jeśli wolisz, co jest znacznie łatwiejsze niż codzienne uruchamianie polecenia za pomocą Ansible.

• unattended-upgradeszajmuje się automatycznymi aktualizacjami każdego dnia i zwykle ogranicza się tylko do aktualizacji bezpieczeństwa (w celu zwiększenia stabilności). Jeśli serwer wymaga ponownego uruchomienia po aktualizacji, to narzędzie może automatycznie uruchomić się ponownie w określonym czasie.

Jeśli Twoje ponowne uruchomienie jest bardziej złożone, unattended upgradesmożesz wysłać Ci wiadomość e-mail, a także tworzy /var/run/reboot-required, dzięki czemu Ansible (lub podobny) może zarządzać ponownymi uruchomieniami w odpowiednim czasie (np. Ciągłe ponowne uruchamianie klastra serwerów internetowych lub DB w celu uniknięcia przestojów, czekając na każdy z nich serwer, aby stał się dostępny na określonym porcie TCP przed kontynuowaniem).

Możesz użyć ról Ansible, takich jak jnv.unattended-upgrade dla systemów Ubuntu / Debian, lub prostego, ale skutecznego geerlingguy.security , który obejmuje również RHEL / CentOS (i utrwala konfigurację SSH).

Jeśli szybkie aktualizacje zabezpieczeń są mniej ważne, możesz najpierw przeprowadzić je przez proces testowy na mniej ważnych serwerach i uruchomić unattended-upgradepolecenie, gdy testy wykażą, że nie ma żadnych problemów - jednak moim zdaniem poprawki zabezpieczeń zorientowane na serwer powodują problemy, moim zdaniem doświadczenie.

Ogólne aktualizacje

Aktualizacje inne niż zabezpieczenia powinny przejść normalny ciągły proces integracji i testowania, aby upewnić się, że nic się nie zepsuje.

W przeszłości widziałem aptitude safe-upgradepoważne problemy na serwerach, więc najlepiej nie uruchamiać tego automatycznie, podczas gdy aktualizacje zabezpieczeń są ogólnie dość bezpieczne.