LearnRun
Synology DSM 7, Docker + Django + Gunicorn + Nginx 본문
◈ Contents
이전 과정처럼 Django와 DB만 연결해도, 일단 사용할 수 있는 페이지 구현이 가능합니다.
외부 접속을 닫는 등.. 부하를 주지 않는 작업에 단순한 툴로써 내부망에서 사용하면 적당히 쓸 수는 있습니다.
하지만, 그래서는 단순히 일개 프로그램을 웹으로 옮겨놓은 것 밖에 안됩니다.
하나의 요청을 처리하는 와중 페이지가 뻗거나, 동시다발적인 처리가 필요함에도 이를 순차적으로 처리하는 등
웹으로써의 장점을 전혀 살리지 못합니다.
그러니, Django 내의 Runserver는 웹 프레임워크로써 제공하는 단순 테스트용 기능에 가깝다고 보시면 됩니다.
성능과 보안 이슈 등 본 방식을 사용할 이유는 다양하지만
자세한 내용은 다른 포스팅으로 남기기로 하고, 본 포스팅에서는 세팅방식을 우선하여 다루겠습니다.
django 컨테이너
패키지 설치
pip install gunicorn- django container 터미널로 접속하여 명령어를 입력합니다.
bashrc 명령어 수정
cd /root
vim .bashrc- 해당 명령어 입력하여 vim 에디터를 실행, bashrc 파일을 수정합니다.
- i를 누르고 수정 모드로 진입하여, 파일 최하단을 수정합니다.
변경 사항은 다음과 같습니다.
- rm -rf collect_static
# 신규 : 이전에 만들었던, collect_static 폴더를 확인절차 없이 삭제합니다. - python manage.py runserver 0:8080
# 삭제 : gunicorn을 통해 서버를 가동해야 하므로, 해당 줄은 지우거나 주석처리합니다. - python manage.py collectstatic
# 신규 : nginx에 전달하기 위해 정적 파일을 모아주는 해당 명령어를 실행합니다. - gunicorn project_test.wsgi --bind 0.0.0.0:8080 --reload
# <프로젝트명>.wsgi를 통해 gunicorn을 실행합니다.
# --bind 인자로 접속채널을 설정하고, --reload 인자로 코드 수정 시 프로젝트를 자동 재시작 하게 만들었습니다.
프로젝트 파일 수정
- settings.py 항목을 다음과 같이 수정합니다.
- BASE_DIR을 통해, 프로젝트 최상위 폴더로 기본 경로를 변경했습니다.
- STATIC_DIR 변수에 로컬 작업용 STATIC 폴더의 경로를 지정했습니다. (PATH: /django_test/project_test/__static)
- STATIC_ROOT 변수에 상기 터미널에서 지정한 collectstatic 명령어로 모이게 될 정적 파일 폴더의 경로를 지정했습니다.
- STATICFILES_DIRS에서는 templete에서 데이터를 불러 올 때 호출할 별칭을 등록합니다.
NGINX
컨테이너 생성
- 레지스트리 탭에서 nginx를 찾아 설치합니다.
- nginx 공식 페이지를 참조하여, stable 버전 중 가장 최신 버전인 1.22.1 버전을 설치했습니다.
- 이후 이미지 탭에 nginx 항목이 생겼다면, 더블클릭하여 컨테이너를 생성하기 위한 설정 창에 진입합니다.
- 네트워크는 이전의 django_test 컨테이너와 같은 그룹에 넣어주시면 됩니다.
- 상기 이미지와 같이, 높은 권한/자동재시작은 필히 체크합니다.
- 고급 설정에서는, 링크 탭에서 django_test와 연결해줍니다.
- docker에서 depends_on 설정하는 것과 맥락이 같습니다.
- 이후, 포트 설정 탭에서는 nginx로 접속할 포트를 임의로 60000으로 정하겠습니다.
- 저는 볼륨설정을 다음과 같이 진행했습니다.
- collect_static 폴더를 nginx의 static 폴더와 연결하여 모아둔 정적 파일을 nginx에서 확인할 수 있게 했습니다.
- django_test라는 메인 폴더 내에 nginx 파일을 링크하여, 설정값을 오버라이딩 할 수 있게 하였습니다.
(본 과정은 폴더 생성 작업이 필요할 수 있습니다.)
설정파일 생성
- docker nginx 공식 문서를 확인하면, '/etc/nginx/conf.d/default.conf' 파일이 자주 언급됩니다.
- 해당 파일의 내용을 확인하면, "include /etc/nginx/conf.d/*.conf"라는 구문이 보입니다.
- 즉슨, 해당 경로 안의 모든 .conf 파일을 설정에 포함한다는 의미이므로, 설정 파일명은 큰 신경을 쓸 필요가 없겠습니다.
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://django_test:8080;
# Do not change this
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /static/ {
alias /static/;
}
}- 저는 매핑해둔 docker/django_test/nginx 폴더 내에 위와 같이 conf 파일을 생성했습니다.
- nginx의 64000 외부포트를 내부 80포트로 이어지게 설정했으니, listen 80으로 80포트를 확인하게 합니다.
- django_test 컨테이너는 내부 네트워크 브리지로 연결했으므로, 그냥 내부포트 8080을 그대로 지정해 연결합니다.
- proxy_pass http://<컨테이너 별명>:8080; 구문을 통해, django_test 컨테이너의 8080포트로 연결하게 하였습니다.
- /static/ 폴더 그대로 매핑하였으므로, static 항목을 동일하게 설정하였습니다.
마치며
이후, 동일 url에 포트만 64000으로 바꾸면 성공적으로 접속이 됩니다.
nginx를 사용하면, 아쉽게도 프로젝트의 수정사항의 반영이 그때그때 이뤄지지 않습니다.
gunicorn도 실험적으로 reload를 사용해봤는데, 결국 gunicorn 단일로 사용할 때 의미가 있었습니다.
심지어 이때 설정을 변경하면 nginx 설정도 무용지물이 되는 경우가 많아 그냥 뒀습니다.
저는 django runserver용 컨테이너를 하나 더 만들어 개발용 컨테이너로써 따로 돌리는 방법을 씁니다.
이후, 굵직한 업데이트를 끝낼 때, nginx 컨테이너를 가동하고, 테스트하는 방식으로 운영합니다.
