Я имею в виду, что ещё не разобрался до конца, как это сделать, но зато хорошо знаю, что я хочу. Смысл всей этой возни − запускать и перезапускать бэкенд-вебсервер и периодические задачи, обслуживающие сайт, от лица того же пользователя, который осуществляет деплоймент и тестирование. Это должен быть пользователь с минимальными привилегиями. Это ниша supervisor.
Как я понимаю, мне нужен не /lib/systemd/system/, а ~/.config/systemd/user/, и ещё “systemd --user” плюс нечто, называемое lingering. Именно это заменяет supervisord в его главном назначении: демонизировать пользовательские скрипты, отделяя их от пользовательской сессии.
Спасибо. Это действительно то, что нужно. systemd развивается так быстро, что за всеми фичами не уследишь. :) Я сейчас запускаю uwsgi, paster, celeryd, haystack на своём хостинге (Debian 8) при помощи supervisord. Пожалуй, стоит перенастроить это всё на systemd и сэкономить немного памяти.
Теперь попросим piromanlynx обновить соответствующим образом примеры в этой статье. Иначе заявленная тема не будет раскрыта. :)
Я ничего не имею против systemd, но, чтобы заменить supervisor, он должен обслуживать таски простых пользователей от их имени, не от root и без помощи sudo. Возможно ли такое?
Спутник, если говорить в терминах наземных ethernet-технологий − это пассивный концентратор. Он ничего не понимает в IP, не говоря уже о шифровании. Соответственно, подключившись к спутниковому каналу, можно и слушать всех соседей, и пакеты внедрять, как в старой общажной локалке на коаксиале.
Было такое понятие раньше: «спутниковая рыбалка», если кто ещё помнит. Самое безобидное, что можно со спутниковым трафиком делать.
Решение этой проблемы, если я вас правильно понял − создать собственный deb-репозиторий и добиться того, чтобы проект можно было развернуть только при помощи этого репозитория, без использования иных пакетных менеджеров, кроме apt?
Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в wheel. Он гарантированно развернётся. Правда, обновления безопасности для компонентов я не получу. Но это в любом случае требует разработчика. Просто wheel-репозиторий требует Python-разработчика, а переупаковка всего проекта или библиотек, которых нет в системном репо или которые в нём устарели, в deb-пакеты требует Python-разработчика, умеющего dpkg-buildpackage и прочую чорную магию. Либо выделить отдельную человекоединицу для упаковки пакетов, а этого далеко не всякий бюджет выдержит. Проще обойтись толковым пайтонистом кмк.
Правда, тут ниже мне уже советуют использовать Docker. Я так понимаю, что установив проект со всеми его сюрпризами в контейнер LXC, можно при помощи Docker сохранить снимок этого контейнера и деплоить проект из этого снимка. Я не знаю подводных камней этого процесса, но выглядит всяко проще, чем создавать deb-пакет на каждый чих.
Docker, как я понимаю, оперирует содержимым контейнеров LXC или OpenVZ? Возможно, стоит попробовать. Либо написать свои скрипты для деплоя в контейнеры.
Но беспокоит вопрос использования дискового пространства. Серверные диски желательно экономить.
Насчёт монструозности − там по ссылке автор приводит зачем-то конфигурацию железа, но вообще ничего не пишет про конфигурацию Apache и nginx. Скорее всего, он действительно сравнивает nginx с mpm-prefork, на что ему и попеняли в комментариях.
Вот, на мой взгляд, несколько более корректное сравнение. В нём, по крайней мере, говорится о том, какой модуль использовался. Стабильный mpm-event и nginx идут ноздря в ноздрю.
Ну, я его особо и не рассматриваю в роли фронтенда. Хотя, с другой стороны, чем не фронтенд? Монструозность Apache сильно преувеличена, зато в его конфигурацию намного проще въехать, чем в конфиг того же nginx.
А если к этому добавить ещё и сборку в пакеты всех библиотек, которые есть в PyPy/Registry, но нет в репо целевой ОС (целевых ОС), управление частным репо, управление ключами… Оно действительно вам надо?
Теперь попросим piromanlynx обновить соответствующим образом примеры в этой статье. Иначе заявленная тема не будет раскрыта. :)
Было такое понятие раньше: «спутниковая рыбалка», если кто ещё помнит. Самое безобидное, что можно со спутниковым трафиком делать.
Спасибо за наводку, не знал про эту штуку. Надо будет иметь в виду. Наверное, я изменю своё мнение насчёт сборки OS-targeted пакетов.
Спасибо, но я с тем же успехом упакую проект целиком, со всеми незадокументированными вовремя какашками, в wheel. Он гарантированно развернётся. Правда, обновления безопасности для компонентов я не получу. Но это в любом случае требует разработчика. Просто wheel-репозиторий требует Python-разработчика, а переупаковка всего проекта или библиотек, которых нет в системном репо или которые в нём устарели, в deb-пакеты требует Python-разработчика, умеющего dpkg-buildpackage и прочую чорную магию. Либо выделить отдельную человекоединицу для упаковки пакетов, а этого далеко не всякий бюджет выдержит. Проще обойтись толковым пайтонистом кмк.
Правда, тут ниже мне уже советуют использовать Docker. Я так понимаю, что установив проект со всеми его сюрпризами в контейнер LXC, можно при помощи Docker сохранить снимок этого контейнера и деплоить проект из этого снимка. Я не знаю подводных камней этого процесса, но выглядит всяко проще, чем создавать deb-пакет на каждый чих.
Мне показалось, или действительно пахнет дымом?
Но беспокоит вопрос использования дискового пространства. Серверные диски желательно экономить.
Уже нет. Как сейчас помню:
Хотя я ещё не настолько параноик, чтобы удалять gcc с сервера. Я вообще не помню ни одной массово эксплуатируемой уязвимости с участием gcc.
Вы правы, наверное. Дело привычки.
Насчёт монструозности − там по ссылке автор приводит зачем-то конфигурацию железа, но вообще ничего не пишет про конфигурацию Apache и nginx. Скорее всего, он действительно сравнивает nginx с mpm-prefork, на что ему и попеняли в комментариях.
Вот, на мой взгляд, несколько более корректное сравнение. В нём, по крайней мере, говорится о том, какой модуль использовался. Стабильный mpm-event и nginx идут ноздря в ноздрю.
Фреймворк − чаще всего Django.
божественнее, чем, скажем
А если к этому добавить ещё и сборку в пакеты всех библиотек, которые есть в PyPy/Registry, но нет в репо целевой ОС (целевых ОС), управление частным репо, управление ключами… Оно действительно вам надо?
как-то первый раз слышу. И вообще, часто встречаю virtualenv в продакшне, и мне он там вполне нравится.
Не могли бы вы обосновать этот пункт поподробнее или ссылочкой кинуть?