[CKA] 32. docker의 image layer관리 (storage driver)

개요

docker를 기반으로 container image구조 및 container image가 어떻게 관리되고 image layer의 실제 정보를 어디에 존재하는지 알아보겠습니다.

목차

container 구조
image layer 관리
image layer의 실제 위치
image layer 관리 ID 관계 정리
image layer의 ID 간 관계 검증
image layer의 실제 파일 위치 검증

container 구조

우선 container의 구조를 살짝 보겠습니다. 
 
container는 image laygers + container layer 구조로 되어있습니다.
 
아래 그림은 docker 공식 site에 가면 나와있는 그림입니다.
https://docs.docker.com/storage/storagedriver/

다음은 각 layer에 대한 설명입니다.

container layer (R/W)

아무것도 없는 빈 layer입니다.
사용자가 container를 생성하고 난 후 무언가 변경하고 추가를 하면 이를 기록하기 위한 layer입니다.
하지만 container를 종료하면 data는 유지되지 않고 사라져 버립니다.

image layer (R/W)

container의 기반이 되는 layer들로써 container 실행 시 Read Only로만 사용이 됩니다.
container image의 layer들이 그대로 사용이 됩니다. 그리고 container들이 모두 공용으로 사용하는 layer입니다.
 
그럼 이제부터 본격 적으로 container image 구조를 파악해 보겠습니다. Let's Go~

container image구조

container image는  image layer 구조입니다. 
그래서 image layer가 구조인 것을 확인하기 위해서 docker를 사용해서 docker pull로 nginx를 다운로드하여 보도록 하겠습니다. 

image download

image를 download 받는 아래에 명시된 대로 2가지의 방식이 존재합니다.
"image 이름으로 pull 받기"와 "image 이름 + Digest로 pull 받기" 

image 이름으로 pull 받기

image 이름을 통해서 받을 때 사용합니다. 
 
root@master:~# docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
52d2b7f179e3: Pull complete 
fd9f026c6310: Pull complete 
055fa98b4363: Pull complete 
96576293dd29: Pull complete 
a7c4092be904: Pull complete 
e3b6889c8954: Pull complete 
da761d9a302b: Pull complete 
Digest: sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest

image 이름 + Digest로 pull 받기

정확하게 원하는 image를 받을 때 사용 합니다.
 
docker pull [REPOSITORY]@[DIGEST_VALUE]
Ex) docker pull nginx@sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
 
root@master:~# docker pull nginx@sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
docker.io/library/nginx@sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c: Pulling from library/nginx
52d2b7f179e3: Pull complete 
fd9f026c6310: Pull complete 
055fa98b4363: Pull complete 
96576293dd29: Pull complete 
a7c4092be904: Pull complete 
e3b6889c8954: Pull complete 
da761d9a302b: Pull complete 
Digest: sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
Status: Downloaded newer image for nginx@sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
docker.io/library/nginx@sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c

image pull 내용 분석

"image 이름으로 pull 받기" 방식으로 image를 pull 받겠습니다. 
nginx를 pull 받게 되면 여러 개의 image layer를  받습니다. 조금 궁금하니 하나씩 알아보겠습니다. 
 
root@master:~# docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
52d2b7f179e3: Pull complete 
fd9f026c6310: Pull complete 
055fa98b4363: Pull complete 
96576293dd29: Pull complete 
a7c4092be904: Pull complete 
e3b6889c8954: Pull complete 
da761d9a302b: Pull complete 
Digest: sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest
 
Docker 이미지를 pull 하는 과정에서의 출력 메시지를 각 line별로 분석해 보겠습니다:

라인별 설명

1. Using default tag: latest

이 메시지는 특정 태그를 지정하지 않아 `latest` 태그를 기본값으로 사용하고 있다는 것을 나타냅니다.

2. latest: Pulling from library/nginx

Docker Hub에서 nginx 이미지의 latest 태그를 pull 하고 있다는 것을 나타냅니다.
library/nginx는 Docker Hub의 공식 nginx 이미지를 의미합니다.
3. 52d2b7f179e3: Pull complete (및 그 이후의 라인들) 이러한 라인들은 각각의 image layer를 나타냅니다. Docker image는 여러 레이어로 구성되며, 각 Layer는 image의 일부 변경 사항을 나타냅니다. 52d2b7f179e3와 같은 값들은 각 레이어의 ID를 나타냅니다. 이 ID는 해당 layer의 SHA256 해시의 앞부분을 표시한 것입니다. Pull complete 메시지는 해당 레이어가 성공적으로 pull 되었음을 나타냅니다.
참고로 맨 위의 layer가 base image가 됩니다.

4. Digest: sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
이 라인은 image의 고유한 콘텐츠 주소, 즉 digest 값을 나타냅니다. 이 값은 image의 모든 layer의 내용을 기반으로 계산된 해시 값입니다.
참고로 Docker에서는 해시 값을 "digest"라고도 부릅니다.
5. Status: Downloaded newer image for nginx:latest

이 메시지는 nginx:latest 이미지의 새로운 버전이 로컬에 이미 있던 버전보다 새롭다는 것을 나타냅니다. 따라서 새로운 이미지를 다운로드했습니다.

6. docker.io/library/nginx:latest

마지막으로, pull 한 이미지의 전체 경로와 태그를 나타냅니다. 여기서 docker.io는 Docker Hub의 기본 도메인을 나타냅니다.
 
이제 docker image가 pull 되는 과정의 모든 의미를 알아보았으니 각 image layer가 docker에서 어떻게 관리되는지 알아보겠습니다. 

image layer 관리

docker에서는 image layer관리를 위해서 Storage driver를 사용하는데 그중에서  overlay2 사용하여 image layer의 실제 datat를 관리합니다. 
실제로 docker가 어떤 storage drvier는 사용하는지 먼저 확인해 보겠습니다. 

docker storage driver

docker info 명령어를 통해서 docker의 strorage driver확인 가능합니다. 
#docker info
...
Storage Driver: overlay2
Docker Root Dir: /var/snap/docker/common/var-lib-docker
...
 
위 정보를 통해서 docker의 storage driver가 overlay2라는 것을 확인했습니다.
그리고 추가 적으로 Docker Root Dir까지 확인했습니다. {Docker Root Dir}를 확인한 이유는 docker에서의 관리되는 모든 것들은 Docker Root Dir하위에 존재하기 때문입니다. 
 
그럼 이번에는 overlay2의 구조에 자세히 알아보고 난 후 {Docker Root Dir} 하위에서 overlay2가 어떻게 구조를 잡고 있는지도 알아보겠습니다.

overlay2 구조

overlay2 구조 설명 시에는 container를 기준으로 설명하겠습니다. 
overlay2에서는 image layer 및 container의 data를 효율 적인 관리를 위해서 하위 layer와의 차이점만을 directory별로 분류하여 관리합니다. 그리고 핵심은 상위 layer에서 파일의 변경이 발생하면 CoW(Copy-On-Write) 방식으로 관리하는 것입니다.
 
아래 그림은 container에서의 overlay2의 동작 방식입니다.

contianer에서의 overlay2 동작 방식

그럼 container의 맨 하위 layer부터 최상위 layer가 어느 directory에 mapping 되는지 그리고 용도를 알아보겠습니다.

docker container	overlay2 directory	용도
image layer	lowerdir	기존의 Docker image layer들을 관리합니다. 읽기 전용이고,  image가 여러 layer로 구성되어 있는 경우 lowerdir는 콜론(:)으로 구분되어 container image의 meta정보의 LowerDir에 표기가 됩니다. 참고: 하위의 layer가 가장 마지막에 표기가되니다
contianer layer	upperdir	container에서 발생하는 모든 파일 시스템 변경사항을 capture해서 관리하는 용도로 사용됩니다. upperdir에서 관리가 됩니다. 이 directory는 쓰기 가능하며, container에서 파일을 추가, 수정, 삭제하는 경우 해당 변경사항은 여기에 저장됩니다.
container mount	mergeddir	mergeddir는 lowerdir와 upperdir를 합친, 통합된 파일 시스템 뷰를 제공하는 directory입니다. 이 directory를 통해 container는 마치 하나의 파일 시스템에 접근하는 것처럼 동작합니다. 실제로는 여러 container layer가 결합된 뷰이고, 이게 container 에 mount가 되어 보여집니다.
	workdir	이 디렉터리는 overlay2 파일 시스템 연산에 필요한 임시 데이터를 위한 것입니다. 주로 파일 및 디렉터리의 삭제 및 이름 변경과 관련된 일시적인 작업을 처리합니다.

overlay2의 이 구조는 lowerdir를 이용해서 container image의 불변성을 유지하면서도 upperdir를 이용해서 container 내에서의 변경사항을 효과적으로 관리할 수 있게 해 줍니다.
 
그래서 container Layer 구조를 overlay2 파일 시스템과 연결시키면 아래 그림과 같이 됩니다.

 
그럼 overlay2의 구조를  살짝 보았으니 image layer들의 실제 위치를 찾는 것을 해보겠습니다.

image layer의 실제 위치

image layer는 overlay2로 관리되고 있다고 했습니다. 그러므로 overlay2의 directory 위치를 알아내야 합니다.

overlayer2의 directory 위치

nginx를 대상으로 찾아보겠습니다. 
 
아래 명령어를 통해서 우선 overlay2로 관뢰되는 directory의 정보를 찾을 수 있습니다.
 

#docker inspect nginx

overlay2에 대한 정보는 GraphDriver.Data에 나와있습니다. 

아래 사용하면 좀 더 명확하게 볼 수 있습니다.
docker inspect nginx | jq .[0].GraphDriver.Data
{
  "LowerDir": "/var/snap/docker/common/var-lib-docker/overlay2/7dfaf0a3b3f9b71452181b3a6c862e3a2b136ceb2c8ebadbb82ce86d5f9bdbdb/diff:/var/snap/docker/common/var-lib-docker/overlay2/832509c2b53d343996e15fc2da8eeea2f2b3993c2ece270c17791a01a945ebac/diff:/var/snap/docker/common/var-lib-docker/overlay2/4aec24d02b04ef5f4627dc2db456f0dea9a9f30b3bf7cebd1a206ef9a1a99fe3/diff:/var/snap/docker/common/var-lib-docker/overlay2/f5cbe004dd5e4b326b994d9b108b3e5c6ac80b57599a687cca7f00876a07ca6d/diff:/var/snap/docker/common/var-lib-docker/overlay2/7e035679f46cfaff563f1068a881092b03bb1dd2915afa16e9ffcaf0f7d6719c/diff:/var/snap/docker/common/var-lib-docker/overlay2/ab53cde44c000fb51fb67aa1d2f1aba523c2c8e4d8696e41671097b3361e4277/diff",
  "MergedDir": "/var/snap/docker/common/var-lib-docker/overlay2/9fbc56d1a7ec985ba5889602117106e9a24f01f9a02d7ea3ce184501d3eed66b/merged",
  "UpperDir": "/var/snap/docker/common/var-lib-docker/overlay2/9fbc56d1a7ec985ba5889602117106e9a24f01f9a02d7ea3ce184501d3eed66b/diff",
  "WorkDir": "/var/snap/docker/common/var-lib-docker/overlay2/9fbc56d1a7ec985ba5889602117106e9a24f01f9a02d7ea3ce184501d3eed66b/work"
}
 
위 내용을 보면 ovleray2에서 container layer에 mapping 되는 directory가 모두 존재합니다.
LowerDir, MergedDir, UpperDir, WorkDir이 모두 표기가 됩니다. 그리고 우리가 관심 갖고 있는 image layer의 정보를 가지고 있는 LowerDir를 좀 더 살펴보면 뭔가 좀 길게 기록되어 있습니다. 
이유는 위의 Overlay2 구조에서도 설명했지만. Overlay2에서는 image layer가 여러 개의 layer를 되어있으면 각 layer를 개별 directory로 관리하고 이를 Lowerdir에서 :(콜론)으로 구분해서 관리한다고 했기 때문입니다.
보기 편하게 : 기준으로 줄 바꿈 하겠습니다
 
 "LowerDir": 
"/var/snap/docker/common/var-lib-docker/overlay2/7dfaf0a3b3f9b71452181b3a6c862e3a2b136ceb2c8ebadbb82ce86d5f9bdbdb/diff
:/var/snap/docker/common/var-lib-docker/overlay2/832509c2b53d343996e15fc2da8eeea2f2b3993c2ece270c17791a01a945ebac/diff
:/var/snap/docker/common/var-lib-docker/overlay2/4aec24d02b04ef5f4627dc2db456f0dea9a9f30b3bf7cebd1a206ef9a1a99fe3/diff
:/var/snap/docker/common/var-lib-docker/overlay2/f5cbe004dd5e4b326b994d9b108b3e5c6ac80b57599a687cca7f00876a07ca6d/diff
:/var/snap/docker/common/var-lib-docker/overlay2/7e035679f46cfaff563f1068a881092b03bb1dd2915afa16e9ffcaf0f7d6719c/diff
:/var/snap/docker/common/var-lib-docker/overlay2/ab53cde44c000fb51fb67aa1d2f1aba523c2c8e4d8696e41671097b3361e4277/diff",
 
그럼 LowerDir에서는 image layer의 가장 base가 되는 layer가 마지막에 표기된다고 했으니 한번 마지막 directory를 살펴보겠습니다. 
 

directory 이동 

cd  /var/snap/docker/common/var-lib-docker/overlay2/ab53cde44c000fb51fb67aa1d2f1aba523c2c8e4d8696e41671097b3361e4277/diff
 

ls로 확인 

root@master:/var/snap/docker/common/var-lib-docker/overlay2/ab53cde44c000fb51fb67aa1d2f1aba523c2c8e4d8696e41671097b3361e4277/diff# ls

뭔가 여러 개 있습니다. 혹시나 nginx가 있는지 찾아보겠습니다. 

nginx 찾기

find로 찾아보겠습니다. 
 
find ./ -name *nginx*
 
결과.. 없음.. 해당 image layer에는 아직 nginx가 깔리기 전인가 봅니다.  그럼 한 단계 위의 layer로 가보겠습니다. 
한 단계 위의 image layer는  LowerDir에서 미지막  경로 바로 앞에 있는 directory경로 임으로 해당 경로로 이동해 보겠습니다.

 
directory 이동 

cd /var/snap/docker/common/var-lib-docker/overlay2/7e035679f46cfaff563f1068a881092b03bb1dd2915afa16e9ffcaf0f7d6719c/diff

nginx 찾기

여기에 nginx가 있는지 find로 찾아보겠습니다. 
find ./ -name *nginx*

해당 image layer에서 nginx가 추가되었네요.

정리

여기까지의 분석한 것의 결론을 내리면. docker image layer의 실제 data overlayer2로 관리가 되고 관리되는 directory들은  {Docker Root Dir} 경로 하위의 overlayer2/{sha56}/diff 에 존재한다로 결론 내릴 수 있습니다.
 
그러면 이제 또 다른 궁금증이 좀 생깁니다.
docker pull nginx로 받아온 image layer들의 sha256 값과 왜 lowerdir의 sha256 값 들이 다른 것인가? 
아래 정보응 docker pull로 nginx를 받아왔을 때의 정보입니다.
 
root@master:~# docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
52d2b7f179e3: Pull complete 
fd9f026c6310: Pull complete 
055fa98b4363: Pull complete 
96576293dd29: Pull complete 
a7c4092be904: Pull complete 
e3b6889c8954: Pull complete 
da761d9a302b: Pull complete 
Digest: sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest
 

일반적으로 생각했을 때 아래 "docker pull ngnix"에서 받아는 image layer의 가장 하위 layer의 sha256값(da761d9a302b)이
LowerDir의 마지막 directory의 sha256 값과 같아야 할 것 같았습니다.

ab53cde44c000fb51fb67aa1d2f1aba523c2c8e4d8696e41671097b3361e4277 
그러나 다릅니다.
 
그래서 이 부분에 대해서는 "image layer 관리 ID 관계 정리"를 통하여 좀 더 알아보겠습니다. 

image layer 관리 ID 관계 정리

docker (20.10.24)에서는 image layer를 관리하기 위해서
3개의 ID와 4개의 directory를 사용하며 directory의 위치는 {Docker Root Dir} 하위에 존재합니다.

ID 종류

id는 sha256를 사용하여 표기됩니다.

distribution ID

docker pull 시 image layer 앞에 붙은 sha256 값 들입니다.

diff ID (difference identifiers)

image layer의 실제 data들에 대한 SHA256 값입니다. 
docker inspect 명령사용 시 RootFS에서 사용이 됩니다

cache ID

실제 image layer가 존재하는 directory에 대한 ID입니다.

Directory 종류

{Docker Root Dir} 하위 기준 

directory 명칭	목적	설명
/image/overlay2/distribution	ID 연결	distribution id 와 diff id 간의 mapping 정보를 기록
/image/overlay2/imagedb	정보관리	download한 docker image에 대한 meta 정보를 관리
/image/overlay2/layerdb	정보관리	diff ID ,cache ID 관리 docker에서는 image layer관리르 위해서 layerdb를 사용
/overlay2	테이터 관리	cache ID를 사용하여  실제 image layer에대한 파일들이 저장되고 관리

 
그럼 ID 및 Directory들을 기반으로 image layer가 어떻게 연결되었는지 검증을 해보겠습니다. 

image layer의 ID 간 관계 검증

docker pull을 받았을 때의 distribution ID를 모두 봐보겠습니다. 
 
root@master:~# docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
52d2b7f179e3: Pull complete 
fd9f026c6310: Pull complete 
055fa98b4363: Pull complete 
96576293dd29: Pull complete 
a7c4092be904: Pull complete 
e3b6889c8954: Pull complete 
da761d9a302b: Pull complete 
Digest: sha256:104c7c5c54f2685f0f46f3be607ce60da7085da3eaa5ad22d3d9f01594295e9c
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest
 
여기서 제일 base가 되는 image layer의 distribution ID인  52d2b7f179e3 의 ID 간 관계부터 정리하겠습니다.

1단계 : distribution ID와  diff ID 관계 찾기

distribution ID와 diff ID의 관계는 {Docker Root Dir}/image/overlay2/distribution/diffid-by-digest/sha256 하위의 파일명으로 관리되고 있습니다. directory 명에서부터 알 수 있듯이 "digest(distribution ID) 별 diff ID"가 기록되어 있다고 합니다.
 
그래서  {Docker Root Dir}/image/overlay2/distribution/diffid-by-digest/sha256에보이는 파일들은 모두 docker pull 받을 나오는 distribution ID입니다. 

여기서 빨간 박스를 보면 docker pull로 nginx을 받았을 때의 첫 번째 distribution ID가 보입니다. 
그럼 이 파일을 열어서 diff ID를 확인해 보겠습니다.
#cat 52d2b7f179e32b4cbd579ee3c4958027988f9a8274850ab0c7c24661e3adaac5
sha256:511780f88f80081112aea1bfdca6c800e1983e401b338e20b2c6e97f384e4299
 
이번에는 diff ID와 cache-ID의 관계를 찾아보겠습니다.

2 단계 : diff ID와 cache-ID 관계 찾기

diff ID와 cache-ID는 {Docker Root Dir}/image/overlay2/layerdb/ 하위에서 layerDB 형태로 관리되고 있습니다.
그런데 docker에서 layerDB를 어떻게 사용하는지 모르기 때문에 layerDB가 간단히 알아보고 바로 diff ID와 cache-ID 와의 관계를 알아보겠습니다.

docker에서의 layerDB 사용법

docker에서는 "image layer" 당 "layerDB에서 사용하는 layerdb ID"를 연결시켜서 관리하고 있습니다.
그래서 image layer 개수만큼 layerdb ID가 존재합니다. 그리고 layerdb ID로 생성된 directroy안에서 2개의 파일을 사용하여 diff ID와 cach ID를 연결하여 관리하고 있습니다. 
 
그럼 layerdb의 내부를  한번 봐보겠습니다. 

layerdb 관리 파일 종류

layerdb가 관리하는 5개의 파일은 다음과 같습니다. 

파일	내용
cache-id	cache ID가 기록 되어 있습니다.
diff	diff ID가 기록 되어있습니다.
parent	적층순서식별 용
size	image layer의 물리적 크기 (바이트 단위)를 포함합니다.
tar-split.json.gz	Docker 이미지의 tarball 데이터를 처리할 때 중요한 메타데이터를 압축하여 저장한 파일입니다.

layerdb ID directory 내부 확인

layerdb ID directory는 {Docker Root Dir}/image/overlay2/layerdb/sha256에
{Docker Root Dir}/image/overlay2/layerdb/sha256로 이동후 layerdb ID directory를 tree 사용해서 구조를 확인해 보겠습니다.
#tree -L 2

cache-id, diff, parent, size, tar-split.json.gz 가 존재하는 것을 확인할 수 있습니다.
여기서 diff ID와 cache-ID 관계 찾기를 파악하기 위해서 눈여겨봐야 할 거은 cache-id, diff 뿐입니다.

layerdb ID의 내부 diff 정보 학인

{Docker Root Dir}//image/overlay2/layerdb/ 하위 존재하는 모든 diff 파일의 내용을 아래 명령어를 통해서 알아보겠습니다.
 
#find . -name diff -exec cat {} \; -print

검색 내용을 분석해 보면
빨간 박스에는 diff 파일의 내용이 보고이고
초록 박스에서 diff 파일 어느 layerdb ID directory에 존재하는지 보입니다. 
 
여기서 주의 깊게 봐야 할 것은 빨간 박스의 diff ID 값입니다. 현재 빨간 박스의 diff 값은 1단계에서 찾은 diff ID값과 동일합니다.
그럼 이번에는 cache-id 확인을 위해서  검색해 보겠습니다.

layerdb ID의 내부 cache-id 정보 학인

{Docker Root Dir}//image/overlay2/layerdb/ 하위 존재하는 모든 cache-id 파일의 내용을 아래 명령어를 통해서 알아보겠습니다.
 
#find . -name cache-id -exec cat {} \; -print

검색 내용을 분석해 보면
파랑 박스에는 cache-id 파일의 내용이 보고이고
초록 박스에서 cache-id 파일 어느 layerdb ID directory에 존재하는지 보입니다.

ID 관계 정리

결국 정리를 해보면 
distributino id는 diff id와 직접 연결되어 있고
diff id와 cache-id는 layereDB id를 중간 매개체로 하여 간접적으로 연결되어 있다고 결론 내릴 수 있습니다.
 
3개의 nginx의  image layer의 ID관계만 정리해 보면 아래와 같습니다. 

distribution id	diff id	layerDB id	cache-id
52d2b7f179e3	511780f88f8	511780f88f8	8e61cd738
fd9f026c6310	4713cb24ee	49bfd4a4ea	6e9e276d0
055fa98b4363	d0a62f56ef4	c7e60968a	ddb176542

image layer의 실제 파일 위치 검증

image layer의 실제 파일 위치는 cache-id 이름으로 생성된 {Docker Root Dir}/overlay2/{cache-id}/diff에 존재합니다. 

nginx base image 파일 위치 검증

nginx의 base layer에 대한 distributino id 가 52d2b7f179e3 이고 cache-id가 8e61cd738 임으로 
{Docker Root Dir}/overlay2/8e61cd738.../diff  의 경로의 내용을 봐보겠습니다. 
 
#ls {Docker Root Dir}/overlay2/8e61cd738452023074cae0d7fbd9a8a7beba49522f18a19435a35cc90450a04a/diff 

실제 파일들이 잘 들어있습니다. 
 
그런데 이 경로가 익숙하지 않나요?? 그렇습니다.. docker inspect nginx의 LowerDir의 마지막 directory와 일름이 동일합니다.
LowerDir : {Docker Root Dir}/overlay2/8e61cd738452023074cae0d7fbd9a8a7beba49522f18a19435a35cc90450a04a/diff 
cache-id  : {Docker Root Dir}/overlay2/8e61cd738452023074cae0d7fbd9a8a7beba49522f18a19435a35cc90450a04a/diff

nginx  두 번째 image 파일 위치 검증

nginx의 base layer에 대한 distributino id 가 fd9f026c6310이고 cache-id가 6e9e276d0 임으로
{Docker Root Dir}/overlay2/6e9e276d0.../diff  의 경로의 내용을 봐보겠습니다.
 
#ls {Docker Root Dir}/overlay2/6e9e276d03ee28c167c0f164792c902b377d1abd7316ec838a84dc272c28b9c3/diff 

실제 파일이  잘 들어있습니다.
 
그런데 이 경로가 익숙하지 않나요?? 그렇습니다.. docker inspect nginx의 LowerDir의 마지막 directory와 일름이 동일합니다.
LowerDir : {Docker Root Dir}/overlay2/6e9e276d03ee28c167c0f164792c902b377d1abd7316ec838a84dc272c28b9c3/diff
cache-id  : {Docker Root Dir}/overlay2/6e9e276d03ee28c167c0f164792c902b377d1abd7316ec838a84dc272c28b9c3/diff

정리

container image는 여러 image layer로 되어있고 docker에서는 실제 image layer데이터를 overlay2로 관리하고 있습니다. 
그리고 docker에서는 image layer와 overlay2의 연결의 위해서 layerdb를 사용합니다.
 

참고 

https://tech.kakaoenterprise.com/171  읽어보기를 추천합니다. overlay2의 동작 과정이 잘 설명되어 있습니다.

Next Post

[CKA] 33. docker의 volume관리 (volume driver)