Примерно пол года назад я начал довольно глубоко изучать функционал и фишки systemd. В то время я получал стабильный отклик от коллег по цеху «зачем усложнять себе жизнь лишним функционалом, которым никто не пользуется».
Ровно то же самое мне говорили почти 10 лет назад, когда я погружался в мир linux систем и практически полностью отказался от изучения windows. В эпоху импортозамещения у меня есть некоторое преимущество по знаниям linux дистрибутивов и принципов их работы.
Чуйка не подвела ни тогда, ни сейчас. Знание функционала systemd очень сильно спасает в сложных и узких настройках. Об одной из них мы поговорим сегодня.
Что делать, если нам нужно запускать какой-нибудь скрипт по расписанию в linux системе? Самое очевидное - crontab. Стабильно, проверено временем, практически безотказно. Но с урезанным функционалом.
А что, если у нас настроен кластер из двух серверов, и нам нужно запускать скрипт по расписанию только на активной ноде?
Можно добавить в скрипт проверку, какая нода сейчас активна, и только на основной выполнять команды.
Во-первых, это довольно странный костыль, так как придется добавлять проверку в каждый скрипт. Во-вторых, скрипты все равно будут запускаться на обеих нодах (как минимум, для проверки), что нам не очень то и нужно.
Systemd в кластере
Помните, как мы создавали свой кластер и добавляли уже имеющийся systemd сервис nginx, а потом создавали свой собственный сервис?
Команды были просты:
pcs resource create nginxres systemd:custom_service
pcs resource create custom systemd:custom_service
А теперь маленькая хитрость: кластеру абсолютно без разницы, какой именно systemd unit вы добавляете. Это может быть и сервис, и таймер, и даже mountpoint. Команда будет одна и та же.
pcs resource create {Имя ресурса в кластере} systemd:{Имя systemd unit}
- Когда мы создавали самописный ресурс в кластере, мы уже создали отдельного демона:
- Давайте немного отредактируем его, просто удалив строку RemainAfterExit:
- Перечитываем конфигурации systemd:
systemctl daemon-reload
- Заранее удалим из кластера ресурс с этим демоном:
pcs resource delete custom
- Создадим для нашего oneshot демона отдельный таймер, с выполнением раз в минуту:
touch /etc/systemd/system/new_test.timer
[Unit]
Description="touch file every 1 minute"
[Timer]
Unit=custom_service.service
OnCalendar=*:*:0
[Install]
WantedBy=timers.target
- Добавляем наш таймер как ресурс в кластер:
pcs resource create cluster_cron systemd:new_test.timer
- Добавляем его в группу:
pcs resource group add NginxBalance cluster_cron
- Проверяем:
- Файлы по скрипту создаются раз в минуту только на основной ноде: