Dobra praktyka zarządzania aktualizacjami pakietów dla wielu serwerów CentOS

W ramach mojej pracy zarządzam kilkadziesiątami serwerów CentOS 5, wykorzystując marionetkę do konfiguracji głównej. Około połowa naszych serwerów ma ustandaryzowaną konfigurację do hostingu różnych stron Django, a reszta to miszmasz aplikacji.

Stopniowo rozwiązuję nasze praktyki hostingowe i teraz doszedłem do punktu, w którym pracuję, jak zarządzać aktualizacjami zabezpieczeń na poziomie systemu operacyjnego. Obawiam się, że po prostu nie wykonam zadania crona, yum -y updateale nie chcę też obchodzić każdego serwera na czas i przeglądać każdego pakietu z dostępnymi aktualizacjami, ponieważ to zajmie trochę czasu.

Zastanawiam się więc, czy istnieją jakieś dobre skróty lub praktyki robocze, które zminimalizowałyby związane z tym ryzyko i zminimalizowałyby czas, który muszę poświęcić. Innymi słowy, istnieją narzędzia lub praktyki, które mogą zautomatyzować dużą część pracy, jednocześnie zapewniając kontrolę.

Kroki, które do tej pory zdecydowałem:

• wyłącz wszystkie repozytoria stron trzecich i skonfiguruj nasze własne repozytorium, abym mógł kontrolować, jakie aktualizacje tam przechodzą.
• mamy serwery pomostowe dla (większości) naszych serwerów produkcyjnych, w których mógłbym przeprowadzić testowanie (ale ile testów wystarczy testowanie?)

Zauważ też, że sprawdziłem wtyczkę bezpieczeństwa yum, ale nie działa ona na CentOS .

Jak zatem zarządzać aktualizacjami dla znacznej liczby serwerów CentOS z różnorodną aplikacją?

W większości moich środowisk jest to zwykle skrypt uruchamiający i poinstalacyjny, aby uruchomić główny system i aktualizować go w tym momencie. Zazwyczaj mam lokalne repozytorium, które synchronizuje się z lustrem CentOS codziennie lub co tydzień. Staram się zamrażać pakiet jądra w dowolnym momencie w chwili instalacji i aktualizować pakiety indywidualnie lub w razie potrzeby. Często moje serwery mają urządzenia peryferyjne, które mają sterowniki ściśle powiązane z wersjami jądra, więc to jest uwaga.

CentOS 5 dojrzał do tego stopnia, że ​​ciągłe aktualizacje nie są konieczne. Pamiętaj jednak, że CentOS 5 się kończy. Tempo aktualizacji nieco zwolniło, a charakter aktualizacji jest bardziej zgodny z poprawkami błędów, a mniej o poważnych zmianach funkcjonalności.

Więc w tym konkretnym przypadku pierwszą rzeczą, którą możesz zrobić, to zbudować lokalne mirror / repo. Użyj istniejącego zarządzania konfiguracją, aby kontrolować dostęp do repozytoriów innych firm. Być może zaplanuj aktualizację zasad krytycznych lub publicznych usług (ssh, http, ftp, dovecot itp.) Wszystko inne będzie wymagało testowania, ale mam wrażenie, że większość środowisk nie działa z w pełni zaktualizowanymi / poprawionymi systemami.

Istnieje wiele narzędzi, które mogą w tym pomóc! Ogólnie rzecz biorąc, system pakietów i które paczki idą tam, gdzie jest obsługiwane przez zarządzanie konfiguracją. Narzędzia te zwykle obejmują więcej niż tylko mniam i RPM i oszczędzają czas i zapobiegają wielu bólom głowy!

Najbardziej znanym narzędziem jest marionetka, której używam do zarządzania praktycznie każdą konfiguracją w moim środowisku. Oto kilka przykładowych marionetek dotyczących zarządzania mniam:

http://people.redhat.com/dlutter/puppet-app.html

Obecnie dostępnych jest wiele narzędzi do zarządzania konfiguracją, które mają dość duże grupy użytkowników:

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• Szef kuchni http://wiki.opscode.com/display/chef/Home (Kilka osób, które znam, niedawno to zaimplementowało i uwielbia)

Wdrożenie ich w środowisku przedłuży życie. Zmniejsza liczbę problemów ze źle skonfigurowanymi systemami i umożliwia łatwą aktualizację / aktualizację. Większość tych narzędzi może również zapewniać pewne funkcje na poziomie audytu, co może znacznie skrócić czas naprawy błędów konfiguracji.

Jeśli chodzi o twoje pytanie dotyczące testowania, korzystam ze środowiska testowego, do którego kierujemy obciążenia niektórych klientów (zwykle klienci beta lub niewielki podzbiór ruchu produkcyjnego). Zwykle pozwalamy temu klastrowi uruchamiać nowy kod przez co najmniej kilka dni, a nawet tydzień (w zależności od powagi zmiany), zanim wdrożymy go do wersji produkcyjnej. Zazwyczaj uważam, że ta konfiguracja działa najlepiej, jeśli spróbujesz dowiedzieć się, ile czasu zajmuje większość błędów do wykrycia. W intensywnie używanych systemach może to być kwestia godzin, w większości środowisk, w których widziałem tydzień, jest wystarczająco długi, aby odkryć nawet nietypowe błędy w ustawianiu / kontroli jakości.

Jedną naprawdę ważną częścią testowania jest replikacja danych / użycia. Wspomniałeś, że masz wersje testowe większości sprzętu produkcyjnego. Czy mają również identyczne kopie danych produkcyjnych? Czy możesz odtworzyć przeciwko temu jakiekolwiek obciążenie produkcyjne? Czy potrafisz nawet włączyć go do klastra produkcyjnego za pomocą funkcji dublowania ruchu? Zwykle staje się to bezpośrednim kompromisem między ilością zasobów, które firma jest skłonna wydać na testowanie / kontrolę jakości. Im więcej testów, tym lepiej, nie ograniczaj się (w granicach rozsądku) i zobacz, co firma będzie wspierać (a następnie znajdź sposób, aby zrobić 10% więcej).