[Docker in Action] Software installation simplified (2)

 

 

 

Installation files and isolation

 

 

실제로 도커에서 우리가 "이미지"라고 부르는 개념은 "이미지 레이어"들의 조합(Collection)을 의미합니다. "이미지 레이어(layer)"는 파일과 파일 메타데이터의 조합으로, 하나의 "Atomic Unit"으로 기능합니다. 도커는 이 각각의 레이어를 이미지처럼 취급하며, 이렇게 이미지를 구성하는 이미지 레이어들과 이미지 사이의 관계를 이해하면 다음과 같은 핵심적인 질문들을 해결하는데 도움이 됩니다.

 

• What image properties factor into download and installation speeds?
• What are all these unnamed images that are listed when I use the docker images command?
• Why does output from the docker pull command include messages about pulling dependent layers?
• Where are the files that I wrote to my container’s filesystem?

 

 

 

Image layers in action

실제로 이미지와 이미지 레이어 간의 관계를 확인하기 위해서 다음 2개의 도커 커맨드를 순차적으로 실행해보도록 하겠습니다. 이미 로컬 컴퓨터에 두 이미지를 Pull 받은 적이 없다면 아래와 같은 결과를 확인할 수 있습니다.

docker pull dockerinaction/ch3_myapp
docker pull dockerinaction/ch3_myotherapp

 

 

주목할 만한 점은 두 번째 커맨드인 "docker pull dockerinaction/ch3_myotherapp"를 실행했을 때 이미지를 Pull 받는 속도가 훨씬 빠르다는 점이며, 중간중간의 알 수 없는 해시값과 함께 "Already exists"라는 메시지가 보인다는 점입니다. 이 "Already Exists"라는 메시지는 실제로 해당 레이어가 이미 로컬 머신에 존재하고 있기 때문에 원격 레포지토리에서 가져올 필요 없이 캐시를 사용했다는 의미이며, 이 때문에 다운로드 속도도 훨씬 빨라지게 됩니다. 

 

 

 

ch3_myotherapp의 이미지를 pull 받을 때 캐시를 사용할 수 있었던 이유는 Docker Image가 레이어들의 모음으로 구성되어 있으며, "ch3_myapp"과 "ch3_myotherapp"을 구성하는 이미지 레이어들 중에 "동일한 레이어"들이 존재하기 때문입니다. 따라서 실제로 두 번째 애플리케이션 이미지를 pull 받을 때는 공통의 레이어들이 아닌 "ch3_myotherapp"에만 존재하는 Unique Layer만 원격지로부터 pull받게 됩니다.

 

도커 이미지는 "대체로" 여러개의 이미지 레이어로 구성됩니다

 

 

Layer relationships

도커는 앞서 설명한 이미지 레이어 구조로 이미지를 관리하기 때문에 각각의 이미지와 이미지 레이어를 유일하게 식별합니다. 이러한 구조 덕분에 공통된 레이어들은 불필요한 중복 다운로드 없이 이미 저장된 레이어를 사용하게 되며, 이렇게 빌드된 이미지가 컨테이너에서 실행될 때, 해당 컨테이너에서 사용 가능한 파일들은 이미지를 구성하는 레이어의 Union(합집합)으로 구성됩니다. 즉 이미지 X가 A, B, C 레이어를 통해 구성되었다면 X가 컨테이너에서 실행될 때는 A, B, C 레이어의 모든 기능과 파일들을 사용할 수 있다는 것을 의미합니다.

 

 

 

Container filesystem abstraction and isolation

컨테이너에서 실행되는 프로그램들은 이미지 레이어에 대해서 알지 못합니다. 각각의 이미지 레이어는 각각의 파일 시스템을 갖겠지만, 컨테이너의 입장에서는 그저 하나의 파일 시스템에서 읽기, 쓰기 연산을 모두 수행하는 것처럼 보여야 합니다. 도커에서는 이를 UFS(Union File System)을 사용해서 관리합니다.

 

 

Union File System

UFS란 여러 개의 파일시스템을 하나로 결합하여 취급할 수 있도록 하는 장치를 의미합니다. 실제로 도커 컨테이너 내부에서 바라보는 파일 시스템은 여러 개의 파일 시스템이 겹쳐져 있는 형태입니다. UFS는 이를 차곡차곡 겹쳐서 컨테이너의 입장에서는 하나의 파일 시스템과 상호작용 하는 것처럼 보이게 합니다. 

 

실제 예시를 통해 도커에서 UFS가 어떻게 동작하는지 알아보겠습니다.

이미지 X와 이미지를 구성하는 이미지 레이어가 A, B, C 순서대로 존재한다고 할 때, 각각의 이미지 레이어를 구성하는 파일은 Read-only 상태로 존재하게 되며, 그 위에 프로그램을 실행하면서 생성되는 파일들을 저장하기 위해 Writable Layer인 D가 추가로 올라가게 됩니다.

 

A, B, C는 다른 이미지 Y를 구성하는 곳에서도 사용할 수 있으므로, 만약 해당 컨테이너에서 C를 변경해야 한다면 Writable Layer D에서 이를 복사해서 그 위에 Write 하는 방식(Copy on Write. CoW)으로 동작하게 됩니다. 따라서 어떤 경우에서든 A, B, C레이어는 Read Only 상태로 남게 되며, 도커 컨테이너는 공유 이미지 레이어인 A, B, C를 사용하면서도 필요에 따라 이를 단일 파일 시스템에서 동작하는 것처럼 읽기도 하고 수정도 할 수 있게 되는 것입니다. 

 

 

 

 

도커는 UFS와 CoW 전략을 사용해서 이미지와 컨테이너를 관리하기 때문에 컨테이너를 독립적으로 구성하여 운영하면서도 이미지 레이어들을 "공유"해서 불필요한 리소스 다운로드를 아낄 수 있도록 합니다. (도커의 파일 시스템 및 심화 레이어 구성에 대해서는 이후 포스팅에서 다룰 예정입니다.)