Jeśli uruchomisz automatyczne aktualizacje

Prowadzę produkcyjne serwery sieciowe Centos. Chcę wiedzieć, jaka jest najlepsza praktyka uruchamiania aktualizacji. Czy powinienem to zautomatyzować za pomocą yum-cron czy yum-updatesd? A może istnieje niebezpieczeństwo, że witryny zepsują aktualizacje, więc lepiej byłoby przeprowadzić aktualizację na serwerze testowym, a następnie uruchamiać aktualizacje ręcznie co tydzień?

Większość serwerów używa tylko oficjalnych repozytoriów, ale niektóre mają repozytorium atomowe dla modułów PHP, które w innym przypadku nie byłyby dostępne. Co jest najlepsze w tym przypadku? czy mogę ustawić yum, aby używał Atomic tylko do modułów PHP? Nie chcę, żeby wszystko aktualizowało się do najnowocześniejszych rzeczy w Atomic, wolałbym raczej Centos (a właściwie Red Hata), aby moje serwery były stabilne i bezpieczne.

Oba sposoby mają swoje zalety i wady i naprawdę musisz przeanalizować architekturę systemu, aby wiedzieć, która droga jest dla Ciebie najlepsza. Niezależnie od tego, którą drogą wybierzesz, powinieneś zrozumieć, dlaczego wybrałeś tę metodę i jakie są wady, abyś mógł je zrekompensować.

Oto kilka rzeczy do rozważenia:

• Aktualizacje zabezpieczeń należy zawsze stosować w taki czy inny sposób, a raczej wcześniej niż później. Jeśli z jakiegoś powodu na serwerze nie są stosowane aktualizacje zabezpieczeń z jakiegokolwiek powodu, napraw swoje nawyki administratora.

• Aktualizacje Distro są zwykle dobre, szczególnie jeśli pochodzą z oficjalnych źródeł. Jeśli czujesz się niekomfortowo stosując je, być może nie używasz najlepszej dystrybucji dla swoich potrzeb. Powinieneś używać dystrybucji, która pasuje do twojej metodologii. Innymi słowy, możesz zaufać aktualizacjom, które będą w Twoim najlepszym interesie. Jeśli poruszają się zbyt szybko lub wprowadzają zmiany oprogramowania, które psują twoje rzeczy, prawdopodobnie powinieneś użyć innej dystrybucji.

• Aktualizacje mogą popsuć twoje rzeczy. Przejście na nowsze oprogramowanie może uszkodzić kod, jeśli używałeś przestarzałych funkcji lub po prostu napisałeś złe rzeczy. Należy rozważyć architekturę systemu, która pozwala przetestować produkt na aktualizacjach przed uruchomieniem ich w systemach produkcyjnych.

• Jeśli korzystasz z funkcji automatycznej aktualizacji, zawsze powinieneś mieć możliwość powrotu do znanych konfiguracji. Pełne migawki systemu mogą uratować życie, jeśli niektóre aktualizacje spowodują uszkodzenie produktu w systemie produkcyjnym.

To nie jest wyczerpująca lista, tylko kilka rzeczy, które skłaniają cię do myślenia. W końcu nie jest to decyzja, którą może podjąć ktoś inny. Jesteś administratorem. Poznaj swoje systemy. Poznaj swoją dystrybucję.

Zgadzam się w 100% z tym, co już powiedział Caleb. Kilka innych wycinków specyficznych dla CentOS ode mnie:

Dystrybucja oparta jest na RedHat i jego łatkach. Łaty te są testowane bardzo dobrze, aw ciągu ostatnich 4 lat, kiedy używaliśmy CentOS 5 z serwerami 50+, nigdy nie było złej łaty.

ALE: Chociaż codziennie nakładamy wszystkie łaty automatycznie na serwery, które obsługują tylko dystrybucję, uruchamiamy serwery produkcyjne (po aktualizacji glibc lub jądra) dopiero po tym, jak kilka dni uruchomiliśmy nasze systemy testowe w tej konfiguracji.

W przypadku innych repozytoriów kopiujemy je do katalogu pomostowego. Te poprawki są najpierw stosowane do serwerów testowych. Jeśli zostanie udowodnione, że nic się nie psuje, aktywujemy katalog pomostowy i skopiujemy go do repozytorium produkcyjnego.

Automatyczne łatanie ma taki efekt uboczny, że łatane komponenty są często restartowane - więc jeśli źle je skonfigurowałeś po uruchomieniu, restart nie powiedzie się.