Запуск программы как службы или напрямую, в чем разница
Наряду с отсутствием технической причины не предоставлять доступ к cron пользователям, на мой взгляд, это излишество. Я обычно резервирую cron для учетных записей root и администратора службы приложений. Если, скажем, разработчик хочет запустить что-то в полночь, я даю им доступ в . Я действительно не хочу, чтобы чрезмерно усердный программист запускал запрос к репозиторию программного обеспечения каждую ночь, чтобы узнать, есть ли новый выпуск, при этом блокируя сетевые соединения и запуская awk / sed / grep / perl для огромных файлов, в результате чего система падает до его колени, мешающие законным работам cron, а иногда и сбой из-за нехватки ресурсов.
Я не хочу звучать как BOFH , но если вы позволите пользователям разгуляться в системе, вы действительно не поймете, во что ввязываетесь. Многие из них похожи на детей, и их нужно контролировать. Если ваши пользователи - старые системные администраторы, выполняющие какие-то другие функции, я бы не возражал дать им немного больше свободы, но разработчику я бы не стал. Я видел, как некоторые из этих людей развиваются . Я не хочу заниматься уборкой дома после того, как они закончат работу с системой, с которой мне придется иметь дело.
Вы не можете использовать systemctl Если ваш PID 1 не является systemd. Вы можете найти свой PID 1 с помощью ps -q 1.
Возможность запускать и останавливать службы обычным способом — одно из преимуществ, упомянутых в этой статье о запуске systemd в непривилегированном контейнере. Другие регистрируют или отслеживают дочерние процессы, как описано в ответе Андрея.
Системный сервис запустит процесс аналогично запуску его напрямую, однако он будет отслеживать все разветвленные процессы и потоки. Это означает, что когда вы systemctl stop apache, он завершит работу всех дочерних процессов.Кроме того, использование системных процессов приятно, потому что они будут работать в фоновом режиме и могут быть запущены при запуске системы.
Учитывая ваше место на кривой обучения, я бы не стал использовать Docker для вашей задачи.
Если вы используете Docker для изоляции процессов, вы можете использовать для этого уникальных пользователей Unix, или systemd также включает директивы для ограничения того, к чему может получить доступ служба systemd. Смотрите, например, Capabilities= в man systemd.exec.
Кроме того, для изоляции процессов в Docker вы запустите каждый из серверов базы данных и веб-сервера в разных контейнерах Docker.
Еще одна важная возможность, которую предоставляет systemd - управление процессами. То есть, если ваш httpd процесс аварийно завершается, systemd перезапустит его за вас.
Я рекомендую сначала запустить все ваши процессы непосредственно на хост-сервере с помощью systemd. Многие современные пакеты поставляются с systemd конфигурационными файлами.
Как только вы хорошо поймете systemd и поймете, какие преимущества даст добавление Docker, тогда рассмотрите возможность использования Docker.
На моей работе мы пробовали использовать Docker для управления набором сервисов, но позже перешли на управление непосредственно с помощью systemd, и в результате получилась более чистая система, которую предпочитает команда, с меньшим количеством bash скриптов для склеивания вещей вместе и их поддержки.