Docker Image Container Volume Network
3줄 요약
- Docker 운영은 Spring 애플리케이션을 image라는 불변 산출물로 만들고, container라는 교체 가능한 실행 단위로 띄우며, volume과 network로 상태와 연결을 분리하는 일이다.
- 핵심은
docker run 명령을 외우는 것이 아니라 image, container, volume, network 중 어디가 실패했는지 나누어 보고 안전하게 재배포하거나 복구하는 것이다.
- 백엔드 개발자는 Dockerfile, image tag/digest, container env, mount, port mapping, log, health check를 통해 장애 중 재현 가능한 증거를 제공해야 한다.
핵심 정리
- Image는 실행 파일과 런타임을 묶은 불변 artifact다. 같은 tag를 재사용하면 rollback과 장애 분석이 어려워지므로 Git SHA, release tag, digest로 추적해야 한다.
- Container는 image의 실행 인스턴스다. container 내부 filesystem은 사라질 수 있으므로 업로드 파일, DB 데이터, 영속 로그를 내부에만 두면 안 된다.
- Volume은 container 교체와 데이터 보존을 분리하는 장치다. named volume, bind mount, backup 대상, 소유권을 명확히 하지 않으면 데이터 유실이 생긴다.
- Docker network와 port mapping은 container 내부 port, host port, Nginx/LB upstream, firewall을 연결한다.
localhost가 어디 기준인지 헷갈리면 장애 분석이 늦어진다.
- Docker 디버깅은 image, container status, logs, env, mount, network, health, resource 순서로 나눠 본다. 한 번에 재빌드하거나 재시작하면 증거가 사라질 수 있다.
헷갈리는 지점
- Docker image와 container를 같은 것으로 보기 쉽다.
- 핵심은 image는 배포 가능한 산출물이고 container는 실행 중인 프로세스와 filesystem 상태라는 점이다.
- volume을 쓰면 무조건 데이터가 안전하다고 생각하기 쉽다.
- 핵심은 volume 이름, mount 위치, 백업 절차, owner 권한이 맞아야 데이터 보존이 실제로 성립한다는 점이다.
- port mapping을
8080:8080 한 줄로만 이해하기 쉽다.
- 핵심은 왼쪽은 host port, 오른쪽은 container port이며 Nginx, firewall, Spring
server.port와 함께 맞아야 한다는 점이다.
확인 질문
- Docker 장애를 볼 때 가장 먼저 나눌 축은 무엇인가?
- image/tag/digest, container status, env/config, mount/volume, network/port, logs, resource 상태를 나누어 본다.
- container 내부에 데이터를 저장하면 위험한 이유는 무엇인가?
- container 삭제, 재생성, image 교체 때 내부 writable layer가 사라질 수 있어 업로드 파일이나 DB 데이터가 유실될 수 있기 때문이다.
- 인프라 담당자에게 Docker 문제를 공유할 때 필요한 증거는 무엇인가?
- image tag/digest, container id/status, env key, mount 정보, port mapping, docker logs, health check 결과, 최근 재시작 시각이다.