Docker 전반적인 설명

1.  DOCKER 설명

Docker는 Linux 기반의 Container RunTime 오픈소스이다. 처음 개념을 잡기가 조금 어려운데, Virtual Machine과 상당히 유사한 기능을 가지면서, Virtual Machine보다 훨씬 가벼운 형태로 배포가 가능하다. 정확한 이해를 돕기 위해서, VM 과 Docker Container의 차이를 살펴보자.

아래는 VM 에 대한 컨셉이다. Host OS가 깔리고, 그 위에 Hypervisor (VMWare,KVM,Xen etc)가 깔린 후에, 그위에, Virtual Machine이 만들어진다. Virtual Machine은 일종의 x86 하드웨어를 가상화 한 것이라고 보면된다. 그래서 VM위에 다양한 종류의 Linux나, Windows등의 OS를 설치할 수 있다.

²  그림 1 기존 VM의 구조

Docker의Container 컨셉은 비슷하지만 약간 다르다. Docker도 VM 처럼 Docker Engine이 Host위에서 수행된다. 그리고, Container는 Linux 기반의 OS만 수행이 가능하다.

Docker는 VM처럼 Hardware를 가상화 해주는 것이 아니라, Guest OS (Container)를 Isolation해준다.무슨 말인가 하면, Container의 OS는 기본적으로 Linux OS만 지원하는데, Container 자체에는 Kernel등의 OS 이미지가 들어가 있지 않다. Kernel은 Host OS를 그대로 사용하되, Host OS와 Container의 OS의 다른 부분만 Container 내에 같이 Packing된다. 예를 들어 Host OS가 Ubuntu version X이고, Container의 OS가CentOS version Y라고 했을때, Container에는 CentOS version Y의 full image가 들어가 있는 것이 아니라, Ubuntu version X와 CentOS version Y의 차이가 되는 부분만 패키징이 된다. Container 내에서 명령어를 수행하면 실제로는 Host OS에서 그 명령어가 수행된다. 즉 Host OS의 Process 공간을 공유한다.

²  그림 2 Docker의 구조

실제로 Container에서 App을 수행하고 ps –ef 를 이용하여 process를 보면, “lxc”라는 이름으로 해당 App이 수행됨을 확인할 수 있다. 

Performance에 대해서는 당연히 Host OS에서 직접 application 을 돌리는 것보다 performance 감소가 있는데, 아래 표와 같이 performance 감소가 매우 적은 것을 볼 수 있다.

²  그림 3 Docker 자원 사용률

²  출처: http://www.slideshare.net/modestjude/dockerat-deview-2013

다음으로 Docker의 특징중의 하나는 repository 연계이다.Container Image를 중앙의 Repository에 저장했다가, 다른 환경에서 가져다가 사용할 수 있다. 마치 git와 같은 VCS (Version Control System)과 같은 개념인데, 이를 통해서 Application들을 Container로 패키징해서 다른 환경으로 쉽게 옮길 수 있다는 이야기다.

²  그림 4 File System

예를 들어 local pc에서 mysql, apache, tomcat등을 각 컨테이너에 넣어서 개발을 한 후에, 테스트 환경등으로 옮길때, Container를 repository에 저장했다가 테스트환경에서 pulling(당겨서) 똑같은 테스트환경을 꾸밀 수 있다는 것이다. Container에는 모든 application과 설치 파일, 환경 설정 정보 등이 들어 있기 때문에, 손쉽게 패키징 및 설치가 가능하다는 장점을 가지고 있다.

여기서 고려해야할점은 Docker는 아쉽게도 아직까지 개발중이고, 정식 릴리즈 버전이 아니다. 그래서, 아직까지는 production(운영환경)에 배포를 권장하고 있지 않다. 단 개발환경에서는 모든 개발자가 동일한 개발환경을 사용할 수 있게 할 수 있고, 또한 VM 보다 가볍기 때문에, 개발환경을 세팅하는데 적절하다고 볼 수 있다.

Docker를 이해하기 이해하기 위한 몇가지 사항

---

# File System ( http://docs.docker.io/en/latest/terms/filesystem/ )

²  그림 5 File System

리눅스 시스템이 구동할때의 과정에는 일반적으로 2개의 파일 시스템이 필요하다. 

boot file system( bootfs )와 root file system( rootfs )가 바로 그것이다. 

boot file system은 부트로더와 커널을 가지고 있다. 사용자들은 boot file system에 어떤 변경도 하지 않는다. 

사실 부팅과정이 끝난직후에는 커널 전체가 메모리에 있고, initrd( 초기의 램디스크로, 리눅스 커널의 부팅 과정에서 사용되는 임시 파일 시스템 )와 연결된 RAM의 정보를 초기화 하고 언마운트 된다. 

root file system은 유닉스 기반의 OS와 관련있는 일반적인 디렉토리 구조( /dev, /proc, /bin, /etc, /lib, /usr and /tmp 그리고, )와 유저 어플리케이션을 실행하기 위해 필요한 모든 환경설정 파일 및 바이너리 및 라이브러리 파일등을 포함한다. 

다른 리눅스 배포판들 사이에 중요한 커널의 차이가 있을수 있지만, root file system의 내용이나 구성은 보통 당신이 만든느 소프트웨어 패키지에 따라 의존적으로 만들어진다. docker는 동시에 다수의 배포버전에서 실행되었을때의 문제점을 해결하는데 도움이 될수 있다. 

---

# Layers ( http://docs.docker.io/en/latest/terms/layer/ )

전통적인 리눅스 부팅 과정에는 커널은 read-only 모드로 root file system을 마운트 하고, 마운트 무결성을 검사한 다음, read-write 모드로 전체 root file system을 전환한다. 

Layer

Docker가 rootfs를 마운트할때, 리눅스의 전통적인 부팅 과정처럼 read-only로 마운트 되지만, read-write 모드로 전환하는것 대신에 read-only 파일시스템 위에 read-write 파일 시스템을 추가하여 union mount를 활용한다.

사실 서로의 위에 쌓인 여러개의 read-only 파일시스템이 있을 수 있으며, 우리(docker.io)는 이들 파일시스템을 layer로서 생각한다.  

²  그림 6 Layer

첫째로 맨위의 read-write 파일시스템 레이어는 그 안에 아무것도 없지만, 언젠가 프로세스에 의해서 파일이 생성될때, 이것은 맨 뒤의 레이어인 read-write 파일 시스템에서 생성된다.

그리고, 낮은 레이어에서 존재하는 파일이 업데이트 될 필요성이 있다면, 그때 파일이 상위 레이어로 복사되고, 변경사항은 복사본으로 이동한다.

Union File System 

우리는 read-write레이어의 통합이라고 부르고, 모든 read-only 레이어들은 union file system 이라고 부른다. 

docker에서 앞서 언급한 read-only 레이어는 image라고 불린다. image는 결코 변하지 않는다. 

docker가 Union File System을 사용한 이래로 프로세스들은 모든 파일 시스템들은 read-write 모드로 마운트 된다고 생각하게 된다.

하지만, 변경되는 모든것들은 쓰기가 가능한 가장 최상위 레이어로 이동하게 되고 그바로 아래에 있는 read-only image의 원본 파일은 변하지 않는다. image들은 바뀌지 않기 때문에 image는 상태를 가질 수 없다. 

²  그림 7 image와 container

Parent Image 

²  그림 8 Parent Image 와 하위 Image

각 image는 아래층을 형성한 더 많은 image에 따라서 의존적이다. 때론 하위 image가 상위 image의 부모 image라고 말하기도 한다. 

Base Image

부모가 없는 image를 base image라고 한다. 

---

# Container ( http://docs.docker.io/en/latest/terms/container/ )

Container

²  그림 9 전체구조

일단 docker 내부 image의 프로세스를 시작한다면, docker는 image와 부모 이미지를 fetch하고, base image에 도달할때까지 fetch 과정을 반복한다. 그때 union file system이 최상위에 read-write 레이어를 추가한다. 이때 생성된 read-write 레이어는 부모 image에 대한 정보와, unique id나 network 환경설정, 리소스 제한 등에 대한 몇가지 추가 정보들을 더하는데 이를 container라고 한다. 

Container State

container들은 바뀔수 있고, 그러므로 당연히 상태를 가질 수 있다. container들은 실행되거나 종료되기도 한다. 

container가 실행중일때, container의 아이디어는 호스트에서 실행중인 다른프로세스로부터의 분리 및 CPU에서 실행중인 프로세스 트리를 포함하고 있다. 

container가 종료되었을때, 파일시스템의 상태와 종료 값들은 유지된다. 다시 실행할 수도 종료 및 재시작할 수도 있다. 프로세스들은 ( container내의 메모리 상태값을 유지하지 못한 상황 ) 스크래치 상태로 재시작하게 되지만, 파일 시스템은 단지 컨테이너가 종료되었을때의 그 상태 그대로 입니다. 

하지만 docker의 commit 명령어를 통해 container를 image로 변경할 수 있다. 한번 image가 된다면 그것을 다른 컨테이너의 parent image로서 재사용할 수 있다.