배포 환경 별 세팅

배포 환경의 구분

개발을 하고 서비스를 단 하나의 웹 컨테이너로 한다고 생각하자. 새로운 코드를 짜게 되면 그것을 테스트 해야하는데 이것을 서비스중에 동시에 한다는 것은 말이 안된다. 불안정한 코드로 인해 의도하지 않은 데이터 수정 및 삭제가 일어날 수도 있고, 테스트 중 코드를 수정하고 다시 서버를 올리는 것은 연속적인 서비스 중단을 낳게 된다.

이 때문에, 우리는 배포 환경을 구분하여 서비스를 배포하게 된다. 배포 환경 별 세팅을 구성함으로써 서비스 환경이 더욱 안정적이어 지고, 무중단 배포 만큼은 아니지만 수정된 사항이 완전히 안정화 된 이후에 서비스 환경에 단 한 번 수정이 이루어지기 때문에 업데이트 및 디버깅으로 인한 배포 중단이 최소화 될 수 있다.

1. 개발환경

서비스 개발자가 개발과 디버깅을 할 수 있는 환경이다. 이 환경을 구성함으로써 개발자가 자유롭게 무슨 짓이든 할 수 있다.

2. 테스트 환경

알파 및 베타 테스트를 할 수 있는 여건이 된다면, 테스트 환경을 따로 두어 개발자가 아닌 다른 인원이 테스트를 진행하게 된다.
또는 서비스 환경과 DB를 제외한 나머지 환경설정을 동일하게 하여 오류 재현을 하는데 사용할 수 있다.

3. 서비스 환경

실제 서비스를 배포하는 환경이다. 테스트와 같은 개발에 관련된 행위가 절대로 일어나서는 안된다.

배포 환경이 나누어졌기에 환경 별로 다른 세팅을 가질 수 있고, 또 가져야만 한다. (DB 세팅의 경우 개발 및 테스트 환경 DB를 서비스 환경과 같이 사용해서는 안된다.)

이 때, 세팅 파일만 여러 개를 만들고, 각 환경에 맞는 세팅을 사용하면 한 벌의 코드로 여러 환경에서 사용이 가능하다.

Django의 환경 별 세팅 운영

Django에서 환경 별 세팅을 운영하는 것은 사실 굉장히 간단하다. 장고 manage.py 파일의 DJANGO_SETTINGS_MODULE의 value에 알맞은 세팅 파일을 명시하면 되기 때문이다.

import os
import sys

if __name__ == '__main__':
    # 아래 문장을 수정하면 된다.
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'SEAT_WATCHER.settings')
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)

사실 이 경우는 manage.py를 직접 사용하는 경우에 사용할 수 있다.

real production 상황에서는 보통 uwsgi를 사용한다. 이 때도 wsgi.py 파일의 세팅 모듈의 값을 바꾸어 주면 된다.

import os

from django.core.wsgi import get_wsgi_application

# 이 곳을 바꾼다.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'SEAT_WATCHER.settings')

application = get_wsgi_application()

위 와 같은 방법으로 환경 별 세팅을 할 수 있다.