Comments 245
Интересная тема. Необходимость заполнить конфиги sgstemd возникает крайне редко, чтобы изучать всё тонкости. Как правило обзожусь копипастой с беглым пролитыванием документации. Поэтому узнать как правильно нужно сделать и почему у очень хорошая задумка
Тут проблема в том, что обычному пользователю (разработчику, например) чтение маеов по администрированию впрок, мало полезно. Хорошо, если получится запомнить какие возможности есть в теории.
С другой стороны, systemd есть не везде по дефолту, если говорить о мире виртуалок, контейнеров и прочих облак.
Зная что для твоей задачи лучше всего использовать, например, systemd, уже легко сможешь найти всю необходимую информацию о том как его использовать, в сети или в манах все легко находится.
А маны по другому устроены:
- это делает это
- это делает то
:(
С другой стороны, systemd есть не везде по дефолту, если говорить о мире виртуалок, контейнеров и прочих облак.
Недостоверно. На уровне операционки — он есть уже везде. Там, где нет — это маргиналы, которые скорее всего знают, как жить без него.
Единственное, где боль — это «засунуть системди в контейнер», но это не нужно, потому что там сама система оркестрации (тот же кубернетес) берет на себя функции системди (запуск, хелсчеки, управление ресурсами и пр)
У systemd есть своя собственная система контейнеризации systemd-nspawn, в которой запихать в контейнеры systemd можно, а местами даже нужно
спасибо, я в курсе. А еще можно не играть с контейнеризацией nspawn, а попросту использовать те механизмы изоляции, которые предоставляет сам systemd — там и изоляция неймспейсов, и cgroups, и лимиты на ресурсы, и возможно сделать chroot в различных формах — вот контейнер и получился.
В LXC systemd присутствует.
никакой боли если ты используешь нормальные контейнеры а не docker
Собственно про journald выше упомянутый, который ну нифига не является достаточно производительным решением by design
Хотя в основном решение неплохое. ))
Но пока не вижу решения, вариант выделите явный источник логов в отдельный канал предварительным описанием конфигов явно не решение. Пока костыль, возможно даже поможет, если не дешевле мимо него обработать.
Вообще принципиально лучшее решение не сделать. Пайплайны обработки логов очевидно имеют разные ограничения. В частности, если речь про аудит логи. И что хуже — нам нужно всегда выбирать между наблюдаемостью системы, производительность и целостностью (блокируемся ли мы для входящих запросов, если мы не можем, логи, например, отгрузить в SIEM)
А ещё я бы серьёзно поразмыслил над вопросом реальной необходимости логирования в таких количествах, что озвученная проблема производительности так остро стоит.
www.researchgate.net/publication/228694459_Rsyslog_going_up_from_40K_messages_per_second_to_250K
тут просто тупо решают проблему увеличения производительности с 40k в секунду до 250 к в секунду
до 40к в проде не приходилось, 20к было, оно в эластик штатно укладывалось
гдет пара терабайт в день по объему выходило.
На машину это около 500 — 4000 в сообщений в секунду. Без особой оптимизации.
Только ключевое условие, весь софт писал напрямую в локалхост по udp на rsyslog.
journald критично не справлялся.
По стоимости это выходило < гита оперативы на машину, и 1 — 4% cpu, ну машины толстые были.
Все мысли на тему реальной необходимости в практике спускаются свыше, и далее в результате консенсуса цена — возможность реализуются на практике.
Т.е наглядно.
Проблема
Решение
Немного комментариев почему, зачем и нахрена.
И ничего лишнего!
Super! Respect!
Единственное что, про конфиг было бы приятно немного подробнее. Или же сделай первую статью в цикле как раз про конфиги, потому как эта единая строка пока выглядит как-то… неясно.
Спасибо!
sysusers.d?Давно практикую services & timers, но вот это первый раз вижу и сходу не понял… Пари старте системе убежлается, что юзкр есть?
systemd-sysusers.service пробегается по каталогам с конфигами, вычитывает их, а дальше действует подобно ансиблу. Если пользователь есть — ничего не происходит. Если пользователя нет, то пользователь создаётся согласно описанию. IDEMPOTENCE
Note that systemd-sysusers will do nothing if the specified users or groups already exist or the users are members of specified groups, so normally there is no reason to override sysusers.d vendor configuration, except to block certain users or groups from being created.
Вы можете сами посмотреть содержимое директории
/usr/lib/sysusers.d там есть примеры конфигов поставленных вместе с пакетами и из поставки systemd.
ExecStartPre=+/usr/bin/install -d -m 0700 -o http -g http /var/run/domoticz
А почему не через systemd-tmpfiles?
systemd-tmpfiles будет отдельно и подробно.
Эти факторы субъективны. Если 30 лет писал на баше init скрипты и т. п., то systemd или supervisord подходы выглядят непонятно (какой шелл будет выполнять ExecStart? Что будет в енв переменных? В чем конкретно разница типов сервисов? ), непредсказуемо (какая последовательность вызовов? Как мониторится состояние процессов и мониторится ли) и, как следствие, потенциально ненадежно и/или оперативно не поддерживаемой в случае инцидента.
А профит для глубокого изучения кроме моды какой-то непонятен
Логику запуска/перезапуска/остановки/релоада конфигов. Логгирование, изоляцию логов, отправку логов на удалённые хосты. Проверку статуса сервисов, ограничение ресурсов (память, проц, сеть, доступ к FS), зависимости запуска сервисов и так далее и тому подобное. Причём если вам не нужен какой-либо функционал, вы вольны просто им не пользоваться. Собственно в systemd есть ровно три обязательных компонента. Сам systemd, journald и udevd. Всё остальное не является обязательным и заменяемым. Например в большинстве десктопных дистрибутивов используется NetworkManager вместо штатного systemd-networkd.
Тогда, наверное, у вас достаточно опыта чтобы дописать недостающие части решения самостоятельно. Уж точно простой запуск программы не должен стать какой-то сложной задачей.
И что, в FreeBSD, Devuan и Gentoo одинаковое универсальное решение? Не, конечно, в принципе возможно поставлять шелл-скрипт, который будет дублировать функциональность инит-системы, учитывая специфику разных ОС и дистрибутивов, и который все равно придётся дергать из rc-скриптов, но какой в этом смысл?
А зачем в той же FreeBSD или Gentoo пихать голые sysvinit-скрипты, дублирующие функциональность инит-систем адской копипастой?
Когда пользовался FreeBSD и Gentoo, всегда такие портяночные скрипты переписывал под родную для системы инфраструктуру, и из 100 строк получалось 10.
Эта универсальность скорее зло. Сколько раз такое было, когда качаешь какую-нибудь проприетарщину, которая разворачивается в /opt с sysvinit-скриптом, и потом мучительно дебажишь копипасту с race condition, найденную тем индусом на каком-нибудь stackoverflow, после чего все равно переписываешь на тот же openrc или systemd unit.
Написание rc-скрипта или юнита — это достаточно несложная задача, чтобы с ней нельзя было справиться за 10 минут, имея в качестве примера что угодно вменяемое. А если там что-то архисложное и замороченное (как в том же MySQL до восьмерки было), это скорее говорит о качестве продукта :)
Как правило достаточно совсем уж дичь добавить в /etc/rc.local или в cron при reboot (и в crontab нужного пользователя)
Будет запускаться после запуска всего и будто в консоли запустили руками...
Можно вопрос для пополнения личной статистики? А по каким объективным техническим причинам было решено использовать НЕ systemd?
В случае небинарных журналов никаких гарантий того, что они целостны — нет. Поэтому — да, формат проще и в теории их восстановить проще, но если там условный аудит — я бы ему не доверял априори.
1 строка — хэш
2 строка — хэш от первой и от второй
и тд
вообще любой формат что бинарный, что не бинарный (по вашему определению)
это последовательность битов и байтов, они могут быть читаемы человеком или нет, но для компа роли никакой. Вопрос индексов (ну коль уж так надо) легко решается дом файлами, более того, я б сильно предпочел именно такое решение, как минимум это возможность индексирования постфактум, вначале накидали логов, потом индексировали. Более того, это давно работающее и стандартное решение, и целостность туда прикручивается с легкостью.
Противоречие в примере вашем вижу я :)
Если это настолько важный и нужный комп, что побитый лог (бинарный или нет — не суть) — проблема, значит, верно одно из:
- Лог неправильно хранится. Его нужно пулять вовне (rsyslog и аналоги)
- Дисковая подсистема не обеспечивает целостность инфы в нештатных ситуациях — всё ли хорошо с железом? Не побьётся ли в следующий раз инфа более важная, чем лог?
… ладно, окей, он рулит некими условными заслонками на трубопроводе гдето в мерзлоте, и всё управление по RS485 :) питание по нему же (да, я изверг)
… но в таких условиях явно надо хотя бы raid 1 и тупо аккумулятор.
но в описанных ОЧЕНЬ СПЕЦИАЛЬНЫХ условиях явно будет трудиться ОЧЕНЬ СПЕЦИАЛЬНЫЙ линукс, там не то что systemd, там много чего не будет, на 15 ваттах то…
Ну, например, в centos по дефолту journald не хранит даже предыдущий dmesg, после ребута его логи начинаются с момента загрузки.
А вот как мне в journald разделить логирование разных сервисов по разным журналам? =) Никак, да? Жаааль. Значит снова без syslog не обойтись. Вот ведь!
Ну, например, в centos по дефолту journald не хранит даже предыдущий dmesg, после ребута его логи начинаются с момента загрузки.
sudo mkdir /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal«И ваши волосы станут мягкими и шелковистыми». ©
А вот как мне в journald разделить логирование разных сервисов по разным журналам? =) Никак, да? Жаааль. Значит снова без syslog не обойтись. Вот ведь!
«Читайте маны, они рулез!» © ;-)
«И ваши волосы станут мягкими и шелковистыми».
Ваши шутки очень остроумны и смешны. Спасибо, я знаю, как это настроить. Обратите внимание на слово "по дефолту". Извиняюсь за слэнг, это означает — "по умолчанию".
«Читайте маны, они рулез!» ;-)
В оригинале было "читайте доки", кмк. Ну раз уж с копирайтами. :)
Да, namespace'ы есть, но в той же доке вы найдете ограничения и описание их реализации — через маунт неймспейсы, что в свою очередь велосипедизм. Протокол syslog имеет вполне простой и понятный механизм разделения facility/priority без велосипедов.
Мы же от них вроде как хотели избавиться?
Протокол syslog имеет вполне простой и понятный механизм разделения facility/priority без велосипедов.
Только этого множества (facility/priority) зачастую недостаточно, учитывая количество разнородных источников логов внутри типичной системы....
Ваши шутки очень остроумны и смешны. Спасибо, я знаю, как это настроить. Обратите внимание на слово «по дефолту». Извиняюсь за слэнг, это означает — «по умолчанию».
Все вопросы к ментейнерам вашего дистрибутива, не? Systemd тут ровно никаким боком. Это ментейнеры centos не озаботились включением постоянного хранилища для логов.
Протокол syslog имеет вполне простой и понятный механизм разделения facility/priority без велосипедов.
journald аналогично имеет простой и понятный механизм разделения facility/priority. Если мне какой-то юнит выдал ошибку, я сразу, одной командой могу посмотреть логи связанные с этой ошибкой. Безо всяких велосипедов. И да. Неймспейсы это не про разделение facility/priority.
Все вопросы к ментейнерам вашего дистрибутива, не? Systemd тут ровно никаким боком.
Конечно. Так изначальный ваш посыл был про посмотреть позапрошлые dmesg. Очевидно, что при небольшой настройке это легко получить и без journald с обычным ®syslog. А если journald нужно донастраивать специально, то тогда 1:1. Только про это речь.
journald аналогично имеет простой и понятный механизм разделения facility/priority.
И какой? Если Namespace'ы не про это, как вы сами только что сказали.
Facility как раз позволяет легко и просто решить задачу разделения логов по (группам) сервисов (источников). Уверен, вы это знаете. Именно это было задачей, на которую вы сами же тыкали меня в маны парой ответов выше.
И какой? Если Namespace'ы не про это, как вы сами только что сказали.
Да, неймспейсы не умеют разделять перенаправление отдельных syslog facilities по отдельным журналам, признаю. Но в вашем изначальном комменте, собственно про facilities ничего не было.
А вот как мне в journald разделить логирование разных сервисов по разным журналам?
И это я вам сказал как — раскидав по разным неймспейсам. Это хорошо и для производительности и для безопасности. Про syslog facilities это вы уже в процессе вбросили. Но при этом посмотреть отдельные логи с фильтром по facility / priority / time / log namespace любым другим признакам вы можете одной командой, быстро, удобно и без напрягов. Плюс к этому вы можете вообще не писать логи на диск / в память, а сразу перенаправлять их куда вам удобно (syslog / kmsg / tty / wall), да хоть во всё сразу. При этом для каждого неймспейса будут свои правила, в отдельных конфигах.
А если journald нужно донастраивать специально, то тогда 1:1. Только про это речь.
Не нужно, ибо официальный ман
journald.conf говорит нам:Storage=
Controls where to store journal data. One of «volatile», «persistent», «auto» and «none». If «volatile», journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed).
If «persistent», data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to
/run/log/journal (which is created if needed), during early boot and if the disk is not writable. «auto» behaves like «persistent» if the /var/log/journal directory exists, and «volatile» otherwise (the existence of the directory controls the storage mode). «none» turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work). Defaults to «auto» in the default journal namespace, and «persistent» in all others.
Note that when this option is changed to «volatile», existing persistent data is not removed. In the other direction, journalctl(1) with the --flush option may be used to move volatile data to persistent storage.
Вот даже теперь и вручную не нужно создавать директории в
/var/log — оно само. Главное изменить Storage=persistent или auto, даже лучше auto, что-б не потерять сообщения на ранних этапах загрузки.Но в вашем изначальном комменте, собственно про facilities ничего не было.
Не было. А почему там должно было быть про них? Речь же шла про (не)возможности journald, а не syslog.
И это я вам сказал как — раскидав по разным неймспейсам. Это хорошо и для производительности и для безопасности. Про syslog facilities это вы уже в процессе вбросили.
Во-первых, давайте не будем подменять. Вопрос был не про производительности и не про безопасность, а про разделение на разные журналы.
Во-вторых, я ничего не "вбрасывал". Попрошу вас, пожалуйста.
Но при этом посмотреть отдельные логи с фильтром ...
Я тронут, но вы напрасно расписываете мне возможности jd. Я, безусловно, не знаю их все, но уже и далеко не на уровне первой страницы мана. Вынесите это в статью — будет намного полезней, имхо.
Моя изначальная цель разделение логов — это не "удобно посмотреть одной командой". У меня на хосте много сервисов, часть из них пишут в логи на порядки больше других. Соответственно, разделение их по журналам требуется для решения нескольких задач: разные дисковые хранилища, разные настройки ротирования(!), и разные параметры компрессии (где нужно), и разная детализация(!!!) и форматы представления.
Плюшки journald далеко не бесплатны, и удобство фильтрации вносит оверхед 2 (два) порядка по объему логов, занимаемых на диске, по сравнению с текстовыми. Это не для красоты речи — это результат испытания на двухнедельном архиве боевых сервисов.
По человечески, без хаков, решить такую задачу на jd — близко к невозможному.
Я тронут, но вы напрасно расписываете мне возможности jd. Я, безусловно, не знаю их все, но уже и далеко не на уровне первой страницы мана. Вынесите это в статью — будет намного полезней, имхо.
Всё будет! журналирование несомненно в планах.
По человечески, без хаков, решить такую задачу на jd — близко к невозможному.
Ну совсем уж сложные задачи надо форвардить соответствующим инструментам. Стёк ELK и что там у нас сейчас есть, из стильно-модно-молодёжного.
Стёк ELK и что там у нас сейчас есть, из стильно-модно-молодёжного.
Вот мы и вернулись к моему изначальному посылу =) Понимаете, что для этой задачи не нужно никакого молодёжного стека, кроме элементарной возможности разделения журналов. Всё остальное давно уже есть. Другое дело, что архитектура jd скорее всего не позволит это реализовать в том виде, как оно сделано для rsyslog. Это не плохо и не хорошо, просто инструменты отличаются. Поэтому, да, jd позволяет одной строкой вывести предыдущий dmesg или там логи с момента загрузки — неплохо, удобно. Но есть и минусы, и есть простые вещи, которые были, а теперь их нет и их не хватает для реальных задач.
Согласитесь, честно будет писать не только плюсах.
Я честно не понимаю Вас.
Согласитесь, честно будет писать не только плюсах.
несомненно. Кто-то спорит? Рассказывайте о минусах. Еще раз — systemd — модульная система. Нет никакой беды в том, чтобы замещать его компоненты какими-то другими внешними компонентами, если предложение от systemd Вас не устраивает. Что не так?
В случае сложного кейса вроде Вашего вариантов несколько:
- использовать "чистый" journald, смирившись с его ограничениями (например, закидать каталог под логи дополнительным местом с отдельного физ накопителя)
- перестроить архитектуру систему — например, отказавшись от локального хранения логов и перенеся его в некую централизованную систему. Как минимум ЦЕНОЙ РЕСУРСОВ получите интересные бонусы вроде корреляций между событиями в разных системах и на разных узлах + та же самая ротация индивидуальная для каждой системы/подсистемы. Еще раз повторюсь, что локальные логи — это днищенско, потому что в случае, например, потери виртуалки (сломалась окончательно), Вы ее теряете вместе с логами. К тому же кто гарантирует целостность логов? НИКТО. А вот внешняя система хоть какие-то гарантии дает (она работает как append-only хранилище на самом деле, но тут уж как настроишь, и вопрос с транспортом стоит особо остро).
- использовать связку journald + rsyslog/syslog-ng…
может можно еще что-то.
А я не понимаю вас =) Я привел контрпример "просмотра предыдущго dmesg", достаточно простой кейс, когда journald (конкретно jd, а не вообще systemd, который в целом мне нравится) или не удобен или вообще не может решить проблему самостоятельно, без привлечения старого sysloga.
Но, похоже, наши протоколы несовместимы. Наверное, я до сих пор текстовый и ламповый, и одной командой меня не посмотреть =) Так что замнем для ясности, видимо.
Никто не только не заставляет пользоваться исключительно journald, но даже и вообще писать его бинарные логи на диск. Неправильно воспринимать сабж как замену для какой-нибудь
классической системы типа rsyslog. Его задача — собирать всеми возможными способами вывод разнообразного софта в единое полотно. А что дальше с этим потоком логов творить — ваше дело. Можно, например, буквально за 10 секунд сделать так, что journald будет хранить логи только в оперативной памяти + форвардить их в классический rsyslog/syslog-ng/ваша_привычная_система. И пусть она пишет в текстовые файлы по любой желаемой логике, пересылает по сети на единый сервер, сливает в /dev/null — всё, что захотите.
Использовать "классические" системы без такой прослойки в мире современного софта, часто пишущего свои логи тупо в stdout, ОЧЕНЬ неудобно. Как минимум, нужно много костылей по передаче fd этих stdout от каждого запущенного скрипта в одну из многочисленных "классических" систем логирования. Journald же встроен в init систему и позволяет проворачивать такие вещи элементарным образом.
Так что конкретно это и близко не техническая причина, просто вы не разобрались до конца в целевой нише journald.
верней 2 рецепта
1) redhat like os
2) debian like os
Нужно отключить вообще journald
все логи, ядро и прочее должны идти в rsyslog или syslog-ng
идти они должны напрямую, не через journald.
А в чём разница (с точки зрения результата) между "логи идут напрямую в rsyslog" и "journald пересылает все логи в rsyslog"? Без стёба, я во всём этом действительно слабо разбираюсь и хочу понять суть спора.
по сути ни в чем, кроме того, что наши коллеги убедительно хотят выкинуть из системы те компоненты, которые считают лишними )))
вырезать его в принципе нельзя
Доказательства будут? Или это очередное. Кхм. Неподтвержденное утверждение?
тут код ))
вырезать путем создания форка и переписывания в принципе можно, а вот путем конфигурирования нет.
Еще какие доказательства нужны? Не хочется (можется) по коду, ну загуглите сей вопрос.
DESCRIPTION
systemd-journal-remote is a command to receive serialized journal events and store them to journal files. Input streams are in the Journal Export Format[1], i.e. like the output from journalctl
--output=export. For transport over the network, this serialized stream is usually carried over an
HTTPS connection.
Вы-ж не боитесь, когда у вас классический syslog данные по сети гоняет? ;-)
Вот этой функцией я не стал бы пользоваться. То ли ее не оттестировали, то от не доработали, но работает так себе.
Варианты как посмотреть что то роли не играют.
Рассказы про валидацию логов, ну тоже если честно.
По крону, есть кейсы где интересней, но в общем то на то и вышло.
Есть варианты сильно лучше чем написание программ для запуска (баш портянок)
есть хуже, появились новые возможности (но сильно опоздали, показатель просто тупо запуск через докер(podman))
Претензии конкретные, замена функционала по логированию на софт не способный это делать, и не возможность простыми способами использовать альтернативы.
Ну давайте так, систему легирования systemd по факту убил, вернее усложнил и сделал частично неработоспособной.
Я только отчасти с этим согласен. Потому что докер системы логирования точно так же «убил». Все сейчас серят в stdout/stderr, а дальше это уже задача инфраструктурный платформы не умереть обрабатывая это ) и передавать логи в отдельное хранилище.
Претензии конкретные, замена функционала по логированию на софт не способный это делать, и не возможность простыми способами использовать альтернативы.
Я не пробовал выкорчевывать journald, но есть гипотеза, что если сделать слушающий сокет /dev/log через тот же rsyslog/syslog-ng, то вы сможете использовать «лучшее» из обоих миров. Systemd модульный и никто не заставляет использовать те его компоненты, которые Вам не нравятся. Например, как выше уже говорили — сеть зачастую настраивают не через systemd-network, а через networkmanager или ifup (кажется, пакет iproute2). То же с управлением ntp — не нравится systemd-timesyncd? Ставь chrony
но сильно опоздали, показатель просто тупо запуск через докер(podman))
Здесь я тоже скорее соглашусь, что докер «взлетел» существенно быстрее и, скажем так, навык его использования есть сильно у бОльшего количества людей, чем навык использования системди. Касательно того, что системди опоздал — вряд ли на самом деле. Потому что все эти «ядерные» штуки для контейнеризации появились в мейнстриме не так уж давно. И поэтому попросту сделать это раньше возможности не было.
как мне это в rsyslog минуя journald отправить?
Ну могу тупо в udp перенаправить, просто средствами linux и с определенной версии systemd, далее читать на сокете. Но это костыли, я просто так могу решить ограничения этой системы, есть другие костыли. Но вы мне говорите что есть универсальная система, но блин она не МОЖЕТ прокачать мой объем логов, и дальше?
Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум(с systemd не помню как тогда было), вы просто не смотрели их документацию.
К journald у меня конкретная претензия, мне приходится ее тупо выпиливать и заменять на rsyslog, syslog-ng, различные шипперы логов типа filebeat и тд (их ну дофига, тупо читают файл и пинают по tcp(udp))
Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца, жду минуту (что по cpu и памяти смотреть не хочу, раньше было страшно, но на машине 32 гита оперативы, и в общем не смертельно)
еще раз, жду минуту, shift-gg (в переводе, покажи последнее)
в терминале (даже фантастическом) меньше 300 строк, утилита вместо того чтоб тупо прочитать (с бинарных данных, с ИНДЕКСАЦИЕЙ) последние 300 строк, посмотреть сколько у меня терминал показывает и вывести, тупо ЧИТАЕТ ВСЕ ЛОГИ ПОСЛЕДОВАТЕЛЬНО.
Я не разобрался… ))
journalctl? -n количество_строк не пробовали, например?это просто тупо логика, и она ну нифига не реализована, и посему если нужно чтоб journalctl использовала начальная линия поддержки, его приходится обкладывать альянсами или скриптами
Претензия по моему конкретно расписана, вы скажете что это не правда?
Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум
Проблемы софта, пишущего в stdout/stderr не решили, только костыли с педиректом вывода полуручными методами
Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца
Ну так именно что не разобрались, судя по написанному. Потому что и вывод можно фильтровать по разному и искать по временным рамкам и индексирование, учитываемое при чтении имеется. И, конечно же, это всё не работает от слова совсем ежели вы самолично просите вывалить вам ВСЕ логи, которые имеются в принципе.
вывалить все логи — и управление с терминала управляющей последовательностью команд, по моему несколько разные вещи.
Где в этом процессе вы увидели хоть какое-то управление или фильтрацию логов в самом journalctl? Самое натуральное «прочитай и вывали мне всё, что есть, а я промотаю руками до конца», только обмазанное less.
Вопроса бы не было.
journalctl --no-pagerА ещё есть такая команда:
journalctl --pager-endИ такая:
journalctl --reverseСуть в другом, тут уже отписали, что да, народ пинает ныне все в докере, и логи в stdout, stderr и в докер втыкают в параметры неблокируемый вывод, и дальше в F(syslog) неожиданно оно так умеет
и дальше рулят, и не от удобства и крутости journald, а от того что оно не выполняет свои функции…
Ох… ну я знаю параметры…Я это прекрасно понимаю, еслиб journalctl мне просто стал бы гнать весь лог в консольjournalctl --no-pager
Нихалеры не понятно. Зачем вы спрашиваете, если знаете. Это уже начинает напоминать откровенный то-ли троллинг, то-ли хейтинг…
Так делают просто потому что есть старый привычный инструмент, а journald — новый и нужно привыкать.
journalctl —since=tomorrow
Можно и конкретные дату/время указать.
Пишу свой велосипед хаба умного дома. Сейчас делает всё, что нужно мне. Когда задался вопросом запуска нужных демонов начал разбираться с systemd. После этого выкинул нафиг все остальные системы инициализации, тем более systemd используется у меня и в Gentoo и в Ubuntu или Raspbian на малинке. Даже крон не нужен. И всё работает отлично. Я уж не говорю о том, что запустить систему с графикой в Gentoo без systemd гораздо сложнее.
с другой стороны особых изменений это не принесло
Ну, что здрасьте. Начать с того, что не везде есть и могут быть куберы/номады и они тоже не святым духом работают (читай поверх тех же виртуалок с линуксом и системди), и кончая тем, что sys v init надо было сжечь. Вы никогда не сталкивались с его ограничениями? По тому, что Вы говорите — очевидно нет. А системди это все изящно решает и упрощает operations
Поясните — как композ файл взаимосвязан с системди?
Начну с того, что компоуз не замена системди НИ РАЗУ. Компоуз — это способ промоделировать запуск нескольких микросервисов на машине разработчика. Отсюда все его ограничения. Попробуйте связать компоуз и реальный мир. Компоуз и порядок монтирования файловых систем или порядок запуска сервисов. В компоуз нет таймеров/крона
И пр. пр. пр. пр.
ему нужен механизм запуска его творения на целевой системе, ну и init систему
он рассматривает как такой механизм, но к сожалению мир не совершенен, и поэтому ему сильно проще передать через формат компоуз файла информацию, чем курить nnn… количество мэн документации по systemd
В итого, субъект становится штукой которой интересуются полторы калеки которые работают прям на железе, но к сожалению он для них так же проблемен, ибо не выполняет заявленных функций.
И да, я и есть те полторы калеки, монтирование файловых систем, запуск задач по таймеру и тд я решал еще 15 лет назад, связываю компоуз и реальный мир я каждый день, неожиданно мне за это платят, и не зп, мне клиенты платят. И пр. пр. пр.
Разработчик, которому не впился системди — это не разработчик, а калека. Точно так же, как почему-то разработчику внезапно необходимо понимать как работают базы данных. Если, конечно, мы под разработчиком не понимаем веб-кодера-макаку, но что тогда плакать о том, как у нас в целом софт плохо работает и требует для работы беспрецедентные мощности? Люди на Луну летали на существенно меньших мощностях, чем есть в современном ПеКа.
90% разработчиков про systemd краем уха, и то только название ))
мой прогноз, на выборке из бэкендеров ))
А разработчики за себя и сами думаю могут сказать ))
За сим откланиваюсь, ответы читать буду завтра, карма знаете ли ))
Сложно поддерживать несколько нитей разговора с разными людьми имея ограничения. Но можем пообщаться где нибудь на другой платформе, где политические, религиозные, технические и прочие воззрения не могут сказываться на возможности выражения мыслей. ))
Частично замена. Restart опции там есть, что позволяет не писать кучи service файлов, только для docker-compose run service cronjob {ну и таймер к каждому). В последнем композе что и для джоб сделали, но доки на момент релиза не было ещё
Если без шуток, то сейчас бы всякие оркестраторы с системами инициализации в одну кучу валить и сравнивать. Или на локалхосте кубер для банального запуска софта использовать.
У меня больше вопрос что использовать оптимально на одиночных дев-стейдж-прод серверах для запуска своего серверного прикладного софта. Вариантов куча, агитируют вокруг в основном за k8s или, вот, systemd. Но стойкое ощущение, что половину разрабов надо будет в админов переобучать, пока спасём я башем и кроном и docker-compose, но всё-же кое-что переписал на systemd, чтоб нагрузку джобов балансировать по времени. Работает, но не скажу, что понравилось…
Спасибо пиши плз
$ man systemd.directives | wc -l
7710
Тут возникает вопрос — а как я вообще должен догадаться, что из этого использовать для своего приложения?
Вот у вас, например, в первом конфиге есть строка
AmbientCapablities=CAP_NET_BIND_SERVICEВ исходной версии с баш-скриптом ничего про выдачу прав нет — там просто биндинг на порт, и понеслась. Я systemd пользовался на уровне "скопипастить готовый конфиг", и никогда бы в жизни не догадался, что мне такое надо что-то вот такое хитрое добавить, чтобы заработало.
Может где-нибудь есть сборник часто встречаемых граблей при использовании systemd?
$ man systemd.directives | wc -l
7710
Вы некорректно посчитали. Директив самого systemd там меньше. Как минимум в два раза, если не в три. А кроме директив systemd там присутсвуют ещё и директивы udev, связанные с systemd параметры ядра, параметры crypttab и fstab, параметры командной строки различных утилит, системные переменные, ну и сами ссылки на маны, в которых всё это описано. Короче это такое содержание «Энциклопедии юных сурков» © ;-) Так что, на самом деле не всё так страшно. Этот справочник хорош когда вы увидели в каком-нибудь юните неизвестный параметр, хотите о нём почитать, то можете выгрепать ман в котором он описан.
man systemd.directives|egrep -A1 'UnknownParameter'Тут возникает вопрос — а как я вообще должен догадаться, что из этого использовать для своего приложения?
Три основных мана для написания собственных юнитов, по крайней мере юнитов типа *.service, это
systemd.unit — директивы общие для всех юнитов; systemd.service — директивы специфичные для юнитов типа *.service и наконец systemd.exec — директивы выставления окружения юнитов — environment, рабочие каталоги, права, лимиты на использование ресурсов (mem / cpu / net etc) и в том числе директивы связанные с Capabilities — это такие мандаты в ядре линукс, которы позволяют процессу запущеному из под непривилегированного пользователя пользоваться некоторыми возможностями рута. В данном случае возможность биндиться к любому порту меньше 1000. Описание этой подсистемы, как и список всех «Cap-s» можно посмотреть в man 7 capabilities
Oxyd, а если демон — питоновский скрипт, что будет считаться его "зависанием"? При ошибке он просто выкидывает исключение и прекращает работу. Systemd это может отловить? А то сейчас приходится через cron делать restart каждые 10 минут (в гарантированной паузе между заданиями), вне зависимости, есть ошибка или нет.
echo $?Можно сделать ход конём и использовать в своём питоновском скрипте sd_notify. Это нечто watchdog-like, созданное для отправки в systemd keepalive сообщений и оповещений об изменении состояния сервиса через специальный сокет. Можно отслеживать и обрабатывать не только падения с ошибками, но и, например, зависание сервиса.
По поводу автоматического перезапуска упавшего сервиса есть нюанс: по умолчанию systemd позволяет не более DefaultStartLimitBurst(=5) перезапусков за интервал, равный DefaultStartLimitIntervalSec(=10s). После чего юнит уходит в failed state и больше не перезапускается вообще. Так что может быть нужным либо StartLimitIntervalSec/StartLimitBurst поправить, либо интервал межу рестартами увеличить. Или сервис может упасть навсегда после пяти неудачных попыток рестарта.
Этот пост напомнил про развитие автоматизации запуска сервисов на моем предприятии.
- (до меня) баш скрипты и крон
- (меня взяли на работу) переписываю все на systemd
- (я ухожу в отпуск на год, зато у нас появился DevOps студент) все переписывается на Ansible, еле еле уговорил не прикручивать Кубернетис (это для запуска 2.5 сайтов на Joomla и одного rest-api на Django то)
Системд это хорошо, но ещё лучше указывать дистр где это всё работает. Например, в центосе 7 несколько устаревшая версия, и я не могу по человечески ограничить логгирование демона. 8-(
Ни разу не линуксоид, но ещё в бородатых десятых для себя подымал оракл под центосью и считал что раз умные дяди в ораклях считают что через системд правильнее, то и мне нех выеживаться.
И вообще, первый шаг в решении любой проблемы (не только научной, или инженерной) должен быть анализ имеющихся решении.
К сожалению, дилетантский подход "программист не читатель, а писатель" получил большое распространение с массовым входом вайтишников.
И как раз такие дилетанты в основном и пройдут мимо этой статьи :)
Тут есть и другой фактор — системд монструозен, что-то из того, что сделал для своего сорта пошло не так и вообще не знаешь куда копать. Его даже просто руками не запустить…
Если не хочется лезть в systemd, можно поставить supervisord
Линукс тоже монструозен. Все. Аргумент слит.
Ответ: потому что люди любят заниматься творчеством или зарабатыванием денег. первым обычно занимаются программисты, вторым менеджеры. Но истина как обычно может быть где-то в другом месте. Можно искать боль и проблемы людей и решать эти проблемы получая за это осмысленную компенсацию.
Сколько лет у вас ушло, чтобы понять что он удобен?
Меньше года. На самом деле — пять минут.
Я их уже десятки написал, плюс таймеров, но как-то всё через боль, всё с открытыми манами и копипастом из них без понимания что и как.
Возможно для практикующих администраторов или системных программистов и так.
Да, документация у systemd прямо эталонно хороша. Её, на мой взгляд, можно смело ставить в пример того, как нужно маны писать.
Всё это я нагуглил вчера, ещё до того как Вы выложили статью. Теперь, пожалуйста, приведите обратный пример. Как убить service в указанное время (и чтобы он больше не поднялся). Способы с systemd.time и Conflicts я и сам нашёл, но хочется обойтись без велосипедов systemd.
systemctl stop servicenameНет, я имел ввиду решение с systemd timer и Conflicts — это и есть велосипед, имхо. А сейчас Вы предлагаете cron, хотя статья, о том как уйти от cron.
systemctl stop servicenameПосле выполнения сервис сможет подняться после перезагрузки. Придётся ещё disable добавлять. А если сервис не нужен то ещё удалить его и сделать daemon-reload. А если их много, например, 10, 100 и более, то это вряд ли будет удобным решением.
Думаю, что логично, что управление процессами подразумевает не только их запуск, но и другие действия, в том числе остановку. Посмотрите, какое решение с помощью systemd предлагают для схожей задачи:
Starting and stopping systemd services with OnCalendar for a period of time, every day
И на сколько, по Вашему, оно элегантно? Повторюсь, если требуется запустить процессов больше, чем 1, то количество юнитов и таймеров возрастает пропорционально.
Повторюсь, если требуется запустить процессов больше, чем 1, то количество юнитов и таймеров возрастает пропорционально.
Сделайте специальный юнит, который остановит все нужные по списку. В результате у вас будет один таймер. А иначе задача «хочу остановить определённые сервисы» не решается, список всё равно придётся где-то хранить.
Как вариант — systemd targets.
А как при таком подходе сообщить оснвному юниту сервиса, что это плановая остановка, а не авария, и не нужно его срочно перезапускать?
А разве при остановке через systemctl stop или Conflicts=… сервис будет перезапускаться?
Увы, нет. Даже если стоит Restart=Always. Причём это исключительное поведение, не укладывающееся в общую документированную логику — это исключение нужно помнить наизусть и знать какие ещё есть способы остановки сервиса эквивалентные systemctl stop (в документации они даже не упомянуты).
Но почему "увы"? Это самое логичное поведение (та самая "плановая остановка"). И оно, вообще-то, документировано.
Защита от случайного стопа. И логике противоречит, если я явно указал "всегда", а есть исключения.
Я не говорил, что не документироано, оно документировано под общей таблицей текстом типа "но есть исключения из этой красивой таблицы". И это исключение надо помнить, когда пытаешься понять почему сервис, с рестарт олвэйс не активен, хотя ты его неделю назад запускал
Вот бы где глянуть такой пример реально сложной системы, не академический...
Учитывая, что все-таки как правило одна виртуалка — одна роль, то такие гиперсложные системы вряд ли нужны.
То есть остаются, наверное, железки, либо очень многокомпонентные сервисы — вроде того же гитлаба, но насколько я помню, большинство не парится и его запускает тупо через omnibus, или более того — docker.
systemctl resque, под капотом аналогичен команде systemctl isolate resque.target — То-есть остановка всего в текущем таргете и запуск всего что прописано в зависимостях к resque.После выполнения сервис сможет подняться после перезагрузки. Придётся ещё disable добавлять. А если сервис не нужен то ещё удалить его и сделать daemon-reload. А если их много, например, 10, 100 и более, то это вряд ли будет удобным решением.
Это прикол такой? Вы сейчас достаточно мощный исполнительный механизм пытаетесь использовать как оркестратор. Как бы совершенно разные задачи и уровни абстракции. Со своей задачей системди разбирается на ура, Ваши аргументы против неубедительны.
А то что Вы хотите — это Scm плавно мигрирующий в оркестрацию.
Либо костылить теми средствами, которые есть в системди (вариант с таймером и внутри systemctl disable юнит — не самый плохой, кстати)
Это прикол такой? Вы сейчас достаточно мощный исполнительный механизм пытаетесь использовать как оркестратор. Как бы совершенно разные задачи и уровни абстракции. Со своей задачей системди разбирается на ура, Ваши аргументы против неубедительны.
Пользоваться ещё не начал, но как раз в поисках решения. Сейчас всё работает на 2-х "bash-велосипедах" по крону. Собственно, вроде бы статья о том, как от велосипедов избавиться, но видимо не всё можно решить с systemd.
Даже если использовать timer, то либо на каждый процесс создавать отдельный таймер, либо внутри таймера вызывать тот-же bash-скрипт с логикой управления процессами. Возвращаемся к велосипедам.
Задача на самом деле тривиальная: клиент оплачивает услугу — запускается серверный процесс. После окончания оплаты процесс завершается.
Вам не systemd нужен, а serverless (lambda, functions)
Ну, и аналогичный функционал можно намутить на системди с триггером запуска по сокету, например, — есть опция создания transient юнитов или шаблонизированных юнитов
Примерно так https://m.habr.com/ru/post/161011/
Ну, и в конечном счете не проблема задать максимальное время выполнения юнита через тайм-ауты (но это лучше для one shot подходит) или, скажем, RuntimeMaxSec
Странный встречный вопрос на странную претензию: покажите мне любую другую init-систему, в которой такое возможно провернуть нативно и без велосипедов.
Подозреваю что пример вряд ли найдётся ибо это задача не совсем из тех, что должны решать данные системы.
тоесть любая init система ))
Тут все деферамбы systemd сводятся к тому что оно уменьшило необходимость написания этих скриптов ( программ) и заменило эти программки на конфиг а претензии к тому, что там где раньше сидела программа которая нормально работала, под общую лавочку завезли что то, что зачастую не работает (ну или работает в n… количестве кейсов, но вариант не использовать systemd при этих кэйсах сделали весьма сложным)
Ну а ответ на ваш вопрос, любая. Они до systemd решали эти вопросы. И сейчас решают.
bash скрипт, или python или Perl или go или ...? ))
тоесть любая init система ))
Это не init-системы, а вагоны костылей разной степени запутанности. Они нативно и без велосипедов нередко и запустить/остановить то нужный софт не могут.
Вот то что вы называете костылями оно просто добавляет логику. Либо эта логика заложена в синит сиcтеме, ну а вы спрашивали какая синит система способна. Отвечаю, любая, потому что есть по сути Тьюринг полное приложение в виде скрипта, или это сразу описанной в программе.
Обсуждаемо, задача любой синит системы ( в минимуме) сводится к запустить, остановить, отследить статус. Потом к этому добавили формирование окружения и тд, потом логику.
Здесь нечего обсуждать. Хотите писать инит скрипты под все мажорные операционки (учитывая специфику убунту, Дебиан, редхата/центос и сусе) — удачи. Мы же в это время быстренько пишем шаблонный юнит файл для системди и идём пить смузи.
Я уж не говорю о том, что никто не юнит тестирует скрипты. Хотя потенциальная возможность есть. И в этом отношении декларативное описание гораздо лучше — у него вариативность способов выполнения на порядки ниже.
И опять же — если есть сложные цепочки (вроде «перезапусти все сервисы, которые используют log сокет») — стандартные init системы тотально отсасывают ((((( Системди же с механизмом depends прекрасно хендлит эти истории. Я уж не говорю про скорость запуска… это одна из причин разработки systemd. Готовы ждать, пока сервер полчаса грузиться будет? Ах, да, в вашем мире все всегда работает…
Кажется понял: за systemd больше топят те для кого релизы под разные дистры или даже ОС — рутинная задача, ну или сложные цепочки на одной целевой системе. А вот когда раз в пол года нужно запускать апп-сервер только когда база данных будет готова обслуживать клиентов, когда каждая задача уникальна в рамках компании, то это самое декларативному описание в ступор вводит на несколько часов минимум, пока не разберёшься в десятый раз какой тип сервиса нужно использовать в конкретном случае, какие зависимости указать, поверить, что они реализованы ожидаемо (не приходят в активный статус сразу при старте), впилить костыль на баше если не ожидаемо, и т. д., и т. п.
Как мониторить юниты вы порекомендуете? Ну понятно можно в лог посмотреть, и увидеть что юнит (таймер или служба) упала. Но это вариант полностью ручной с массой недостатков. Можно настроить например graphana dashboard, но это излишне сложно для домашнего использования или для какого то pet сервера.
Нужно что то простое и надежное.
Вопрос нетривиален. Статические можно мониторить чем угодно. Хоть monit’ом. Изи заббиксом. Если же хочется Гуй — можно попробовать что-нибудь в духе cockpit. Но если вы начнёте использовать template юниты, то там все сложно будет, потому что нельзя будет заранее сказать — должен был быть он запущен или нет. Но при этом проконтролировать уже созданный проблем нет…
del
Нет. Это плохая практика. Проблема в том, что лучше не придумали. А хомячки не в состоянии либо затащить кубернетес (это сложна!), либо научиться использовать systemd на полную катушку (те же systemd-nspawn) — это же учиться надо.
Если хотите обсудить более подробно — напишите, поговорим. Приведу примеры из личного опыта.
И то, и другое сложно, и тому и другому учиться надо. Проблема в том, что всё чаще такие задачи возлагаются на разработчиков, Или они их сами берут для резюме или просто поиграться. В общем серьёзно, комплексно, на уровне сисадминов, погружаться не хотят. Мы программировать любим, решать бизнес (или свои) задачи путём написания своего программного кода, а не конфигурирования стороннего. Это может быть интересно немного поначалу разобраться в общих чертах, чтоб понимать что снизу, сверху и сбоку от твоего кода, но минимально. Я вот systemd начал использовать когда стал вопрос тащить в контейнеры Докер супервизор и крон, или попробовать использовать вроде бы где-то в фоне развившийся systemd, на который перешли почти все дистры.
systemd перешли все мейнстрим дистры, активно использующиеся в проде. За исключением, может-быть, каких нибудь Rancher, у которых свой путь.Так может и оставить его дистростроителям да мэйнтейнерам пакетов и реп "наивных"?) А от программистов прикладных больше заготовки для Dockerfile и не ждать ничего особо?)
спорный вопрос, для многих преимущество в унификации сред
Унификации между чем и чем? Дев-стейджинг-прод? Разные, но схожие архитектурно (MSA, например) системы для разных проектов?
Дев-стейджинг-прод?
да, хотя бы в параметре deploy.
Разные, но схожие архитектурно (MSA, например) системы для разных проектов?
прошу выражаться более понятно для человеков
да, хотя бы в параметре deploy.
На баше это делаетс десятилетиями :) Любителям декларативного ямла есть Ансибль, например. Да, у него немного другая модель, но оверхеда субъективно меньше
прошу выражаться более понятно для человеков
На потоке однотипные проекты, отличающиеся в основном дизайном и бизнес-логикой.
На баше это делаетс десятилетиями :) Любителям декларативного ямла есть Ансибль, например. Да, у него немного другая модель, но оверхеда субъективно меньше
Один вопрос — что на Ваш взгляд проще — ямл с описанием объекта кубернетес (ну, ок, Хельм чарт) или плейбук на ансибле? Ну, для меня ответ очевиден.
На потоке однотипные проекты, отличающиеся в основном дизайном и бизнес-логикой.
Это не влияет на ответ
Тут смотря что считать сервисом ещё. Вот микросервис с nginx в качестве реверс-прокси перед fastcgi, wsgi апп-сервером и т. п. — это один сервис или два… А ещё с того же образа кронджоб это три?
Он говорит что композ сам умеет рестартовать и следить за процессами докер контейнеров
не умеет. Это делает сам докер, но только если это ему явно указать. Но делает он это плохо )
В докер-композе укзываешь restart: always|failed|... и он передаёт соотвествующую опцию демону докера в аналоге команды docker run
Не аргумент вовсе. Даже если функциональности пересекаются — это разные инструменты для разных задач. И тем более странно их сравнивать или говорить, что в случае «компоуза системди не нужен»
А можно сказать: если в вашем прикладном софте (системный отдельный разговор) systemd используется только для запуска и рестарта сервисов из docker-compose (а это не так тривиально), то может что-то вы делаете не так.
Абсолютно верно ) потому что один компонент в Вашей модели лишний ) и либо нужно идти до конца и деплоиться в куб, либо (если деплоитесь виртуалками) — лишний — докер компоуз )))
А системди одинаково хорошо подходит, что для управления системными сервисами, что прикладными
Вот не понимаю я этого максимализма "раз связались с докер, то нужно идти до конца и деплоиться в куб". Ладно когда стоят задачи масштабирования, отказоустойчивости, абстрагирования от чего угодно и бизнес готов за это платить и за железо, и администратрам (своим, аутсорсу или облака — не суть), и разработчикам (если хоть немного разделяем девопс). Но когда докер вводится в проект исключительно или почти исключительно как продвинутый chroot, то зачем туда всё это?
Ну, положим, лично у меня здесь возникает вопрос не "зачем докер?", а "зачем compose?" Сам докер в связке с systemd — это ещё звучит вполне вменяемо.
docker-compose (вариант docker swarm mode) очень удобны для простого разворачивания а-ля git pull && docker-compose up. systemd же навскидку вижу несколько вариантов:
- полноценный пакет ОС deb/rpm формировать (и хз что делать, если надо одновременно разные версии держать поднятыми)
- километровые readme для ручного бездумного копирования файлов юнитов и ко
- инсталл/апдейт скрипты на баше с разной степенью кастомизируемости от тогоже бездумного копирования, до выборов параметров,, нэймспэйсов и т. п.
- иметь в требованиях наличие рабочей конретной системы управления конфигурации типа ансибля, и роли/плэйбуки в своей репе...
Как-то все варианты простыми не выглядят.
полноценный пакет ОС deb/rpm формировать (и хз что делать, если надо одновременно разные версии держать поднятыми)
так же как и обычно — устанавливать в /opt/software-name-version.
километровые readme для ручного бездумного копирования файлов юнитов и ко
дают неповторяемые окружения (опечатки в инструкциях, человеческий фактор при выполнении инструкций, да и попросту инструкции заточены на какую-то определенную среду, а у клиента/заказчика другие версии ОС и пакетов среды)
инсталл/апдейт скрипты на баше с разной степенью кастомизируемости от тогоже бездумного копирования, до выборов параметров,, нэймспэйсов и т. п.
баш скрипты зачастую не предоставляют опции корректного удаления ПО и не учитывают древовидную структуру зависимостей от системных пакетов. Так что вариант с rpm/deb выглядит для пользователя максимально прямолинейным. Единственное, что в случае rpm/deb за scope вываливается конфигурирование приложения, но баш скрипт только отчасти может в этом помочь....
иметь в требованиях наличие рабочей конретной системы управления конфигурации типа ансибля, и роли/плэйбуки в своей репе...
сложна, правда!
Недостатки этих способов я знаю, но для использования systemd с ними придётся мириться так или иначе. Предпочтительно залить кадрами, деньгами и времени а-ля отдельная если не команда, то специалист, для качества и предсказумости начальной разработки и поддержки. На практике, скорее, маны в зубы и пилить в личное время без "код-ревью" или как там процесс называется.
Докер с композом проще гораздо. ) Пока не хайлоад
Мы так записываем "крон" джобы. Сервисы запускаются через docker-compose c restart always, а джобы через systemd one-shot service с docker-compose run по таймеру. Есть ещё идеи как интегрировать плотнее, но надо экспериментировать
Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0