[Django파이썬웹프로그래밍] 06 Django의 웹 서버 연동 원리 - 6.1~6.3

 

이어서 꼬~

 

 

웹 애플리케이션을 개발 후에 이를 실제로 서비스하기 위해서는

 

개발한 프로그램을 운영 환경에 배포하고 실행해야 하죠?

 

이렇게 개발해온 것을 운영 환경으로 옮겨가기 위해서는

 

우리가 개발 시 지정했던 설정 사항을 몇 가지 변경해야 해요~

 

 

 

6장에서는

 

웹 서버로 오래전부터 가장 널리 사용되어온

 

'아파치'와

 

차세대 웹 서버로 알려진

 

'NGINX'

 

 뿐만 아니라

 

'PythonAnywhere 클라우드 웹 서버'

 

까지  장고 애플리케이션을 실행하기 위해 필요한 사항들을 설명하겠다~

 

 

'개발 / 운영' 환경의 차이점을 이해하고, 이에 따라 설정 사항을

 

변경하는 것이 주요 작업입니다.

 

( 책에서의 운영 구성 환경은 CentOS 7.x 에서 진행합니다.

저는 Windows 에 VSCode IDE + ProgresSQL 입니다.)  

 

자, 그럼 시작!

 

---

6.1 장고의 wsgi.py 파일

---

프로젝트 구성시 wsgi.py 파일에는

 

웹서버의 동적처리를 할 수 있게하는 애플리케이션을 application 이라는 이름의 객체로 정의해 두었다.

 

# path - /프로젝트디렉토리/wsgi.py

import os					

from django.core.wsgi import get_wsgi_application	# 미리 application 객체를 로딩 하기 위한 위치 명시

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "kej_test.settings")

application = get_wsgi_application()    # application의 형태로 저장됨을 알 수 있다!

 

application 객체는 운영 웹서버 뿐만 아니라

 

장고의 개발용 웹 서버인 runserver에서도 같이 사용하는 객체이다.

 

다만, 다른 점은 application 객체의 위치를 지정하는 방식이며,

 

운영 웹서버는 각 웹서버의 설정 파일(httpd.conf)에서 하며,

 

장고의 개발용 웹서버는 settings 모듈(settings.py)의 WSGI_APPLICATION 변수로 지정한다.

 

 

웹 서버는 이 application 객체를 호출하여 장고의 애플리케이션을 실행하며,

 

그 전에 미리 설정 정보를 로딩하는 작업이 필요하고,

 

설정 정보를 담고 있는 settings 모듈의 위치를 위와 같이 wsgi.py에서 지정해준다!

 

 

---

6.2 장고의 WSGI 인터페이스

---

장고를 활용한 웹 프로젝트의 아키텍쳐는 아래와 같다!

 

[그림06_01] 웹 프로그래밍 아키텍쳐

 

위 부분 중에 우리가 먼저 신경 써야 될 부분은 uWSGI 부분입니다. 

 

웹서버의 동적처리를 위한 장고 웹 프레임워크로 규격화 해서 처리를 요청 주고/받아야 하죠.

 

이때, WSGIHandler 라는 객체를 활용합니다.

 

정리하면 아래와 같아요.

 

장고는 웹 애플리케이션을 만들어주는 프레임워크이고,
WSGI 규격의 애플리케이션 스펙을 구현하기 위해 wsgi.py 파일을 제공하며,
규격에 따라 WSGI 서버에서는 application 호출자를 호출하는데, wsgi.py 파일에서 이 호출자를 정의하고

장고에서는 이 호출자를 WSGIHandler 클래스로 정의하고 있어요.

---

6.3 운영 서버 적용 전 장고의 설정 변경 사항

---

 

배포 환경을 체크하기 위해선 아래 명령어를 수행해야 한다.

 

python manage.py check --deploy

 

그런데, 주요 배포 설정 값이 따로 있다.

 

1) SECRET_KEY

# path - /프로젝트디렉토리/settings.py

...

# SECRET_KEY 확인
# 개발시에는 하드코딩 되어 있지만, 

# 외부 유출되면 안되기에 따로 환경 변수에 저장하거나  
import OS
SECRET_KEY = os.environ['SECRET_KEY']

# 프로젝트 내 파일에 저장한 후에 사용한다.
with open(os.path.join(BASE_DIR, 'www_dir', 'secret_key.txt')) as f:
    SECRET_KEY = f.read().strip()
    

...

2) DEBUG

# path - /프로젝트디렉토리/settings.py

...

DEBUG = False

...

3) ALLOWED_HOSTS ( DEBUG = False 면 꼭 필요 . True 면 자동으로 로컬호스트만 됨.)

# path - /프로젝트디렉토리/settings.py

...

# 잘 조정하자..(192.168.56.101는 내부 웹서버 IP인 듯)
ALLOWED_HOSTS = ['192.168.56.101', 'localhost', '127.0.0.1']

...

4) STATIC_ROOT

리소스 파일(css, js 등)이 지정 되어 있는 디렉토리를 명시해주어야 한다.

 개발 환경은 알아서 찾아주지만, 운영 환경은 다르다.

( 장고의 collectstatic 명령 실행 시 정적 파일들을 한 곳에 모아주는 디렉토리 )

# path - /프로젝트디렉토리/settings.py

...

# www_dir이라는 디렉토리로 리소스 파일(css, js 등)이 지정 되어있다.
# 개발 환경은 알아서 찾아주지만, 운영 환경은 명시해주어야 한다.
STATIC_ROOT = os.path.join(BASE_DIR, 'www_dir', 'static')

...

# 정적데이터 정의 파일을 모아서 정리
python manage.py collectstatic

 

 

자... 이렇게 준비 끗!!!!!

 

(근데 이것만 해서 배포 전 체크 명령어 수행하면 왜 이러지? ㅋㅋㅋ)

[그림06_02] 배포 준비 체크 명령어 수행 결과