이렇게 설정하면 80번 포트로 들어오는 요청이 8000 번으로 redirect되기는 하지만 AWS ec2 인스턴스의 보안 정책에서 8000 번포트를 오픈해야만 app_server 가 요청을 정상적으로 받을 수 있었다.
즉 아래 Fig 1의 붉은 선 처럼 nginx 가 요청을 외부에서 들어오는 8000번으로의 요청 처럼 리다이렉트 하는 것으로 보인다.
Fig 1. nginx 동작
이렇게 하면 ec2 인스턴스의 8000번 포트를 오픈해야 해서 불필요하게 보안 위험이 증가하고 nginx 가 app server 로 들어가는 모든 요청을 관리하게 하는 계획과는 많이 달라진다.
목표 아키텍쳐
원래의 내 계획은 app server 로의 요청은 반드시 80 번 포트로 들어와 nginx를 거쳐 app server 로 가게 하는 것이었다. 이를 위해 docker network를 이용해 nginx continer 와 app container 사이의 일종의 private network 를 구성했다. 전체 아키텍쳐는 아래 Fig 2 와 같다. Fig 1과 비교해 보면 redirect to port 8000 을 의미 하는 붉은 색 선이 ec2 인스턴스 밖으로 나가지 않고 nginx container 와 app container 사이에 존재 한다. 이렇게 하면 ec2 인스턴스의 보안 그룹에서는 8000port 를 오픈할 필요가 없어 보안 위험을 줄일 수도 있고 계획 대로 80번 포트로 들어오는 요청만 nginx를 거쳐 app server 에 전달하는 것이 가능해 진다.
Fig 2. 목표 요청 처리 아키텍쳐
이를 위한 nginx 및 docker compose.yml 예시를 아래 추가 했다. 주석과 함께 보면 이해하기 쉽다. 간단히 말하면 docker-compose.yml 에서는 nginx container 와 app server conatiner 간의 private network 구성을 위해 networks 예약어를 이용해 backend 라는 네트워크를 추가했다. 이렇게 하면 docker의 네트워크 기능을 이용해 두 컨테이너 간 통신이 가능해 진다. 그리고 nginx 에서는 myapp.com의 80 번 포트로 오는 요청 만 app 이 동작하는 app server 서비스의 8000 번 포트로 redirect 하도록 설정 했다. 이때 nginx 의 upstream 의 server 에는 app이 동작하는 서비스의 이름 (docker-compose.yml 에서 app을 실핸 하기 위해 설정 한 service 이름)을 입력해야 한다.
new nginx 설정
upstream jnbdrive_app{
server app_server:8000; ## docker-compose.yml의 app_server 서비스 네임
}
server {
listen 80;
server_name myapp.com; ##client 가 접속하는 도메인네임, 장고 app 의 서버 주소
# redirect https setting
location = /favicon.ico { access_log off; log_not_found off; }
location /static {
alias /home/nginx/www/static;
}
location / {
include proxy_params;
proxy_pass http://myapp.com;
}
}
이렇게 하려고 하다 보니 생기는 문제가 static 파일들을 어떻게 nginx 와 django app이 실행되는 container 에 모두 연결 할수 있는가 였다. 사실 어려운 문제는 아니지만 웹 운영에 익숙치 않는 나의 얕은 지식에서 비롯된 문제 였다.
내가 처음 헷갈렸던 문제는 다음과 같다.
이슈 1. container 1(nginx)와 container 2(django app)이 접근 또는 사용 하는 static 파일들은 물리적으로 같은게 좋은건가? 각각 동일한 파일들을 복사해서 따로 사용 하는게 좋은 걸까?
Answer: 실제 운영 환경에서 어떤지는 잘 모르겠다. 다만 static 파일이 다르면 django app에서 물리 파일이 추가/변경 될때 마다 nginx가 참조 하는 static 파일들을 django app의 최신 파일들과 싱크를 맞추는 과정이 필요하다.
이슈 2. container 1(nginx) 와 container 2(django app) 내에서 static 파일들의 절대 경로가 같아야 하는가?
Answer: 이럴 필요 전혀 없었다.
nginx 를 실행 하는 container 상의 staticfile 위치와 django app 실행 하는 container 내의 staticfile 위치는 달라도 된다.
Container 분리를 위한 과정 및 설정
1. django app settings.py(내 경우 config/settings/prod.py 파일) 에 STATIC_ROOT=./staticfiles 를 파일 맨 밑에 추가.
django 에서 static 파일과 관련된 django setting.py 내의 변수들은 대략 5가지 인데 3가지만 정리 우선 정리 하면 1. STATIC_URL: 웹페이지에서 사용할 정적 파일들의 최상위 URL 경로. 실제 파일들의 물리적인 위치가 아니며 개념적인 경로로이고 반드시 '/'로 끝나야 한다. 2. STATICFILES_DIRS: 개발 단계에서 사용하는 정적(static)파일이 존재 하는 위치하는 경로를 설정하는 항목. 운영시에도 django app은 여기 정의된 위치에서 static 파일을 참조 한다고 한다. 3. STATIC_ROOT:django app에서 사용하는 모든 정적파일들이 모여 있는 디렉토리로 아래 collectstatic 명령 사용시 정적파일들이 복사 되는 위치이기도 하다.
2. 아래 명령을 실행해 static 파일들을 한 directory 에 모은다.
python manage.py collectstatic
3. 이 directory 를 nginx container로 mount 하고 nginx server 설정 파일(django_app_server)에서 내 서버로 들어오는 요청이 static 파일 참조가 필요할 경우 mount한 위치에서 static 파일을 찾도록 아래와 같이 내용 변경.
upstream django_app{
server 192.168.0.102:8000;
}
server {
listen 80;
server_name 192.168.0.102; ##client 가 접속하는 도메인네임, 장고 app 의 서버 주소
location = /favicon.ico { access_log off; log_not_found off; }
location /static {
alias /home/nginx/www/static; ##docker compose 에서 volume 마운트 한 static 파일의 위치를 여기에 설정
}
location / {
include proxy_params;
proxy_pass http://django_app; # static 이 아닌 요청은 jnbdrive_app upstream 으로 요청 포워딩
}
}
아래는 docker-compose.yml 파일이다. django_app_server 설정 파일과 staticfiles 파일의 마운트 위치를 잘 살펴 보자.
staticfiles은 nginx container의 /home/nginx/www/static 위치에 마운트 했고 이 이 위치를 django_app_server 설정에서 참조하도록 했다.
nvidia docker runtime 설치를 위해 GPG 키 추가 후 apt update 를 하니 다음과 같은 에러가 발생했다.
E: Conflicting values set for option Signed-By regarding source https://nvidia.github.io/libnvidia-container/stable/ubuntu18.04/amd64/ /: /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg !=
E: The list of sources could not be read.
운영 대상은 필자가 개발한 장고 앱으로 지인의 부탁으로 잘 모르지만 재능 기부(?) 로 개발을 하게 되었다.
필자는 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 을 운영 할 수 있지만 포트를 이용하는 것은 느려서 비효율 적이라고한다.(점프 투 장고에서 봤다.) 유닉스 계열에서는 유닉스 소켓을 이용해 하는 것이 더 빠른 성능을 기대 할수 있다고 한다.
위 심볼릭 싱크를 만들어 주면 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에 절대 경로가 아닌 상대 경로를 사용한 경우로 심볼릭 링크를 제거 하고 다시 만들면 된다.
