ADG Оставить заявку
Блог Системное администрирование 5 мин чтения

CentOS 7 в продакшне: полгода тестов позади, systemd меняет привычки

Первые клиентские серверы переводим на CentOS 7 после полугода тестов. Разбираем unit-файлы, journalctl и firewalld - что прижилось, что потребовало привыкания.

Контекст момента

Первые продакшн-серверы клиентов переходят на CentOS 7 после полугода тестирования на стенде

В июле писали про выход CentOS 7 и первые переносы unit-файлов на стенде. С тех пор прошло полгода. Стенд превратился в два реальных клиентских сервера на сопровождении, и теперь есть что рассказать уже не про «потрогали», а про ежедневную работу.

Спойлера не будет: CentOS 7 не сделал жизнь сложнее. Но и переходом «нажал кнопку - всё само» он не стал. Набор непривычных мест оказался вполне конкретным.

Почему именно сейчас

Клиент поднимал новую пару серверов под веб-сервис с базой. Задача позволяла начать чисто, без груза существующей конфигурации. Мы предложили сразу идти на CentOS 7 - как раз накопили достаточно практики на стенде, чтобы не рисковать с незнакомым поведением в продакшне.

Параллельно это совпало с тем, что базовый Ansible-плейбук мы к тому времени уже переписали с учётом systemd. Так что провизионирование нового сервера на CentOS 7 шло через автоматизацию, а не ручной разбор «а что здесь по-другому».

Systemd: что реально изменилось в работе

Главный сдвиг - не технический, а в том как мы думаем о сервисах. На SysVinit/CentOS 6 привычный путь был: залезть в /etc/init.d/, найти скрипт, посмотреть что он делает, поправить. Запуск - service nginx restart, статус - /var/log/messages + grep.

На CentOS 7 цепочка другая.

Старт и статус. systemctl start/stop/restart/status <unit> - это быстро усваивается. systemctl status nginx даёт не просто «running/stopped», а последние строки лога прямо в выводе, PID, дату последнего запуска и exit code если упал. Это удобнее чем лазить в лог отдельно. Первые дни по привычке всё равно открывали лог руками, потом перестали.

Автозагрузка. Раньше chkconfig nginx on. Теперь systemctl enable nginx. Привыкаешь за день. Неочевидный момент: enable не запускает сервис прямо сейчас, только добавляет в автозагрузку. Если надо и то и другое - systemctl enable nginx && systemctl start nginx. Несколько раз пришлось напомнить коллегам.

Unit-файлы вместо init-скриптов. Для пакетных сервисов (nginx, postgresql, zabbix-agent) unit-файлы уже есть в пакете, менять их не нужно. Проблемы начинаются с кастомными сервисами - Java-демоны, самописные агенты, что-то поставленное не из репозитория. Здесь пишем unit руками. Это компактнее init.d-скрипта и в целом приятнее, но требует понимания Type=, ExecStart, Restart= - иначе сервис формально стартует, но не так как ожидается.

Типичная ошибка которую поймали: Type=forking для процесса, который на самом деле остаётся на переднем плане. systemd ждёт форка, не дожидается, через таймаут объявляет сервис упавшим. В логе выглядит запутанно. Решение - поставить Type=simple или Type=notify в зависимости от того как процесс сигналит о готовности.

journalctl вместо /var/log/messages

Это потребовало наибольшей перестройки - не потому что плохо, а потому что привычка смотреть в файлы сидит глубоко.

journalctl -u nginx - логи конкретного сервиса. journalctl -u nginx --since "1 hour ago" - за последний час. journalctl -f - аналог tail -f /var/log/messages, живой поток. journalctl -p err - только ошибки.

По сравнению с grep по текстовому файлу это мощнее - структурированные записи, фильтрация по юниту, приоритету, времени без sed. Но /var/log/messages никуда не делся, rsyslog на CentOS 7 по умолчанию всё ещё пишет текстовые логи параллельно. Так что старый способ тоже работает, просто journalctl объективно быстрее для диагностики конкретного сервиса.

Одна практическая настройка которую сделали сразу: ограничили размер журнала через SystemMaxUse=500M в /etc/systemd/journald.conf. По умолчанию journal может занять до 10% диска, что на небольших серверах удивляет.

firewalld вместо iptables

Честно говоря, самая спорная часть перехода. firewalld работает поверх iptables, управляет через зоны и сервисы, предполагает что ты описываешь политику декларативно, а не пишешь правила руками.

На стенде мы с ним поигрались и решили: на клиентских серверах пока отключаем firewalld и работаем напрямую через iptables-restore и сохранённые наборы правил. Не потому что firewalld плохой - просто наш Ansible-плейбук уже умеет управлять iptables-правилами, а переписывать его под firewalld-зоны прямо сейчас нет смысла. Сделаем когда будет повод. systemctl disable firewalld и yum install iptables-services - и дальше как раньше.

XFS: пока без сюрпризов

На новых серверах разметили под XFS и LVM сразу правильно, с учётом того что XFS не умеет уменьшаться. Для данных базы отдельный логический том с запасом. Расширить через lvextend + xfs_growfs - работает без размонтирования, что для продакшна ценно.

Утилиты другие - вместо fsck.ext4 теперь xfs_repair, вместо tune2fs - xfs_admin. Скрипты резервного копирования тоже поправили: там где был dump, теперь rsync или xfsdump.

Итог первого месяца

Два сервера работают третью неделю. Инцидентов из-за CentOS 7 как такового не было. Пара раз тратили лишние 10-15 минут, когда по инерции искали что-то не там - в /etc/init.d/ которого уже нет, или пытались читать /var/log/messages когда нужный сервис в journal.

Переучиваться не так болезненно, как казалось до первого реального сервера. Системный подход помогает: сделали внутреннюю шпаргалку по новым командам для всей команды - две страницы, systemctl vs service, journalctl vs tail, firewalld vs iptables. Новые серверы для клиентов теперь поднимаем сразу на семёрке.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.