Docker Platform

Docker는 application을 host별 설치 상태와 분리해 build·run·share하는 container platform이다. "VM보다 가벼운 실행 파일"로만 이해하면 image build, runtime isolation, data persistence라는 서로 다른 책임을 한 덩어리로 섞기 쉽다. 이 page는 그 세 책임을 어디서 나눠야 하는지 정리한다.

아키텍처: client가 daemon에 요청하고 daemon이 object를 관리한다

flowchart LR
    C[Docker client / Compose] -->|API request| D[Docker daemon]
    D --> I[Image]
    D --> R[Registry]
    D --> CT[Container]
    CT --> N[Network]
    CT --> V[Volume]

• Docker는 client-server architecture다. client(또는 Docker Compose)가 REST API로 daemon(dockerd)에 요청을 보내고, client와 daemon은 UNIX socket 또는 network interface로 통신하며 같은 system에 있을 수도, 서로 다른 system에 있을 수도 있다.^[1]
• daemon은 Docker API request를 받아 image·container·network·volume 같은 Docker object의 lifecycle을 관리한다.^[2]

image는 배포 입력, container는 그 입력의 실행 인스턴스다

• image는 container를 만들기 위한 instruction을 담은 read-only template이고, container는 그 image의 runnable instance다. Dockerfile의 각 instruction이 image의 한 layer가 되며, Dockerfile을 바꾸고 rebuild하면 변경된 layer만 다시 build된다.^[3]
• registry는 image를 저장·배포하는 역할이며, volume은 container lifecycle과 분리해 data를 유지할 때 사용한다.
• Wiki에서의 핵심 구분은 image는 재현 가능한 배포 입력, container는 그 입력의 실행 인스턴스, volume/network은 실행 중 외부와 맺는 상태·통신 경계라는 점이다. Dockerfile과 build cache, multi-stage build는 image를 어떤 입력에서 만들지의 문제고, Compose는 여러 container를 application 단위로 함께 선언·실행하는 문제다. 같은 Docker ecosystem에 있지만 목적이 다르므로 하나의 command recipe로 일반화하지 않는다.

Docker 공식 학습 경로 자체가 이 구분을 따른다: container/image/registry/Compose를 "기초"로, Dockerfile·build cache·multi-stage build를 "image building"으로, port publishing·persistent data·multi-container application을 "running container"로 별도 묶음에 둔다.^[4]

Compose는 multi-container application의 선언 모델이다

• Docker Compose는 compose.yaml에서 multi-container application의 service를 선언하고 CLI로 함께 lifecycle을 관리하는 model이다. Service는 같은 image와 configuration을 한 번 이상 실행해 구현할 수 있는 application component이며, service는 network를 통해 통신하고 persistent data가 필요한 component에는 volume을 붙인다.^[5]
• Compose는 multi-container application의 local/declarative model이지 production orchestration, secret policy, deployment platform을 자동으로 결정하는 개념은 아니다.
• 이 정리는 공식 문서의 architecture와 learning path를 재조합한 것이다. Kubernetes, registry별 policy, production security hardening은 현재 source 범위 밖이다.

적용 범위와 경계

• Container는 VM과 동일한 isolation model이 아니며, host kernel·runtime security model의 세부 차이는 이 page에서 다루지 않는다.
• Docker는 CI platform이 아니다. CI의 event trigger, job scheduling, permission은 GitHub Actions Workflow의 책임이다.
• Build cache의 invalidation rule은 Docker Build Cache Design에서 다룬다. Compose service의 전체 syntax와 image hardening은 후속 source가 추가될 때 확장한다.

실패 모드

• image와 container를 같은 것으로 취급해, source 변경 후 rebuild가 필요한지 running container restart만으로 충분한지 판단하지 못하는 경우.
• database data를 container writable layer에만 두어 container replacement 때 persistence 경계를 잃는 경우.
• Docker daemon access를 단순 local command 권한으로 보고 remote API 또는 socket access의 control boundary를 누락하는 경우.

관련

• GitHub Actions Workflow — CI job은 Docker image build·test·publish를 step으로 실행할 수 있지만, 실행 orchestration과 workflow control은 별도 책임이다.
• Prometheus — Dockerized application도 metric endpoint를 노출할 수 있으나, container packaging은 monitoring 수집 책임을 대체하지 않는다.
• Docker Build Cache Design — image build의 cache boundary와 CI build cost를 다룬다.
• Virtualization and Hypervisors — 이 page가 범위 밖으로 둔 container와 VM의 격리 모델 차이(커널 공유, namespace·cgroup, 이기종 OS 불가)를 다룬다.

출처

테스트 질문

• Docker daemon, image, container, registry, volume은 각각 어떤 lifecycle 책임을 가지는가?
• image build 문제와 running container의 data persistence 문제를 왜 같은 troubleshooting 단계로 다루면 안 되는가?