1번째 줄: |
1번째 줄: |
− | 실제로 서비스하기 위한 지식들을 구분하기 위한 분류. | + | 실제로 서비스하기 위한 지식들을 구분하기 위한 문서. |
− | [[분류:장고]] | + | |
| + | = 사전준비 = |
| + | 웹서비스를 위해 몇몇 준비가 필요하다. |
| + | |
| + | == Static == |
| + | 서비스용 스태틱 설정이 필요하다. |
| + | |
| + | [[2. 장고 스테틱 서비스용 설정|스태틱 서비스용 설정]] 문서를 참고하자. |
| + | |
| + | = Settings.py = |
| + | |
| + | ==settings.py 분리[정리해야 함;]== |
| + | DEBUG모드를 False로 바꾸어주어야 하는데, 개발컴에선 True로 되어 있어야 편하다. |
| + | |
| + | 서비스용 settings와 개발용 settings는 다르게 작동해야 하는데.. 분리해두면 하나를 수정했을 때 다른 하나를 또 고쳐야 되기도 하고 귀찮은 점이 많다. |
| + | |
| + | 그러나, DEBUG 등의 세팅을 위해선 분리해주는 게 좋긴 하다; -> 그래서 import를 사용해 덧씌운다! |
| + | |
| + | service_settings.py를 다음과 같이 짜두면 특정한 설정만 덧씌워 서비스 할 수 있다.<syntaxhighlight lang="python"> |
| + | from .settings import * |
| + | |
| + | DEBUG = True # DEBUG=True이면 개발모드, False면 운영모드로 인식한다. |
| + | </syntaxhighlight> |
| + | |
| + | ====세팅파일에선 DEBUG설정을 False로 해주어야 한다.==== |
| + | 디버그 정보는 프로젝트에 관련한 중요 사항들로, 정보가 노출되지 않게끔 해야 한다. |
| + | ===로컬용 세팅파일로 서버 실행=== |
| + | 기본적인 실행에선 settings.py를 통해 기본 세팅을 받지만, 이 파일을 바꾸어 서버를 실행하는 옵션이 있다. |
| + | |
| + | python manage.py runserver --settings=config.로컬용세팅파일 #기존 세팅파일과 같은 경로에 있는 경우. |
| + | |
| + | 위와 같이 실행하면 새로 만든 파일을 세팅으로 받아 서버를 실행한다. |
| + | |
| + | 결과적으로 <code>python manage.py runserver --settings=config.로컬용세팅파일 0:8000</code> 형태로 작동시켜주면 된다.(리눅스라면 &을 붙이자. 백그라운드에서 실행하게끔) |
| + | |
| + | 0:8000은 8000번 포트로 모든 IP로부터 접속을 허용한다는 이야기. |
| + | |
| + | service_settings.py 라는 이름으로 같은 경로에 다음과 같이 작성하였다.<syntaxhighlight lang="python"> |
| + | from .settings import * |
| + | |
| + | DEBUG = False # DEBUG=True이면 개발모드, False면 운영모드로 인식한다. |
| + | </syntaxhighlight><code>python3 manage.py runserver --settings=config.service_settings</code> 라는 명령어로 세팅파일을 바꾸어 실행할 수 있다. |
| + | |
| + | 이렇게 하면 개발할 때엔 지금과 같은 <code>python3 manage.py runserver</code>명령으로 개발모드에 들어설 수 있다. |
| + | |
| + | <code>python3 manage.py runserver --settings=세팅파일명</code> 형태로 settings.py 대신 다른 파일을 사용할 수 있다. |
| + | |
| + | == 비밀 파일 분리 == |
| + | settings.py엔 비밀키, 이메일 비밀번호 따위가 들어가 있어 민감함 정보를 보호하지 못한다. 보호할 정보를 다른 파일로 만든 후 그걸 불러오는 방식으로 분리하거나 아예 다른 setting으로 실행하는 등 다양한 방법이 있는데(환경변수에 등록하기도 한다.), 여기에선 다른파일로 만든 후 불러오는 방식을 사용하겠다.(json파일로 만들어 불러오거나 환경변수에 값을 저장하는 등... 다양한 방법이 있다.) |
| + | |
| + | ===공유되지 않는 보안용 파일 만들기=== |
| + | 다양한 방법으로 보호되어야 할 정보를 따로 분리한 후 gitignore에 설정한다. |
| + | {| class="wikitable" |
| + | |+보호전략 |
| + | !방법 |
| + | !설명 |
| + | !단점 |
| + | |- |
| + | |라이브러리 활용 |
| + | |pip install django-environ 설치 후 .env 파일을 작성해 보호할 정보를 저장한다.(django-environ 도큐먼트 참고) |
| + | settings.py에서 import os, environ으로 불러온 후, 보호된 정보를 활용한다. |
| + | |
| + | 이후 .env를 gitignore에 담는다. |
| + | |굳이; 이렇게 복잡하게;;? |
| + | |- |
| + | |텍스트 파일 활용 |
| + | |외부에 텍스트파일을 만들어 두고, 이를 읽어 비밀키 등에 대입. |
| + | |쓸 코드가 길어져; |
| + | |- |
| + | |.py 활용 |
| + | |다른 파이썬 파일 안에 각종 정보를 담아두고 settings.py에서 import해 변수로 활용. |
| + | | |
| + | |- |
| + | |환경변수 활용 |
| + | |감출 키를 환경변수에 등록하고 os.environ['환경변수'] 형태로 사용할 수도 있다. |
| + | |특수문자때문에 환경변수에 추가 안될 수도 있다. |
| + | |}SECRET_KEY는 쿠키, 세션 같은 보안에 쓰여 외부에 노출되면 안되지만, 많은 이들이 그냥 github에 올려버리고 만다. 그런 경우, 다음 링크를 통해 새로운 키를 만들어보자. https://miniwebtool.com/django-secret-key-generator/ |
| + | |
| + | 필자는 setting.py와 같은 경로에 secret.py를 만들고 다음과 같이 변수를 정의하였다.<syntaxhighlight lang="python"> |
| + | SECRET_KEY= '비밀키' |
| + | </syntaxhighlight>기존 변수와의 관계를 알기 쉽게 하기 위해 이름을 그대로 사용한다. |
| + | |
| + | 이외 이메일 비밀번호 등 필요하다 판단되는 변수들을 secret.py로 옮겨 정의한다. |
| + | |
| + | == 기존 settings.py 설정 == |
| + | |
| + | === ALLOWED_HOSTS === |
| + | ALLOWED_HOSTS 안에 서버의 아이피를 기입했기 때문에 localhost로 동작하지 못하게 된다. 이건 서버가 아닌, 작업PC에서 시범사이트를 돌리는 데 문제가 된다. |
| + | |
| + | 이를 방지하기 위해 세팅파일을 구분하여 로컬호스트로 동작할 때는 다른 파일로 서버를 동작시켜주어야 한다. |
| + | |
| + | 사실, settings를 분리해줄 것 없이, ALLOWED_HOSTS = ['''<nowiki/>'도메인'<nowiki/>''', '''<nowiki/>'127.0.0.1''''] 처럼 도메인을 벡터로 추가해주면 로컬과 서버에서 모두 사용할 수 있다. |
| + | [[분류:6. 장고 웹서비스]] |