Deploying

Channels 2 (ASGI) applications deploy similarly to WSGI applications - you load them into a server, like Daphne, and you can scale the number of server processes up and down.

WSGI 와 유사하게 배포한다. Daphne라는 것을 사용한다.

$ WSGI - 파이썬 스크립트(웹 어플리케이션'django')가 서버와 통신하기 위한 인터페이스

$ Daphne -

The one optional extra requirement for a Channels project is to provision a channel layer. Both steps are covered below.

channels 프로젝트를 구현하기 위해서 추가적인 요구사항은 Channel layer를 제공해줘야 한다.

Configuring the ASGI application

The one setting that Channels needs to run is ASGI_APPLICATION, which tells Channels what the root application of your project is. As discussed in Routing, this is almost certainly going to be your top-level (Protocol Type) router.

It should be a dotted path to the instance of the router; this is generally going to be in a file like

myproject/routing.py:

ASGI_APPLICATION = "myproject.routing.application"

Channel는 ASGI_APPLICATION 를 설정해줘야 한다.
(나는 app-config-settings.py에 선언해줌)

django-channel

app(base or root?)

config-settings.py (ASGI_APPLICATION 변수 선언)
chat
members
templates
static
manage.py

Setting up a channel backend

Note!!
This step is optional. If you aren’t using the channel layer, skip this section.

Typically a channel backend will connect to one or more central servers that serve as the communication layer - for example, the Redis backend connects to a Redis server. All this goes into the CHANNEL_LAYERS setting; here’s an example for a remote Redis server:

CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {
            "hosts": [("redis-server-name", 6379)],
        },
    },
}    

settings.py에 선언 (나는 app-config-settings.py에 선언해줌)

pip install -U channels_redis 설치 해주기

Run protocol servers

In order to talk to the outside world, your Channels/ASGI application needs to be loaded into a protocol server. These can be like WSGI servers and run your application in a HTTP mode, but they can also bridge to any number of other protocols (chat protocols, IoT protocols, even radio networks).

channels/ASGI 에플리케이션은 프로토콜 서버에 로드 되어져야 하는데
http 모드에서는 WSGI 서버처럼 존재하고 실행시킬 수 있지만 다른 프로토콜과도 연결 될 수 있다.

All these servers have their own configuration options, but they all have one thing in common - they will want you to pass them an ASGI application to run. Because Django needs to run setup for things like models when it loads in, you can’t just pass in the same variable as you configured in ASGI_APPLICATION above; you need a bit more code to get Django ready.

In your project directory, you’ll already have a file called wsgi.py that does this to present Django as a WSGI application. Make a new file alongside it called asgi.py and put this in it:

config - asgi.py 파일 생성해서 만들기

"""
ASGI entrypoint. Configures Django and then runs the application
defined in the ASGI_APPLICATION setting.
"""

import os
import django
from channels.routing import get_default_application

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
django.setup()
application = get_default_application()

If you have any customizations in your wsgi.py to do additional things on application start, or different ways of loading settings, you can do those in here as well.

Now you have this file, all you need to do is pass the application object inside it to your protocol server as the application it should run:

daphne -p 8001 myproject.asgi:application

서버로 asgi 응용 프로그램을 전달하기만하면 됩니다.

HTTP and WebSocket

While ASGI is a general protocol and we can’t cover all possible servers here, it’s very likely you will want to deploy a Channels project to work over HTTP and potentially WebSocket, so we’ll cover that in some more detail.

모든 서버를 다룰 수 없지만, HTTP 및 WebSocket을 통해 작동하도록 채널 프로젝트를 배포 할 예정이다

The Channels project maintains an official ASGI HTTP/WebSocket server, Daphne, and it’s this that we’ll talk about configuring. Other HTTP/WebSocket ASGI servers are possible and will work just as well provided they follow the spec, but will have different configuration.

Channels 프로젝트는 ASGI HTTP / WebSocket 서버인 Daphne를 이용하여 유지보수 된다. 다른 HTTP/WebSocket ASGI servers도 가능하지만 여기서 다 다루지 않을 것이다.

You can choose to either use Daphne for all requests - HTTP and WebSocket - or if you are conservative about stability, keep running standard HTTP requests through a WSGI server and use Daphne only for things WSGI cannot do, like HTTP long-polling and WebSockets. If you do split, you’ll need to put something in front of Daphne and your WSGI server to work out what requests to send to each (using HTTP path or domain) - that’s not covered here, just know you can do it.

Daphne 와 WSGI 서버 앞에 무엇인가(routing?)를 통해 각각 동기 비동기 요청을 처리해야 합니다.(여기서 전부 다루지 않을 것입니다)

If you use Daphne for all traffic, it auto-negotiates between HTTP and WebSocket, so there’s no need to have your WebSockets on a separate domain or path (and they’ll be able to share cookies with your normal view code, which isn’t possible if you separate by domain rather than path).

Daphne를 사용하면 HTTP와 WebSocket간에 자동적으로 처리 되므로
경로에 WebSocket을 둘 필요가 없습니다.(도메인 별로 분리하지말고 경로로 분리해라)

To run Daphne, it just needs to be supplied with an application, much like a WSGI server would need to be. Make sure you have an asgi.py file as outlined above.

Then, you can run Daphne and supply the ASGI application as the argument: