django로 웹서비스 배포하는 docker 이미지 만들기

강재민·2022년 5월 11일
2

Docker

목록 보기
6/7

Docker 설치


Python 설치


로컬 환경에서 django 웹서비스

mkdir python-django
cd python-django
python3 -m venv djangoapp					#django를 위한 가상환경 만들기
. djangoapp/bin/activate					#가상환경으로 접속
pip3 install Django							#django 설치
django-admin startproject mysite			#django 프레임워크로 웹서비스 만들기
ls											#mysite라는 디렉토리 생성확인
cd mysite
ls
vi mysite/settings.py
ALLOWED_HOSTS = ['*']						#이부분만 편집, 모든 호스트주소의 방문을 허용한다는 의미
python3 manage.py runserver 0.0.0.0:8000	#8000번 포트로 웹서비스 실행

django 웹서비스 결과


freeze

pip3 freeze > requirements.txt		#freeze를 이용해 패키지 목록 묶기
ls									#freeze된 파일 확인
cat requirements.txt

.dockerignore

vi .dockerignore
djangoapp/
Dockerfile
dockerignore

dockerfile 성공 CASE1

deactivate
cd ~/python-django
vi Dockerfile
FROM python:3.9-alpine
RUN pip3 install Django
WORKDIR /
RUN django-admin startproject mysite
WORKDIR /mysite/mysite/
RUN sed -i 's/ALLOWED_HOSTS = \[]/ALLOWED_HOSTS = \["*"]/g' settings.py
WORKDIR /mysite
EXPOSE 8000
CMD ["python3", "manage.py", "runserver", "0.0.0.0:8000"]
sed -i 's/ALLOWED_HOSTS = \[]/ALLOWED_HOSTS = \["*"]/g'
sed를 이용해서 치환하는 명령어이다. []기호는 정규화표현식에 사용되므로 앞에 \를 붙여서 문자로 변환해주어야 한다. 또한 ''기호도 이미 sed에서 사용되고 있으므로 ""기호로 해주어야 정상적으로 치환이 가능하다.

dockerfile 성공 CASE2

deactivate
cd ~/python-django
vi Dockerfile
FROM python:3.9-alpine
RUN apk add gcc musl-dev

COPY . /app
WORKDIR /app
RUN python3 -m venv venv && . venv/bin/activate
RUN pip3 install -r requirements.txt

WORKDIR /app/mysite
CMD ["python3", "manage.py", "runserver", "0.0.0.0:8000"]
EXPOSE 8000
RUN apk add gcc musl-dev
gcc 패키지를 설치해주어야 나중에 requirements.txt파일을 읽어서 파이썬 패키지들을 설치할 때 에러가 나지 않는다. 이유는 몇몇의 파이썬 패키지들이 gcc를 참조하고 있기 때문이다.

이미지 빌드 및 실행

docker build -t pyhello:django .
docker ps -a
docker run -p 8000:8000 -d pyhello:django		#8000번 포트를 직접 연결해주어야 열린다.. 이것때문에 엄청 애먹었다.

django 웹서비스 결과


dockerfile 결과 비교

CASE1CASE2
이미지 크기89.2MB233MB

생각해볼 문제

물론 결과적으로 CASE1의 방식이 이미지 빌드하는 속도면에서나 만들어진 이미지의 데이터 용량면에서나 우수한 결과를 보여주었다. 하지만 CI/CD 관점에서는 CASE1의 접근 방식은 그닥 좋지 못하다. 왜냐하면 CASE1의 방식은 sed 명령어를 이용해서 개발자가 보내준 파일을 본인이 수정했기 때문이다.

CASE2의 방식을 따른다면 개발자가 빌드한 정보 그대로 도커이미지를 만들려고 했기 때문에 결과적으로 옳은 방식이 된다. 물론 CASE2의 방식에서 내가 임의로 apk 명령어를 활용해 추가적인 작업을 해주었지만 이는 이미지 빌드 과정에서의 오류를 해결하기 위해 추가한 작업이므로 근본적인 목적이 다르다.

0개의 댓글