1. MariaDB 분리 필요성과 container 생성
DB 분리 필요성
django container에 DB가 연동되어 있으면 django container가 에러가 나거나 삭제되면 DB 데이터도 사라질 수 있으므로 MariaDB container를 따로 분리하는 작업을 한다. named Volume으로 설정할 것이기 때문에 MariaDB container가 문제가 생기더라도 데이터는 남아있게 될 것이다.
MariaDB 컨테이너 생성
DockerHub MariaDB 공식문서 참고
dockerHub에서 mariaDB를 검색하여 들어가보면, official image 페이지에서 어떤 설정을 해줘야하는지를 참고할 수 있다.
Dokcer에서 이 공식 image를 바탕으로 container를 만들 때 어떤 설정을 해야하는지 명령어 부분을 통해서 알 수 있다. 아래 그림에서 -v, -e라는 옵션을 주는 부분이 있는데 각 부분이 volume, env 설정을 하는 부분이다. 뒤에서 실제로 container를 만들면서 다뤄볼 것이다.
환경 설정 부분에서, 아래 그림에 표기한대로 필수적인 4가지 부분만 설정할 것이다. MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD 부분을 설정한다. MariaDB는 MySQL에서 상속받은 RDBMS이기 때문에 일단 지금은 MYSQL이라는 정보로 입력해도 무방하다.
마지막으로 caveats(경고) 부분에서 docker를 활용한 mariadb container 생성 시 데이터가 저장되는 기본 디렉토리 정보를 알려준다. 기본으로 설정되어있는 /var/lib/mysql 부분으로 volume을 설정할 것이다.
mariaDB Container 생성
이름은 mariadb, image는 mariadb:10.5 버전으로 지정한다. 만약 :latest로 지정한다면 계속해서 최신 버전을 참조하게 된다. 여기서는 최근 버전 중 안정화된 버전을 선택했다.
volumes 페이지에서 database-local 이라는 volume을 만들고 mariaDB container에 매핑해준다.
network도 기존 nginx, django에 포함되도록 설정해준다.
마지막으로 환경변수는 위에서 살펴본 4가지 값을 지정한다. root와 user에 대해서 나중에 설정할 값들로 미리 지정해놓는다.
2. DB 환경설정 추가, 개발-배포 환경 분리
django container가 분리된 mariaDB의 container를 바라볼 수 있도록 환경설정을 변경해준다. 원래 개발 환경에서는 localDB를 바라봤으나 이 부분은 놔두고 배포 환경에서 mariaDB를 참조하도록 변경하기 위해 settings directory를 만들고 아래처럼 코드들을 수정한다.
1. pragmatic/settings
pragmatic/settings 라는 python 패키지 생성 후 settings.py를 옮긴다. 이 파일을 base.py로 이름을 변경하고, deploy.py, local.py라는 파일로 복사하여 설정파일을 분리한다.
2. local.py, deploy.py 작성
base.py의 내용을 복사해와서, env등 일부 설정부분만 남기고 나머지는 제거한다. 그리고 아래 코드에서 '##여기' 라고 표시된 부분들을 수정한다.
맨 아래 DATABASES 정보는 위 주석으로된 링크에 들어가서 양식을 복사해올 수 있다. NAME, USER 등은 임의로 설정하는 값이고 상기 mariaDB container를 만들 때 환경변수로 넣어준 값이다. 또한 HOST는 연결할 mariaDB의 container 이름으로 설정해주어야한다. PORT는 mariaDB의 기본 port이다.
아래 코드는 deploy.py의 코드이므로 DEBUG = False 옵션을 주었다. local.py에서는 True로 주면 된다.
from .base import * ##여기
# Build paths inside the project like this: BASE_DIR / 'subdir'.
from django.urls import reverse_lazy
# Take environment variables from .env file
environ.Env.read_env(os.path.join(BASE_DIR, '.env'))
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = env('SECRET_KEY')
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = False ##여기
ALLOWED_HOSTS = ['*']
# Database
# https://docs.djangoproject.com/en/4.0/ref/settings/#databases
DATABASES = { ##여기
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'django',
'USER': 'django',
'PASSWORD': 'password1234',
'HOST': 'mariadb',
'PORT': '3306'
}
}
그리고 local.py에서는 local 환경에서는 sqlite3에 접근하도록 아래처럼 기존 값을 넣어준다. 이 DATABASES 내용은 굳이 base.py에는 있을 필요가 없다.
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
python과 mysql이 연결될 수 있도록 해주는 mysqlclient 라이브러리를 설치한다. 나중에 local에서 실행이 할 수 있으므로 로컬에서도 'pip install mysqlclient'로 라이브러리를 설치해준다.
3. base.py, manage.py 수정
pragmatic 패키지에서 settings 패키지로 한 단계 내려왔으므로 base.py에서 BASE_DIR 부분에 .parent를 하나 더 달아준다.
BASE_DIR = Path(__file__).resolve().parent.parent.parent
manage.py에서 setdefault의 두번째 인자값을 'pragmatic.settings.local'로 변경해준다. 기존에는 settings.py만 있었으나, 이제 local, deploy가 추가되었으므로 어떤 설정파일을 local 테스트시에 사용할 것인지 매핑해주는 작업이다.
def main():
"""Run administrative tasks."""
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'pragmatic.settings.local')
4. 실행 및 github push
로컬에서 실행하여 문제가 없는지 확인한다. 그리고 변경된 내용을 github에 푸시한다!
3. MariaDB, Django container 연동 마무리
Dockerfile 변경
mariaDB와의 연동을 위해서 django image를 변경하고 다시 container로 배포해야한다. Dockerfile을 아래처럼 수정한다.
FROM python:3.9.0
WORKDIR /home/
RUN echo "testing"
RUN git clone https://github.com/CJ0823/inflearn_study_django_pinterest.git
WORKDIR /home/inflearn_study_django_pinterest/
RUN pip install -r requirements.txt
RUN pip install gunicorn
RUN pip install mysqlclient
RUN echo "SECRET_KEY=django-insecure-$ioa*(%5%p#1&c(as*nqzw7xpo(g8l6ovb_&d+x-+(-pdyo&z+" > .env
RUN echo yes | python manage.py collectstatic
EXPOSE 8000
CMD ["bash", "-c", "python manage.py migrate --settings=pragmatic.settings.deploy && gunicorn pragmatic.wsgi --env DJANGO_SETTINGS_MODULE=pragmatic.settings.deploy --bind 0.0.0.0:8000"]
RUN echo "testing"
도커가 기존에 생성된 image 파일을 캐싱하고 있기 때문에 git에 echo라는 의미없는 문구를 추가하여 docker가 캐시된 정보로 image를 생성하는 것이 아니라 새롭게 다시 빌드할 수 있도록 해준다.
RUN install mysqlclient
python과 mysql이 연결될 수 있도록 해주는 mysqlclient 라이브러리를 로컬과 마찬가지로 설치될 수 있도록 한다.
CMD ...
기존 python manage.py runserver를 이용하지 않는다. 배포 환경이기 때문에 bash 명령어를 사용한다. 그리고 기존에 따로 RUN으로 빠져있던 migrate 명령어도 배포 환경이므로 이 CMD 구문으로 들어오고, --settings 옵션으로 deploy 설정을 주었다. 즉 로컬 환경에서 migrate가 되는 것이 아니라 docker에 EXPOSE 8000으로 network 연결이 되고, mariadb 라는 환경설정을 이용해서 migrate를 하는 것이다. 마지막으로 gunicorn 명령어에서도 --settings 옵션을 deploy로 변경해준다
Django image 및 container 새로 생성
image를 새로 생성한다. django_image_test:4라는 이름으로 상기 작성한 Dockerfile을 바탕으로 만들어준다.
그리고 해당 image를 바탕으로 django_container_gunicorn이라는 이름의 container를 다시 만들어준다. 기존 container는 remove로 제거해도 된다. 생성 시에, 기존에 했던 대로 Volumes와 Network 설정은 동일하게 해준다.
다시 서버로 접속해보면, 새로운 DB에 매칭되어 데이터가 없는 것을 볼 수 있다. 이제 여기에 새롭게 데이터를 만들고 container를 삭제했다가 다시 만들더라도, 데이터가 남는 것도 확인해보자.
참조
1. 작정하고 장고! Django로 Pinterest 따라만들기 : 바닥부터 배포까지-박형석님 인프런 강의
