서론은 없다. 바로 시작하자.
프로젝트 시작에 앞서 가상 환경을 설치하고
Cobeeui-MBP:cobee_space cobee$ python3 -m venv v_site
가상환경을 실행해준다.
Cobeeui-MBP:v_site cobee$ source bin/activate
그 안에 django를 설치한다.
(v_site) Cobeeui-MBP:v_site cobee$ pip install django
시작할 django 프로젝트를 만들어준다.
(v_site) Cobeeui-MBP:v_site cobee$ django-admin startproject cobee_space
나같은 경우에는 프로젝트 파일들이 담길 폴더의 이름을 src로 통일해 준다.
(v_site) Cobeeui-MBP:v_site cobee$ mv cobee_space src
(v_site) Cobeeui-MBP:v_site cobee$ cd src/
(v_site) Cobeeui-MBP:src cobee$ ls
cobee_space manage.py
settings.py와 wsgi.py 분리
deploy를 할거라서 local 환경과 deploy 환경을 나눠준다.
분리 해주는 이유는, local환경에서 개발팀끼리 컨트롤 할 수 있고, debug를 위해 코드를 복잡하게 반복해서 작성하지 않아도 될 뿐더러, 뭐 찾아보면 긍정적인 부분들이 더 있을거다. 검색 ㄱㄱ!
한번 나눠보자.
- settings 폴더를 만들어주고 그 안에 base.py, local.py, deploy.py 를 만들어 준다.
- wsgis 폴더를 만들어주고 그 안에 local.py, deploy.py 를 만들어 준다.
path는 src/cobee_space/settings
src/cobee_space/wsgis
(참고로 각 settings폴더와 wsgis폴더 안에 __init__.py 파일을 하나씩 만들어 줘야 한다.
이유는 따로 포스팅 하고 나중에 링크 하겠음)
아무튼, settings.py 안에 내용을 전부 복사해서 settings/base.py에 넣어준다.
그리고 base.py 안에 있는 WSGI_APPLICATION은 지우든 주석처리하든... 오버라이드 될거라고 생각은 하는데 그래도 그냥 저는 해주겠음.
and then,
>> settings/local.py
>> settings/deploy.py
보시다시피 사실 가장 큰 차이는 DEBUG의 차이다.(아 deploy 캡쳐에 커서가 같이 찍혔네 ㅡ.ㅡ)
>> wsgis/local.py
>> wsgis/deploy.py
(캡쳐 일일이 찍는거 넘 불편하다... 그치만... brunch엔 코드가 예쁘게 써지지 않는걸...)
그리고 기존에 있던 settings.py 파일과 wsgi.py 파일은 삭제해준다.
+
settings 파일을 분리하고 나면 manage.py파일의 os.environ.setdefault 부분을 수정 해야함.
'project_name.settings.base' 로 변경 해준다.
원래는 settings.py 안에 SECRET_KEY는 분리보관 해야하는 형태로 만들어 줘야 하는데, 이번 프로젝트에서는 그냥 두고 한다.(deploy에만 신경써도 헷갈릴게 많아서 기본적인 것 부터 먼저 집중해서 해보도록 한다)
>> 관련 참고 할만한 포스팅 링크
https://wayhome25.github.io/django/2017/07/11/django-settings-secret-key/
자, 환경이 이제 local 개발용 환경과 deploy용 환경으로 분리 세팅되었다.
그 말인 즉슨...
DJANGO_SETTINGS_MODULE 환경변수를 통해 settings 경로를 확인하므로,
python3 manage.py runserver --settings=cobee_space.settings.local (local)
python3 manage.py runserver --settings=cobee_space.settings.deploy (deploy)
이런식으로 runserver 할때 --settings 옵션을 이용해서 지정해 줄 수 있다.
(요렇게 안하면 django가 어느 장단에 춤을 출지 몰라서 바보됨)
아니면 환경변수를 설정해버리는 방법도 있다.
쉘을 새로 켤때 마다 이런식으로 세팅 해주면 된다.
local에서 쓸 쉘이라면,
$ export DJANGO_SETTINGS_MODULE=cobee_space.settings.local
deploy에서 쓸 쉘이면,
$ export DJANGO_SETTINGS_MODULE=cobee_space.settings.deploy
짠, 영롱하게 잘 뜬다.
이제 본격적으로 nginx, uwsgi, AWS EC2를 건드려 보자.
위 그림은 웹의 큰 그림을 잘 나타내고 있어서 구글 검색으로 퍼왔다.
1. 클라이언트다. 웹브라우저를 통해 요청을 보내고 응답을 받고, 뭐 그런식이다.
2. 웹서버, nginx다. 클라에서 HTTP request 받으면 정적 파일을 돌려준다(HTML, CSS, JS)
근데 동적인 데이터가 필요한 request는 웹 애플리케이션(django)으로 보낸다.
그게 성능적으로 좋고 효율적임.
3. unix socket인데 nginx하고 uwsgi 사이에서 http 프로토콜을 사용하는 방법보다, 효율상 socket으로 통신하는게 좋아서 주로 이렇게 씀.
4. 웹 애플리케이션서버, uwsgi. 간단하게 얘기하면 nginx와 django 사이를 translate 해준다. 왜냐면 nginx는 python으로 만들어진 django를 이해 못하기 때문. request와 response를 중간에서 변환해서 서로에게(nginx, django) 전달해준다.
5. 웹 애플리케이션, django. request를 받아서 동적 데이터들을 반환해준다.
여기서부터 저도 많이 헤매고 삽질했던 구간이라, 다음 포스팅에 이어서 집중 빡 해서 써보도록 하겠음.
그럼 4요나라
