┌────────────────────────────────────────────────────┐
│  컨테이너 레이어 (읽기/쓰기 가능)                     │  ← docker run 시 생성
├────────────────────────────────────────────────────┤
│  레이어 4: COPY . /app (앱 소스코드)                 │  ← 읽기 전용
├────────────────────────────────────────────────────┤
│  레이어 3: RUN pip install -r requirements.txt      │  ← 읽기 전용
├────────────────────────────────────────────────────┤
│  레이어 2: RUN apt-get install python3             │  ← 읽기 전용
├────────────────────────────────────────────────────┤
│  레이어 1: FROM ubuntu:22.04 (베이스 이미지)          │  ← 읽기 전용
└────────────────────────────────────────────────────┘

컨테이너에서 파일 읽기:
  1. 최상위 쓰기 레이어 확인
  2. 없으면 아래 레이어 순서대로 탐색
  3. 처음 발견된 파일 반환

컨테이너에서 파일 수정(Copy-on-Write):
  1. 해당 파일을 하위 읽기 전용 레이어에서 쓰기 레이어로 복사
  2. 쓰기 레이어에서 파일 수정
  3. 이후 읽기 시 쓰기 레이어의 파일이 우선

이미지 A (python-app):          이미지 B (node-app):
  레이어 4: COPY python-app     레이어 4: COPY node-app
  레이어 3: pip install         레이어 3: npm install
  레이어 2: python3 설치        레이어 2: nodejs 설치
  레이어 1: ubuntu:22.04 ────── ubuntu:22.04 (공유!)

# 실습 디렉토리 준비
mkdir -p /tmp/docker/part2/exam_6 && cd /tmp/docker/part2/exam_6

# overlay2 드라이버 사용 확인
docker info | grep "Storage Driver"
# Storage Driver: overlay2

# 이미지 레이어 실제 저장 위치
sudo ls /var/lib/docker/overlay2/

# 특정 이미지의 레이어 ID 확인
docker image inspect nginx --format '{{json .RootFS.Layers}}'

# 공식 이미지 예시 (사용자명 없음)
docker pull nginx          # Nginx 공식 이미지
docker pull postgres        # PostgreSQL 공식 이미지
docker pull python          # Python 공식 이미지
docker pull node            # Node.js 공식 이미지
docker pull ubuntu          # Ubuntu 공식 이미지
docker pull alpine          # Alpine Linux 공식 이미지

# 검증된 퍼블리셔 이미지 (조직명/이미지명)
docker pull elastic/elasticsearch:8.11.0
docker pull bitnami/postgresql:15

# 커뮤니티 이미지 (사용자명/이미지명)
docker pull myusername/myapp:latest

[레지스트리호스트:포트/][사용자명/]이미지명[:태그]

예시:
  nginx                              # Docker Hub 공식, latest 태그
  nginx:1.25.3                       # Docker Hub 공식, 특정 버전
  myuser/myapp:v2.1                  # Docker Hub 커뮤니티
  registry.example.com/myapp:1.0.0  # 프라이빗 레지스트리
  gcr.io/google-containers/pause:3.9 # Google Container Registry

# 위험한 패턴 — 언제 이미지가 바뀔지 모름
FROM python:latest  # ❌ 프로덕션에서 절대 금지

# 안전한 패턴 — 정확한 버전 고정
FROM python:3.11.7-slim-bookworm  # ✅ 재현 가능한 빌드

# 시맨틱 버저닝 기반 태그 전략
docker tag myapp:latest myapp:2.1.3      # 정확한 버전
docker tag myapp:latest myapp:2.1        # 마이너 버전
docker tag myapp:latest myapp:2          # 메이저 버전
docker tag myapp:latest myapp:stable     # 안정화 채널
docker tag myapp:latest myapp:latest     # 최신 (개발용)

# Git 커밋 해시 기반 태그 (CI/CD에서 많이 사용)
GIT_SHA=$(git rev-parse --short HEAD)
docker tag myapp:latest myapp:$GIT_SHA

전체 형식:
[레지스트리호스트[:포트]/][네임스페이스/]저장소[:태그][@다이제스트]

예시:
docker.io/library/nginx:1.25@sha256:abc123...def456
    ↑          ↑       ↑      ↑          ↑
 레지스트리  네임스페이스 저장소  태그     다이제스트

# 생략 시 기본값 채우기
nginx                = docker.io/library/nginx:latest
nginx:alpine         = docker.io/library/nginx:alpine
myuser/myapp         = docker.io/myuser/myapp:latest
myuser/myapp:v1.0    = docker.io/myuser/myapp:v1.0

# 다른 레지스트리 사용
ghcr.io/myorg/myapp:latest          # GitHub Container Registry
123456.dkr.ecr.ap-northeast-2.amazonaws.com/myapp:latest  # AWS ECR
asia-northeast1-docker.pkg.dev/project/repo/myapp:latest  # GCP Artifact Registry
myregistry.internal:5000/myapp:v2   # 사설 레지스트리

# 태그: 가변 (같은 태그가 언제든 다른 이미지를 가리킬 수 있음)
docker pull nginx:latest
# 오늘의 latest와 내일의 latest가 다를 수 있음!

# 다이제스트: 불변 (SHA256 해시, 항상 동일한 이미지 보장)
docker pull nginx@sha256:a0bcfe...8d12c
# 언제 어디서 pull해도 완전히 동일한 이미지

# 현재 이미지의 다이제스트 확인
docker image inspect nginx:latest --format '{{.RepoDigests}}'
# [nginx@sha256:a0bcfe...8d12c]

# 다이제스트로 pull (프로덕션 환경 권장)
docker pull nginx@sha256:a0bcfe...8d12c

# 로컬에서 빌드한 이미지를 사설 레지스트리에 push
# 1. 이미지에 레지스트리 주소 포함한 태그 추가
docker tag myapp:latest myregistry.example.com:5000/myapp:latest
docker tag myapp:latest myregistry.example.com:5000/myapp:v1.2.3

# 2. 레지스트리에 push
docker push myregistry.example.com:5000/myapp:latest
docker push myregistry.example.com:5000/myapp:v1.2.3

# 3. 다른 서버에서 pull
docker pull myregistry.example.com:5000/myapp:v1.2.3

# 4. 이미지 목록 API 확인
curl http://myregistry.example.com:5000/v2/_catalog
# {"repositories":["myapp","nginx","redis"]}
curl http://myregistry.example.com:5000/v2/myapp/tags/list
# {"name":"myapp","tags":["latest","v1.2.3","v1.2.2"]}

# Docker 전체 디스크 사용량 확인
docker system df
# TYPE            TOTAL   ACTIVE  SIZE      RECLAIMABLE
# Images          12      3       4.2GB     3.1GB (73%)  ← 회수 가능
# Containers      5       2       12MB      1kB (0%)
# Local Volumes   8       3       2.1GB     800MB (38%)
# Build Cache     23      0       1.5GB     1.5GB        ← 전부 회수 가능

# 상세 목록
docker system df -v

# 같은 태그로 재빌드하면 이전 이미지가 <none>:<none> 으로 남음
docker build -t myapp:latest .   # 첫 번째 빌드 → abc123
docker build -t myapp:latest .   # 재빌드 → def456 (새 이미지)
                                  # abc123은 태그를 잃고 <none>:<none>으로 전락

docker images
# REPOSITORY   TAG       IMAGE ID       SIZE
# myapp        latest    def456         200MB  ← 현재 이미지
# <none>       <none>    abc123         200MB  ← dangling 이미지!

# 1. dangling 이미지만 삭제 (가장 안전)
docker image prune
# WARNING! This will remove all dangling images.
# 삭제할 공간: 1.2GB

# 2. 사용 중이지 않은 이미지 전체 삭제
docker image prune -a
# 실행 중인 컨테이너에서 사용 중인 이미지는 삭제 안 됨

# 3. 미사용 컨테이너 삭제
docker container prune

# 4. 미사용 볼륨 삭제 (주의: 데이터 영구 삭제!)

# 5. 한 번에 전체 정리

# 특정 날짜 이전 이미지만 삭제
docker image prune -a --filter "until=72h"  # 72시간 이상 미사용

# 특정 라벨이 있는 이미지만 삭제
docker image prune --filter "label=stage=dev"

# cron으로 주기적 자동 정리 (매주 일요일 새벽 3시)