docker CLI / Docker Compose
          | Docker API
          v
      dockerd (daemon)
          |
          +-- image / container / network / volume 관리
          +-- registry에서 image pull·push

docker context ls
docker info
docker container ls --all
docker image ls
docker network ls
docker volume ls

client와 daemon

Docker는 client-server 구조입니다. docker CLI와 Docker Compose는 API client이고, dockerd는 요청을 받아 image build·pull·container 실행·network·volume 관리를 수행합니다. client와 daemon은 같은 machine에 있을 수도 있고 SSH·TLS 등으로 remote daemon에 연결될 수도 있습니다.

# CLI가 현재 연결한 daemon의 정보
docker info

# 실제 명령 대상 endpoint 확인
docker context inspect

그래서 docker ps가 비어 있다고 image나 container가 없는 것으로 단정하면 안 됩니다. 현재 context가 local인지 remote인지, Docker Desktop Linux VM인지, 권한 오류로 daemon API를 읽지 못한 것인지를 먼저 분리합니다.

Docker object

docker container rm은 container만 지우고 docker image rm은 local image reference를 지웁니다. image를 쓰는 container가 있거나 다른 tag가 같은 image를 가리키면 image removal이 거절되거나 disk가 예상만큼 줄지 않을 수 있습니다.

docker container rm app
docker image rm my-app:1.2.3
docker system df -v

container의 writable layer는 object의 일부지만 application data를 둘 영속 저장소로 쓰기에는 적합하지 않습니다. data는 volume 또는 외부 storage로 분리하고, object별 목록·inspect·prune 범위를 따로 확인합니다.

권한과 실행 환경

Docker Desktop은 macOS·Windows에서 Linux VM 안에 daemon을 실행합니다. CLI가 native host에 있어도 image storage, Linux container, cgroup resource limit은 그 VM 안에서 동작합니다. Linux Engine에서는 daemon host의 kernel·filesystem·network 설정이 더 직접적으로 영향을 줍니다.

dockerd, containerd, OCI runtime은 구현상 함께 작동하지만, application 운영 판단을 "daemon 재시작에도 container가 항상 유지된다"로 단순화하면 안 됩니다. live restore 설정, daemon version, runtime, restart policy에 따라 영향이 다르므로 maintenance 전에는 해당 host의 Engine 문서와 deployment 정책을 확인합니다.

/var/run/docker.sock 또는 remote daemon API에 접근할 수 있는 주체는 image build, privileged container 실행, host mount 등 강한 권한을 행사할 수 있습니다. socket을 편의상 임의 container에 mount하거나 인증 없는 TCP daemon endpoint를 열지 않습니다.