Docker의 간략한 소개
Docker는 Go로 작성된 리눅스 컨테이너 런타임 패키징 오픈 플렛폼이다. 컨테이너라는 것은 새로운 개념은 아니고 이미 몇몇 대형업체에서는 10여년 전부터 사용하고 있으며 Docker또한 이 개념에서 출발하여 리눅스 컨테이너를 대체하기 위해 만들어졌다. 물론 리눅스 컨테이너와 호환되기도 한다. (LXC – Linux containers)
당연스럽게 VM과 주로 비교가 되곤 하는데 유사한 기능을 가졌으니 그럴 수 밖에 없는 것 같다. VM이나 Docker나 개발자 그리고 시스템엔지니어가 격리된 분산환경을 구축하고 배포하기에 용이하게 만들어 줄 수 있다는 것은 동일한 부분인데 Docker는 VM보다 경량화된 형태로 이를 가능하게 하며 리눅스 커널이 작동되는 곳에서라면 어느 곳에서든 작동한다.
MS도 Docker와 협력하여 윈도우용 컨테이너 기술을 따로 개발하기로 결정을 해서 앞으로 윈도우 기반 서버에서도 사용할 수 있다. 관련내용은 MS-도커, 윈도우 서버용 컨테이너 기술 지원 에서 확인이 가능하다.
VM과 Docker의 구조
VM은 어플리케이션 뿐만 아니라 관련 바이너리와 라이브러리들 그리고 결정적인 차이인 OS 전체가 포함된다. Docker 엔진 컨테이너는 어플리케이션이 구동되기 위해 필요한 바이너리와 라이브러리만을 포함하고 있다. 하이퍼바이저 없이 OS의 격리된 프로세스로 작동하기 때문에 훨씬 가볍다.
컨테이너는 구축, 배포, 이식성에서 그 효과를 발휘할 수 있는데 어플리케이션은 컨테이너에 담긴채로 다양한 환경으로 옮겨져 작동될 수 있으며 다양한 환경에서 동일한 작동을 보장받을 수 있다.
Google도 Docker 컨테이너를 지원하고 있으며 앱 엔진에 Docker 이미지 지원 기능을 추가하였고 관리툴도 오픈소스로 공개하였다.
Docker 1.0 버전부터는 Docker Hub라는 클라우드 기반 서비스도 탑재되어 협업공간으로 사용이 가능하며 Docker 서비스를 생성하고 공유할 수 있도록 돕고 있다. 넷플릭스도 Docker Hub에 기존에 제공하던 오픈소스 기술들의 이미지를 올려놓고, ZeroToDocker를 지원하고 있다.
Netflixoss’s Recently Updated Repositories
설치 (CentOS 기준)
# yum install docker-io
CentOS 6.3에서 EPEL Repos의 몇 Endpoint 기본 설정이 SSL 3.0으로 지정되어 있는 것과 관련하여 “Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again” 에러 메시지를 만날 수 있다. 이럴 때는 다음 명령을 실행하여 HTTPS가 아닌 HTTP를 사용하도록 업데이트 한다.
# sed -i “s/mirrorlist=https/mirrorlist=http/” /etc/yum.repos.d/epel.repo
# yum -y update
이후 docker-io를 다시 yum 명령을 이용하여 설치 한다.
설치가 완료되면 docker service를 실행 한다.
# service docker start
docker 서비스 실행
root 계정이 아니라면 docker의 명령을 실행할 때 권한과 관련된 에러 메시지를 만날 수 있다. 이때는 해당 user name을 docker 그룹에 추가하면 실행이 가능하다.
# useradd wwwuser -g docker
간단한 사용
이미지 가져오기
docker의 명령을 이용하여 이미지를 가져오기 위해서는 pull 명령을 이용한다. 일단 예로 centos6 이미지를 받아 보기로 하자.
# docker pull centos:centos6
이미지 받기
이미지가 정상적으로 받아졌다면 images 명령으로 설치된 이미지를 확인해 볼 수 있다.
# docker images [image]
이미지 확인
위에서 pull 명령을 이용하여 실제 다운로드된 이미지들과 아래의 images 명령을 이용해서 출력된 이미지의 수가 차이가 나는 것을 볼 수 있는데 images 옵션에 -a 옵션을 추가하면 보이지 않는 이미지들까지 모두 출력이 된다. 대부분 REPOSITORY가 <none> 상태일텐데 이것은 이미지가 빌드되는 과정에서 만들어진 이미지들이다.
컨테이너 생성
개인적인 해석인데 OOP를 가지고 비유를 해보자면 이미지는 Class에 해당되고 컨테이너는 이미지를 바탕으로 만들어진 객체라고 볼 수 있는 것 같다. (하나의 이미지로 여러개의 컨테이너도 생성이 가능하다.) 일단 위에서 다운로드 받은 이미지를 가지고 컨테이너를 생성해 보자.
# docker run -i -t centos:centos6 /bin/bash
docker는 run 명령을 이용하여 컨테이너를 생성할 수 있다. i 옵션은 STDIN과 관련된 -t 옵션은 TTY와 관련된 옵션이며 기타 다른 옵션을 확인하고 싶으면 run 명령까지만 입력하여 확인할 수 있다.
현재 컨테이너가 정상적으로 생성되었는지 확인하려면 ps 명령을 이용하여 확인할 수 있다. (이 명령을 실행하는 곳은 생성된 컨테이너가 아님)
# docker ps
컨테이너 확인
위에서 /bin/bash 명령을 실행하도록 했기 때문에 centos 컨테이너를 생성하고 이 컨테이너의 쉘에 있는 상태가 될 수 있었던 것이다. 이 것은 docker의 컨테이너는 해당 어플리케이션을 수행하고나면 독립된 환경에서 해당 어플리케이션을 수행 후 종료가 됨을 의미한다. 종료가 된 컨테이너의 목록을 확인하려면 위의 ps 명령에 -a 옵션을 추가하여 확인할 수 있다.
전체 컨테이너 확인
위에서 STATUS가 종료된 상태인 몇개의 컨테이너들을 확인할 수 있다. 종료된 컨테이너는 물론 재시작도 가능한데 CONTAINER ID를 가지고 restart 명령과 함께 사용하여 재시작할 수 있다.
# docker restart [CONTAINER ID]
하지만 컨테이너를 만들면 아까와는 다르게 만들어진 컨테이너의 쉘이 실행된 것은 확인할 수 없는데 이때는 attach 명령을 사용하여 붙을 수 있다.
# docker attach [CONTAINER ID]
여기서 컨테이너가 종료되면 이 컨테이너는 또 ps -a 명령을 이용하여 확인이 가능한데, CONTAINER ID를 가지고 rm 명령과 함께 삭제도 가능하다. 만약 자동으로 컨테이너가 종료와 함께 제거되길 원한다면 -rm 옵션을 이용하면 된다.
설치와 기본적인 부분은 상당히 간단한데 관련 포럼을 돌아다녀보니 상당히 난관에 봉착하는 경우가 많은 것 같다. 다음번 포스트에서는 실제 어플리케이션을 담은 컨테이너를 생성해보고 실제로 이미지도 만들어 보자.
