'Layer'에 해당되는 글 2건

  1. 2015.08.20 Docker - Part 5
  2. 2015.08.17 Docker - Part 4
분류없음2015.08.20 00:30

 


Docker,layer, image, aufs, parent, size, build, container, aufs, device mapper  : today Key

 

개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform인

Docker의 5번째 포스팅입니다.  

지난 포스팅에 이어서 Docker의 Layer 이미지에 대한 두 번째 내용입니다.

지난 포스팅에서 나눈 이유가 길어져서 였는 데, 테스트 한지가 조금 되다보니 뒷 부분 정리한게 생각보다 길어지진 않았습니다. ^^;

물론 추후 언제라도 동일한 주제로 해당 내용은 업데이트 될 수 있습니다! ^^

그럼 먼저 Docker의 이미지에 대한 간단한 몇 가지 정리에 이어서, 지난 포스팅과 마찬가지로 테스트한 내용을 중심으로 이해해보겠습니다.

다음 포스팅도 대략적으로 50% 이상 써 놓은 상태여서 다음 포스팅까지는 멀지 않은 시일내에 업데이트 하도록 하겠습니다.

 


 

Docker Layered Image.

 

▪  Docker는 하나의 Image에 Layer를 결합하기 위해서 Union File System을 사용.
▪  Union 파일 시스템은 branches 알려져 있는 각 파일 시스템 내 파일 및 디렉토리들을 transparent하게 오버레이 형태로 적용되어

    하나의 일관된 파일 시스템을 형성
▪ Docker Image가 변경될 때, 새로운 Layer가 생성
▪ Docker Image에서 새로운 Layer를 생성되는 과정을 'instructions'이라 함.
▪ instructions이 발생하는 경우
    - Command 실행
    - File이나 directory 생성
    - 환경변수 생성
    - Image로 Container를 생성하여, 어떤 Process를 실행할 경우
▪ Dockerfile : Instructions 들을 모아 놓은 파일
▪ Docker가 이 Dockerfile을 읽어서, instructions을 수행하고 최종 image를 생성
▪ Docker에서 지원하는 파일 System
     - AUFS / Device Mapper /  Btrfs
▪ Docker에서는 Default로 AUFS (Advanced multi layered Unification File System)를 사용

 

root@ubuntu:~/Docker# docker info | grep Storage

Storage Driver: aufs

 

 


Docker 이미지 이해하기

  ▷ 현재 조건

    현재 Docker의 이미지는 아래의 그림과 같이 Base Image로 부터 zigiweb:latest 가 만들어 지고,

       다시 zigiweb2:0.1 이미지가 만들어진 상태.

       ※ 물론 이미지 생성 과정에서 다수의 이미지가 생성되기 때문에 그림에는 다수의 이미지가 생략된 상태.

    zigiweb 이미지를 통해서 modizigi 라는 Container가 생성된 상태

 

  

 

  ▷ 테스트

   Step 1

     - modizigi Container를 삭제 [ Container는 현재 Stop된 상태라고 가정

   Step 2

     - zigiweb:latest 이미지를 삭제

   Step 3

     - zigiweb2:0.1 이미지를 삭제

 

 

 

   •Step 1에서 Container를 삭제 시에는 해당 Container만 삭제된다.

   •Step 2에서 Image를 삭제 시에는 해당 이미지에 대해서 Untagged만 되었다고 표기된다 

   •Step 3에서 zigiweb2:0.1 Image를 삭제 시에는 해당 이미지에 대해서 Untagged되고, 다수의 이미지가 삭제된다

   •위의 현재 Layer된 이미지에서 보듯이 zigiweb2:0.1은 기존 base image부터 시작하여 zigiweb:latest 이미지까지의 계층화된

      이미지에 추가로 덧붙여져 만들어진 이미지이다.  따라서, 해당 이미지보다 상위(그림에서는 아래)의 이미지를 삭제를 하더라도

      실제 이미지는 삭제되지 않으며, 해당 이미지에 대해서 Untagged라고 표기가 된다.

      즉, 기존 이미지를 Parent Image로 사용하는 경우에는 Parent Image를 삭제하더라도 해당 이미지에 변경된 사항에 대해서

      계층화 된 이미지를 사용하기 때문에 실제 이미지가 삭제되지 않는 것이다. 

   •즉, 모든 이미지는 상위 이미지에 대해서 의존성을 가지고 있다는 것을 알 수 있다.  

 

 

 •실제 Step 2를 수행하기 전과 후의 Disk 상태를 보면 용량이 변화가 없다. (바로 위의 그림)

 

 

 

 •하지만, Step 3을 수행하게 될 경우에는 수행 전과 후의 Disk 사용량이 해당 이미지 크기 만큼 변경됨을 알 수 있다.

 

 

 

Posted by 네떡지기
분류없음2015.08.17 23:54

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를 포함한 전체 사이즈가 된다.

 

 

 

Posted by 네떡지기

티스토리 툴바