docker registry file structure

2020-11-19

Docker registry 내부 구조

이번에는 private registry에 도커 이미지를 저장하였을 때 이미지가 저장되는 구조에 대해서 살펴본다. 먼저 간단한 registry를 구동하는데, registry 내부의 디렉토리 구조를 살펴보기 위하여 docker volume(-v) 옵션을 이용하여 registry 내부의 데이터 디렉터리 경로를 호스트 환경으로 노출시켜서 구동하도록 하자.

1	$ docker run -d --name=registry -p 5000:5000 -v $PWD/registry:/var/lib/registry registry:latest

docker registry의 기본적인 데이터 디렉토리 위치는 /var/lib/registry 이며 해당 경로는 registry config 파일을 수정하여 변경 가능하다. 최초 registry를 구동한 시점에서는 해당 경로에 기본적으로 생성되는 파일이나 디렉토리는 없지만, 이미지가 push 된 시점부터 해당 경로에 이미지와 관련된 파일이 생성된다.

아무런 파일도 없으면 디렉토리 구조를 살펴볼 수 없으므로, 여기서는 테스트를 위해 로컬 환경에 registry를 구동하고 태그를 변경하여 임의의 localhost:5000/HARANG:latest 이라는 이름의 이미지를 registry에 push 하였다. push 후에 tree 명령어를 이용하여 디렉토리 구조를 출력한 결과는 아래와 같다.

registry/
└── docker
    └── registry
        └── v2
            ├── blobs
            │   └── sha256
            │       ├── 1c
            │       │   └── 1c889e8ec921d2ebb0c6730d06943b96269194f3f50d1ada90c903a99e58d8d1
            │       │       └── data
            │       ├── 20
            │       │   └── 2071770b9246dde806828d558bcaea76ce3d07654691ffe1a71d64175113e185
            │       │       └── data
            │       ├── ae
            │       │   └── aed400a7ca9e93f9219bec5740ca3b5b70d4dda6b38023c1021dd6a2500997ca
            │       │       └── data
            │       └── b5
            │           └── b5464cb6b67eb599fa7da169d3f31d239540205aeba7689df57a419f16da48da
            │               └── data
            └── repositories
                └── HARANG
                    ├── _layers
                    │    └── sha256
                    │        ├── 1c889e8ec921d2ebb0c6730d06943b96269194f3f50d1ada90c903a99e58d8d1
                    │        │   └── link
                    │        ├── 2071770b9246dde806828d558bcaea76ce3d07654691ffe1a71d64175113e185
                    │        │   └── link
                    │        └── b5464cb6b67eb599fa7da169d3f31d239540205aeba7689df57a419f16da48da
                    │            └── link
                    ├── _manifests
                    │    ├── revisions
                    │    │   └── sha256
                    │    │       └── aed400a7ca9e93f9219bec5740ca3b5b70d4dda6b38023c1021dd6a2500997ca
                    │    │           └── link
                    │    └── tags
                    │        └── latest
                    │            ├── current
                    │            │   └── link
                    │            └── index
                    │                └── sha256
                    │                    └── aed400a7ca9e93f9219bec5740ca3b5b70d4dda6b38023c1021dd6a2500997ca
                    │                        └── link
                    └── _uploads

위 tree구조를 분석해보자. 먼저 기준 디렉토리인 registry 밑으로 /docker/registry/v2 까지의 디렉토리명은 docker registry v2 에서 이미 지정되어 있다. 그 하위 디렉토리는 blob 과 registry로 나누어진다.

blob 은 Binary Large Object의 약자로 대용량 바이너리(이진) 객체를 저장하기 위한 파일 형식이다. 주로 기존의 데이터베이스에 저장하기 어려운 이미지, 동영상 등의 바이너리 데이터를 담는 개체이며 여기서는 실제 docker image 를 물리적으로 나누어 blob 파일로 저장하고 있다. 따라서 현재 push한 이미지 HARANG은 4개의 blob 파일로 나누어져서 registry에 저장됨을 확인할 수 있다. 각각의 blob 파일들은 서로 겹치지 않는 해쉬값으로 분류되어 해쉬값과 동일한 디렉토리 이름으로 저장된다. 즉 1개의 이미지는 N개의 blob 파일로 나누어져 저장되며 추가적으로 이 blob 파일들 중에는 1)해당 이미지의 Dockerfile 정보를 포함하고 있는 blob파일과, 2)이미지의 레이어 구성정보를 포함하고 있는 blob파일(이하 meta blob)도 포함되어 있다. 위 예제의 경우 동일한 색깔로 해당 blob파일을 표시하였다.

blob 이 실제 물리적인 데이터를 저장하는 공간이라면, repositories 디렉토리는 주로 이미지의 구성 정보, 이력, 태그 등에 대한 메타 정보를 나누어 저장하고 있다. registry는 먼저 1단계 구분으로 image의 이름을 기준으로 분류한다. 현재는 1개의 이미지만 push 하였기 때문에 위의 tree 구조에서는 repositories 항목 하위에 바로 HARANG 이라는 디렉토리가 하나만 존재 하고 있다. 좀 더 하위의 디렉토리를 확인해보면 ‘_layer’, ‘_manifests’, ‘_uploads’의 3개의 디렉토리로 나누어진다.

‘_layer’ 디렉토리는 meta blob(이미지 구성정보를 포함하고 있는 blob)을 제외한 다른 모든 blob파일의 경로를 보유하고 있다. 위 예제에서도 blob 하위의 4개 layer 중 이미지 구성정보를 담고 있는 ae(로 시작하는) layer 를 제외한 다른 3개의 blob 파일에 대한 정보를 표시하고 있는 것을 확인할 수 있다.

‘_manifest’ 디렉토리는 이미지의 메타 정보를 관리하고 있다. ‘_layer’ 가 실제 이미지의 물리적 경로를 보유하고 있다면, ‘_manifest’는 특정 이미지가 현재 어떤 태그를 가지고 있으며, 어떤 이미지 레이어들로 구성되어 있는지에 대한 메타 정보를 가지고 있다. 하위의 revision 디렉토리에서는 메타 정보를 담고 있는 ae layer를 가지고 있는 것을 확인할 수 있다. 또한 태그에 대한 정보도 가지고 있는데, 위의 경우 HARANG이라는 이미지의 latest 태그 정보를 표시하고 있다. 하위의 index 디렉토리에는 (이미지가 같은 태그로 overwrite 되었을 경우) 해당 태그로 들어온 모든 meta blob 주소를 가지고 있으며, current 디렉토리에서는 그 index 중에서 가장 마지막에 overwrite 된 meta blob 의 주소를 가지고 있다.

‘_upload’ 디렉토리는 업로드가 진행되고 있는 이미지의 임시 파일을 저장한다. 정상적으로 이미지가 push 되는 경우에는 비어있지만, push 가 진행되는 동안 temp 파일들이 쌓이는것을 확인할 수 있다. 또한 registry api를 이용하여 layer 단위로 이미지를 push 하는 경우에도 하나의 manifest로 묶이기 전의 layer 파일들은 이 디렉토리 하위에서 확인할 수 있다. registry api 를 이용한 push는 다른 주제로 별도로 정리되어 있다.

uncategorized

Docker registry 내부 구조