[도커 & 쿠버네티스] 도커 이미지

목차 (OPEN)

• 🖼️ 이미지
• 1️⃣ 이미지의 본질
• 2️⃣ 이미지와 컨테이너의 관계
• 💡 비유하자면
• 📦 컨테이너 이미지의 내부 구조
• 🧱 레이어(Layer)
• ⚙️ Config JSON
• 📜 Manifest
• 📚 결론

 

 

 

 

🖼️ 이미지

1️⃣ 이미지의 본질

이미지는 작은 리눅스나 가벼운 VM이 아니라,

컨테이너 실행을 위한 설계도와 재료 꾸러미에 가깝다.

 

즉, 안에는 운영체제 전체가 들어있는 것이 아니라,

필요한 파일시스템 스냅샷(레이어들의 모음)과 실행 환경을 정의하는 설정(config)이 담겨있다.

 

따라서 이미지는 불변(Immutable)한 상태로 저장되며,

동일한 이미지라면 누구나 같은 컨테이너를 만들 수 있다.

 

---

2️⃣ 이미지와 컨테이너의 관계

이미지는 정적(Static)인 존재이다.

즉, 실행 전에 준비된 상태이고, 해시 값으로 고유하게 구분된다.

 

그러나 컨테이너는 동적(Dynamic)인 존재이다.

이미지를 기반으로 실제 프로세스(PID 1)를 실행하면서 살아 움직이는 상태를 뜻한다.

 

따라서 컨테이너가 종료되면 실행 중인 데이터는 사라지지만,

이미지는 그대로 남아 있기에 재사용이 가능하다.

 

 

---

💡 비유하자면

• 이미지 = 레시피+ 재료 상자
  (어떤 음식을 만들지, 어떤 재료가 필요한지 정리된 문서와 묶음)
• 컨테이너 = 실제로 조리 중인 음식
  (레시피와 재료를 꺼내와서 주방에서 조리하는 상태)

 

이처럼 레시피(이미지)는 그대로 남아 있어서 같은 음식을 여러 번 만들 수 있지만,

조리 중인 음식(컨테이너)은 먹고 치우면 사라져버리는 것과 비슷하다고 이해하면 된다.

 

---

📦 컨테이너 이미지의 내부 구조

컨테이너 이미지는 단순히 프로그램 파일을 묶어놓은 압축 파일이 아니다.

내부를 살펴보면 OCI(Open Container Initiative) Image 스펙이라는 표준에 따라 정해진 구조를 따른다.

 

정확히는 아래의 4가지 구조를 포함하는데, 각각을 좀 더 자세히 살펴보자.

 

---

🧱 레이어(Layer)

레이어는 파일 시스템 변경점(diff)을 담은 묶음이다.

보통 tar 형태로 저장되고, 읽기 전용이라서 바뀌지 않는다.

 

---

그렇다면 왜 '변경점'이라고 부를까?

이미지가 누적되는 과정에서 각 단계가 새로운 전체 복사본이 것이 아니라
그 순간의 차이만 기록하기 때문에 변경점이라고 부른다.

 

 

이미지는 여러 단계의 작업으로 만들어지는데,

예를 들어서 Dockerfile이 아래와 같이 생겼다고 해보자.

FROM ubuntu:20.04                              # (A) 우분투 기본 파일 시스템
RUN apt-get update && apt-get install -y curl  # (B) 패키지 추가
COPY app/ /app                                 # (C) 내 애플리케이션 복사

 

• (A) 단계 👉🏻 기본 우분투 파일 시스템이 하나의 큰 레이어가 된다.
• (B) 단계 👉🏻 curl 같은 패키지를 추가하며, 새로운 레이어가 위에 쌓인다.
• (C) 단계 👉🏻 /app 에 파일을 복사한 내용이 또 새 레이어가 된다.

즉, 각 명령이 '이전까지의 상태 + 이번 변경'이라는 새로운 레이어를 위에 얹는다고 보면 된다.

 

---

그렇다면 이것들이 어떻게 합쳐서 하나의 파일 시스템이 되는 걸까?

Union File System 덕분에 파일 시스템은 여러 읽기 전용 레이어를 겹쳐서 하나로 합쳐 보이게 만들고,
그 위에 얇은 쓰기 전용 레이어를 얹는 방식으로 동작한다.

 

 

컨테이너를 시작할 때, 런타임은 여러 읽기 전용 레이어를 위에서 아래로 겹쳐서 하나의 루트 파일시스템처럼 보이게 만든다.

그리고 맨 위에 컨테이너 전용의 얇은 쓰기 가능한 레이어를 임시로 올린다. 

[컨테이너 실행 시 보이는 FS]
┌──────────────────────────┐ ← (쓰기 가능) 컨테이너 레이어 (임시, 컨테이너 종료 시 사라짐)
├──────────────────────────┤ ← 레이어 C (ex. app 복사)
├──────────────────────────┤ ← 레이어 B (ex. curl 설치)
├──────────────────────────┤ ← 레이어 A (ex. ubuntu:20.04 기본)
└──────────────────────────┘

 

이처럼 읽기 전용 레이어들은 그대로 두고,

컨테이너에서 파일을 수정, 추가, 삭제하면 그 변화는 맨 위의 쓰기 레이어에만 기록된다.

 

또한, 파일 삭제 같은 동작은 내부적으로 화이트아웃 같은 방식으로 표시되어,

아래 레이어에 있던 파일이 가려진 것처럼 보인다.

 

---

⚙️ Config JSON

이미지 안에는 파일만 들어있는 게 아니라 '어떻게 실행할지'에 대한 기본 설계도가 함께 들어있는데,

이 설계도가 바로 Config Json이다.

 

컨테이너를 띄울 때 런타임이 이 정보를 기본값으로 사용하고,

docker run 옵션이 있으면 그것으로 덮어씌워(override) 실행한다.

 

정리하자면, Config JSON은 실행 기본값의 묶음이다.
                   (ex. ENTRYPOINT, CMD, ENV, USER, WORKDIR 등)

 

 

---

📍 참고사항

• ENTRYPOINT: 실행할 프로그램을 지정
• CMD: ENTRYPOINT에 넘길 기본 인수, 또는 ENTRYPOINT가 없을 때 기본 실행 프로그램을 가리킴

만약 아래와 같이 ENTRYPOINT와 CMD가 둘 다 있으면, 그냥 두 개가 합쳐져서 실행된다.

ENTRYPOINT ["nginx", "-g"]
CMD ["daemon off;"]

 👉🏻 nginx -g "daemon off;"

 

• ENV: 실행 환경 변수
• USER: 어떤 사용자로 실행할지
• WORKDIR: 기본 작업 디렉터리

 

---

이러한 Config JSON은 어디서 생길까?

대부분은 Dockerfile 지시어로부터 자동 생성된다.

 

예를 들어 아래와 같은 Dockerfile이 있다고 해보자.

FROM ubuntu:22.04
ENV APP_ENV=prod
WORKDIR /app
COPY bin/server /app/server
EXPOSE 8080
USER 1001
ENTRYPOINT ["/app/server"]
CMD ["--port","8080"]

 

빌드 시 Config JSON에는 아래와 같은 정보가 들어갈 것이다.

• Env=['"APP_ENV=prod", ...]
• WorkingDir="/app"
• ExposedPorts={"8080/tcp":{ }}
• User="1001"
• Entrypoint=["/app/server"]
• Cmd=["--port", "8080"]

 

런타임에서는 이 값들이 기본값이 되고, 만약 docker run 옵션이 있다면 해당 항목만 덮어쓰게 된다.

 

---

📜 Manifest

Manifest는 '이 이미지가 어떤 Config와 어떤 Layer(Blob)들로 구성되어 있는지'를 정확히 가리키는 청사진이다.

 

컨테이너 런타임은 pull할 때 먼저 Manifest를 받아보고,

거기에 적힌 다이제스트(sha256) 목록을 따라 실제 블롭들을 내려받아 검증한다.

 

이러한 Manifest에는 아래의 항목들이 담긴다.

• schemaVersion / medisType (스펙 버전 / 유형)
• Config Json의 위치
• 이미지 파일 시스템을 이루는 레이어들의 위치(다이제스트) 목록

 

대충 매우 간단하게 예시를 들어보자면 아래와 같을 것이다.

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:...config...",
    "size": 1234
  },
  "layers": [
    {"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip","digest":"sha256:...A...","size":111},
    {"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip","digest":"sha256:...B...","size":222}
  ]
}

 

핵심은 결국 Manifest는 config + 여러 layer의 다이제스트 목록으로 구성된다는 것이다.

다이제스트로 모든 것을 식별하기 때문에 불변성과 무결성, 캐시가 보장된다.

 

---

그렇다면 Manifest List(= Image Index)란 무엇일까?

 

하나의 이미지 이름 아래에 여러 아키텍처(amd64, arm64, arm/v7 등) 혹은 여러 OS(리눅스, 윈도우) 버전을 묶어두는

상위 인덱스가 Manifest LIST 이다(OCI에서는 Image Index).

 

이는 사용자가 docker pull nginx:latest 를 실행할 때,

클라이언트의 플랫폼 정보에 맞는 개별 Manifest를 자동으로 선택해주기 때문에 필요하다.

 

예를 들어서 x86 서버에는 자동으로 amd64용 Manifest를 선택해주고,

M1, M2 맥에는 자동으로 arm64용 Manifest를 선택해준다.

 

 

매우 축약한 간단한 예시를 보면 아래와 같을 것이다.

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:...amd64...",
      "platform": {"os":"linux","architecture":"amd64"}
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:...arm64...",
      "platform": {"os":"linux","architecture":"arm64","variant":"v8"}
    }
  ]
}

 

여기에서 핵심은 Index란 여러 플랫폼용 Manifest들의 목록이고,

클라이언트는 자신의 플랫폼에 맞는 엔트리를 자동 선택한다는 것이다.

 

---

📚 결론

• 이미지는 작은 운영체제가 아니다.
  • 처음에는 이미지 안에 OS 전체가 들어있는 줄 알았지만, 사실은 파일 시스템 변경점(Layer)과 Config JSON, Manifest, Index 같은 메타 데이터가 합쳐진 불편 템플릿이었다.
• 레이어는 변경점의 기록이다.
  • 각 Dockerfile 명령이 새로운 전체 복사본을 만드는게 아니라 '이전 상태 + 새로운 변경'만 기록된다는 점이 효율성과 캐싱의 핵심이라는 것을 알 수 있었다.
  • 아마 이게 바로 도커가 빠르고 저장공간도 절약하는 이유일 것이다.
• Config JSON의 역할
  • 단순히 파일만 담는 게 아니라, 컨테이너가 실행될 때 어떤 프로그램을 띄우고 어떤 환경에서 실행할지에 대한 기본값을 정의한다는 것을 알 수 있었다.
  • 덕분에 docker run 만으로도 바로 실행 가능한 환경이 만들어지는 것이다.
• Manifest와 Index의 중요성
  • Manifest는 이미지의 청사진 역할을 하고, Index는 멀티아키텍처 환경에서 자동으로 맞는 이미지를 가져올 수 있게 해준다.
  • 이 덕분에 동일한 nginx:latest 라는 이름으로도 x86 서버와 ARM 서버에서 각각에 맞는 바이너리를 쓸 수 있는 것이다.

 

오늘 정리한 내용을 통해서 앞으로는 단순히 docker pull 만 하고 쓰는게 아니라

"이 이미지의 레이어는 어떻게 구성되어 있을까?", "Config JSON에 어떤 기본값이 들어가 있을까?" 같은 시선으로 바라볼 수 있을 것 같다.

 

그러나 아직은 너무 어렵긴 해서 오늘 포스팅한 내용은 더 공부해봐야겠다 .. (ŏ̥̥̥̥ ɞŏ̥̥̥̥)