<stdio.han>

이제 파이보게시판을 만들어서 누구나 접속할 수 있게 되었다. 하지만 점프 투 장고 에서 추가로 설명한 도메인설정, SSL, PostgreSQL 등 도 하지 않았다. 보안이나 관리의 편의성 등에 문제가 있을 수 있는 게시판이지만 유료로 도메인을 등록할 필요성등을 아직 못느꼈기 때문에 하지 않았다. 점프 투 장고 온라인 책을 보며 만들었는데 따라서 파이참, 장고, DB, AWS, 등 대부분이 다 처음 사용해보는것들이였다. 이제 책없이 처음부터 다시 만들라고 하면 못만들것 같긴하지만 그래도 한번 만들어 본 경험이 있기 때문에 책을보며 다시 만든다면 막히는 부분없이 잘 만들 수 있을것같다. 학교에서 그냥 프로그래밍 언어만 배우며 얻지 못했던 지식들이나 학교에서 제대로 공부하지 않았던 부분을 다시 배우며 개발과정 전체의 흐름을 이해하는 계기가 되었다. 파이썬과 장고가 내가 미래에 사용할 주된언어가 될지 아닐지는 모르지만 기본적인 틀을 배웠다고 생각한다. 그냥 학교에서 내주는 하나의 과제가 아닌 스스로 공부하며 시작해보는 프로젝트 자체가 처음이라 정말 좋은 경험이였다. 점프 투 장고를 배우며 다시 정리하는 느낌으로 블로그를 작성했는데 말솜씨가 좋지 않아 점프 투 장고 온라인 책을 그대로 옮겨적는 것 같은 느낌이 되버린것이 정말 아쉽다. 이게 책의 저자님께 피해가 가거나 그렇게 되지를 않기를 바라고 있다. 마지막으로 이 책의 저자님께 감사하다는 말을 드리고 싶다. 다른 사람들도 한번씩 해보는것도 좋을것 같다. 

https://wikidocs.net/book/4223

저번 게시물에서 DEBUG=False 로 설정했기 때문에 파이보 이용중 오류가 발생한다면 404오류같은 페이지가 출력되고 오류의 원인같은 정보는 출력되지 않는다. 이제 오류의 원인이 무엇인지 파악을 할 수 없는데 그렇다고 DEBUG=True 로 변경할수는 없다. 이를 해결하기 위해 로그 파일을 이용하는것이 가장 좋다.

로그를 파일로 저장하기 위해서 먼저 장고의 DEFAULT_LOGGING 설정을 알아보자.

DEFAULT_LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse',
        },
        'require_debug_true': {
            '()': 'django.utils.log.RequireDebugTrue',
        },
    },
    'formatters': {
        'django.server': {
            '()': 'django.utils.log.ServerFormatter',
            'format': '[{server_time}] {message}',
            'style': '{',
        },
    },
    'handlers': {
        'console': {
            'level': 'INFO',
            'filters': ['require_debug_true'],
            'class': 'logging.StreamHandler',
        },
        'django.server': {
            'level': 'INFO',
            'class': 'logging.StreamHandler',
            'formatter': 'django.server',
        },
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler'
        },
    },
    'loggers': {
        'django': {
            'handlers': ['console', 'mail_admins'],
            'level': 'INFO',
        },
        'django.server': {
            'handlers': ['django.server'],
            'level': 'INFO',
            'propagate': False,
        },
    }
}

version 은 고정값 1을 사용해야만 한다. 다른값이 입력되면 오류가 발생한다.

disable_existing_loggers 항목은 False로 설정했다. True 로 설정하면 기존에 설정된 로거들을 사용하지 않는다. 파이보도 False 로 설정할 것이다.

filters 는 특정 조건에서 로그를 출력하거나 출력하지 않기 위해서 아용된다. require_debug_false 필터는 DEBUG=False 인지 판단하는 필터이고 require_debug_ture 필터는 디버그가 True 인지 판단하는 필터이다.

formatters 는 로그를 출력할 형식을 정한다. 포맷터에 사용된 항목은 server_time(서버의 시간), message(출력 내용) 이다.

handlers 는 로그의 출력방법을 정의한다. console은 콘솔에 로그를 출력한다. 로그레벨이 INFO 이상이고 디버그가True 일때만 로그를 출력한다.

django.server 는 python manage.py runserver 로 작동하는 개발 서버에서만 사용하는 핸들러로 콘솔에 로그를 출력한다. mail_admins 는 로그내용을 이메일로 전송하는 핸들러로 로그레벨이 ERROR 이상이고 DEBUG=False 일때만 로그를 전송한다. 이 핸들러를 사용하려면 환경설정파일에 ADMINS 항목을추가하고 관리자 이메일을 추가해줘야한다. 그리고 이메일발송을 위한 SMTP 설정도 해줘야한다.

loggers 항목은 로그를 출력하는 프로그램에서 사용하는 로거의 이름을 의미한다. django 는 장고 프레임워크가 사용하는 로거이고 로그 레벨이 INFO이상일 경우에만 로그를 출력한다. django.server 는 개발서버가 사용하는 로거로 로그레벨이 INFO 이상일 경우에만 로그를 출력한다. 'propagate' : False 의 의미는 django.server 가 출력하는 로그를 장고 로거로 전달하지 않는다는 의미이다. True 로 최상위 패키지명이 django 로 동일하기 때문에 django.server 하위 패키지에서 출력하는 로그가 django.server 로거에도 출력되고 django 로거에도 출력되어 이중출력 현상이 발생한다.

로그레벨은 5단계로 구성된다. logging.debug, logging.info, logging.warning, logging.error, logging.critical 함수로 출력된다.

1단계 DEBUG : 디버깅 목적으로 사용된다.

2단계 INFO : 일반 정보를 출력할 목적으로 사용된다.

3단계 WARNING : 경고 정보를 출력할 목적으로 사용된다. 주로 작은문제를 출력한다.

4단계 ERROR : 오류 정보를 출력할 목적으로 사용된다. 주로 큰 문제를 출력한다.

5단계 CRITICAL : 아주 심각한 문제를 출력할 목적으로 사용된다.

로그는 설정한 레벨 이상의 로그만 출력된다. 예를들어 핸들러나 로거의 레벨을 INFO로 설정하면 DEBUG로그는 출력되지 않고, INFO 이상의 로그 INFO, WARNING, ERROR, CRITICAL 로그들만 출력된다.

이 파일들을 적용하기위해 먼저 projects\mysite\config\settings\base.py 에 위에 적힌 DEFAULT_LOGGING 을 복사하자.

복사를 그대로 하는데 이름만 DEFAULT_LOGGING 에서 LOGGING 으로 변경해주자.

그리고 포맷터 standard 를 추가하자.

standard 포맷터에 사용한 항목들은 asctime(현재시간), levelname(로그의 레벨,단계), name(로거명), message(출력 내용) 이다.

handlers 에 file 핸들러도 추가해주자.

file 핸들러에 사용한 항목은 

level : 출력 레벨로 INFO를 사용

filters : DEBUG=False 인 운영환경에서 사용

class : 파일 핸들러로 RotatingFileHandler 사용. RotatingFileHandler 는 파일 크기가 설정한 크기보다 커지면 파일 뒤에 인덱스를 붙여서 백업한다. 이 핸들러의 장점은 로그가 무한히 증가해도 일정 개수의 파일로 Rolling 되기 때문에 로그 파일이 너무 켜저 디스크가 꽉 차는 위험을 방지한다.

filename : 로그 파일명은 logs 디렉토리에 mysite.log 로 설정

maxBytes : 로그 파일의 최대 크기는 5MB

backupCount : 롤릴되는 파일의 개수는 총 5개로 설정

formatter : 포맷터는 standard를 사용.

마지막으로 django 로거의 handlers 에 file 핸들러를 추가하자.

설정을 다 완료한 후 git으로 서버에 적용하자. 서버에 적용한 후 서버에 logs 디렉토리를 만들어 주자.

개발환경에서도 projects\mysite\logs 디렉토리를 만들어주자. 그리고 logs 디렉토리는 버전 관리 대상이 아니므로 .gitignore 파일에 logs 디렉토리를 추가하자.

잘 적용되었나 테스트를 해보기 위해 

projects\mysite\pybo\views\base_views.py 파일에 다음과 같이 강제로 오류를 발생시켜보자.

index 함수가 호출되면 3을 0으로 나누려고 하기 때문에 ZeroDivisonError 가 발생한다. 깃을 이용해 서버에 적용하자. 설정한 후 서버에서 파이보 메인 페이지에 접속해보자. 'Server Error (500)' 오류가 발생한다. 이제 로그를 확인해보자.

어떤 오류가 발생했는지 로그파일에 출력된다. 앞으로는 tail -f mysite.log 로 로그를 확인하자. 이 명령을 하면 mysite.log 파일에 로그가 깧일 때마다 로그의 내용이 자동으로 출력된다.

지금까지 설정한 로깅은 장고가 사용하는 django 와 django.server 라는 로거로만 사용했다. 이번엔 새로운 로거를 생성해 파이보 프로그램에서 로그를 출력해보자.

먼저 projects\mysite\pybbo\views\base_views.py 를 수정하자.

적어 뒀었던 3/0 강제오류 코드를 지우고 사진과 같이 수정하자. 로그 파일에 로그를 출력하기 위해서는 logging 모듈이 필요하다. logger = logging.getLogger('로거명') 으로 얻은 logger 객체를 이용해 logger.debug, logger.error, logger.warning 등의 함수를 이용해ㅑ 로그를 출력할 수 있다. 이렇게 설정해도 'INFO 레벨로 출력' 이라는 문장은 로그로 출력되지 않는다. 그 이유는 위 코드에서 사용한 pybo 라는 로거는 LOGGING 설정에 등록되지 않은 상태이기 때문이다.

이를 등록하기 위해 projects\mysite\config\settings\base.py 를 다음과 같이 수정하자.

console 과 file 핸들러를 사용하는 pybo 로거를 등로했다.

이제 서버에 변경내용을 적용하고 파이보 메인페이지에 접속후 로그를 확인해보자.

잘 작동한다.

장고 환경셜정 파일에는 DEBUG 라는 항목이 있다. 이 항목은 기본값이 True 이지만 장고 공식 문서에는 '운영 환경에서 DEBUG는 반드시 False로 해야한다' 라고 되어있다.

장고는 실행 도중 오류가 발생하면 디버그가 True 인 경우 오류내용을 상세하기 출력한다. 이 때 settings.py 나 urls.py 같은 파일에 설정한 항목들도 노출된다. 정보 노출이나 해킹 등의 위험 때문에 False 로 해야한다.

projects\mysite\config\settings\prod.py 를 수정하자.

그리고 깃을 커밋해 서버에 적용하자. 하는 방법은 전 게시물을 확인하자.

그 후 http://고정ip/asdf 같이 존재하지 않는 페이지로 접속해 보자.

이전에는 오류의 원인같은 다양한 메시지가 적힌 페이지가 출력되었는데 이제는 아무런 정보도 표시되지 않는다.

정보를 표시하지 않기는 하지만 페이지가 단조롭기 때문에 꾸며보자. 꾸미기 위해 먼저 

projects\mysite\config\urls.py 를 수정하자.

handler404 변수를 설정하면 404 오류 발생 시 사용자가 정의한 뷰 함수가 호출된다. 우리는 적어 넣은대로 common/views.py 파일의 page_not_found 함수가 호출될것이다. 이 handler404 변수는 반드시 config\urls.py 에 등록해야한다. common\urls.py 같은 곳에 등록하면 작동하지 않는다. 호출할 함수를 설정했으므로 이제 그 함수를 정의해보자.

projects\mysite\common\views.py 를 수정해주자.

함수가 받는 매개변수중 exception 매개변수는 오류의 내용을 담고있다. 오류의 내용을 화면에 보여주려면 exception 값을 읽어 화면에 출력할 수도있다. 함수에 common/404.html 을 리턴한다고 했으므로 그 파일을 만들어주자.

projects\mysite\templates\common\404.html 을 새로 만들고 다음과 같이 작성해주자.

그리고 깃을 이용해 서버에 적용하자. 서버에 적용한 후 구니콘을 restart 해주자. 이제 파이보를 확인해보자.

이제 좀더 깔끔하게 나온다.

서버환경에서 장고 Admin 을 사용하기위해 개발환경에서 한것처럼 슈퍼유저를 생성하자.

너무 쉬운 비밀번호로 생성하려하면 재확인 메세지가 나온다. 그리고 http://고정ip/admin 로 접속해보자.

Nginx가 장고 Admin 에서 사용하는 정적 파일을 제대로 읽지 못해서 이렇게 응답을 한다. 엔진엑스가 바라보는 정적 파일은 /home/ubuntu/projects/mysite/static 디렉토리에 위치해야 한다. 장고 어드민이 사용하는 정적파일들은 다른위치에 있다 이를 해결하기 위해 장고 환경설정 파일에 STATIC_ROOT 디렉토리를 설정하고 python manage.py collecstatic 명령을 수행해 관리자 앱의 정적 파일을 STATOC_ROOT 디렉토리로 복사해야 한다.

먼저 projects\mysite\config\settings\prod.py 파일에 STATIC_ROOT 항목을 추가하자.

BASE_DIR은 /home/ubuntu/projects/mysite 이다. 엔진엑스의 정적 파일위치를 /home/ubuntu/projects/mysite/static 디렉토리로 등록했기때문에 STATIC_ROOT 도 똑같이 설정해줘야한다.

그리고 STATICFILES_DIRS = [] 도 추가해준다. 추가해주는 이유는 base.py 파일에는 STATICFILES_DIR 항목이 이미 있는데 prod.py 에 다시 빈 값으로 설정하는 이유는 STATIC_ROOT 가 설정된 경우 STATICFILES_DIRS 리스트에 STATIC_ROOT 와 동일한 디렉토리 포함되어 있으면 서버 실행시 오류가 발생하기 때문이다. 이를 방지하기 위해 prod.py 파일에 STATICFILES_DIRS = [] 로 설정했다.

파일을 수정했기 때문에 git 에 커밋하자.

커밋 후 내려받자

git pull 로 내려받은 후 서버에 프로그램이 변경되었으므로 Gunicorn 을 재시작 하기위해 sudo systemctl restart mysite.service 명령을 해주자.

이제 python manage.py collecstatic 명령을 수행해 관리자 앱의 정적 파일을 복사하자.

yes 를 입력해 진행하면 복사가 성공되었다는 메세지가 출력된다. static 디렉토리로 이동 후 ls -l 로 확인해 보면 정적파일들이 다 있는것을 확인할 수 있다.

이제 정적파일들을 잘 찾을수 있기 때문에 어드민 로그인 페이지도 잘 로딩된다.

웹서버는 브라우저의 정적 페이지 요청을 처리하고 동적 페이지 요청은 WSGI 서버를 호출하는 역할을 한다. 이번엔 파이보가 사용할 웹 서버인 Nginx 를 설치하고 적용해보자.

그리고 /etc/nginx/sites-available 디렉토리로 이동하자. 이 디렉토리는 Nginx의 설정 파일들이 위치한 디렉토리다. 최초 설치시에는 default 라는 설정파일만 존재한다. 해당 위치로 이동 후 sudo vi mysite 파일을 생성해 작성한다.

listen 80 은 웹 서버를 80포트로 서비스한다는 의미이다. HTTP 프로토콜의 기본포트는 80이다. 이제 http://고정ip:8000 대신 포트를 생략해 http://고정ip 만으로 접속할 수 있다.

server_name 에는 고정 ip 를 등록한다.

location /static 은 종적 파일에 대한 설정으로 /static 으로 시작되는 url 요청은 엔진엑스가 /home/ubbuntu/projects/mysite/static 디렉토리의 파일을 읽어서 처리한다는 설정이다.

location / 은 location /static 에서 설정한 것 이외의 모든 요청은 구니콘이 처리하도록 하는 설정이다. proxy_pass 는 동적 요청이 발생하면 해당요청을 구니콘의 유닉스 소켓으로 보내라는 설정이다.

한마디로 /static 으로 시작되는 url 은 엔진엑스가 나머지 url 은 구니콘이 처리하게 된다.

이제 작성한 mysite 파일을 Nginx 가 환경파일로 읽을 수 있도록 설정하자.

먼저 cd /etc/nginx/sites-enabled 디렉토리로 이동하자. 이 디렉토리는 site-available 디렉토리에 있는 설정 파일 중에서 활성화 하고 싶은 것을 관리하는 디렉토리 이다. ls 명령을 하면 현재 default라는 설정 파일만 링크되어있는데 default 를 삭제하고 mysite 파일을 링크하도록 변경해야 한다. 

sudo ln -s /etc/nginx/sites-available/mysite 로 링크한후 ls 로 확인해보면 링크 되어있다.

Nginx 설치할 때 자동으로 실행되므로 앞에서 작성한 엔진엑스 설정을 적용하려면 엔직엑스를 다시시작해야한다.

sudo systemctl restart nginx 를 해주자.

이제 http://고정ip 로 접속을해보자. 이제 주소 뒤에 :8000 을 안해도 된다.

정상적으로 잘 접속된다.

이번엔 WSGI 서버인 Gunicorn 을 설치하고 사용해보자. WSGI 서버는 대표적으로 Gunicorn 과 uwsgi 가 있다. 우리는 Gunicorn 을 사용할 것이다.

구니콘은 서버에 필요한 도구이므로 서버 환경에 설치하자. AWS에 접속한 뒤 pip install gunicorn 명령을 해 설치하자.

설치후 테스트해보자. gunicorn --bind 0:8000 config.wsgi:application 명령을 해보자

/projects/mysite 디렉토리로 이동한 뒤 명령을 실행했다. 해석해보자면 --bind 0:8000 은 8000번 포트로 WSGI 서버를 수행한다는 의미이다. config.wsgi:application 은 WSGI 서버와 연결된 WSGI 어플리케이션은 config/wsgi.py 파일의 어플리케이션이라는 의미이다. 

http://고정IP:8000 으로 접속을 해보자.

이상하게 보일텐데 그 이유는 gunicorn 이 정적파일을 못읽었기 때문이다. 파이보는 bootstrap.min.css, bootstrap.min.js 등은 정적 파일인데 정적파일을 못 읽었기 때문이다. 일단 잘 작동하는것을 확인했으므로 control+c 로 구니콘을 종료하자.

구니콘은 포트를 이용해 서버를 띄울 수 있다. 아지만 Unix 계열 시스템에서는 포트로 서비스하기보다 유닉스 소켓을 사용하는 것이 빠르고 효율적이다. 이번엔 유닉스 소켓으로 서비스해보자. AWS 서버가 유닉스 계열 시스템인 우분투이다. 

이번엔 gunicorn --bind unix:/tmp/gunicorn.sock config.wsgi:application 명령을 했다. 잘 실행됬으니 종료하자.

AWS 서버에 Gunicorn 서비스로 등록해 보자. 구니콘의 시작, 중지를 쉽게 하고, 또 AWS 서버를 다시 시작할 때 Gunicorn 을 자동으로 실행하기 위해서이다.

먼저 환경변수를 수정하자.

/home/ubuntu/venvs/mysite.env 를 새로 만들고 작성하자.

vi 편집기로 작성했다.

내용 한줄만 작성하자. 그리고 /etc/systemd/system/ 디렉토리에 mysite.service 파일을 생성하자. 이 파일은 시스템 디렉토리에 저장해야 하므로 sudo vi mysite.service 같이 관리자 권한으로 작성해야 한다.

서비스 파일의 EnvironmentFile 항목이 우리가 작성한 환경 변수 파일을 사용하게 하는 설정이다. --workers 2 는 구니콘 프로세스를 2개 사용하라는 의미이다. 프로세스를 2개로 지정한 이유는 우리가 선택한 월 사용료 5달러 사양의 서버에는 이정도가 적당하기 때문이다.

이제 서비스를 실행해 보자. 서비스 파일이 관리자 디렉토리에 있으므로 실행 역시 관리자 권한으로 실행해야 한다.

sudo systemctl start mysite.service 명령을 해보자.

그리고 sudo systemctl status mysite.service 로 상태를 확인해보자. 다음처럼 잘 작동이 되지 않는다면 /var/log/syslog 파일에서 오류를 확인하고 수정하자.

마지막으로 AWS 서버가 다시 시작될때 구니콘이 자동으로 실행되도록 enabble 옵션을 추가해 서비스로 등록하자.

구니콘 서비스를 종료하려면 sudo systemctl stop mysite.service 

재시작 하려면 sudo systemctl restart mysite.service 명령을 하자.

지금까지 python manage.py runserver 명령어를 이용해 내장 서버를 구동하는 방식을 사용했다.

이제는 WSGI(위스키) 를 이용해 서버를 연다. WSGI 를 이용하면 기능이 더 많아지고, 이용자가 몰릴경우를 더 효율적으로 처리할 수 있다.

먼저 웹브라우저, 웹서버의 작동방식을 알아보자. 웹브라우저가 웹서버에 요청하는 페이지는 크게 두 가지 이다. 정적 페이지, 동적 페이지.

정적 페이지는 css, js, jpg, png 같은 변하지 않는 동일한 값을 리턴하는 정적 파일을 요청하는 것이다. 동적 페이지는 파이보의 메인페이지인 http://<고정 ip:8000> 같은 페이지를 요청하는 경우이다. 파이보 메인 페이지를 요청하면 질문 목록을 데이터베이스에서 조회해 리턴하고 그 목록은 DB가 변할때마다 바뀐다. 이런것을 동적 페이지라고 한다.

웹 서버는 정적 요청과 동적 요청을 처리하는 서버이다. 웹서버는 대표적으로 Apache, Nginx 등이 있다. 파이보는 장고와 잘 어울리는 엔진엑스(Nginx)를 웹서버로 사용할 것이다. 웹 서버는 정적 페이지 요청이 들어오면 간단하게 정적 파일을 읽어 응답한다. 하지만 동적 페이지 요청이 들어온다면 웹서버는 파이썬 프로그램을 호출해 질문목록을 조회해 리턴하는 파이썬 프로그램을 호출해야 한다. 하지만 대부분 웹 서버는 파이썬 프로그램을 호출하는 기능이 없다. 그러므로 파이썬 프로그램을 호출하는 WSGI(web server gateway interface) 서버가 반드시 필요하다. 웹 서버에 동적 요청이 발생하면 웹 서버가 WSGI 서버를 호출하고, WSGI 서버는 파이썬 프로그램을 호출하여 동적페이지 요청을 대신 처리한다.

WSGI 서버에는 여러 종류가 있지만 파이보는 Gunicorn을 사용할 것이다. 웹서버에 동적 페이지 요청이 발생하면 WSGI 서버를 호출하고 WSGI 서버는 다시 WSGI 어플리케이션을 호출한다. WSGI 어플리케이션은 장고, 플라스크 등이 있다. 파이보 시스템이 사용할 WSGI 어플리케이션은 우리가 지금까지 공부한 장고이다. WSGI 서버는 항상 projects\mysite\config\wsgi.py 파일을 경유해 Django 프로그램을 호출한다. 

간단하게 정리하자면 사용자가 웹서버에 정적요청을 할 경우엔 간단하게 웹 서버가 정적 파일을 찾아 응답한다.

이번엔 사용자가 웹서버에 동적요청을 할 경우에는 WSGI 서버(Gunicorn)를 호출하고 WSGI 서버는 WSGI 어플리케이션인 django 를 호출하고 장고는 데이터베이스를 조회해 응답해준다.

저번에 settings.py 의 ALLOWED_HOSTS 에 고정아이피를 추가해 서버를 구동했다. 하지만 이제 로컬서버를 구동해 파이보에 들어가면 오류가 발생한다. ALLOWED_HOSTS에 고정아이피를 등록했기 때문에 localhost 로 동작하는 로컬서버는 오류가 발생하는 것이다. 이 오류를 해결하려면 간단하게 ALLOWED_HOSTS 에 등록한 고정 아이피를 제거하면 된다. 하지만 로컬서버가 아닌 서버는 다시 오류가 발생한다. 이를 해결하기 위해 로컬환경과 서버환경을 구분해 줘야한다.

먼저 projects\mysite\config 위치에 settings 디렉토리를 생성해주자.

그리고 settings.py 파일을 settings 디렉토리에 base.py 라는 이름으로 이동시키자.

mv settings.py settings/base.py 명령어로 settings/base.py 로 이름을 변경해 옮긴 후. 옮긴 base.py 를 사진과 같이 수정해준다.

.parent 를 하나 더 적어준 이유는. 원래 settings.py 파일의 위치는 /projects/mysite/config 인데 /projects/mysite/config/settings 로 하나 더 깊어졌기 때문이다. /projects/mysite/config/settings/base.py 에서 총 3번의 .parent 가 사용되었으므로 BASE_DIR은 결국 /projects/mysite 인 것이다.

로컬환경을 담당하는 local.py 를 새로만들어 작성해준다.

projects\mysite\config\settings\local.py 를 만들어준다.

from .base import * 은 base.py 의 모든 내용을 사용한다는 의미이고, ALLOWED_HOSTS 는 로컬환경에 맞게 항목을 비워놓은 것이다. 

로컬환경은 설정했으니 서버 환경을 담당할 파일도 만들어 줘야한다.

projects\mysite\config\settings\prod.py 파일을 새로 만들어주고 다음과 같이 작성해주자.

이제 로컬서버를 구동해보자. 

오류가 발생한다. 이제는 로컬환경과 서버환경을 구분지어서 구동시켜줘야하기 때문이다. 먼저 로컬환경을 구동시키려면

python manage.py runserver --settings=config.settings.local 이라고해야 로컬환경을 구동시킬수 있다.

python manage.py runserver 뒤에 --settings=config.settings.local 이라는 옵션을 주었다. --settings 옵션은 장고서버가 읽어야할 설정파일을 지정하는 옵션이다. 그 뒤에적힌 명령어는 config\settings\local.py 를 읽으라는 뜻이다.

그렇다면 서버환경을 구동할때는

python manage.py runserver --settings=config.settings.prod 라고 해야한다. 서버 환경을 구동해서 파이보에 접속해보면 오류가 발생한다. 서버환경으로 구동하는. 파일 prod.py 에는 ALLOWED_HOSTS 에 서버의 고정아이피가 등록되어있기 때문이다.

이번엔 DJANGO_SETTINGS_MODULE 환경변수를 이용해보자. 이 환경변수는 장고 서버 실행 시 사용하는 --settings=config.settings.local 옵션을 대신하는 환경변수이다. DJANGO_SETTINGS_MODULE 환경변수를 settings=config.settings.local 로 설정해주면 python manage.py runserver 를 했을때 자동으로 환경변수를 찾아 뒤에 옵션을 안붙여도 로컬환경으로 구동이 된다. 이것들을 설정해주자.

\Users\<사용자명>\.zshrc 파일을 수정해 alias 를 추가해주자.

파일 수정은 vi 로 수정했다.

서버환경도 커밋하자.

그리고 AWS 터미널에 접속하여 올린 파일들을 내려받자.

AWS 터미널에 접속 후 가상환경에 진입 후 git 을 pull 하자. 그 후 

--settings=config.settings.prod 옵션을 추가해 서버를 구동하고 테스트를 해보면 잘 작동한다.

서버환경도 옵션을 추가할 필요없이 자동으로 작동하게 변경해보자. 

\home\ubuntu\.profile 파일을 vi 편집기로 수정해보자.

이렇게 .profile 파일을 수정하고 터미널을 종료후 다시 켜서 아무데서나 mysite 를 입력하면 자동으로 가상환경으로 진입한다. 그리고 서버구동시 옵션을 추가할 필요도 없어진다.