2013. 10. 22. 17:20
[코드]
개발할 때는 'manage.py runserver' 명령으로 테스트하고 작업하고 반복하느라 몰랐던, 실제 라이브 서버에 배포하고 나서야 안 몇 가지 사실들
- manage.py 실행 시 unknown command 오류
- 로컬/프로덕션의 셋팅이 나누어져 있을 경우, manage.py는 'DJANGO_SETTINGS_MODULE' 환경설정 값에 설정되어 있는 셋팅을 사용한다.
- manage.py 의 실행가능한 명령들은 셋팅이 어떻게 구성되어 있느냐에 따라 달라지는데, unknown command 가 뜨는 대부분의 경우에는 바로 이 셋팅값이 잘못 구성되어 있을 경우가 대부분이다.
- 셋팅파일을 구성이 제대로 되어 있는지 이중확인을 꼭하고, 그래도 문제가 된다면 명시적으로 '--settings' 옵션을 적용해 주는 것이 도움이 된다.
$ python manage.py collectstatic --settings=testapp.settings.production
- static 파일 배포 문제
- 보통은 개발 시 부터 모든 정적 리소스 (이미지, 스타일시트, 스크립트파일 등)이 분산되어 있지 않고 Django의 디렉토리 규칙에 따라 /testapp/static/ 이하에 모두 들어가 있는 경우에 많다. 하지만 라이브 서버에 배포할 경우 이런 파일들은 배포 전략에 따라 다른 서버나 혹은 특정 권한이 있는 디렉토리에 모여 있어야 되는데, 이럴 때를 위해 Django 에서는 collectstatic 이라는 명령어를 지원하고 있다.
- 다중 settings 구성
- 구글링을 통해 몇 가지 검색해 본 것 중에 제일 추천되는 방법은 /testapp/settings.py 대신 다음과 같이 구성하는 방법을 쓴다.
/testapp/settings/__init__.py/base.py -- 기본 셋팅파일/local.py -- 로컬용 셋팅파일/production.py -- 배포용 셋팅파일
* local.py
from testapp.settings.base import *
# 오버라이딩될 구성값
- 이렇게 설정을 구성하고 manage.py를 실행할 때는 항상 '--settings=testapp.settings.local' 또는 '--settings=testapp.settings.production' 옵션을 붙여 실행하도록 한다.
- wsgi.py 에 'DJANGO_SETTINGS_MODULE' 값도 바꿔주는 부분도 잊으면 안됨은 물론이고.
그 외에 아파치 연동 설정이라던가 기타 등등 굉장히 많은 헛짓과 구글링을 통해 얻은 사실들이 있지만, 일단 오늘은 여기까지 ...
반응형