Django에서 초기화 과정 살펴보기

나는 장고로 처음 웹을 배워서 장고로 먼저 찾아보았는데, 웹 프레임워크에서 보편적인 개념이라고 해서 정리해보았다. 

---

초기화 시점 

장고의 초기화는 서버가 시작될 때 이루어진다. 

runserver 기준 서버의 시작 

• runserver를 실행하면 서버가 시작됨 
• 이 명령어를 실행하면 Django는 내장 웹 서버를 실행하여 클라이언트의 HTTP 요청을 받아 처리한다. 

python manage.py runserver

 

gunicorn(WSGI 서버) 기준 서버의 시작 

• gunicorn은 Django 애플리케이션을 실행하는 실제 서버 역할을 한다. Gunicorn은 HTTP 요청을 받아 Django 어플리케이션에 전달하고, 그 응답을 클라이언트에 반환한다. 
• gunicorn 명령어는 다음과 같다. 

gunicorn myproject.wsgi:application

이 명령어를 실행하면 wsgi.py 파일에 정의된 application 객체를 통해 Django 애플리케이션이 실행된다. 

gunicorn을 실행하는 시점에 실제로 서버가 시작되며, 이때 Django 애플리케이션이 로드되고 요청을 처리할 준비가 된다. 

---

그럼 이런 상황에서 Docker는 무엇인가... 

우리 팀 프로젝트는 도커를 활용해서 컨테이너를 띄우고, 서버를 시작하는 걸로 알고 있는데 헷갈려서 찾아보았다. 

도커를 사용하면 애플리케이션을 실행할 환경을 표준화하고 격리할 수 있다. 즉, 도커 컨테이너 내에서 Django 애플리케이션을 실행할 수 있게 도와주는 것이다. Dockerfile이나 docker-compose.yml 파일에 정의된 명령어가 실행된다. 그래서 우리 팀의 docker-compose.yml 파일을 찾아보았다. 일부 발췌. 

  web:
                image: "${DOCKERHUB_IMAGE}:${IMAGE_TAG}"
                container_name: ********_web
                restart: always
                env_file: .env.prod
                environment:
                  DJANGO_SETTINGS_MODULE: config.settings.prod
                  DJANGO_SECRET_KEY: ${DJANGO_SECRET_KEY}
                  SECRET_KEY: ${DJANGO_SECRET_KEY}
                volumes:
                  - ./staticfiles:/********_app/staticfiles
                  - ./logs:/********_app/logs
                  - app_data:/data
                networks: [appnet]
                expose:
                  - "8000"
                depends_on:
                  db:
                    condition: service_healthy
                command: >
                  sh -lc "
                  gunicorn config.wsgi:application
                  --bind 0.0.0.0:8000
                  --access-logfile /********_app/logs/gunicorn_access.log
                  --error-logfile /********_app/logs/gunicorn_error.log
                  --log-level debug
                  "

우리 팀은 github workflow 파일을 이용하여 ci-cd를 관리하고 있는데, 간단히 말하면 CI/CD 과정은 다음과 같다. 

개발자가 코드를 푸시하면, Docker 이미지를 빌드하고, 자동화된 테스트를 실행하여 코드가 잘 작동하는지 확인한다. 테스트가 성공하면, CI/CD 파이프라인은 Docker 이미지를 저장소에 푸시하고, 배포 서버로 전달한다. 배포서버는 새로운 Docker 이미지를 받고, 이를 기반으로 서버를 재실행한다. 최종적으로 새로운 코드가 운영환경에서 실행되며, 사용자에게 최신 애플리케이션이 제공된다. 

따라서 도커에 띄워져있는 기준에서는 서버 재실행 시점이 장고가 초기화를 진행하는 시점일 것이다. 

---

초기화의 공통적인 기능 

앱 설정 로드 

대부분의 프레임워크에서 초기화 과정에서 애플리케이션의 설정 파일을 로드하여 서버나 애플리케이션이 동작할 수 있도록한다. 

미들 웨어 초기화 

모든 웹 프레임워크에서는 미들웨어를 초기화하여, 요청과 응답을 처리할 수 있는 환경을 준비한다. 특히 요청을 처리하는 단계에서 중요한 역할을 한다. 

라우팅 설정

웹 어플리케이션에서 요청을 처리할 라우터를 설정하는 과정은 초기화의 중요한 부분이다. 

데이터베이스 연결 

대부분의 웹 프레임워크에서는 애플리케이션이 시작될 때 데이터베이스 연결을 초기화하여 애플리케이션에서 데이터를 처리할 준비를 한다. 

---

장고에서의 초기화 

앱 로딩	INSTALLED_APPS에 정의된 앱을 로드하여 설정을 초기화한다.
데이터베이스 연결	데이터베이스 설정을 읽고, 연결을 초기화한다.
미들웨어 처리	미들웨어가 요청을 처리하고, 응답을 수정할 준비를 한다.
시그널 연결	ready() 메서드에서 시그널을 연결한다.
뷰와 URL 처리	URL 라우팅을 통해 뷰와 연결되는 URL들을 초기화한다.

 

---

도커 단의 초기화와 장고 단의 초기화 차이 

도커는 애플리케이션을 실행할 환경을 설정하고, 서비스를 실행하는 역할이다. 애플리케이션 초기화는 애플리케이션 자체 내에서 처리된다. 따라서 도커가 더 넓은 개념임을 인지하고 있으면 된다.