At a Glance
| 질문 | Docker에서 확인할 대상 | 바로 할 일 |
|---|---|---|
| 실행 환경을 동일하게 나누고 싶은가 | image | Dockerfile·tag·digest를 관리 |
| 그 환경을 실제 process로 실행할 것인가 | container | runtime option·network·volume 지정 |
| DB data를 container 교체 뒤에도 남길 것인가 | volume 또는 외부 storage | writable layer 밖에 저장 |
| host OS와 kernel이 다를 수 있는가 | platform | target OS/architecture compatibility 확인 |
docker image pull nginx:alpine
docker run -d --name web -p 8080:80 nginx:alpine
docker logs webcontainer는 image와 runtime configuration으로 만든 격리된 process입니다. Docker는 image build·distribution·container lifecycle·network·volume 관리를 하나의 CLI와 API로 묶어 주지만, OS/CPU platform과 security boundary까지 자동으로 같게 만들지는 않습니다.
실행 환경의 단위
image는 application binary, library, file, default command 같은 실행 환경을 묶은 read-only package입니다. container는 그 image에 environment, mount, network, user, resource limit을 더해 만든 실행 instance입니다. 같은 image라도 runtime option이 다르면 다른 동작을 할 수 있습니다.
# 동일 image, 다른 runtime configuration
docker run --name api-dev -e LOG_LEVEL=debug my-api:1.2.3
docker run --name api-prod -e LOG_LEVEL=info --read-only my-api:1.2.3container의 writable layer는 instance마다 분리되지만, container 삭제·recreate 뒤에도 data가 남아야 하면 volume 또는 external storage를 사용합니다. image와 container의 data lifetime 차이는 이미지와 컨테이너 차이 카드에서 다룹니다.
VM과 격리 범위
Linux container는 host kernel의 namespace와 cgroup 기능을 사용해 process, network, mount, resource를 격리합니다. VM은 hypervisor 위에 guest OS kernel을 별도로 둡니다. 따라서 container는 일반적으로 guest OS 전체를 boot하지 않고 빠르게 시작할 수 있지만, host kernel과 runtime 취약점의 영향을 공유하는 security boundary입니다.
VM: host hardware -> hypervisor -> guest OS kernel -> application
Linux container: host kernel -> namespace/cgroup -> application processmacOS·Windows의 Docker Desktop은 Linux container를 native kernel에서 직접 실행하지 않고 Linux VM 안에서 실행합니다. Windows container와 Linux container의 OS compatibility, linux/amd64와 linux/arm64의 architecture compatibility는 image reference와 target platform을 함께 확인해야 합니다.
재현성과 한계
image layer는 local image store에서 재사용될 수 있어 build·pull의 중복을 줄입니다. 그러나 tag는 registry에서 이동할 수 있고, build context, secret, environment variable, database data, host mount, external API까지 image에 들어가지는 않습니다. release를 재현하려면 image digest와 runtime configuration·platform·data migration을 함께 기록합니다.
# 대상 platform을 명시해 실행 image를 확인
docker image pull --platform=linux/arm64 nginx:alpine
# 실제 image reference와 container 설정 확인
docker image inspect nginx:alpine
docker inspect webOCI image format은 여러 container tool이 호환할 수 있는 공통 기반이지만, 모든 Docker feature·network·storage driver·CPU architecture가 runtime마다 동일하다는 보장은 아닙니다. 다른 runtime 또는 host로 옮길 때는 image portability와 runtime compatibility를 구분합니다.
container는 VM과 같은 완전한 OS boundary가 아니며, image만으로 production이 재현되는 것도 아닙니다. untrusted code, host socket, privileged mode, kernel capability는 별도 security policy로 다루고, persistent data는 container layer 밖에 둡니다.
참고 링크
3 sources