Najlepsza praktyka w zakresie automatycznych aktualizacji systemu Linux

Pracujemy nad sposobem wykonywania automatycznych aktualizacji naszych serwerów opartych na RHEL / RHEL.

Początkowy pomysł: za pomocą Puppet wyłączamy domyślne repozytoria i wskazujemy własne. Następnie używamy ensure => latestpakietów, które chcemy automatycznie aktualizować.

Problem: Widzimy, że niektóre usługi uruchamiają się ponownie po aktualizacji (duh).

Pytanie: Czy ktoś ma jakieś porady na temat lepszego zautomatyzowania aktualizacji systemu Linux i strategii ograniczania automatycznego ponownego uruchamiania usług? Wolelibyśmy rozwiązanie obejmujące Puppet, ale jeśli potrzebujemy skorzystać z innej usługi, nie jest to przełom.

Edytować

Możliwe rozwiązanie: przesłałem rozwiązanie, które implementuje wiele z sugestii @ voretaq7 i @ewwhite. Wygląda na to, że na razie wybieram trasę. Jeśli masz inne sugestie, skomentuj lub prześlij odpowiedź.

Ogólna strategia aktualizacji jest prawidłowa: masz lokalne repozytorium (które, jak zakładam, testujesz w środowisku deweloperskim), i aktualizujesz wszystko na podstawie tego (zakładam, że znane dobre) repo.

Ponowne uruchomienie usługi jest nieuniknione: jeśli zmienił się kod bazowy, musisz ponownie uruchomić usługę, aby ta zmiana zaczęła obowiązywać. Niezastosowanie się do tego może prowadzić do gorszych konsekwencji (brak synchronizacji kodu z biblioteką współdzieloną, co prowadzi do awarii aplikacji).
W moim środowisku uważam, że kwartalne okienka poprawek są kwartalne „Zrestartuj wszystkie rzeczy!” Windows też. Zaletą takich zasad jest to, że wiesz, że twoje serwery wrócą po ponownym uruchomieniu i wiesz, że będą działać poprawnie (ponieważ regularnie je testujesz).

Moją najlepszą radą jest zaplanowanie wydań oprogramowania (być może oznacza to, że będziesz musiał uruchomić je „ręcznie” za pomocą marionetki) i poinformować użytkowników o planowanej konserwacji / przestoju.
Alternatywnie (lub w ramach tego) możesz skonfigurować redundancję w swoim środowisku, tak aby można było zrestartować kilka komputerów lub usług i nadal świadczyć usługi użytkownikom końcowym. Może to nie całkowicie wyeliminować żadnych zakłóceń, ale może pomóc w ich zminimalizowaniu.

Dodatkowa redundancja chroni również w przypadku awarii sprzętu, które są nieuniknione w wystarczająco długim okresie czasu.

Czy koniecznie jest problem z ponownym uruchomieniem usługi po aktualizacji pakietu? Przetestuj na małą skalę przed wdrożeniem, aby sprawdzić, czy występują jakieś problemy. Niedawno miałem brzydki problem z pakietem RPMForge z DenyHosts . W rzeczywistości zmienił lokalizację swoich katalogów konfiguracji i pracy między wersjami z ostatniej aktualizacji. To jest całkowicie niepożądane zachowanie. Zazwyczaj w ramach tej samej wersji RHEL nie ma zbyt wielu problemów, ale nigdy nie można być pewnym bez testowania i uważnego obserwowania efektów.

Inną opcją jest selektywna aktualizacja usług. Czy na przykład zawsze potrzebujesz najnowszych pakietów? Powraca to do zrozumienia przyczyn uruchamiania aktualizacji. Jaki jest prawdziwy cel?

Zaletą prowadzenia własnego repozytorium jest to, że możesz wystawiać wersje lub wdrożenia i zarządzać harmonogramem. Co się stanie, jeśli masz sprzętowego producenta urządzeń peryferyjnych lub oprogramowania, który wymaga RHEL 5.6 i złamałby się poniżej 5.7? To jedna z zalet zarządzania własnymi pakietami.

@Beaming Mel-Bin

Uproszczenie wyeliminuje potrzebę używania ssh do narzędzi pętli, aby uruchomić / zatrzymać marionetkę.

Przede wszystkim musisz zmienić swoje manifesty, aby zawierały zmienną o nazwie „noop”, której wartość pochodzi z ENC.

Więc miałbyś coś takiego w klasie:

noop => $noop_status

Gdzie noop_statusjest ustawiony w Twojej ENC. Po ustawieniu wartości noop_statusna true, manifest będzie działał tylko w trybie noop.

Jeśli masz 100 lub 1000 hostów, możesz użyć ENC, takiego jak Dashboard lub Foreman, który pozwala na masową zmianę parametrów wielu hostów, dziedzicząc je na poziomie „Grupy hostów” lub „Domeny”. Następnie można ustawić wartość „false” dla niewielkiej liczby hostów testowych, zastępując wartość grupy hostów.

Dzięki temu wszelkie zmiany zostaną zastosowane tylko do wybranych hostów.

Zmiana jednego parametru w centralnej lokalizacji może wpłynąć na dowolną liczbę hostów, bez potrzeby włączania / wyłączania marionetki za pomocą ssh dla narzędzi pętli. Możesz podzielić gospodarzy na wiele grup dla bezpieczeństwa / zarządzania.

Zauważ też, że zamiast na stałe kodować numery wersji pakietów w manifestach, możesz umieścić je w ENC. Podobnie jak powyżej, możesz selektywnie stosować zmiany i zarządzać wdrożeniami.

Jeśli chcesz uzyskać większą szczegółowość (i złożoność), możesz nawet mieć parametry według klas, itp noop_status_apacheClass.

Może to być trudniejsze w zarządzaniu, jeśli prowadzisz includezajęcia w innych klasach.

Możliwe rozwiązanie oparte na odpowiedzi @ voretaq7:

1. Numery wersji twardego kodu pakietów w puppetmanifestach i utrzymuj pakiety w naszym własnym repozytorium.

2. Kiedy potrzebujemy nowej wersji pakietu zrobić coś, co oferuje (np. Ulepszenia bezpieczeństwa, funkcje wymagane przez naszych klientów itp.), Pobieramy pakiet do repozytorium.

3. Przetestuj zaktualizowany pakiet na serwerze testowym.

4. Po przetestowaniu aktualizacji użyj czegoś takiego jak funclub, psshaby wyłączyć puppetagenta na dotkniętych węzłach.

5. Zaktualizuj puppetmanifesty, aby mieć pewność, że nowa wersja pakietu zostanie zainstalowana w dotkniętych węzłach.

6. Na koniec uruchom puppet agent --onetime && rebootna serwerze za pomocą funclubpssh

Skomentuj i daj mi znać, jeśli zauważysz jakieś braki w tym rozwiązaniu lub cokolwiek, co można by uprościć.