LINUX.ORG.RU
ФорумTalks

Как правильно организовать патчинг-процесс Linux в крупной IT-конторе? (400+ серверов)

 


0

2

Привет.

Я работаю в IT-компании и мы поддерживаем Linux-серверы по модели 'оутсорсинг'.

В распоряжении 400+ Linux-серверов. И почти все из них патчатся. Также мы поддерживаем Windows-серверы (но другая команда). Microsoft выкатывает свои патчи раз в месяц, каждый второй вторник, насколько мне известно. Поэтому патчинг-процесс начинается в третий понедельник месяца и заканчивается в след. месяце во второй понедельник. Т.е. патчинг выглядет логичным с точки зрения Windows.

Но у патчей на ОС Linux нет каких-либо привязок к какой-kибо дате, патчи выходят в любое время. Но сейчас мы патчим Linux-серверы по такому же принципу, что и Windows-серверы, т.е. раз в месяц. У каждого сервера есть своё расписание (типа сервер A патчится в третью среду месяца, сервер B — четвёртое воскресенье и т.д.). Владельцы серверов привыкли к такому рапсианию (они ожидают, что сервер A будет перезагружен в третью среду и т.д.)..

Очевидно, что в этом нет никакого смысла и с технической точки зрения такое расписание ничем не обосновано, процесс выглядит странным...

Но как улучшить этот процесс мы не знем, идей нет... Можете ли вы поделиться своим опытом или своими идеями? Серверы крайне критичные, у каждого сервера свой владелец, «ребутать когда захочу» нельзя.

Спасибо!

★★★

Последнее исправление: iljuase (всего исправлений: 3)

google://linux automated compliance
google://SCAP
лучше бы неправильные чёрточки поставил, третий раз переписываю.

system-root ★★★★★
()
Последнее исправление: system-root (всего исправлений: 3)

Для начала перестать перезагружать сервера в том случае, если не обновилось ядро. Для действительно критичных купить livepatch, вообще перезагружать не придется.

Deleted
()

Обновляйте сервера в ненагруженное время предварительно прогнав тестовый апдейт на стаге. Едрить-педрить, вот у людей проблемы-то.

kirk_johnson ★☆
()

патчить как патчите, раз в месяц, чтобы даунтайм был для пользователей предсказуем.

shimshimshim
()
Ответ на: комментарий от Deleted

Тут теперь при обновлении systemd надо ребут делать, а ты про ядро.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Deleted

Мы так и работаем, ребутаем только в том случае, если обновляется ядро или другие пакеты, которые требуют ребута.

Но по опыту ядро почти гарантировано выходит раз в месяц, поэтому, как правило, серверы ребутаются каждый месяц.

Livepatch у нас установлен на Oracle-кластерах (Uptrack), они патчатся без доунтайма.

На RedHat (у нас стандартная подписка) и на CentOS, насколько мне известно, нет адекватной системы патчинга ядра на лету.

95% скопа — это RHEL\CentOS, Debian около десятка серверов, SLES скоро будет (100+ серверов, livepatch куплен).

iljuase ★★★
() автор топика
Последнее исправление: iljuase (всего исправлений: 1)
Ответ на: комментарий от vasya_pupkin

yum-cron настроен на ~10-ти серверах (+ ребут раз в неделю при необходимости через

/usr/bin/ls  /var/run/yum.pid 2>/dev/null || /usr/bin/needs-restarting -r  || /usr/sbin/reboot

Другие не согласились внедрять эту идею на своих серверах... боятся.

iljuase ★★★
() автор топика
Последнее исправление: iljuase (всего исправлений: 1)

У каждого сервера свой владелец - это хорошо и правильно, но это полдела. Сделайте второй шаг - спихните патчинг на владельцев.

Чтобы у владельца сервера голова болела, что сервер не пропатчен, а не у вас. Т.е. чтобы у владельца высвечивался красный алерт: ваши сервера не пропатчены, и предлагались возможные даты для патчинга. Тогда владелец, увидев этот алерт, выбирает окно для патчинга, и в это самое время сервер патчится и перезагружается автоматически.

И чтобы владелец понимал, что за непатченный сервер его будут иметь, а также то, что это его (владельца) обязанность проверить, что после патчинга все поднялось.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 2)
Ответ на: комментарий от bigbit

Сделайте второй шаг - спихните патчинг на владельцев.

Это невозможно. Мы работаем по оутсорсингу, по сути мы — дешёвая рабочая сила. И покрывать патчинг-процесс входит в наши обязанности и кастомер за это платит. И кастомеров (т.е. владельцев серверов) у нас очень много (порядка сотни), и если каждый будет рандомно выбирать дату для патчинга, то нанётся хаос..

+ будут проблемы с автоматизацией... Будет только хуже и непонятнее...

iljuase ★★★
() автор топика
Ответ на: комментарий от iljuase

Не рандомно выбирать, а а одну из дат, предложенных вами.

И патчинг-weekend'ы расписываются и согласуются со всеми владельцами на год вперед, чтобы не вылезало потом гоблинов «у нас релиз в эти выходные, отмените всё».

Врочем, дело ваше. Я рассказал, как процесс был организован в самом зверском (в хорошем смысле этого слова) энтерпрайзе, в котором я когда-то работал, и о котором у меня остались самые приятные воспоминания.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от bigbit

Хмм, а можешь расписать процесс чуть подробнее? Какие инструменты\автоматизацию использовали?

iljuase ★★★
() автор топика
Ответ на: комментарий от iljuase

Веб-морда для владельцев серверов, насколько я понимаю, была самописная - выглядела простенько и ничего лишнего. Скрипты для патчинга *nix-серверов - тоже, а для виндовых серверов использовали BigFix.

bigbit ★★★★★
()
Ответ на: комментарий от AlexAT

Если серверы некритичные и приложение стартует автоматом — почему бы не сделать ребут раз в неделю при необходимости?

Но увы, не все на это соглашаются...

iljuase ★★★
() автор топика
Ответ на: комментарий от AlexAT

yum update по крону - это худшее из возможного. Нравятся внезапные отвалы сервиса?

RHEL - это тебе не генту на коленке собрать, там такого в пределах ветки не бывает..

vasya_pupkin ★★★★★
()
Ответ на: комментарий от vasya_pupkin

вообще не понял зачем обновлять если нет необходимости? перезагрузить сервер потому-что вышел новый vi? лiль.

system-root ★★★★★
()
Ответ на: комментарий от system-root

вообще не понял зачем обновлять если нет необходимости? перезагрузить сервер потому-что вышел новый vi? лiль.

Я вообще нифига не понял, что хочет аффтор :)

vasya_pupkin ★★★★★
()
Ответ на: комментарий от vasya_pupkin

Хочу по-человечески организовать патчинг-процесс. Но не знаю как. Решил спросить помощи тут. Чтобы кто-то поделился своим опытом.

iljuase ★★★
() автор топика
Ответ на: комментарий от vasya_pupkin

Ооо, отваливается еще как. Особенно на первых стадиях жизненного цикла RHEL, когда активно внедряются новые фичи и происходят ребэйзы пакетов (например, при обновлении c 7.3 до 7.4 OpenSSH обновился v6 до v7, а rsyslog - с v7 до v8). RHEL 7 сейчас находится в этой самой бурной фазе. Наивно думать, что при таких ребейзах ничего не отвалится.

Вот пример капитального отваливания при обновлении с RHEL 7.3 на RHEL 7.4:

https://access.redhat.com/solutions/3139201
https://bugzilla.redhat.com/show_bug.cgi?id=1478175

Наступил на этот баг в июле прошлого года, когда этой статьи в редхате и бага в багзиллле еще не существовало. Отвалилось капитально - пользователи не могли по ssh на сервер зайти.

Это уже потом, когда войдет в какую-то там фазу (не помню, как она называется), бурное внедрение новых фич прекращается, и выходят только критические фиксы - т.е. именно та стадия, в которой сейчас находится RHEL 6. Тогда уж конечно вряд ли что отвалится, дык там и обновлений всего ничего.

bigbit ★★★★★
()
Ответ на: комментарий от vasya_pupkin

Бывает, к сожалению. Ту же самбу громили вдоль и поперёк между 7.2-7.3-7.4 круто.

AlexAT
()
Ответ на: комментарий от Deleted

Для glibc тоже надо презагружать, и вообще, посмотри сколько файлов висит при большом аптайме в состоянии «удален».

Shaman007 ★★★★★
()
Ответ на: комментарий от Deleted

systemd тоже можно перезапустить?

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.