Docker,layer, image, aufs, parent, size, build, container : today Keay
개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform인
Docker의 4번째 포스팅입니다. 이래저래 개인사에 힘입어, 정리만 대략적으로 하고 포스팅이 많이 늦어졌습니다.
이번 포스팅에서는 Docker를 보면서 나오는 Docker 이미지가 Layer로 구성되어 있다는 것을 어떤 의미인지 알아보려고 합니다.
정리하다보니 조금 길어져서, 이번 편은 Part 5에서 다시 이어질 예정입니다.
(이미 대략적인 정리가 된 상태에서 포스팅용 정리만 필요로하니, 오래 걸리지 않도록~ 하겠습니다.)
혼자 정리하고 시일이 조금 길어져서, 포스팅이 약간 메끄럽지 않더라도~ 이해하시는 크게 어렵지는 않도록 최대한 많은 사진 예제로
정리해보았습니다.
Docker 이미지
• Docker의 이미지는 Layer들의 모임으로 구성있다.
• Docker의 Lightweight한 특징이자, 강점의 이유 또한 이러한 Layer 구성 때문이기도 하다.
• 그럼 지금부터, Docker 이미지의 Layer 구성이 어떤 것인지 예를 가지고 하나씩 이해해보자.
Docker 이미지 생성하여 이미지 크기 확인하기
• 현재의 디스크 사이즈 확인 : Used 5739664
•Ubuntu:14.04(188.3MB)를 기본 이미지로, zigiweb 이미지를 새로 Build함.
|
build 시 사용한 Dockerfile |
|
FROM ubuntu:14.04 MAINTAINER ZIGI SPACE<zigispace.net> RUN apt-get update RUN apt-get install -y nginx RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf RUN chown -R www-data:www-data /var/lib/nginx VOLUME ["/data", "etc/nginx/site-enabled", "/var/log/nginx" ] WORKDIR /etc/nginx CMD ["nginx"] EXPOSE 80 |
•새롭게 생성된 zigiweb 이미지의 사이즈를 보면, 227.9MB로 표기가 된다.
•이 때, zigiweb 이미지의 history를 확인해 보면, 실제 Base 이미지(여기서는 ubuntu:14.04)에서 부터 어떠한 과정을 거쳐서
최종 zigiweb 이미지가 생성되었는지를 알 수 있다.
•History에서의 우측의 Size를 보면, 최초 Base Image가 Size로부터 각 단계별로 이미지가 어떻게 증가되고 있는지를 볼 수 있다.
•zigiweb 이미지가 생성되었으니, 다시 한 번 현재 디스크 사이즈를 확인해보면
Used : 5780780 으로 변경되었음을 볼 수 있다.
•이제 현재까지 확인한 디스크 사이즈와 이미지 사이즈를 가지고 정리를 해보면 아래의 표와 같이 구성된다.
•최초 베이스 이미지는 192,614.4KB(188.1MB * 1024)
거기에 각 zigiweb build를 수행하면서 Size상에 나타난 Step별 용량을 모두 더한다. (모두 KB로 변환)
•Base Image Size와 Build Step별 수행 시 증가한 사이즈의 합을 보면 233,332.1KB이 되고 이를 MB로 전환하면
227.9MB (zigiweb 이미지 크기)이 됨을 알 수 있다.
•이제 df -k 확인 했던 이미지 크기를 가지고 다시 Used 이미지 크기를 비교하면
Build 전에는 5739664였던 used size가 zigiweb build 후에는 5780780이 됨을 볼 수 있고, 이 크기의 차이를 구해보면
약 40MB 차이가 난다.
•ubuntu:14.04의 이미지와 zigiweb 이미지의 차이도 약 40MB가 됨을 알 수 있다.
•즉, 하나의 Docker 이미지를 생성하게 될 경우에 새롭게 이미지가 모두 만들어 지는 것이 아니라, 기존 base 이미지 위에 추가 된 내용만
덧붙여진 이미지가 Layer 형식으로 구성됨을 알 수 있다.
•다음의 그림을 현재 Docker 버전에서는 지원되지 않는 명령인,
Docker image --tree
명령을 수행한 결과이다.
•이 명령어는 이미지 history에 따른 Image ID와 각 이미지의 용량을 확인할 수 있는 데, 이 이미지의 크기는 전체 이미지가 아니라,
기존 이미지 + 증가분 크기를 나타내게 된다.
Docker Container 생성 시의 디스크 사용량 확인
•이번에는 Docker Image를 가지고 Container를 생성한 후에 디스크 사이즈를 비교해본다.
•Container 생성 전에 df -k로 현재 used 용량을 확인하고, Container를 생성한 후에 다시 Used 용량을 비교해보면
실제 용량이 증가가 거의 일어나지 않음을 알 수 있다. 즉, 이미지를 가지고 Container를 생성 시에도 Docker 이미지의 크기만큼
새롭게 만들어서 Container화 시키지 않고 Container는 해당 이미지의 공간을 그대로 사용함을 알 수 있다.
•그렇다면, 생성된 Container에서 Disk를 추가로 사용하게 될 경우에는 디스크 사이즈에는 어떤 변화가 생길 것인가?
아래와 같이 Container에서 임의 20MB를 사용하는 것처럼 할당해보면,
•Used 사이즈가 약 20MB (5788224 → 5799224 :KB) 변화하였음을 볼 수 있다.
Docker Layerd 이미지 확인
•이제부터 실제 Docker의 Layerd 이미지가 어떻게 구성되는지에 좀 더 알아보자.
•docker inspect 명령을 사용하게 되면, 현재 이미지의 상세 정보를 볼 수 있는 데, 여기에 나온 정보를 이제부터 확인해보자.
•먼저, Ubuntu:14.04에 대한 정보의 일부를 살펴보면, 상단에 이미지 ID, Parent ID 등의 정보와 함께 아래 쪽에는
VirtualSize라는 항목이 188304295 임을 볼 수 있다. 그리고 Size는 0이다.
•다음으로 zigiweb 이미지의 정보를 보면, 마찬가지로 이미지 / Parent ID정보와 함께 아래 쪽에는
VirtualSize 항목이 227877825임을 볼 수 있다. 마찬가지로 Size는 0이다.
•이 정보만으로는 어떤 내용인지 알기가 어려우니, 아까 전에 살펴 본, history 명령으로 zigiweb 이미지가 만들어진 내용을 다시 보자.
•제일 앞의 IMAGE ID가 위의 inspect에서의 ID의 앞 12자리임을 알 수 있는 데, 매치시켜보면
ubuntu 14:04의 이미지는 아래의 history에서 아래부터 4번째 이미지이고 (즉, ubuntu 이미지도 몇단계의 작업을 거친 이미지이다)
zigiweb 이미지는 제일 위의 이미지인 것을 확인할 수 있다.
•먼저 inspect에서 표기되는 Image ID는 자신의 Image ID인 것은 이미 알고 있고, Parent ID는 history에서 살펴보면, ID 바로 아랫 줄의
ID와 동일한 것을 알 수 있다. 즉, Parent ID는 자신의 Image의 바로 직속 Base Image를 뜻하는 것이다.
(마치 OOP에서의 클래스 상속처럼..)
•다음으로 위에 나온 VirtualSize와 Size가 이제 어떤 뜻인지 보면,
VirtualSize는
현재 가리키고 있는 이미지의 Base이미지 + 현재 Step에서 증가된 이미지 크기
이다.
•즉, zigiweb이라는 이미지의 크기는 227877825인데, 이 이미지의 ID는 5242- 이다.
이 때 zigiweb의 base 이미지는 ubuntu:14.04로부터 만들어지지만, 각 step을 거치면서 각 step마다 이미지가 생성이 된다.
즉, 이미지 ID 5242의 base 이미지는 d374-(2번째 줄)이 되고, d374-의 Base 이미지는 다시 0a5a-(3번째 줄)가 된다.
•그렇다면, Size가 0인 것은 해당 이미지의 Step에서는 추가로 Size가 증가되지 않았기 때문에 '0'이라는 것을 알 수 있다.
•다음은 8aaf98371fcb 이미지의 inspect 정보이다.
이 이미지는 1615(1.615KB)가 증가한 step이기 때문에 Size가 1615로 표기되고, Virtualsize는 1615를 포함한 전체 사이즈가 된다.
