본문 바로가기
공부 및 활동/heroku, django

Heroku Server 배포(django에서 Heroku서버 배포)

by KChang 2021. 10. 7.

heroku와 django EER 다이어그램

설계

 

1. Heroku Server 배포하도록 체크할 수 있다.

나의 헤로쿠 프로젝트 경로 : dongagd | Heroku

사진1

여기서 Deploy에 들어간다.

사진2

첫 실행시 이와 같이 되는데, Github과 연결하기 위해

Github을 클릭한다.

사진3

아마 repository를 적어라고 나올텐대 입력한 후, connect한다.

그리고, enable automatic deploy를 설정 해준다.

하단에 있는 Manual deploy -> (master) : deploy branch를 클릭한다.

이게 어떤 작업일까?🤔

: github master에 배포했을 때, 알아서 heroku 서버에 배포가 될 것이다. (자동 배포)

(github 저장소의 code를 Heroku에 배포하는 작업이다.)

완료되어 Environments에 추가됨

배포 완료

 

2. gdproject, django server 실행

1) django server 실행할 때, 기존 설정파일은 프로젝트 디렉터리 안에 있는 settings.py 파일을 참조하게 되어있다. (변하지 않는다.)

  • 디렉터리 구조가 만들어지면서, 그 안에 기본 사용될 settings.py 파일이 생긴다.(default)
  • manage.py runserver를 할 때, settings를 가져다가 웹 서버 초기 구성을 만들어준다.
  • settings.py
    • 초기화할 때 쓰이는 파일이다.(없으면 실행이 안된다.)
    • 환경변수, DB설정, 포트설정, 접근제어, Template은 어떻게 할 것인지, staticfiles, Language 설정 등이 들어있다.
    • 기본 설정은 내부(프로젝트 디렉터리 안에 있는) db, db.sqlite3 파일을 바라보고 있다.
    • 기본적으로는 파일형식의 local db를 사용하고 있다.
  • 현재 프로젝트에서는 서비스 규모가 크고, 사용자 데이터를 쌓으며 편하게 관리할 필요가 있어서 외부에 있는 DB Server를 사용한다.
  • 그래서 같은 디렉터리 안에 만들어진 설정파일이 있다. (settings_heroku.py)
    • settings_heroku_LI
    • 맨 윗줄에 from gdproject.settings import *이 되어 있다.
    • 기존에 로컬에서 쓰던 설정파일 그대로 쓰고 싶은데, DB 설정만 바꾸려고 한다.
    • 상용환경이니 DEBUG 옵션은 꺼야한다. (부가적인 목적)
    • 그러므로, gdproject 하위의 settings 모듈에 있는 모든 설정을 그대로 불러온다.
    • DEBUG랑 DATABASES 값을 덮어 씌운거다.
    • 결국, 이는 오버라이딩이다.
      • 가져와서 필요한 것만 바꿀 수 있어 편하다.
    • 이와 같이 하지 않았을 경우, settings.py 처럼 직접 다 작성했어야 했다.
  • 배포 환경에서는 서버를 settings_heroku.py 파일을 settings 옵션으로 줘서 실행시켜야한다.
    • python manage.py migrate --settings=gdproject.settings_heroku
    • 만약, heroku run python manage.py migrate로 할 시 settings.py를 기본으로 사용하므로 local db 쪽을 바라보게 된다.(sqlite3)
    • 현재 local db(sqlite3)는 없는 상태이기 때문에, db도 없는 상태에서 superuser를 만들고, table을 찾을 시 실패한다.
    • 아마, 작업 환경 디렉터리를 뒤져보면 db.sqlite3가 보이긴 할텐데, 배포할 때는 올라가지 않는다. (올리면 안된다. 내부db가 없기 때문)
  • makemigrations, migrate
    • makemigrations : 각 앱안에 migrations 폴더만 생성된다.
      • models 안에 정의된 모델 클래스 정보가 변경되었을 때 변경점을 기록하기 위해 사용한다.(migrations 디렉터리가 생긴다.)
    • migrate : db.sqlite3등 파일들이 새로 생긴다.
      • migrate가 실행되면 그 파일들을 기준으로 DB에 반영한다.
      • migrations 디렉터리의 기록을 기준 삼아, 현재 settings에서 바라보기로 했던 db가 어떤 상태인지 확인하고 동기화 시켜주는거다.
  • local db가 존재하지 않은 상태로도 server가 잘돌아간다.
    • Heroku 컨테이너가 Procfile보고 wsgi.py 통해서 웹서버 실행시켜준다.
    • wsgi.py에서는 os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'gdproject.settings_heroku')
      • 설정파일이 settings_heroku 바라보고 있다.
      • 배포된 버전의 웹 서버 프로세스는 원격 DB를 바라보는 채로 서버 프로세스가 작동하게된다.
      • 그러므로, 배포된 버전의 서버구동은 이상이 없다.
      • 이와중에, heroku run으로 별도의 마이그레이션 작업을 한다면? local db는 존재하지 않고 유저테이블에 유저는 추가하고 싶고, 커맨드로 실행되던 장고 스크립트는 ~ 아무튼 되지 안된다.
  • python manage.py collectstatic --settings=gdproject.settings_heroku : 서버구동 전 CI로 collectstatic 해준다. (static 파일 추가)

 

 

 

참고 사항

  • heroku run으로 넘길경우, heroku 인스턴스가 실행중이거나 바라보고 있는 DB 서버가 갖고 있는 설정파일에 따라서 다르게 반영될 수 있어서 이상적인 방법이 아니다.
  • 보통 DB 마이그레이션은 Github Action으로 CI걸어놓고 진행하거나 Master 배포전에 DB migrate하고 배포한다.

댓글