"демоны" или "юниты", если отвечать более строго, сами являются процессами, которые выполняются в фоновом режиме без прямого взаимодействия с пользователем. Типичные задачи демонов: серверы сетевых протоколов, управление оборудованием, поддержка очередей печати, управление выполнением заданий по расписанию и т. д. В техническом смысле демоном считается процесс, который не имеет управляющего терминала.
В статье я назвал их сервисами, которые отслеживают процессы и поддерживают для облегчения понимания что они делают и зачем нужны в данном случае. По-сути, здесь он является процессом, который запускает скрипт start_gunicorn.sh и start_celery.sh.
Более подробно о демонах можно почитать здесь и здесь
При развертывании проектов - хорошо настроенный Docker. Для всего остального на сервере - systemd, bash и cron.
Хотя тут можно поспекулировать на тему что такое "более серьёзная автоматизация", Вы можете раскрыть тему и рассказать, что думаете, хотя мне кажется, что это будет не в тематику данного поста.
Большое спасибо за Ваш полезный комментарий. Я, в целом, и не претендую на истину в первой инстанции мира автоматизации на баш, и написал статью, которую было бы самому полезно прочитать на тех этапах, когда я только начинал такой автоматизацией заниматься.
Полезны и нтересны Ваши замечания про " ","|" в названиях переменных, о чём я не подумал, а также всё про pipefail, а про безопасный запуск команд при падении я отвечу:
По сути, ничего ужасного с системой этот скрипт не делает, и если где-то он упадёт, то дальнейшие команды, например, включение юнита, если его запись упала (допустим, из-за отсутствий прав sudo), то systemctl сам отпишется об ошибке, которую будет видно в консоли, и это можно будет в дальнейшем отработать. Да и сам я намеренно запускал скрипт с ошибками, чтобы убедиться в его "безопасности", если использовать его по прямому назначению без модификаций :)
Вообще, данный скрипт я предоставил для ознакомления и доработки, ведь он не предназначен для непосредственного использования вне определенных условностей архитектуры построения проекта, которую навязывает Django, например, и подход к настройке gunicorn из примера упомянутого в статье "Диджитализируй"
"демоны" или "юниты", если отвечать более строго, сами являются процессами, которые выполняются в фоновом режиме без прямого взаимодействия с пользователем. Типичные задачи демонов: серверы сетевых протоколов, управление оборудованием, поддержка очередей печати, управление выполнением заданий по расписанию и т. д. В техническом смысле демоном считается процесс, который не имеет управляющего терминала.
В статье я назвал их сервисами, которые отслеживают процессы и поддерживают для облегчения понимания что они делают и зачем нужны в данном случае. По-сути, здесь он является процессом, который запускает скрипт start_gunicorn.sh и start_celery.sh.
Более подробно о демонах можно почитать здесь и здесь
При развертывании проектов - хорошо настроенный Docker. Для всего остального на сервере - systemd, bash и cron.
Хотя тут можно поспекулировать на тему что такое "более серьёзная автоматизация", Вы можете раскрыть тему и рассказать, что думаете, хотя мне кажется, что это будет не в тематику данного поста.
Большое спасибо за Ваш полезный комментарий. Я, в целом, и не претендую на истину в первой инстанции мира автоматизации на баш, и написал статью, которую было бы самому полезно прочитать на тех этапах, когда я только начинал такой автоматизацией заниматься.
Полезны и нтересны Ваши замечания про " ","|" в названиях переменных, о чём я не подумал, а также всё про pipefail, а про безопасный запуск команд при падении я отвечу:
По сути, ничего ужасного с системой этот скрипт не делает, и если где-то он упадёт, то дальнейшие команды, например, включение юнита, если его запись упала (допустим, из-за отсутствий прав sudo), то systemctl сам отпишется об ошибке, которую будет видно в консоли, и это можно будет в дальнейшем отработать. Да и сам я намеренно запускал скрипт с ошибками, чтобы убедиться в его "безопасности", если использовать его по прямому назначению без модификаций :)
Вообще, данный скрипт я предоставил для ознакомления и доработки, ведь он не предназначен для непосредственного использования вне определенных условностей архитектуры построения проекта, которую навязывает Django, например, и подход к настройке gunicorn из примера упомянутого в статье "Диджитализируй"