Ваша проблема в том, что вы вызываете оба процесса в одном контексте/строке, и один никогда не вызывается, потому что первый никогда не заканчивается.
этот процесс: gunicorn app.wsgi:application --bind 0.0.0.0:8000 --reload
не завершится в любой момент, поэтому команда && никогда не будет запущена, если вы не убьете эту команду вручную, и в этот момент я не уверен, что это не убьет всю цепочку процессов полностью.
если вы хотите запустить оба, вы можете фонировать оба процесса с &, например.
(не могу проверить, но это должно работать)
gunicorn app.wsgi:application --bind 0.0.0.0:8000 --reload & daphne -b 0.0.0.0 -p 8089 app.asgi:application &
Научить человека вылавливать информацию по этому типу проблем можно следующим образом: a-single-line">здесь
Я совершенно уверен, что вы потеряете нормальное ведение журнала консоли, которое вы обычно имели бы, запустив их в фоновом режиме, поэтому я бы посоветовал изучить nohup вместо & или отправить журналы куда-нибудь с помощью утилиты ведения журнала, чтобы вы не летали слепой.
Что касается других вариантов, если вы планируете масштабироваться до большого количества пользователей, возможно, более 100, я бы просто запустил два сервера: один для http-запросов wsgi django и один для запросов asgi daphne ws. Имейте прокси-сервер nginx между ними для всего, что вам нужно, и все готово. Это также то, что каналы рекомендуют для больших приложений.
Рекомендуется использовать общий префикс пути, такой как /ws/, чтобы отличать соединения WebSocket от обычных соединений HTTP, поскольку это упростит развертывание каналов в производственной среде в определенных конфигурациях.
В частности, для больших сайтов можно будет настроить HTTP-сервер производственного уровня, такой как nginx, для маршрутизации запросов на основе пути либо к (1) производственному серверу WSGI, такому как Gunicorn+Django, для обычных HTTP-запросов, либо (2) производственному ASGI-сервер высокого класса, такой как Daphne+Channels для запросов WebSocket.
Обратите внимание, что для небольших сайтов вы можете использовать более простую стратегию развертывания, при которой Daphne обслуживает все запросы — HTTP и WebSocket — вместо отдельного сервера WSGI. В этой конфигурации развертывания не требуется общий префикс пути, такой как /ws/.
person
aericks1337
schedule
01.05.2020
