Docker란

가상머신

프로그래밍뿐만 아니라 컴퓨터자체를 사용하다보면 다양한 이유로  가상머신을 사용하는 경우가 자주있다. (프로젝트마다 다른 개발환경이라던지, 또는 단순하게 하나의 게임을 여러개 돌리고 싶은 경우에도 종종 사용하기도 한다)

예전에 근무했던 회사 같은 경우는 Windows 환경에서 작업하였었는데 유지보수하는 프로그램마다 OS 버전과 환경이 전혀 달랐다 (예를들어 A프로그램은 window 7이면서 특정 프로그램이 설치되어있어야 하고 B프로그램은 window xp면서 또 다른 프로그램이 설치되어있어야 하고..) 그러다 보니 처음에 해당 프로그램 업무를 맡게되면 팀장님에게 가상 이미지 파일을 받고 작업을 시작했었는데, 개발환경 따로 설정하는 과정이 필요없어서 꽤나 편리했었다.

하지만 어느정도 시간이 지나자 하나씩 문제점들이 들어나기 시작했는데. 

1. 가상 이미지의 용량이 생각보다 커서 부담이되었다.
   가상 이미지의 경우 OS가 하나하나 설치되어 있어야 하다보니 용량이 클수밖에 없었고, 프로젝트가 늘어날때마다 저장공간이 점점 부족해지기 시작했다. 게다가 매번 메일이나 ftp로 제공받다 보니 전송받는것도 상당히 오래걸린다.
2. 속도가 너무 느렸다.(성능이 너무 낮았다.)
   호스트 환경에서 작업하는 경우는 괜찮았는데 가상머신에서는 속도가 상당히 느렸고 여러개의 가상머신을 가동하는 경우에는 메모리 부족문제도 심각했다. (가상머신을 껐다가 키는것도 상당히 오래 걸리는 경우도 있고 간단한 수정 같은 경우는 굳이 하나 끄고 하나 키는 방식보다는 필요한 걸 잠깐 껐다가 수정하고 끄는 경우가 많았다. 물론 둘다 엄청 느려져서 후회한 적도 많고)
3. 처음에 받은 이미지를 제공받았을때랑 나중에 점점 차이점이 커진다.
   처음 팀장님에게 이미지를 제공받은 이후로 개발작업과 환경변화가 점점 커지기 시작하고, 한 일년이상 작업을 하다보면 다른 팀원과 팀장님과 나의 환경자체가 전혀 달라졌다. 그러다보니 내 환경에서는 잘 작동하는데 다른 환경에서 작동하지 않는 문제가 종종 발생하였다.(흔히 말하는 "제 컴퓨터에서는 잘 되는데요?")

내가 느꼈던 단점들은 아마 다른사람들도 쉽게 느꼈을거라 생각한다. 물론 저 단점들이 있더라도 가상머신 환경자체가 상당히 편리하고 좋다는 건 대부분 공감할 것이다. 그렇다면 저 단점들을 제거하면 되는거 아닌가? 라는 생각으로 만든게 docker가 아닌가한다.

물론 이런 발상과 개념이 docker가 처음은 아니다 가상머신 자체는 나온지 상당히 오래되었고, 발전과 연구도 함께 오래되었겠지.

Docker?

기존 가상머신 환경의 가장 큰 단점은 호스트 환경에 비해서 성능이 너무 안 좋았다는 것이다. 초기에는 전가상화 (Full Virtualization) 방식으로 하드웨어를 완전히 가상화하였다. 하드웨어를 완전히 가상화하였기때문에 게스트OS에 특별한 수정이 필요하지도 않고 windows든 Linux든 어떠한 OS 를 사용하든지 상관없다. 하지만 물리적인 가상화 지원기능이 필요하다 즉 CPU의 가상화 지원 기능이 필요하다. 그래서 기존 전가상화 방식에는 Intel-VT나 AMD-V 가 지원되는 CPU가 필수였다. 하지만 성능 저하 문제가 많이 발생했다.

이러한 문제를 해결하기 위해 반가상화라는 방식이 나왔는데, 전가상화와 다르게 하드웨어를 완전히 가상화 하지않고 게스트OS가 하이퍼바이저에게 하드웨어 제어를 요청하고 하드웨어 제어를 하이퍼바이저가 하기때문에 기존 전가상화 방식보다 성능이 훨씬 괜찮았다. 하지만 반가상화의 단점은 게스트 OS의 커널에 수정이 필요하여, windows처럼 OS소스가 공개되지 않은 경우에는 불가능했다. 그래서 Linux처럼 오픈소스 OS에만 적용이 가능하였고 OS를 가상화하는 것에만 초점이 맞춰져있어서 배포와 관리기능의 문제는 여전히 남아있었다.

Docker는 반가상화보다 더 경량화하였는데, Docker는 게스트OS 자체를 설치하지않는다. 대신에 Docker 이미지에 프로그램과 라이브러리만 격리해서 설치하여 용량이 크게 줄어들었고, OS자원을 호스트OS와 공유하여 기존 가상머신 방식보다 훨씬 성능이 좋다. 게다가 가상 머신들과 다르게 이미지 생성과 배포에 특화되었다. Git에서 사용하는 개념들을 도입하였는데, 이미지 버전관리와, 중앙 저장소에 이미지를 올리고 받을수 있으며, GitHub과 비슷한 Docker Hub을 제공하고 다양한 API로 사용자가 원하는 만큼 자동화가 가능하여 개발과 서버 운영에 유리하다.

LXC(LinuX Container)

리눅스/유닉스 환경에는 chroot이라는 격리공간 생성명령어가 있는데 특정 디렉터리를 루트 디렉터리로 설정하고 그 디렉터리는 외부의 파일과 디렉터리에 접근이 불가능하다.

chroot은 실행파일과 공유 라이브러리를 직접 준비해야하고 설정방법이 많이 복잡한데다가 완벽한 가상환경이 아니기때문에 제약이 많다. 그래서 리눅스에서는 LXC라는 시스템 레벨 가상화 환경을 제공한다.

LXC는 가상화하여 OS를 실행하는 것이 아니고 커널레벨에서 제공하는 격리된 가상공간으로, OS를 설치하지 않기때문에 가상 머신이라 하지않고 컨테이너라고 한다. 리눅스 커널의 cgroups기능에 의존하며 cgroups는 CPU,Memory, disk, network 자원을 할당하여 완전한 형태의 가상 공간을 제공한다. 또 프로세스 트리, 사용자 계정, 파일시스템, IPC등을 격리시켜서 호스트와 별개의 공간을 만들고, 이를 Namespace isolation(namespaces)이라고 한다.

(출처 : http://forum.odroid.com/viewtopic.php?t=17417 )

LXC는 격리된 공간만 제공하여 개발 및 운영에 필요한 부가 기능이 부족하였고 Docker는 LXC를 기반으로 이미지, 컨테이너 생성 및 관리 기능과 다양한 부가 기능을 제공한다.

Docker가 처음 개발될때는 LXC를 기반으로 구현하였지만 0.9버전 부터는 libcontainer를 개발하여 사용하고 있다. 내부적으로는 실행 드라이버(exec driver) 라 하는데 libcontainer는 native, LXC는 lxc로 표현하고 옵션으로 선택이 가능하다.

(출처 : http://www.zdnet.com/article/docker-libcontainer-unifies-linux-container-powers/ )

이미지와 컨테이너

Docker 베이스 이미지) 리눅스 배포판의 유저랜드(커널공간이 아닌, 유저 공간에서 실행되는 실행파일과 라이브러리를 유저랜드라고 한다)만 설치된 파일을 뜻한다. 보통 리눅스 배포판 이름으로 되어있고 리눅스 배포판 유저랜드에 Redis나 Niginx등이 설치된 베이스 이미지도 있다. Docker이미지라고 하면 베이스 이미지에 필요한 프로그램과 라이브러리 , 소스슬 설치한 뒤 파일 하나로 만든 것을 뜻한다.

Docker 이미지의 경우 베이스 이미지에서 바뀐부분만 이미지로 생성하고 실행할 때는 베이스 이미지와 바뀐 부분을 합쳐서 실행하여 용량이 커지는 걸 방지했다.

(출처 : http://www.slideshare.net/ruo91/introduce-docker-52374559 )

즉 Docker는 이미지를 통째로 생성하지 않고 바뀐 부분만 생성한 뒤 부모이미지를 계속 참조하는 방식으로 동작한다. Docker 에서 이 것을 레이어라고 한다.

Docker 이미지는 파일이므로 저장소에 올린 뒤 다른 곳에서 받을 수 있다. 저장소에 올릴때는 자식 이미지와 부모 이미지를 함께 올리고, 받을 때도 부모이미지를 함께 받고 그 이후에는 내용이 바뀐 부분만 주고받는다.

Docker 컨테이너는 이미지를 실행한 상태이다. 이미지로 여러개의 컨테이너를 만들 수 있다. 이미지는 실행 파일이고 컨테이너는 프로세스라고 볼 수 있다. 이미 실행된 컨테이너에서 변경된 부분을 이미지로 생성할 수도 이다.