핵심 정리

# CLI(클라이언트)가 데몬으로 명령을 전달하는 흐름
docker info          # 데몬 상태 확인
docker ps            # 컨테이너 객체 목록
docker images        # 이미지 객체 목록
docker network ls    # 네트워크 객체 목록
docker volume ls     # 볼륨 객체 목록

구조 이해

어떤 Docker 구조 요소를 먼저 떠올리면 되나

CLI와 데몬의 분리 — 명령을 내리는 쪽과 실제로 처리하는 쪽이 다르다

터미널에서 입력하는 docker 명령은 Docker CLI 바이너리를 실행하는 것입니다. CLI는 실제로 컨테이너를 만들거나 이미지를 내려받지 않습니다. 대신 Unix 소켓(/var/run/docker.sock)이나 TCP를 통해 Docker 데몬(dockerd)에 REST API 요청을 보냅니다. 데몬이 요청을 받아 실제 작업을 수행합니다.

# 데몬이 실행 중인지 확인
systemctl status docker

# 소켓을 통해 데몬 API 직접 호출 (CLI 없이)
curl --unix-socket /var/run/docker.sock http://localhost/version

Docker 객체 — image, container, volume, network가 핵심 4가지다

Docker 데몬이 관리하는 리소스를 "객체"라고 부릅니다. 이미지는 컨테이너의 읽기 전용 청사진이고, 컨테이너는 이미지로부터 생성된 실행 단위입니다. 볼륨은 데이터 영속성을, 네트워크는 컨테이너 간 통신을 담당합니다. 모든 docker 명령은 이 객체 중 하나를 대상으로 동작합니다.

# 객체별 서브커맨드 구조
docker image ls
docker container ls
docker volume ls
docker network ls

이미지와 컨테이너는 이름이 비슷해도 수명과 명령이 다르다

이미지는 템플릿이고, 컨테이너는 그 이미지로부터 만들어진 실행 인스턴스입니다. 그래서 docker rm은 컨테이너를 지우고, docker image rm은 이미지를 지웁니다. 디스크 공간을 정리하고 싶은데 컨테이너만 삭제하면 이미지 레이어는 그대로 남아 있을 수 있습니다.

# 컨테이너 삭제
docker rm app

# 이미지 삭제
docker image rm my-app:latest

containerd와 runc — 실제 컨테이너 실행은 데몬이 아니라 런타임이 담당한다

dockerd는 요청을 받아 처리하지만, 컨테이너를 직접 실행하지는 않습니다. 데몬은 containerd에 컨테이너 생성을 위임하고, containerd는 OCI 런타임인 runc를 통해 실제 리눅스 네임스페이스와 cgroup을 생성해 프로세스를 격리합니다. 이 분리 덕분에 데몬을 재시작해도 실행 중인 컨테이너가 영향을 받지 않습니다.

Docker CLI
    ↓ REST API (/var/run/docker.sock)
dockerd (Docker 데몬)
    ↓
containerd (컨테이너 라이프사이클 관리)
    ↓
runc (OCI 런타임, 실제 프로세스 격리)

체크포인트

주의할 점

docker rm app
docker images
# 이미지가 그대로 남아 있어 디스크 사용량은 거의 줄지 않을 수 있음