Aktualizowanie produkcji Ubuntu zawiera dosłowne uwagi i uwagi

Co jakiś czas loguję się do produkcyjnych skrzynek web / db / tools i widzę typowy komunikat:

30 pakietów można zaktualizować. 16 aktualizacji to aktualizacje bezpieczeństwa.

Moje pytanie brzmi: w jaki sposób wszyscy radzicie sobie z aktualizacjami produkcyjnych pudeł Ubuntu? Czy automatyzujesz te aktualizacje? Czy ustawiasz dla nich przestoje? Problem polega na tym, że nigdy nie wiadomo, kiedy aktualizacja coś zepsuje, na przykład istniejący plik konfiguracyjny itp.

Inną częścią tego problemu jest to, że nadążanie za łatkami jest „dobrą rzeczą”, ale łatki są wydawane prawie codziennie. Ile zaplanowanych wyłączeń należy wykonać, jeśli każdego dnia dostępna jest nowa poprawka bezpieczeństwa?

Myślę, że bardzo przydatny byłby wątek odpowiedzi na temat zarządzania aktualizacjami.

Nie ma nic specjalnego w łataniu Ubuntu vs. Windows, RHEL, CentOS, SuSE, debian itp.

Podstawowym stanem umysłu, w którym musisz się znaleźć przy projektowaniu procedury łatania, jest założenie, że coś się zepsuje.

Oto niektóre z podstawowych wskazówek, których używam podczas projektowania instalacji łatek:

• Zawsze używaj systemu lokalnego, aby scentralizować wewnętrznie sieć, z której instalowane są łatki

Może to obejmować używanie programu WSUS lub kopii lustrzanych <your_os_here>na wewnętrznej maszynie do zarządzania poprawkami. Preferowany, który może centralnie przesyłać zapytania i informować o stanie poprawek zainstalowanych na poszczególnych komputerach.

• Wstępne etapy instalacji - jeśli to możliwe - na maszynach.

Gdy jest to możliwe, gdy pojawiają się łatki, serwer centralny kopiuje je na poszczególne komputery. To naprawdę tylko oszczędność czasu, więc nie musisz czekać na pobranie i instalację ORAZ po prostu rozpocznij instalację w oknie aktualizacji.

• Uzyskaj okno awarii, aby zainstalować łatki, być może będziesz musiał zrestartować komputer i coś prawdopodobnie się zepsuje. Upewnij się, że podmioty zainteresowane dla tych systemów wiedzą, że wprowadzane są łatki. Przygotuj się na „to” nie działa połączenia.

Zgodnie z moją podstawową teorią, że łatki psują rzeczy, upewnij się, że masz okno przestoju, aby zastosować łatki wystarczająco długo, aby rozwiązać krytyczne problemy i ewentualnie wycofać łatkę. Nie musisz koniecznie mieć ludzi siedzących tam, testujących po łatkach. Osobiście polegam w dużej mierze na moich systemach monitorowania, aby dać mi znać, że wszystko działa na minimalnym poziomie, z którego możemy uciec. Ale bądź też przygotowany na dręczące cię problemy, gdy ludzie zaczną pracować. Zawsze powinieneś mieć kogoś zaplanowanego, aby był tam gotowy do odebrania telefonu - lepiej nie od faceta, który był do 3 nad ranem łatając pudełka.

• zautomatyzować jak najwięcej

Podobnie jak wszystko inne w IT, skrypt, skrypt, a następnie skrypt jeszcze więcej. Skrypt pobierz pakiet, rozpocznij instalację, kopię lustrzaną. Zasadniczo chcesz zmienić okna krosowe w miejsce do siedzenia dla dziecka, które potrzebuje tylko człowieka na wypadek, gdyby coś się zepsuło.

• Posiadaj wiele okien każdego miesiąca

Daje to możliwość nie łatania niektórych serwerów, jeśli z jakiegokolwiek powodu nie można ich załatać w „wyznaczoną noc”. Jeśli nie możesz tego zrobić w nocy 1, wymagaj, aby były wolne w nocy 2. Pozwala także zachować liczbę serwerów załatanych jednocześnie.

Co najważniejsze, nadążaj za łatkami! Jeśli tego nie zrobisz, będziesz musiał robić bardzo duże 10-godzinne okna krosowe, aby wrócić do punktu, w którym jesteś złapany. Wprowadzenie jeszcze większej liczby punktów, w których może się nie udać, oraz ustalenie, która łatka spowodowała, i wydanie tego o wiele trudniejsze.

Inną częścią tego problemu jest to, że nadążanie za łatkami jest „dobrą rzeczą”, ale łatki są wydawane prawie codziennie. Ile zaplanowanych wyłączeń należy wykonać, jeśli każdego dnia dostępna jest nowa poprawka bezpieczeństwa?

Patchowanie serwera raz w miesiącu lub raz na dwa miesiące jest - IMHO - bardzo osiągalnym i akceptowalnym celem. Co więcej, a więc ciągle będziesz łatać serwery, a tym bardziej zaczynasz wpadać w sytuacje, w których masz setki łatek, które należy zastosować na serwer.

O ile okien potrzebujesz na miesiąc? To zależy od twojego środowiska. Ile masz serwerów? Jaki jest wymagany czas przestoju dla twoich serwisów?

Mniejsze środowiska, które mają wymiary 9 x 5, prawdopodobnie mogą uniknąć jednego okienka łaty na miesiąc. Duże sklepy 24x7 mogą potrzebować dwóch. Bardzo duże 24x7x365 może wymagać ruchomego okna co tydzień, aby co tydzień łatać inny zestaw serwerów.

Znajdź częstotliwość, która działa dla Ciebie i Twojego środowiska.

Należy pamiętać, że 100% aktualności jest niemożliwym do osiągnięcia celem - nie pozwól, aby dział bezpieczeństwa powiedział inaczej. Daj z siebie wszystko, nie pozostań zbyt daleko w tyle.

Rzeczy do zrobienia:

1. Zrób kopię zapasową
2. Upewnij się, że jest to kopia zapasowa, którą można przywrócić (chociaż te dwie są ogólnymi punktami)
3. Podczas aktualizacji staraj się kierować ruch z dala od skrzynki produkcyjnej.
4. Postaraj się zastosować metodę dostępu pozapasmowego na wypadek, gdyby wszystko poszło nie tak, KVM, konsola szeregowa, dostęp lokalny lub zdalne ręce.
5. Przetestuj na jednym serwerze, a następnie upewnij się, że wszystko działa, zanim wdrożysz aktualizacje na większej liczbie serwerów
6. Użyj marionetki, jeśli możesz upewnić się, że numery wersji są takie same na wielu serwerach. (Możesz go również użyć do wymuszenia aktualizacji)
7. Na serwerze testowym porównaj wersje plików konfiguracyjnych z nowymi (zainstalowanymi aktualizacjami) i upewnij się, że nic nie spowoduje poważnego uszkodzenia. Wydaje mi się, że pamiętam pytanie dpkg przed instalacją nowych wersji, które różnią się od aktualnie zainstalowanych.

Rzeczy, których należy unikać:

1. Robienie aktualizacji w środku dnia lub o 09:00 w poniedziałek rano lub o 17:00 w piątek po południu! (dzięki @ 3influence!)
2. Aktualizacja MySQL na naprawdę dużych serwerach baz danych (restart może zająć dużo czasu)
3. Robienie wszystkich serwerów jednocześnie (szczególnie jąder)
4. Robienie czegokolwiek, co może zmienić / etc / networks (ponieważ możesz stracić łączność)
5. Zautomatyzowane aktualizacje, które mogą wykonać powyższe czynności bez konieczności sprawdzania wszystkiego, są w porządku.

Kolejna kwestia, o której warto wspomnieć: jeśli jesteś przyzwyczajony do systemu Windows, zdziwisz się, że większość aktualizacji systemu Linux nie wymaga przestojów ani ponownego uruchamiania systemu. Niektóre tak, na przykład aktualizacje jądra. Jednak aktualizacje wymagające ponownego uruchomienia lub przestoju są zwykle oznaczone jako takie i mogą być obsługiwane w osobnym harmonogramie.

Wszystkie nasze maszyny Ubuntu są w wersji LTS.

Po prostu automatycznie instalujemy wszystkie aktualizacje - na pewno nie jest to „najlepsza praktyka”, ale jesteśmy stosunkowo małym sklepem i nie mamy środowiska testowego / programistycznego / produkcyjnego dla każdej usługi. Aktualizacje LTS są ogólnie dość dobrze przetestowane i minimalnie inwazyjne.

Aktualizacja do nowej wersji jest oczywiście nieco bardziej zaangażowana.

Aktualizacje dotyczą następujących systemów ubuntu LTS:

1. Mait zestaw testów akceptacyjnych, które sprawdzają wszystkie krytyczne ścieżki w naszym oprogramowaniu
2. Instaluj aktualizacje bezpieczeństwa bez nadzoru o 4 rano każdego ranka i natychmiast uruchom testy akceptacyjne. Jeśli coś zawiedzie, inżynier zostaje przywołany i ma mnóstwo czasu na naprawę lub wycofanie się przed 9 rano. Do tej pory zdarzyło się to tylko dwa razy w ciągu pięciu lat - LTS jest dobrze przetestowany i stabilny.
3. Co tydzień automatycznie wdrażamy całą naszą infrastrukturę (w wersji cyfrowej) z wdrożeniami niebiesko-zielonymi, dzięki czemu wszystkie pakiety mają najnowsze wersje. Jeśli nowe wdrożenie nie powiedzie się w testach akceptacyjnych, wdrożenie jest wstrzymane, dopóki inżynier nie zdoła debugować problemu.

Kolejnym logicznym krokiem dla nas jest wyeliminowanie informacji o sesji w pamięci, dzięki czemu możemy po prostu wdrożyć infrastrukturę codziennie lub nawet wiele razy dziennie bez wpływu na klientów i wyeliminować krok (2).

Takie podejście wymaga niewielkiej konserwacji i całkowicie eliminuje okna konserwacji.

Jedną rzeczą, którą poleciłbym, jest wycofywanie pakietów. Zobacz Transakcje i wycofywanie z Debianem, aby dowiedzieć się, jak to zrobić, ponieważ czasami potrzebujesz szybkiej poprawki do aktualizacji, która coś psuje.