Quick Comparison
| 대상 | 생성 방법 | 바뀌는가 | 삭제하면 사라지는 것 |
|---|---|---|---|
| image | docker build, docker pull | 같은 image content는 read-only | tag reference를 지워도 다른 reference·container가 남을 수 있음 |
| container | docker run, docker create | writable layer와 runtime state가 생김 | writable layer와 container 설정 |
| named volume | docker volume create 또는 Compose | application data가 바뀜 | explicit volume removal 전까지 유지 |
docker image pull nginx:alpine
docker run -d --name web1 -p 8081:80 nginx:alpine
docker run -d --name web2 -p 8082:80 nginx:alpine
docker image ls nginx
docker ps --filter ancestor=nginx:alpineimage 하나에서 여러 container를 만들 수 있습니다. 같은 image여도 container마다 command, environment, network, mount, writable layer가 다르므로 실제 동작과 data lifetime은 같지 않습니다.
image layer
image는 application file, library, default command, configuration을 layer로 묶은 read-only template입니다. Dockerfile의 FROM, RUN, COPY 같은 build step은 image filesystem의 새 layer를 만들 수 있고, local image store는 같은 content layer를 여러 image가 재사용할 수 있습니다.
docker image history nginx:alpine
docker image inspect nginx:alpinetag는 image를 사람이 찾기 쉽게 붙이는 이름이고 registry에서 다른 content를 가리키도록 바뀔 수 있습니다. 정확한 release를 고정하려면 tag만이 아니라 digest·platform을 기록합니다. tag와 digest 선택은 image digest와 tag pinning 카드에서 다룹니다.
container writable layer
container를 만들면 image의 read-only layer 위에 해당 container만의 writable layer와 runtime configuration이 추가됩니다. file 수정, temporary cache, process가 만든 output은 이 layer에 쌓이고 다른 container와 공유되지 않습니다. container를 restart하면 같은 writable layer가 남지만, docker rm 또는 Compose recreate 후 새 container를 만들면 그 layer는 사라집니다.
docker run -d --name web nginx:alpine
docker exec web sh -c 'echo patched > /usr/share/nginx/html/index.html'
docker restart web # 같은 writable layer는 남음
docker rm -f web
docker run -d --name web nginx:alpine # 새 writable layer, patch 없음runtime에 수정한 container를 docker commit으로 image처럼 저장할 수는 있지만, source code·Dockerfile·build argument·검증 절차가 빠진 snapshot입니다. debugger가 임시 상태를 보존할 때와 team이 재현 가능한 release를 만들 때를 구분하고, product 변경은 Dockerfile과 CI build에 남깁니다.
data lifetime
container writable layer는 DB와 upload data의 영속 저장소가 아닙니다. container가 제거되면 data가 함께 사라지고, image layer에 data를 bake하면 instance 간 공유·backup·migration이 어려워집니다. data는 named volume, bind mount, managed database, object storage처럼 lifecycle이 분리된 storage에 둡니다.
docker run -d --name db \
-e POSTGRES_PASSWORD=password \
--mount type=volume,src=pgdata,dst=/var/lib/postgresql/data \
postgres:17
docker rm -f db
docker volume inspect pgdata # data volume은 유지volume이 data를 자동 backup하거나 database consistency를 보장하는 것은 아닙니다. DB backup, retention, encryption, restore rehearsal은 storage와 application에 맞춰 별도로 설계합니다.
container 안을 고쳐서 문제를 해결한 뒤 docker restart만 해 보면 patch가 남아 정상처럼 보일 수 있습니다. deploy의 recreate, scale-out, host 교체에서도 동일하게 동작하려면 변경을 image build 또는 runtime configuration으로 옮기고 data는 volume 밖에서 검증하십시오.
참고 링크
3 sources