Docker Container Image에 대한 고찰

Docker에서 Container Image는 layer의 연속이다. 각 레이어는 Dockerfile에서의 각 명령(instruction)을 대표한다. 가장 상단의 layer를 제외하고는 모두 Read Only이다.

 

갑자기 가장 상단의 layer는 제외하고 Read Only라니 무슨 말인지 이해가 안될 것이다. 이에 대한 설명은 바로 아래에 있다.

 

1. Container Image, Writable Layer 

FROM ubuntu:16.04
COPY . /app 
RUN make /app 
CMD python /app/app.py

위 Dockerfile은 4개의 command를 가진다. 각 command는 layer를 생성하게 된다. 각 Layer는 stack 처럼 쌓인다. 또한 각 layer는 바로 이전 layer와 차이점을 가진다. 

 

컨테이너 실행시, 가장 상단에 새로운 Writable Layer가 생긴다. 그리고 이 레이어를 Container Layer라고 부른다.

 

실행중인 컨테이너에서 생긴 모든 변화는 Container Layer에서 이루어진다.

 

2. Container와 Image, 어떻게 다를까?

결론적으로 컨테이너와 Image간의 Major Difference는 가장 상단의 Writable Layer이다.

 

실행중인 컨테이너는 모든 변화를 이 writable layer에 쓴다. 만약 컨테이너가 삭제되면 이 writable layer 또한 삭제된다.

 

이것이 가장 큰 차이이다. “이미지가 실행되면 컨테이너가 되었다” 라고 보통 말한다.

 

이도 틀린말은 아니지만 조금 더 살을 붙이자면 "컨테이너란 [Image + 각 컨테이너만의 Writable Layer] 이다" 라고 말하는 것이 가장 좋을것이다.

 

3. Container Image 그리고 Content Addressable

[Docker v1.10 이전]

 

새로운 레이어는 commit action의 결과로 생성되었고, 도커는 레이어 생성마다 itermediate image를 생성하였다. 그리고 이 이미지를 Randomly generate 256bit-UUID로 대표 하였다. 즉 각 레이어는 randomly generated uuid를 가진다.

 

또한 각 이미지의 레이어는 각 ID와 Parent를 가지고 있다. (베이스 layer는 parent가 없다.)

그리고 Docker image의 ID는 가장 상단의 레이어 ID와 같은 이름으로 생성되었다.

 

이러한 방법으로 Docker는 filesystem을 구축하였다.

 

그러나 이 방법은 Content를 표현 할 수 없었다.

 

Registry로 부터 image를 pull 하거나 push 할 때 이미지의 내용이 변경 되었는지에 대해 알 수 있는 수단이 부족하다.

 

이미지 및 layer의 ID가 랜덤하게 생성되기 때문에 ID 만으로 내용물에 대한 무결성을 확인할 수 없었다. 또한 레이어 중 중복 또한 확인할 수 없었다.

 

그리하여 Content Addressable IDs라는 방법이 동원되었다.

 

[Docker v1.10 이후]

 

Image는 하나 이상의 레이어를 참조한다. 그리고 Layer들은 digest로 구별된다.

 

이 digest는 sha256으로 이루어지는데, layer의 내용물을 기반으로 만들어진다. 그렇기에 내용물이 변하면 digest 또한 변하게 된다.

 

따라서 이전처럼 Layer의 ID와 Image의 ID가 동일하게 될 일이 없다. 또한 Layer는 파일 및 디렉토리의 모음으로 취급된다.

 

즉 Docker Image는 layer들의 digest를 모아놓은 어떠한 오브젝트이고, 이미지 ID 또한 digest이다.

 

뭐 이런식으로 되어있다.