systemd в Debian: Технический комитет решил, споры продолжаются

4 февраля Технический комитет Debian проголосовал за systemd как init-систему по умолчанию для Debian 8 Jessie. Голосование прошло с перевесом в один голос, что само по себе говорит о степени консенсуса в сообществе. У нас в команде новость восприняли неоднозначно - несколько человек немедленно открыли чат и начали объяснять почему это хорошо или плохо. Дискуссия продолжалась часа три.

Попробуем вынести за скобки эмоции и разобраться что это значит на практике.

Что меняется и для кого

Для большинства наших серверов на Debian - не так уж много в краткосрочной перспективе. Debian 7 Wheezy с SysVinit никуда не денется, поддержка продолжается. systemd появится по умолчанию только в Jessie, а до его выхода ещё есть время. Но готовиться надо сейчас, потому что новые инсталляции рано или поздно пойдут на Jessie.

Для тех кто работает с CentOS/RHEL - systemd там уже появился в RHEL 7, о котором писали в январе. То есть в мире RPM-дистрибутивов переход уже идёт, и Debian присоединяется.

SysVinit vs systemd: что реально отличается

Часть команды провела несколько лет с SysVinit и знает его в деталях - скрипты в /etc/init.d/, уровни запуска, update-rc.d. Логика привычная: shell-скрипты, последовательный запуск, предсказуемый порядок.

systemd устроен принципиально иначе.

Юниты вместо init-скриптов. Сервисы описываются в .service-файлах с декларативным синтаксисом. Вместо shell-скрипта с start(), stop(), restart() - INI-подобный файл с секциями [Unit], [Service], [Install]. Пример для простого демона:

[Unit]
Description=My Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp
Restart=on-failure

[Install]
WantedBy=multi-user.target

Это короче и читабельнее, чем типичный init.d-скрипт. Но непривычно.

Параллельный запуск. SysVinit запускает сервисы последовательно, номера в именах скриптов (S20networking, S50ssh) определяют порядок. systemd строит граф зависимостей и стартует что можно параллельно. На практике это быстрее загрузка - в тестах на свежих машинах разница заметна. Но если зависимости в юнитах прописаны криво, сервис стартует раньше чем нужно.

Журналирование через journald. journalctl вместо хождения по /var/log/. Можно фильтровать по юниту, по времени, по уровню. journalctl -u nginx -f - как tail -f для конкретного сервиса. Удобно. Но rsyslog при этом не исчезает, они живут вместе - часть команды ещё разбирается какой из двух смотреть в первую очередь.

Управление через systemctl. systemctl start/stop/restart/status nginx вместо /etc/init.d/nginx start. Короче и единообразнее. systemctl status показывает последние строки лога сразу - не надо идти в /var/log/nginx/error.log за первичной диагностикой.

Что нас беспокоит

Скрипты в /etc/init.d/ SysVinit писали годами, накопилось много. У клиентов на сопровождении есть сервисы с нетривиальными init-скриптами - хитрая логика pre/post, зависимости от монтирования конкретных разделов, условный запуск. Всё это нужно переписывать в формат юнитов. systemd умеет запускать старые SysV-скрипты через compatibility layer, но рассчитывать на это в продакшне не очень хочется.

Второй момент - Ansible. Мы активно используем Ansible для провизионинга, и модуль service в нём с systemd работает нормально. Но playbooks, которые управляют сервисами через shell-команды типа /etc/init.d/..., надо будет пересмотреть.

Третья вещь - отладка нетипичных ситуаций. SysVinit предсказуем до скуки: скрипт не запустился - смотришь в лог, видишь ошибку. systemd с его параллельным стартом и зависимостями иногда преподносит сюрпризы. Пока опыта не наберёшь - systemctl status и journalctl -xe станут основными инструментами.

Практический план перехода

Что решили делать у нас.

Первое - тестовая среда уже на systemd. Поднимаем новые тестовые машины на Ubuntu 13.10 (там systemd уже опциональный) и на Debian с systemd вместо upstart/SysVinit. Нарабатываем навык, не трогая продакшн.

Второе - инвентаризация init-скриптов. Проходим по серверам клиентов и фиксируем все нестандартные скрипты в /etc/init.d/. Всё что написано руками или не из пакетного менеджера - кандидаты на переписывание в .service.

Третье - шаблоны юнитов. Берём типовые сценарии - веб-сервер, демон приложения, воркер очереди - и пишем шаблонные .service-файлы. Потом включаем в Ansible-роли.

Четвёртое - journald vs rsyslog. Пока оставляем оба, но договариваемся внутри команды что для оперативной диагностики - journalctl, для долгосрочных логов и централизованного сбора - rsyslog и ELK как обычно.

Дискуссия в команде закончилась примерно тем, что решение Debian - не катастрофа и не откровение. Переход неизбежен, инструмент в целом современнее SysVinit, но работы по адаптации скриптов и playbooks предстоит достаточно. Главное - не откладывать до момента когда Jessie встанет в продакшн.