Ваша проблема в том, что вы вызываете оба процесса в одном и том же контексте / строке, и один из них никогда не вызывается, потому что первый никогда не "заканчивается".
этот процесс: 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 &
Научить человека сообщать sh информацию об этом типе проблема в здесь
Я вполне уверен, что вы потеряете обычное ведение журнала консоли, которое вы обычно имели бы, запустив их в фоновом режиме, поэтому я бы посоветовал вместо этого посмотреть nohup & или отправка журналов куда-нибудь с помощью утилиты ведения журналов, чтобы вы не летали вслепую.
Что касается других вариантов, если вы планируете масштабировать до большого числа пользователей, вероятно, 100+, я бы просто запустить два сервера, один для ш sgi django http запросы и один для asgi daphne ws запросов. Имейте nginx прокси между двумя для того, что вам нужно, и все готово. Это также то, что каналы рекомендуют для более крупных приложений.
Рекомендуется использовать префикс общего пути, например / ws /, чтобы отличать guish соединения WebSocket от обычных HTTP-соединения, потому что это упростит развертывание каналов в производственной среде в определенных конфигурациях.
В частности, для больших сайтов можно будет настроить HTTP-сервер промышленного уровня, например nginx, для маршрутизации запросов на основе пути либо (1) сервер WSGI промышленного уровня, например Gunicorn + Django для обычных HTTP-запросов, либо (2) сервер ASGI промышленного уровня, например Daphne + Channels для запросов WebSocket.
Обратите внимание, что для небольших сайтов вы можно использовать более простую стратегию развертывания, где Daphne обслуживает все запросы - HTTP и WebSocket - вместо того, чтобы иметь отдельный сервер WSGI. В этой конфигурации развертывания не требуется префикс общего пути, такой как / ws /.