[Docker]초짜의 삽질기 리뷰 1 (feat. Django Dockerizing)

Django Dockerizing 시리즈

https://leffept.tistory.com/330

[Django]Docker-compose로 Django 환경 구축하기 1 - Django

 

길고도 길었던 Django 프로젝트 환경을 Dockerizing 하는 시리즈가 끝이 났습니다. 이 시리즈를 시작하기 전에는 저는 도커에 대해 아무것도 모르는 상태였습니다. 그저 단순히 주변에서 "도커 너무 좋다, 편하다", "한번 써봐", "요즘에는 도커가 필수지" 라는 이야기는 수도 없이 들었지만 이에 대한 공감은 전혀 하지 못하고 있었습니다. 

 

우연히 기회가 되어 현업에서 서비스 되고 있는 프로젝트를 도커를 이용해 개발환경을 구축하는 업무를 진행하게 되었습니다.

도커가 뭐야? 라고 외치던 제가 개발환경 구축을 완료하기까지 어려웠던 점은 무엇인지, 도커가 진짜 편리한지?, 지금은 어떠한 생각을 갖고있는지 등을 다뤄보는 시간을 가져볼까 합니다. 

 

도커를 접하다

처음 도커를 접하였을때는 도커를 통해서 대체 뭘 해야하는지, 이걸로 무엇을 할 수 있는지, 그토록 사람들이 열광하는 이유는 무엇인지에 대한 궁금증이 가장 컸습니다. 현재 제가 다니고 있는 회사에서는 VM 환경에서 개발을 진행하기 때문에 도커와 VM은 거의 똑같은거 아닌가? 하는 생각이 먼저 들었습니다. 많은 시간을 공부하고 검색하면서 내린 결론은 다음과 같았습니다.

 

개발환경의 획일화

네 그렇습니다, 도커는 어느기기에서든 항상 동일한 환경을 제공해주는 것이 그 목적입니다. VM의 경우 환경을 새롭게 구성하거나 변경해야할 경우 이미지 자체를 주고받거나, 개개인이 설정을 바꿔주는 방식을 주로 이용합니다. 또한, 개발을 진행하다보면 새롭게 라이브러리를 설치해야하는경우 역시 생기기 마련입니다. 이렇게 시간이 지남에 따라 개개인의 VM 서버들은 동일한 상태를 유지할 수 없게 됩니다. 따라서, 새로운 인원이 들어올 경우엔 환경설정을 처음부터 다시 해야하는 수고가 들게됩니다.

 

도커는 이러한 환경문제에서 정말 완벽하게 벗어날 수 있습니다.

도커의 특성상 같은 image를 빌드하면 항상 동일한 환경이라는 것을 보장받을 수 있기 때문에 이런 것이 가능합니다. (도커 컨테이너의 구조에 대해서는 따로 다루지 않겠습니다.) 즉, 환경구성에 드는 비용을 정말 극적으로 줄일 수 있다고 생각합니다.

VM에 비해 가벼운 Docker 컨테이너

두번째 특징은 VM 이미지에 비해 컨테이너는 상당히 가볍다는 것입니다. 어느정도의 규모가 있는 프로젝트의 경우 VM 이미지의 크기는 보통 수십기가에 달합니다. 이렇게 거대한 용량을 전송하는데 오랜 시간이 든다면 비효율적이겠죠?

도커는 Dockerfile, docker-compose.yml 이라는 단 2개의 파일만으로 VM과 같은환경을 동일하게 구성할 수 있습니다.

 

따라서 개발자들은 이 파일을 가지고 자신의 로컬 PC에서 그저 빌드만 한번 진행해주면 개발환경을 구축할 수 있습니다. 또한, 한번 빌드된 이미지의 경우 자신의 컴퓨터에 cache 되기 때문에 추후에 빌드하는 시간 역시 단축할 수 있습니다.

만약 환경을 바꿔야 하는 상황이 생겼다고 가정해봅시다. 이 때 개발자들은 단순히 변경된 dockerfile을 재빌드 하는 것만으로 바뀐 환경을 적용할 수 있습니다. (이렇게 구성된 환경역시 모두 동일한 상태를 유지합니다)

수십기가의 이미지를 주고받는 것에서 단순히 파일을 빌드하기만 하면 되니 굉장히 편리하지 않나요?

 

직접 환경을 구축해보니..

자, 지금까지의 이야기를 종합해보면 "도커를 이용하면 얻는 것이 너무나도 많다" 로 말할 수 있습니다. 이제부터는 제가 환경을 구축하며 느낀 경험을 공유해보겠습니다.

 

그래서 대체 어떻게 시작해야 되는데 ?

도커로 환경을 구성할 때 첫번째로 든 생각은 대체 어떻게 컨테이너를 구성해야 하는거지? 스택별로 컨테이너를 분리해야 하나? 였습니다. 제가 맡고있는 서비스는 Django 와 Vue를 메인 스택으로 하여 Websocket, RabbitMQ, Redis, Postgres, Celery와 같은 스택으로 구성되어 있습니다.

기존에는 이 스택들을 VM이라는 환경에 전부 설치하였기 때문에 위와 같은 고민을 할 필요가 없었습니다. 이것에 대한 해답을 내리는 데까지는 생각보다 오랜 시간이 들었습니다.

 

꽤 많은 시간을 들여 생각하고 컨테이너를 지웠다 생성하기를 수십번 반복하면서 하나의 결론에 도달하게 되었습니다. 스택별로 컨테이너를 나누자. 이 결론은 도커 컨테이너의 원칙이라고도 할 수 있습니다.

1. 각 컨테이너는 하나의 서비스를 제공해야한다. (MSA)
2. 컨테이너는 항상 포그라운드로 동작되어야한다.
   (그렇지 않으면 컨테이너는 작업을 실행하고 종료됨)
3. 컨테이너는 언제나 생성과 삭제가 가능해야한다. 

도커의 원칙이라고 언급을 하였는데 저는 이에 따라 각 스택별로 컨테이너를 나누어 보기 시작합니다. 

 

좋아, 호기롭게 시작은 했다!!

컨테이너의 큰 구조를 잡았으니 "스택별로 컨테이너를 분리해서 띄우고 컨테이너끼리 연결하면 되겠다!" 라는 생각과 함께 순조롭게 진행이 되는 상상과 함께 저는 불타올랐습니다. 하지만 이 상상의 불씨가 꺼지는데는 얼마 걸리지 않았습니다.

Docker hub에는 상당수의 official 이미지들이 존재합니다. 이 수많은 이미지들 중 과연 저는 무엇을 골랐을까요?

저는 구글 검색을 통해 프로젝트를 dockerizing하는 과정을 많이 찾아보았습니다. 하지만, 찾아볼 때마다 대부분의 자료에는 장고를 사용하니 이미지는 파이썬, Postgres를 사용하니 이미지는 Postgres. 대부분은 이런식 이었습니다.

물론 위의 내용이 틀리다는 것이 아닙니다. 하지만 저희 서비스는 Ubuntu 환경에서 이루어져 있었기 때문에 이와 동일하게 구성할 필요가 있었습니다. 그렇게 저는 Ubuntu 공식 이미지를 선택해 컨테이너를 띄우기 시작합니다..

 

잘못된 선택이었을까요...?

Ubuntu 이미지를 선택하고 컨테이너를 띄웠을 때는 파이썬도, 유틸리티도, 자주 사용하는 그 어떤 것도 설치가 되어있지 않았습니다. 그렇게 저는 가장 중요한 파이썬을 설치하기로 합니다. 하지만 이 과정에서 상당히 험난한 여정이 시작됩니다.

무슨 이유에서인지 파이썬이 설치가 잘 되지 않습니다. 설상가상 끝에 먼저 깔아야할 패키지들이 있다는 것을 알게되고 Dockerfile에 이 과정을 명시합니다. 또한 파이썬의 Default version을 선택해주는 부분 역시 전부 Dockerfile에 명시해줘야 했습니다. 이렇게 빈 Ubuntu에 환경을 세팅하는 과정을 반복한 것이지요.

 

그렇다면 이런 생각이 들수도 있습니다. 그냥 파이썬이 깔린 이미지를 사용하면 되는거 아닌가? 

네, 처음 프로젝트를 시작하거나 공부가 목적인 경우라면 그렇게 해도 된다고 생각합니다. 하지만, 저의 목적은 기존에 사용하던 VM 개발환경을 그대로 도커 컨테이너 환경으로 옮기는 것이 목적이었기 때문에 Ubuntu 이미지를 선택하게 된 것입니다. 갑작스런 환경의 변화는 항상 모든 문제를 초래할 수 있으니까요.

 

그렇게 컨테이너를 가동하고 쉘에 접속해 패키지를 설치해보고 해당 명령어를 Dockerfile에 명시해주고 하는 과정을 정말 수도 없이 많이 반복하였습니다. 그래도 여러번 하다보니 노하우도 생기고 결국에는 완성이 되더군요..

이렇게 저는 메인 스택인 Django를 위한 저만의 image를 만들어 냈습니다. 이제 남은건 Websocket, Postgres, RabbitMQ....등...

Ubuntu 환경을 구성하면서 이미 지칠대로 지쳤던 저는 과연 이게 맞는 방법인가? 잘못된 시작은 아니었나 하는 생각을 하게 됩니다.

다들 힘든일을 겪고나면 빛이 찾아온다고 합니다. 정말로 지금부터는 그 빛이 드디어 찾아오게 됩니다!!

 

이야기가 너무 길어져 다음편에 이어서 작성해야 할 것 같습니다. 다음 이야기에도 흥미진진한 에피소드가 담겨 있으니 많이 기대해주세요!