프로젝트

🐳 도커 “이미지”와 “컨테이너” 차이, 그리고 이미지 빌드 이유

Chansman 2025. 6. 14. 06:32

🐳 도커 “이미지”와 “컨테이너” 차이, 그리고 이미지 빌드 이유

1️⃣ 도커 이미지란?

  • 이미지 = 앱 전체 실행환경+코드+패키지+설정의 '스냅샷'
  • 즉, "이 이미지만 있으면 누구든, 어떤 환경이든,
    똑같이 100% 동일하게 실행할 수 있다!"
  • OS, 파이썬 버전, pip install, 소스코드 등
    모든 게 포함된 “실행 준비 파일”

2️⃣ 이미지를 만드는 이유

  • “이미지”를 만들면,
    → 이걸로 "컨테이너(실행 인스턴스)"를 언제든 몇 개든 띄울 수 있음
  • “이미지 = 앱의 실행 레시피”
    “컨테이너 = 실제로 돌아가는 인스턴스”
  • 실무 배포/테스트/롤백/확장에
    “이미지 → 컨테이너” 방식이 최적

3️⃣ 빌드 과정의 핵심

  • docker build ...
    → Dockerfile(환경설정, 코드 복사, 패키지 설치 등 명령)을
    “이미지”로 변환
  • 만든 이미지를 기반으로
    → docker run/compose로 "실제 실행"하는 것

4️⃣ 실무 장점

  • 동일성:
    개발/운영/로컬/클라우드 어디서든
    100% 같은 환경, 같은 결과 보장
  • 확장성:
    이미지 하나 만들어두면
    → 서버 10대/100대/무제한 자동 배포 가능!
  • 버전 관리/롤백:
    이미지 태그별로 과거/새 버전 자유롭게 롤백
  • 이식성:
    내 PC, 동료 PC, 클라우드…
    어디든 ‘docker run’만 있으면 바로 똑같이 실행

5️⃣ compose vs run 차이

  • docker run ...
    : 단일 컨테이너(서비스)만 실행할 때 씀
  • docker-compose up ...
    : 여러 개(웹, DB, 캐시 등) 서비스를
    한 번에 '패키지'로 관리할 때 필수

🚩 실전 정리

  1. Dockerfile로 이미지 만든다
    (앱 환경+코드+설정 “스냅샷” 제작)
  2. 이미지를 기반으로
    → 컨테이너(실행 인스턴스) 생성
  3. 어디서든 “같은 이미지면 같은 결과!”

💡 실제 진행 순서

  • sudo 권한 처리 (docker group 추가)
  • 프로젝트 폴더 이동
  • docker build → “이미지 생성”
  • docker-compose up → “컨테이너 실행”(DB, redis, 웹 모두 포함)
  • 포트 오픈 후 웹에서 테스트 접속