<Docker(고래)는 Golang(고퍼, 땅다람쥐)으로 만들어졌습니다. 그리고 리눅스(펭귄) 배포에 가장 특화되어있죠>

Docker 와 컨테이너

일단 Docker 가 뭔지 한 문장으로 정의 내리기에 앞서, 가상머신 이야기를 먼저 해봅시다. 가상머신이란 말그대로 물리 머신위에 또다른 가상의 머신을 실행시키는 개념입니다. 예를 들어서, 현재 제가 이 글을 쓰고 있는 맥북은 MacOS로 돌아가고 있지만, 맥북에서도 Windows를 실행시키고자 VMware나 Paralles 같은 프로그램을 이용할 수 있습니다. 가상머신을 사용하는 이유는 여러가지가 있습니다. 흔히 대학생들이 맥북을 써서 겪는 조별과제의 고충 때문일수도 있겠거니 싶지만, 보통은 하나의 머신에서 여러 가상머신을 생성하여 사용하는 것이 가능하기 때문입니다. 예를 들어 AWS나 구글 클라우드 같은 클라우드 제공 업체들이 사용하는 컴퓨팅 서비스는 보통 *베어메탈 형식으로 제공되지 않습니다. 하나의 머신위에서 여러 가상 호스트들을 프로비저닝(할당)하여 제공하는 형태가 됩니다. 컴퓨팅 리소스를 하나의 머신위에서 분할하여 사용가능하다는 것은 효율적인 운영을 가능케하죠.

*베어메탈: 물리 머신(컴퓨터) 하나를 통채로 대여하여 사용하는 방식을 말합니다.

*프로비저닝: 클라우드내에서 어떤 특정 리소스(CPU, 메모리, 스토리지 등)을 새로 할당하는 과정을 말합니다.

가상머신이 가지는 문제점

문제는 가상머신은 무겁다는 것입니다. 가상머신은 하이퍼바이저(Hypervisor) 위에서 또다른 OS를 띄우는 식입니다. 이렇게 되면 호스트 머신에서의 OS를 통해 스케쥴링이 돌아가는데 그 위의 가상머신에서도 또 스케쥴링을 하는 형태가 됩니다. 따라서 호스트 머신의 성능을 최대한으로 활용할 수도 없고, 그만큼 리소스도 많이 잡아먹고 무겁습니다. 이렇다 보니, 가상머신 방식의 프로비저닝은 성능의 문제와, 처음 가상머신을 실행시키는 실행 시간이 오래걸리는 문제가 발생합니다.

컨테이너

이러한 가상머신을 대체할 새로운 개념이 나오게되는데 바로, '컨테이너'라는 개념입니다. 기존 가상머신과의 가장 큰 차이점은 바로 하이퍼바이저(Hypervisor)의 유무입니다. 컨테이너는 하이퍼바이저 없이 호스트 OS의 커널과 직접 통신하여 새로운 컨테이너를 하나 띄우게 됩니다. 가상머신과의 차이점은 바로 여기서 비롯하는데, 컨테이너 하나 자체를 프로세스로 취급합니다. 하나의 OS위에서 띄워지는 여러 컨테이너들은 동일한 하나의 커널을 공유하여 돌아가게 됩니다.

그러면 여기서 드는 한가지 의문은 하이퍼바이저가 없다면, 서로 다른 OS에서는 어떻게 컨테이너를 구동하는가에 대한 의문입니다. (e.g 윈도우에서 Linux를 사용하는 경우) 이 내용은 이번 포스트에서 다루기에는 조금 깊이 있는 내용이니 다음 포스트에서 다루겠습니다.

자 그런데 여기서 용어와 개념을 다시 한번 정리할 필요가 있습니다. 사실 지금까지 말한 가상머신은 정확히 말하면 '하드웨어 수준의 가상화'를 말합니다. 그리고 컨테이너라는 개념은 사실 'OS 수준의 가상화' 입니다. 지금까지 일컬은 가상머신은 '하드웨어 수준의' 라는 수식어를 생략하고 언급하였습니다. 원래 컨테이너라는 개념 역시 결국 가상화 방식의 일종이기 때문에, 컨테이너 역시 하나의 가상머신이라고 부를 수는 있으나, 혼동을 피하기 위해 여기서 칭하는 가상머신은 '하드웨어 수준의 가상화'로 명명합니다.

Docker의 등장

Docker의 모체는 moby 프로젝트로 부터 출발합니다. 그리고 moby 프로젝트는 containerd라는 프로젝트로부터 기원합니다. 여하튼, Docker의 시작은 2013년의 셰르비아의 어느 소프트웨어 회사에서 시작된 오픈소스 프로젝트로 부터 출발합니다. Docker는 앞의 두 프로젝트를 포함하고 있습니다. 실제로 containerd는 Docker의 런타임을 구성하는 컴포넌트 중 일부로 존재합니다.

사실 Docker는 쉽게 말해 그냥 앞서 말한 컨테이너라는 개념을 조금더 구체화하여 쓰기 쉽게 만든 하나의 인터페이스일 뿐입니다. 알고보면 엄청나게 혁신적인 기술은 아니지만, 사용성과 그것을 통해 얻는 장점들이 많기에 오늘날 Docker 생태계가 구축될 수 있었습니다.

Docker의 기술 기반

Docker의 런타임 구성은 크게 4가지로 나뉩니다. Docker Daemon, Docker Client, Docker Registry 그리고 Docker Objects(Image, Container, Networks, Volume...) 입니다. 여기서 Docker Client와 Docker Daemon을 쉽게 관리해주는 툴인 Docker Desktop이라는 것도 존재합니다.

LXC

태초에 Docker가 있기전에 LXC(Linux Container)라는 것이 먼저 존재했습니다. 앞서 언급했듯이 컨테이너라는 기술은 이미 존재했습니다. 그 시초격 즈음 되는 것중 하나가 바로 LXC이고(LXC이외에도 여러가지 컨테이너 기술이 존재합니다.), 컨테이너라는 개념을 구현한 기술들 중 하나가 바로 LXC 입니다. 그리고 Docker는 사실 이 리눅스 컨테이너를 관리하기 위한 도구라고 볼 수 있습니다. 물론 극 초창기에나 그랬었고 이후에는 Docker 자체 컨테이너 역시 지원을 합니다. 사실 Docker 가 아니어도 LXC를 관리하고 사용하는 것은 가능합니다. 하지만 Docker를 사용하는 것이 훨씬 더 편하기에 지금은 Docker 없이 컨테이너를 직접 다루기란 여간 불편한일이 아닐 것입니다.

Linux와 Docker

Docker는 리눅스에 최적화되어 있습니다. Docker를 LXC 컨테이너를 관리하기 위한 상위 인터페이스 개념쯤으로 이해할 수 있는데, 물론 리눅스 상에서만 유효한 이야기 입니다. LXC가 아니더라도 후술할 윈도우 기반 컨테이너나 심지어 MacOS 컨테이너도 가능합니다. 물론 그럼에도 불구하고 일반적으로 우리가 Docker를 사용한다고 하면 제일 많이 사용하는 컨테이너가 바로 리눅스 기반의 컨테이너일 것입니다.

Winodws와 Docker

윈도우즈 에서는 크게 리눅스 기반 컨테이너와 윈도우즈 기반 컨테이너 두가지를 사용할 수 있습니다. 리눅스 컨테이너의 경우 일반적으로 WSL을 기반으로 사용됩니다. WSL은 정확히 표현하면 리눅스 커널을 윈도우에 맞게 커스텀하여 사용하는 윈도우 전용 리눅스라고 할 수 있습니다.

위에서 설명하였듯, 실질적으로는 WSL의 컨테이너화 기술을 이용해 윈도우에서 Docker를 실행하는 것이 가능합니다. 이전처럼 가상머신을 별도로 설치할 필요가 없어졌습니다. 반대로 윈도우즈 기반 컨테이너를 사용한다면 얘기가 달라집니다. 호스트 OS와 동일한 윈도우즈 기반의 컨테이너를 사용하면 리눅스에서 Docker를 사용하는 것 처럼 윈도우즈에서도 이점을 그대로 얻을 수 있게됩니다.

물론 반드시 WSL을 사용해야하는 것은 아닙니다. WSL 대신 Hyper-V나 VirtualBox 같은 가상머신을 사용해도 됩니다. 다만 그만큼 실행속도와 성능은 WSL에 비해 좋지 않다는 것을 감수해야합니다.

컨테이너와 Docker를 쓰는 이유?

이쯤 되면 Docker를 왜 굳이 써서 다들 그렇게 배포하는가에 대한 의문은 아직 남아 있을 수 있습니다. 이를 논하기 위해서는 실제 소프트웨어 회사들이 어떻게 소프트웨어를 배포하고 공급하는가에 대해 알아볼 필요가 있습니다. 물론 여기서 말하는 소프트웨어 회사들은 대개 웹 기반의 서비스(Saas)를 제공하는 회사들을 보통 일컫는다고 봐야합니다.

보통 소프트웨어를 개발하고 실제 사용자들에게 전달하는 과정을 배포(Deployment)라고 합니다. 배포를 수행하는 방식은 여러가지가 있는데 가장 기본적인 방법은, 개발자가 직접 검수가 완료된 앱을 수작업으로 빌드하고 타겟 서버에서 배포환경을 설치하고 구동시키는 방식입니다. 여기서 더 나아가 개발자가 직접 배포하는 방식이 아닌 자동화된 방식의 배포를 지속적 배포(Continious Deployment)라고 합니다. 원래는 이러한 배포와 같은 과정은 본디 개발(Development)가 아닌 운영(Operation)의 영역에 가깝습니다. 그래서 이미 21세기 초반부터 현장의 소프트웨어 실무자들은 개발과 영역으로 나뉜 이 작업을 어떻게 하면 통합적으로 수행시킬 수 있을까를 고민했고, 그 결과 나오게 된 것이 바로 데브옵스(DevOps)라는 개념입니다.

여기서 컨테이너의 개념과 Docker를 사용하면 기존의 수작업을 통해 배포환경을 구축하던 작업들의 상당수를 아주 쉽게 코드로 관리할 수 있게 됩니다. 이는 Docker에서 제공하는 Dockerfile을 이용하면 가능해집니다.

Dockerfile을 통해 배포환경을 구성하면 한 가지 장점이 더 생깁니다. 로컬에서 작업하는 개발자는 프로덕션 환경과 동일한 가상의 스테이지를 구성할 수 있게됩니다. 흔히 프로덕션 환경과 개발 환경간의 아주 사소한 차이 하나 때문에 버그 재현이 안되거나, 원인 찾기가 어려운 경우가 종종 실제로 있습니다. 하지만, Docker를 기반으로 옮겨 간다면 이런 걱정을 할 필요가 없습니다. 왜냐하면 서로 같은 이미지로 동일한 컨테이너를 구동함으로써 동일한(Homogeneous) 배포 환경을 만들 수 있게됩니다.

그리고 사실 어떻게보면 가장 중요한 이유이기도 한 것이 바로 Docker는 쓰기가 쉽다는 것입니다. 실제로 후술 할 Docker의 사용 예시를 보면 알겠지만, docker라는 명령어를 통해서 직관적으로 모든 작업들을 한 번에 쉽게 수행하는 것이 가능합니다. Docker의 개념만 이해한다면, 이를 가지고 쓰는 것은 자유자재로 다룰 수 있죠.

대충 요약하면 Docker의 사용이유를 다음과 같이 요약가능합니다.

Stateless(상태를 가지지 않는)한 배포/운영 환경 구축 가능
DevOps 추세에 따른 지속적 배포(Continious Deployment)와 궁합이 잘맞음
개발 환경과 배포 환경을 동일한 런타임으로 구성이 가능, 다른 런타임으로 인한 잠재적 오류 최소화
기존 가상머신보다 리소스 사용이 훨씬 효율적
무엇보다도 가장 중요한 것은 간편하고 쓰기 쉽다!

Docker를 써봅시다

대충 이론적인 내용은 어느정도 길게 썼으니 이제는 실제로 Docker를 사용해 봅시다. Docker를 설치하였다고 가정해보고 실제로 사용하는 예시를 몇가지 들어보겠습니다. 그냥 아무런 목적 없이 Docker 이미지를 빌드하는 건 별로 도움이 되지 않으니, 실제로 저의 블로그 어드민(React.js)을 배포하는 과정을 예로 들어보겠습니다.

먼저 다음과 같은 Dockerfile을 먼저 준비합니다. Dockerfile은 Docker 이미지의 환경을 어떻게 구성할 것인가에 대한 정의를 내리는 역할을 가집니다.

FROM node:alpine

WORKDIR /usr/app

# Copy all files
COPY ./ ./

RUN npm install
RUN npm build

# Expose the listening port
EXPOSE 3000

FROM nginx:latest

# Run container as non-root (unprivileged) user
# The "node" user is provided in the Node.js Alpine base image
USER node

# Launch app with PM2
CMD ["pm2-runtime", "start", "npm start"]

여기서 보여지는 Dockerfile의 경우, 각 명령어 내용이 어떤 의미를 가지는지 차근히 설명해보겠습니다.

FROM node:alpine

Dockefile에는 기본적으로 20가지 정도 명령어를 지원합니다. 그 중 제일 먼저 사용되는 명령어는 FROM입니다. FROM 명령어는 우리가 빌드하고자 하는 이미지를 어떤 기반 이미지(Base Image)로 부터 이미지를 만들지 설정하는 부분입니다. 여기서 가져온 기반 이미지는 node:alpine 이미지 입니다. alpine 리눅스를 기반으로 nodejs가 설치된 이미지에서 우리는 어떤 작업을 수행할 것이고, 그것을 위해 명시해놓은 것입니다.

WORKDIR /usr/app

이후에 수행할 작업은 실제 이미지에 담고자 하는 어떤 명령어들이 들어갑니다. 가장 먼저 React 앱을 빌드하기 위해 의존성을 설치한 후 이를 빌드하는 작업을 거치는데, 평소 로컬에서 수행하던 작업과 동일합니다.

COPY ./ ./

WORKDIR 명령어는 어느 디렉토리에서 작업을 수행할지 지정하는 명령어입니다. 리눅스의 최상단 디렉터리에는 보통 /etc, /usr, /bin, /home 등 여러가지 디렉터리가 존재합니다. 여기서는 그 중 /usr/app 디렉터리에서 작업을 수행하려 합니다.

RUN npm install
RUN npm build

Docker와 관련된 모든 작업은 docker 명령어로 시작합니다. Dockerfile은 shell에서 다음과 같이 명령어를 입력하여 Dockerfile로 작성된 내용들을 실제 Docker 이미지로 옮기는 과정을 거칩니다. 첫번째 인자는 이미지의 이름, 두번째 인자는 이미지 빌딩에 사용할 Dockerfile의 디렉토리입니다. 여기서 첫번째인자의 명명 구성을 '<Author>/<Name>'와 같이 짓는 이유는, 이렇게 해야 <Author> 이름으로 등록된 Docker Hub에 이미지를 Push하는 것이 가능하기 때문입니다.

$ docker build -t 6unpk/6uarchive-admin:latest .

위의 명령어를 실행시킨 후 성공적으로 이미지 빌딩이 끝나게 됩니다. 그리고 이번에는 위에서 빌드한 이미지를 실제로 확인해보겠습니다.

$ docker images

그러면 다음과 같이 현재 Docker가 설치된 로컬 환경에서 어떤 이미지들이 저장되어 있는지 확인 할 수 있습니다. 이번에는 아까 우리가 빌드한 이미지를 Docker Hub에 업로드 해봅시다. 그러기 위해선 먼저 Docker Hub에 로그인 해야합니다. 마찬가지로 docker 명령어로 수행가능합니다.

$ docker login

로그인할때의 Username과 Password는 Docker Hub에 가입할 때 사용한 정보를 입력해주면 됩니다.

$ docker push 6unpk/6uarchive-admin:latest

그리고 push 명령어로 Docker Hub에 우리가 빌드한 이미지를 올려봅시다.

정상적으로 잘 올라가있는 것을 확인해볼 수 있네요. 이로써 가장 간단한(?) Docker 이미지를 만들어서 Hub에 올려봤습니다.

결론 - Docker는 만능인가?

앞서도 말했지만 컨테이너라는 기술은 갑자기 튀어나온 신기술이 아닙니다. 물론 컨테이너도 단점은 존재하고 해결해야할 부분도 여전히 많습니다. 최근에는 Docker를 대체할 만한 여러가지 기술들이 많이 존재하기도 합니다.

어떤 기술이든 그렇지만, 타당한 목적과 쓰임새에 맞게 도입하고 활용하는 것이 가장 좋습니다. 그렇지 않으면 오버엔지니어링이 되기도 하고 되려 효율성을 저하시키기도 하는 결과를 낳기도 합니다. 따라서 필요에 따라 Docker를 시의적절하게 쓰는게 필요하다고 볼 수 있겠죠.

참조

https://docs.docker.com/get-started/overview/

댓글