[3장] 도커에서 주로 컨테이너를 저장하는 이유와 방법, 어떤 예시가 있는지

도커(Docker)를 사용하다 보면 “컨테이너는 일회성으로 쓰고 폐기하는 것이 좋은데, 그럼 데이터는 어떻게 영구 저장하지?”라는 질문이 떠오를 때가 많습니다. 실제로 도커 컨테이너는 기본적으로 수명이 짧은(휘발성) 특성을 갖고 있어, 컨테이너 내에서 저장한 데이터는 컨테이너가 제거되면 함께 사라지는 것이 일반적이죠. 하지만 실제 환경에서는 로그, 데이터베이스 파일, 설정 파일 등 반드시 보존해야 하는 데이터가 존재하므로, 이를 어떻게 관리할지 결정해야 합니다.

이번 포스팅에서는 도커에서 컨테이너를 “저장한다”는 개념과 이유, 그리고 대표적인 방법과 사례를 살펴보겠습니다.

---

1. 컨테이너 저장(데이터 영속성)이 필요한 이유

1. 데이터 손실 방지
   • 애플리케이션이 컨테이너 안에서 동작 중 생성하는 데이터(로그, 업로드 파일 등)는 컨테이너가 종료되면 자동으로 사라집니다. 중요한 데이터를 보존해야 한다면 반드시 별도의 저장 방식을 마련해야 하죠.
2. 지속적 운영 및 재시작
   • 운영 중인 컨테이너가 장애로 중단되거나, 애플리케이션 버전 업그레이드를 위해 재시작이 필요한 경우가 있습니다. 이때 기존 데이터를 그대로 유지하면서 컨테이너를 재실행할 수 있어야 합니다.
3. 환경 이식성
   • 개발 환경, 스테이징 환경, 운영 환경 등 여러 환경에 걸쳐 컨테이너를 이동시킬 때, 필요한 데이터가 분리되어 있으면 훨씬 유연하고 간편하게 마이그레이션할 수 있습니다.

---

2. 도커에서 컨테이너를 저장(영구화)하는 주요 방법

1) 볼륨(Volume) 사용

• 개념
  • 도커가 직접 관리하는 디렉터리(파일 시스템)로, 컨테이너와 호스트 간에 데이터를 주고받을 수 있도록 해줍니다.
  • docker volume create, docker run -v(혹은 -mount), docker-compose.yml의 volumes: 섹션 등을 통해 설정 가능.
• 장점
  • 컨테이너가 삭제돼도 볼륨은 남아 있으므로 데이터가 보존됩니다.
  • 호스트와 컨테이너 간의 권한 문제가 비교적 적고, 여러 컨테이너가 동일 볼륨을 공유할 수 있습니다.
• 예시
  • 데이터베이스 컨테이너(MariaDB, PostgreSQL 등)에서 /var/lib/mysql, /var/lib/postgresql/data 같은 경로를 볼륨으로 설정해 DB 파일을 영구화.

2) 바인드 마운트(Bind Mount) 사용

• 개념
  • 호스트의 특정 디렉터리를 직접 컨테이너 내부 디렉터리에 연결(마운트)하는 방식.
  • 도커가 직접 관리하는 볼륨과 달리 호스트 경로를 지정하므로, 호스트 파일시스템에 대한 접근 범위가 넓을 수 있음.
• 장점
  • 로컬 개발 환경에서 IDE/에디터로 수정한 파일이 즉시 컨테이너 내부에 반영되어, 빠른 디버깅 및 개발 가능.
• 예시
  • 웹 애플리케이션 소스코드를 호스트 PC의 /home/user/project 디렉터리와 컨테이너의 /app 디렉터리를 바인드 마운트해, 소스 수정 시 바로 컨테이너에 적용.

3) 데이터 전용 컨테이너(Data Volume Container) 방식

• 개념
  • 별도의 컨테이너를 하나 만들어서 그 안에 데이터를 저장하고, 다른 컨테이너들이 --volumes-from 같은 옵션으로 이를 공유.
  • 과거에 자주 사용되던 방식으로, 현재는 볼륨 기능이 발전하면서 직접 활용되는 경우는 드물지만, 여전히 레거시 환경에서 볼 수 있습니다.
• 장점
  • 데이터가 들어 있는 컨테이너를 백업하고 복원하기 편리한 구조.
• 예시
  • “data-only” 라는 이름의 컨테이너에 로그 디렉터리를 두고, 웹 서버나 애플리케이션 컨테이너가 해당 디렉터리를 공유해 로그 쌓기.

4) 이미지로 저장(Commit, Save, Push 등)

• docker commit [컨테이너 ID or 이름] [이미지명:태그]
  • 현재 실행 중인 컨테이너의 상태(파일, 설정 등)를 스냅샷 찍듯이 이미지로 저장.
  • 개발/테스트 용도로 임시 백업할 때 사용하기는 편리하지만, 실제 운영 단계에서는 비효율적인 경우가 많습니다.
• docker save -o [파일명].tar [이미지명:태그] / docker load
  • 이미지를 tar로 내보내거나 불러오는 방법.
  • 인터넷 연결이 제한된 환경에서 이미지를 이동할 때 활용.
• docker push [이미지명:태그]
  • 도커 허브나 개인 레지스트리에 이미지를 업로드.
  • 여러 환경에서 동일 이미지를 재사용하고 싶을 때 유용.

---

3. 실제 예시 시나리오

1. 웹 애플리케이션 + DB 분리 구조
   • 웹 앱 컨테이너: 소스코드는 바인드 마운트, 로그 파일은 볼륨에 저장.
   • 데이터베이스 컨테이너: DB 데이터 디렉터리는 볼륨에 저장.
   • 웹 앱이 재시작 또는 재배포돼도 볼륨에 저장된 로그와 DB 데이터는 그대로 유지.
2. 개발 환경에서의 Dockerfile + Bind Mount
   • 로컬에서 웹 서버 소스코드를 수정하면, Bind Mount를 통해 컨테이너 안 파일이 즉시 업데이트.
   • 빌드나 테스트는 컨테이너 내부에서 진행해 호스트 환경 오염 없이 개발 가능.
3. Backup & Restore
   • 특정 시점의 컨테이너 상태를 통째로 보관해야 할 때, docker commit을 활용해 이미지 생성 후, 이를 docker save하여 파일로 추출하고 백업.
   • 추후 복원이 필요하면 docker load로 이미지를 복원한 뒤, 해당 이미지로 컨테이너 실행.

---

마무리

도커를 사용하면 컨테이너를 자유롭게 띄우고 내릴 수 있지만, 그러면서도 중요한 데이터는 안전하게 보존해야 합니다. 이때 볼륨, 바인드 마운트, 이미지 백업 등 다양한 기법을 적절히 활용하면 컨테이너의 “유연성”과 “안정성” 두 마리 토끼를 모두 잡을 수 있습니다.
앞으로 도커 환경을 설계할 때, “어떤 데이터를 어디에, 어떻게 저장할까?”라는 질문을 항상 염두에 두면서 설계해보시길 바랍니다.

이 글은 개인적인 의견과 스터디 결과를 정리한 것이며, 모든 내용이 절대적인 정답이 될 수는 없습니다.

---

docker-container-storage#docker-volume#docker-bind-mount#docker-commit#docker-save#docker-push#data-persistance#docker-backup#container-데이터관리#운영환경