Комментарии 10
ansible?
Приведённая автоматизация несколько похожа на форменное вредитльство в мире автоматизации. Идея хороша, а исполлнение плохое.
В частности - давайте представим, что какая-нибудь команда из последовательности завершилась с ошибкой. Следующие команды можно безопасно запускать? А ведь они будут запущены.
Или кто-то опечатался в имени переменной и вместо переменной молча подставилась пустая строка. Это - ожидаемое поведение? И надо запускать такую команду?
Или давайте представим, что кто-то подставил пробел или символ | в PROJECTNAME или PROJECTFOLDER в ваших скриптах всё правильно отработает?
Или кто-то использовал bash pipes не зная, что при падении первой команды, вы об этом не узнаете. Смотри про опцию pipefail.
Баш - классный язык, но он не полный и, на мой взгляд, не вполне переносимый между платформами. Если пишешь разовый скриптик под кокретную задачу и ошибки отсмотришь глазами - да. Так можно.
А вот в фоновые процессы Баш стоит писать только прочитав внимательно Bash pitfalls https://mywiki.wooledge.org/BashPitfalls и дописывая всегда в начале файла set -euo pipefail и кавычки к подстановкам переменных
Большое спасибо за Ваш полезный комментарий. Я, в целом, и не претендую на истину в первой инстанции мира автоматизации на баш, и написал статью, которую было бы самому полезно прочитать на тех этапах, когда я только начинал такой автоматизацией заниматься.
Полезны и нтересны Ваши замечания про " ","|" в названиях переменных, о чём я не подумал, а также всё про pipefail, а про безопасный запуск команд при падении я отвечу:
По сути, ничего ужасного с системой этот скрипт не делает, и если где-то он упадёт, то дальнейшие команды, например, включение юнита, если его запись упала (допустим, из-за отсутствий прав sudo), то systemctl сам отпишется об ошибке, которую будет видно в консоли, и это можно будет в дальнейшем отработать. Да и сам я намеренно запускал скрипт с ошибками, чтобы убедиться в его "безопасности", если использовать его по прямому назначению без модификаций :)
Вообще, данный скрипт я предоставил для ознакомления и доработки, ведь он не предназначен для непосредственного использования вне определенных условностей архитектуры построения проекта, которую навязывает Django, например, и подход к настройке gunicorn из примера упомянутого в статье "Диджитализируй"
что вы предпочитаете для более серьезной автоматизации?
При развертывании проектов - хорошо настроенный Docker. Для всего остального на сервере - systemd, bash и cron.
Хотя тут можно поспекулировать на тему что такое "более серьёзная автоматизация", Вы можете раскрыть тему и рассказать, что думаете, хотя мне кажется, что это будет не в тематику данного поста.
Есть тема для размышления - если автоматизация с помощью bash, какое здесь будет взаимодействие синхронное или асинхронное. Я считаю, что автоматизация с помощью bash сильнее, структурнее будет, нежели запуск unit-тестов в java или python.
А вы прямо вот уверены, что "демоны - это специальные системные сервисы, которые следят за состоянием сторонних процессов и поддерживают их работоспособность"? А то я из тех, кто не в курсе, и хотел бы больше ясности.
"демоны" или "юниты", если отвечать более строго, сами являются процессами, которые выполняются в фоновом режиме без прямого взаимодействия с пользователем. Типичные задачи демонов: серверы сетевых протоколов, управление оборудованием, поддержка очередей печати, управление выполнением заданий по расписанию и т. д. В техническом смысле демоном считается процесс, который не имеет управляющего терминала.
В статье я назвал их сервисами, которые отслеживают процессы и поддерживают для облегчения понимания что они делают и зачем нужны в данном случае. По-сути, здесь он является процессом, который запускает скрипт start_gunicorn.sh и start_celery.sh.
Простая автоматизация с Bash для новичков