[Django] 장고 앱 공개 운영

이 포스트는 간단한 장고 앱을 공개 운영하는 방법에 대해 다룬다.

운영 대상은 필자가 개발한 장고 앱으로 지인의 부탁으로 잘 모르지만 재능 기부(?) 로 개발을 하게 되었다.

필자는 DL/ML 엔지니어로 장고와 서버 운영의 전문가는 아니므로 본 포스팅은 불완전한 내용을 포함할 수 있다.

내용이 틀리거나 보완필요 한 부분이 있다면 댓글로 알려주면 좋을거 같다.

참고한 자료는 본 포스트의 끝에 있다.. 점프 투 장고 가 큰 틀에서 이 장고 앱 공개 과정을 이해하는데 가장 도움이 많이 되었다. 관심있는 분들은 읽어 보면 큰 도움이 될거 같다.

 

 

운영 계획은 아래와 같다.

필자의 컴퓨터에 django 앱과 DB(mysql)서버를 docker container 로 인스턴스화 해 운영하고

웹서버로 nginx, wsgi 서버로 gunicorn을 사용할 계획이다.

 

운영 환경

os: ubuntu 20.04

docker version: 20.10.18

Docker Compose version: v2.10.2

nginx: 1.18.0

gunicorn: gunicorn-20.1.0

 

아래 그림은 운영 환경 다이어그램이다. 이 포스트에서는 아래 다이어그램 처럼 운영 되도록 nginx 와 wgsi서버를 설정 하는 것을 정리한다.

Fig 1. 운영 환경 다이어그램

 

WSGI 서버

WSGI 서버는 여러 종류가 있다고 하지만 편의상 gunicorn 을 사용 하기로 했다.

WSGI 서버의 역할을 Fig 1. 에서 보는 것처럼 동적 페이지 요청이 웹서버로 들어왔을 경우 웹서버의 호출에 응답해 장고 어플리케션을 호출하고 동적 페이지를 전달 받아 웹서버로 해당 응답을 전달한다.

웹서버가 장고 어플리케이션을 바로 호출하지 않고 WSGI 서버를 통해 처리 하는 이유는 웹서버는 python 어플리케이션인 장고 앱을 어떻게 호출하는지 모르기 때문이다.

 

장고 앱을 생성하면 기본적으로 장고 프로젝트의 config/wsgi.py라는 파일이 생성된다.

기본 내용은 아래와 같고 맨 아래 줄의 application 이 이 포스트에서 공개 운영하고자 하는 장고 앱이다.

 

참고: 개발과 운영시 setting을 분리해 사용 한다면 아래 os.environ.setdefault()의 두번째 인자로

운영을 위한 setting파일 경로를 넘겨 주거나 운영 환경에서 'DJANGO_SETTINGS_MODULE' 환경 변수를 따로 등록 해 사용해야 한다.

"""
WSGI config for config project.
It exposes the WSGI callable as a module-level variable named ``application``.
For more information on this file, see
https://docs.djangoproject.com/en/4.1/howto/deployment/wsgi/
"""

import os
from django.core.wsgi import get_wsgi_application

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings')
application = get_wsgi_application() #<<<<----- 이 애플리케이션이 공개 운영하고자 하는 장고 앱이다

 

gunicorn

설치:

 pip install gunicorn

테스트:

운영하고자 하는 장고 앱 프로젝트 위치로 이동해 아래 명령을 입력한다.

필자의 경우 장고 앱 위치를 /home/pajama/jnbdrive 로 가정한다.

cd /home/pajama/jnbdrive
gunicorn --bind 0:7878 config.wsgi:application

--bind 0:7878 옵션은 7878포트로 들어 오는 요청을 처리 대상으로 하겠다는 것이고 config.wsgi:application 은 요청을 장고 앱이 confing.wsgi 파일에 정의된 application 이라는 의미이다.

실행하면 아래와 같은 내용이 terminal에 뜬다.

Fig 2. gunicorn 실행 정보

실행 정보를 보면 'Listening at: http://0.0.0.0:787' 이라는 내용으로 7878 포트로 들어오는 요청을 듣고 있다는 것을 확인 할 수 있다.

 

실행 후 운영하려는 대상 웹페이지에 접속하면 개발했던 것과 다르게 아래 와 같은 화면이 뜬다. 배경 같은 디자인적 요소가 적용이 하나도 안된 페이지 인데 이유는 gunicorn 이 정적 파일을 처리하지 못했기 때문이다. 내 운영 환경에서 gunicorn 은 동적 페이지 요청에 대해서만 담당하므로 이렇게 뜨는게 정상이다.  정적 파일과 관련된 것은 nginx 설정에서 다룬다.

Fig 3. 구니콘으로 실행한 운영 페이지

참고: 위의 예제 처럼 --bind 0:7878 로 포트를 설정해서 gunicorn 을 운영 할 수 있지만 포트를 이용하는 것은 느려서 비효율 적이라고한다.(점프 투 장고에서 봤다.) 유닉스 계열에서는 유닉스 소켓을 이용해 하는 것이 더 빠른 성능을 기대 할수 있다고 한다.

유닉스 소켓을 사용 하기 위해서는 아래와 같이 gunicorn 실행 명령을 바꾸면 된다.

gunicorn --bind unix:/tmp/gunicorn.sock config.wsgi:application

실행 정보를 보면 아래와 같이 'Listening at' 정보가 명령에서 지정한 유닉스 소켓으로 바뀐 것을 볼 수 있다.

Fig 4. 유닉스 소켓을 사용한 gunicorn 실행 정보

gunicorn 도 설정 할 수 있는 옵션이 꽤 많다.

예를 들어 --workers  옵션은 'request를 처리하는 worker 프로세스의 수를 의미 한다.' 이 값이 1 이면 1나의 프로세스가 모든 request 를 처리하게 되므로 사용자 입장에서 요청에 대한 응답이 느리게 느껴 질 수 있다.

이 외에도 성능 튜닝을 할 수 있는 옵션들이 꽤 있다. 참고자료 4, 5 를 보고 파악해 보길 바란다.

 

웹서버

웹서버란 client 가 요청 하는 html 문서나 각종 리소스를 전달 하는 서버를 말한다.

기본적으로

1. 정적 파일(*.js, *.css 등 의 파일) 요청을 처리(/static 으로 시작 하는 resource에 대한 요청을 전담 처리)

->WSGI 서버 설명에서 gunicorn 으로 실행 한 장고 앱 페이지(Fig 3.) 가 정적 파일 로딩 문제로 개발 당시와 다르게 로딩 되었던 것을 기억 해보자. 이때 문제가 되었던 이 정적 파일들에 대한 처리를 웹서버(nginx)가 처리 하도록 할 것이다.

2. 리버스 프록시로서의 역할

리버스 프록시란

클라이언트 요청을 대신 받아 내부 서버로  전달하는 것 '즉 클라이언트가 내부 서버와 직접 소통하는 것을 중간에 hooking 하는 것이라고 보면 될거 같다. '

 

이런 역할을 하는 웹서버는 대표적으로 apache, IIS, GWS, nginx 등이 있다고 하는데 나는 nginx 를 사용하기로 했다.

사유는 가볍고 빠르고 설정이 비교적 간단하다고 해서 선택했다.

(필자가 자의적으로 고른건 아니고 서버 개발자인 지인의 추천으로 이걸 선택하게 되었다.)

 

아래는 필자의 nginx 설정 파일로 /etc/nginx/sites-available/jnbdrive 에 위치 해있다.

server {
        listen 80;
        server_name 192.168.0.102; ##client 가 접속하는 도메인네임, 장고 app 이의 서버 주소

        location = /favicon.ico { access_log off; log_not_found off; }

        location /static {
                alias /code/item_log/static;
        }

        location / {
                include proxy_params;
                proxy_pass http://unix:/tmp/gunicorn.sock;
        }
}

server 모듈은 server_name(192.168.0.102)와 일치하는 Host HTTP 헤더 갖는 모든 요청에 적용 할 설정을 정의 한다.

server 모듈은 한개 이상의 location 블록을 포함한다.

location 모듈은 요청 URI가 지정 경로와 일치할 경우에만 설정이 적용 된다.

예를 들면 location /static 은 URI 가 /static 으로 시작하는 요청은 nginx 가 /code/item_log/static 에 있는 파일을 읽어서 처리한다는 설정이다.

location / 은 /static 으로 시작 하는 URI를 제외한 모든 URI 요청을 /tmp/gunicorn.sock 으로 보낸다는 설정으로 gunicorn 이 처리 하도록 한다는 것이다.

이유는 위 WSGI 서버에서 설명에서  gunicorn 이 /tmp/gunicorn.sock 으로 들어오는 요청을 처리 하게 했기 때문이다.

 

이렇게 설정 하고 아래 명령으로 위파일에 대한 심볼릭 링크를 /etc/nginx/sites-enabled 아래에 jnbdrive 라는 이름으로 만들어 준다. (각자 심볼릭 링크의 source 와 link 이름은 자신의 상황에 맞게 바꾸면 된다)

# ln -s {source} {linke_name}
ln -s /etc/nginx/sites-available/jnbdrive /etc/nginx/sites-enabled/jnbdrive

 

위 심볼릭 싱크를 만들어 주면 nginx의 기본 환경 설정 파일인 /etc/nginx/nginx.conf  이 위 심볼릭 링크 설정 파일에 정의된 서버 설정을 기반으로 동작 해 192.168.0.102 로 들어오는 요청을 /etc/nginx/sites-available/jnbdrive 의 server 모듈에서 정의한 대로 처리 해 준다.

 

참고: 성능 최적화를 위해서는 /etc/nginx/nginx.conf 파일 설정도 변경 필요한 경우가 있으므로 위 파일의 내용도 공부해봐야 한다.

 

정의한 /etc/nginx/sites-available/jnbdrive  내용을 nginx 에 적용하기 위해서는 아래 명령을 터미널에 입력한다.

systemctl restart nginx

nginx 파일에서 오류가 발생하면 다음과 같이 nginx -t 를 입력해 확인할 수 있다.

Fig 5 nginx -t 결과

 

 

issue 1.nginx 실행 시 '40: Too many levels of symbolic links' 에러가 발생한 경우는 심볼링 링크를 만들때 source나 link_name에 절대 경로가 아닌 상대 경로를 사용한 경우로 심볼릭 링크를 제거 하고 다시 만들면 된다.

 

 

- 끝 -

 

 

참고 자료:

1. 점프 투 장고(https://wikidocs.net/72283)

2. nginx 기본 환경 설정 (https://12bme.tistory.com/366)

3.구매한 도메인을 Nginx 서버에 연동 / 등록하기(https://jizard.tistory.com/163)

4. gunicorn 설정에 관한 설명-한글(http://blog.hwahae.co.kr/all/tech/tech-tech/5567/)

5. gunicorn documents(https://docs.gunicorn.org/en/latest/settings.html#workers)