한 프로젝트에 배포용과 개발용이 나누어지고 개발용에서는 나와 다른 팀원이 함게 로컬에서 작업을 한다고 가정하자. 그럼 만약 각각의 로컬의 db를 사용하면, 비밀번호가 다 다를텐데, 이걸 매번 git에 올리면 complict가 난다. 이걸 해결하기 위해서 세팅을 각각 다르게 사용한다
위에서 언급했지만 로컬에서 개발하는 환경과 프로젝트 배포에서 사용하는 환경이 저마다 제각각이다. (ex.로컬의 경우 Debug = True
, 배포시Debug = False
) Django 프로젝트의 환경을 분리하여 사용하면 이런 부분을 편하게 관리할 수 있다.
처음 프로젝트를 생성하면 아래와 같은 구조가 된다
내가만든프로젝트/
manage.py
app 파일
내가만든프로젝트/
settings.py
프로젝트명/프로젝트명/settings.py
순인데 settings.py
대신 아래와 같은 구조로 변경해주자
내가만든프로젝트/
manage.py
app 파일
내가만든프로젝트/
__init__.py
base.py #기본적용
development.py # 개발용 셋팅. base.py를 읽어들인다
production.py # 배포용 셋팅. base.py를 읽어들인다
기존의 setting.py는 settings라는 파일이 생겼고 안에 설정이 되었으므로 삭제하면 된다
__init__.py
base.py
: settings.py를 그대로 복사해서 이름만 알아보기 쉽게 설정해주었다. 이 안에서 설정이 배포, 개발 설정에 따라 바뀌는것들은 남기지 말고 삭제하면 됨(삭제한 내용은 바로 development와 production에서 작성될꺼니까!)
development.py
: 개발시 로컬에서 사용할 내용을 담아두었다
production.py
: 배포시 서버에서 사용할 내용을 담아두었다
서버를 실행시키면 settings -> base.py ->
production
ordevelopment
순으로 읽게 설정!
이름은 그냥 아무렇게나 알아보기 쉽게 적자
from .base import * #base를 import한다
DEBUG = True # 에러메세지 확인을 위해 true로 설정
ALLOWED_HOSTS =
DATABASES =
여기에 로컬에서 개발할때 적용할 ALLOWED_HOSTS
, DATABASES
등을 넣어주자
from .base import * #base를 import한다
DEBUG = False # 에러메세지 확인안되게 False로 설정
ALLOWED_HOSTS =
DATABASES =
회사에서 실제 배포할때 사용하는 설정들을 넣어주면 된다. )내 데이터베이스로 배포하는거 아닐테니까) Debug = False
하는거 잊지 않기!
2,3에서 우리는 각각의 환경에 필요한 내용들을 분리해서 설정해두었다. 그럼 base에서 내가 2,3에 적은 내용들을 지워주면 된다.
🙄주의할점🙄
settings.py 에 기본으로 설정되는 BASE_DIR
이라는 값이 있다. 프로젝트 파일 경로를 지정할 때 사용하는데
settings.py
는 프로젝트/프로젝트/settings.py
였는데,프로젝트/프로젝트/settings/base.py
한 단계 더 하위에 존재하게 되었다. 따라서 BASE_DIR
를 수정해줘야한다.
BASE_DIR = Path(__file__).resolve().parent.parent
라고 되어있는걸
BASE_DIR = Path(__file__).resolve().parent.parent.parent
.parent
를 추가해주자
이건
os.path.dirname()
로 하는 방법도 있다는데, 나는 이해를 잘 못해서 그냥parent
를 넣어주었다
이렇게 각각 나눠진 development.py 와 production.py을 shell과 runserver 명령을 이용하기 위해서는 --settings 사용해야한다
$ python manage.py shell --settings=myproject.settings.development
$ python manage.py runserver --settings=myproject.settings.development
그런데 매번 하기 귀찮으니
$ export DJANGO_SETTINGS_MODULE=myproject.settings.development
$ python manage.py runserver
로 설정을 지정해주거나
direnv
등의 환경변수를 지정하는 방법을 통해 적용하는 방법이있다
위코드에서 miniconda를 통해 가상환경을 만났다. 만일 좀더 세분화해서 각 디렉토리별로 환경을 설정해줘야한다면? 폴더별로 관리가 필요한순간,
direnv
가 우리를 도와주러 나타난다
이름 그대로 폴더별로 환경을 관리해주는 도구이다. direnv로 설정을 해 놓으면 폴더 이동을 할 때마다 자동으로 설정해놓은 환경변수나 원하는 런타임 버전 지정 등을 알아서 할 수 있다.
Home Brew가 있다면
$ brew install direnv
#잘 설치 됬는지 확인
$ direnv version
그리고 각 쉘의 설정파일에 direnv관련 내용을 추가해준다(다른버전은 공식사이트 확인)
# vi ~/.zshrc에 아래 내용 추가
eval "$(direnv hook zsh)"
그리고 쉘을 다시실행하면 위 설정이 적용이 됨!(안끄면 적용안됨..)
간단하다!(진짜로)
내가 ncnc라는 디렉토리의 환경설정을 한다고 치면 ncnc디렉토리에 들어가서
#파일 생성
$ touch .envrc
#파일에 들어가기
$ vi .envrc
direnv가 읽을수있는 .envrc
를 만들고 들어가면된다.(touch단계에서 에러가 뜨는경우도 있으나 나는 바로 들어가졌다.에러가 떠도 그냥 $ direnv allow
쳐주면 인식됨)
여기서 원하는 내용 입력해주면 된다
나의 경우 settings/production.py가 아닌 settings/development.py가 자동으로 적용되게 하는 내용을 추가했다
#development.py가 적용되도록
export DJANGO_SETTINGS_MODULE=상위파일명.settings.development
DJANGO_SETTINGS_MODULE
라는걸 .envrc
에 추가했다. 그럼 이걸 적용시키기위해서
$ echo $DJANGO_SETTINGS_MODULE
라고 쳐주면된다.
그런데 환경을 변경하는거라서 .envrc
에 대한 내용을 바로 받아주지 않고 에러메세지를 띄울거다. 그래서 위의 내용을 치기전에
$ direnv allow
라고 먼저 변경내용을 받아들이겠다는 명령어를 쳐주면 된다.
디렉토리에 접근하면
자동으로 로딩을 해준다~
반대로 환경설정에 포함되지 않는 디렉토리만 나가면 아래와 같이 적용되던 내용이 적용이 안되는걸 확인 할 수 있다
👉이번 기업협업에서 settings관련해서 적용해보았는데, runserver 할때마다 --settings 명령어를 치는게 아니라 그냥 프로젝프 디렉토리에 들어가는순간 자동으로 환경이 구축이 되었다. 직접 사용해보면 바로 파악가능한데 너무나 신기했다! 왜 사용하는지 정말 몸으로 깨달은 순간~.~
터미널을 통해 작업하다보면 이유없이
DS_store
란 파일이 생성되어있다. git에서 공동으로 작업할때, 과연 이걸 어떻게 처리하는게 좋을까
Desktop Services Store
의 약자로 맥 os가 시스템에 접근할 때 생기는 해당폴더에 대한 메타데이터를 저장하는 파일이다.
맥 환경에서만 생기기 때문에 파일을 공유하는 과정(git)에서는 이 파일도 공유될 가능성이 있으므로 사전에 삭제하거나 생성을 방지하는 방법을 추천한다
터미널에서 사용하는 방법은 간단하다!
sudo find / -type f -name '\.DS_Store' -print -delete
defaults write com.apple.desktopservices DSDontWriteNetworkStores ture
생성방지를 ture
로 했으니
false
를 하면 다시 생성되게 할 수 있음