У меня много серверов работает CentOS 5.* и CentOS 6.*, Я хотел бы их обновить, но некоторые приложения работают, и я могу вывести их из строя, поэтому я написал этот пост, помня об этом.
Что вы мне посоветуете, ребята?
и я могу сломать эти приложения
1) Одна из основных причин использования хорошо зарекомендовавшего себя дистрибутива - и особенно Centos (как, по сути, копии RHEL - моментального снимка, а не скользящего выпуска) заключается в том, что любые обновления сохранят обратную совместимость - обновления вряд ли что-нибудь сломают
2) Если биты кода, хранящиеся на диске, заменены чем-то несовместимым, то не должно быть никакого воздействия, пока вы не попытаетесь загрузить и запустить новый код - очень немногие биты программного обеспечения будут выполнять любое динамическое связывание, отложенное после запуска - следовательно, программы могут не перезапускаться, но их сбой маловероятен.
3) Если есть какая-либо возможность удаленного доступа к этим системам (или даже локально с любой возможностью злонамеренного намерения), выдолжен обновляйте свои патчи.
4) в случае патчей ядра вы должны перезагрузить компьютер после применения патча - то есть ваш текущий текущий код будет остановлен
5) если у вас "много машин", и они делают что-нибудь ценное, тогда у вас должна быть возможность тест самостоятельно обновлять некритическую систему (как указывает фонбранд, для этого вам даже не понадобится специальный компьютер).
Попробуйте обновления на запасном компьютере (или на виртуальной машине) с запущенными вами приложениями. Заранее определите набор тестов, запустите их с установленными версиями и сохраните результаты для сравнения.
С участием yum list installed вы можете увидеть, какие пакеты установлены, rpm -Va даст вам список пакетов rpm думает, что были изменены (по какой-то странной причине дает много ложных срабатываний), проверьте, какие файлы конфигурации были изменены, отметьте изменения и сохраните их. Ищите другие, внешние конфигурации и локальные модификации. Делать конечно при необходимости вы можете восстановить точную копию.
Настройте файлы кикстарта для каждой из машин, поддерживая их в актуальном состоянии, что значительно упростит будущие миграции (или перемещение машины в случае сбоя, или создание зеркала для всплесков активности, или ...).
К чему вы должны стремиться:
Иметь автоматизированный способ сборки / восстановления ваших машин
Используйте это для создания идентичной тестовой среды (обычно виртуальных машин)
Иметь автоматизированный набор тестов, который гарантирует, что машина выполняет то, для чего она предназначена.
Запустите этот автоматический тест в тестовой среде до и после обновлений, а затем еще раз до и после обновлений реальной среды.
Все это зависит от возможности быстрой и автоматической сборки ваших машин, и именно здесь на помощь приходит puppet / chef и тому подобное. Мы используем vagrant и virtualbox для тестовой среды, что также позволяет вам безопасно писать новый код puppet / chef и тестировать его. слишком.
Вы знаете, когда вашей автоматизации «достаточно», когда ваши тесты проходят на новой машине, которая ранее была новой установкой, желательно без вмешательства пользователя.
Да, и для критически важных систем используйте пару аварийного переключения и сначала обновите пассивный узел (затем переключитесь, и, если ваши тесты пройдут, обновите ранее активный узел).
Перед запуском обновления вы должны подтвердить, что ваши запущенные приложения совместимы с обновленной версией, а затем вы можете обновить все пакеты с помощью yum.
Перечислите все пакеты с помощью команды «yum list updates». Таким образом, вы получите лучшее представление о том, какие пакеты вы собираетесь установить. и запустите команду обновления
ням обновление