[Docker] 5. Docker volume 이용한 Persistent Storage

s

 

컨테이너는 무상태 application에서는 최적의 실행환경이다. 하지만 유상태 application을 docker로 실행하면 고려해야 할 것이 많다.

무상태와 유상태는 애플리케이션 내에서 데이터와 상태를 다루는 방식에 차이가 있다.

 

- Stateless(무상태) Application

• 요청에 대한 처리할 때 세션상태나 과거의 상태 저장 x
• 각각의 요청을 완전히 독립적으로 처리하는 방식

 

- Stateful(유상태) Application

 

• 사용자의 상태나 데이터를 application 내부나 외부에 저장하여 사용
• 상태가 바뀔 때마다 관리와 동기화 문제가 발생할 수 있다.

 

📝 목차

1. 컨테이너 속 데이터가 사라지는 이유
2. Docker Volume
3. 파일 시스템 Mount
4. Bind Mount의 한계
4. 컨테이너 파일 시스템

 

---

1. 컨테이너 속 데이터가 사라지는 이유

 

 

모든 컨테이너는 독립된 파일 시스템을 가지고, 같은 이미지에서 실행한 여러 개의 컨테이너 모두 처음에는 디스크 내용이 같다.

한 컨테이너의 파일을 수정하면 이미지나, 다른 컨테이너에 영향을 주지 않는다. 

 

컨테이너 파일 시스템 = 단일 디스크 = 이미지 레이어와 기록 가능 레이어들이 합쳐서 만들어진 가상 파일 시스템

 

 

1️⃣ 이미지 레이어 (Image Layer):

• 모든 컨테이너가 동일한 레이어 공유
• 읽기전용

 

2️⃣ 기록 가능 레이어(Writable Layer):

• 컨테이너마다 다르다.
• 기록 가능 레이어가 변경되면 컨테이너의 파일 시스템에 변경사항 반영된다.
• 컨테이너 삭제시 레이어도 같이 삭제된다. 

이미지 레이어와 기록 가능 레이어를 분리함으로써, 여러 컨테이너가 동일한 이미지 레이어를 공유하고 

각 컨테이너의 변경 사항은 기록 가능 레이어에 저장되므로 각 컨테이너는 독립적으로 실행되거나 변경될 수 있다.

 

📍 이미지 레이어 파일 수정

이미지 레이어는 읽기 전용인데 어떻게 파일 수정이 가능할까?

 

기록 중 복사

• 이미지 레이어의 파일을 수정하기 위해
• 해당 파일을 쓰기 가능 레이어로 복사
• 쓰기 가능 레이어에서 파일 수정

 

=> 수정된 파일은 해당 컨테이너의 기록 가능 레이어에만 존재하기 때문에, 다른 컨테이너나 이미지는 영향을 받지 않는다.

 

---

2. Docker Volume

📍 Docker Voulme

도커에서 스토리지를 다루는 단위

컨테이너와 독립적으로 존재

 

=> 볼륨을 생성해 컨테이너에 연결하면 컨테이너 파일 시스템의 한 디렉터리가 된다.

 

📍 Docker Voulume 생성 방법

1) Dockerfile 스크립트에서 VOLUME 인스트럭션 사용

- Dockerfile 스크립트

VOULUME <target-directory>

Dockerfile 스크립트에 VOULUME 인스트럭션을 사용하면 컨테이너를 실행했을 때 자동으로 볼륨을 생성해 컨테이너에 연결한다.

<target-diretory>에 있는 내용은 볼륨에 영구적으로 저장된다.

 

Volume은 도커에서 이미지나 컨테이너와 동급인 요소로,

docker volume 명령을 사용해 볼륨을 만들고 목록을 확인하고 삭제할 수 있다.

 

 

2) 수동으로 직접 볼륨 생성

docker volume create <name>

만약 volume 생성 이후에 컨테이너를 생성하면 자신과 연결된 컨테이너가 삭제되어도 그대로 남아있다.

=> 볼륨이 컨테이너와 별개의 생애주기를 가짐으로써, 컨테이너를 교체해도 데이터를 보존할 수 있다.

 

📍 Volume 공유

Dockerfile 스크립트에서 Volume을 정의하면 컨테이너를 생성할 때마다 새로운 볼륨을 만든다.

컨테이너가 같은 Volume을 공유하는 방법에 대해 알아보자.

 

volumes-from 플래그: 다른 컨테이너의 Voulume을 연결할 수 있다.

 

todo1이라는 컨테이너가 미리 만들어져 있을 때, todo1의 Volume을 공유해보자.

docker container run --name todo2 --volumes-from todo1 <image>

=> todo2는 todo1의 Volume을 공유한다.

 

 

✏️ 컨테이너는 종종 자신만이 접근할 수 있는 파일이 필요하므로, 다른 컨테이너에서 파일에 동시 접근하면 비정상적으로 동작할 수 있다. Volume은 업데이트 간 상태를 보존하기 위한 용도로 사용하며, 이미지에서 정의하는 것보다 수동으로 생성하여 관리하는 것이 좋다.

 

📍VOLUME 인스트럭션과 --volume 플래그

VOLUME 인스트럭션

• 도커 image 빌드할 때 Dockerfile 내부에 사용
• 컨테이너의 파일 시스템에 특정 directory를 연결하도록 설정
• docker container run 명령에서 Volume을 지정하지 않으면 새로운 Volume 생성

 

--volume 플래그

• 컨테이너 실행할 때 호스트의 directory를 컨테이너 내부의 특정 경로와 연결
• image에 Volume이 정의되어 있어도 컨테이너 실행시, 이 정의는 무시되어 새로운 Volume 생성되지 않는다.

 

---

 3. 파일 시스템 Mount

 

Volume은 호스트 컴퓨터상에 존재하지만 컨테이너와는 분리되어있다.

호스츠와 스토리지를 컨테이너에 직접적으로 연결하는 수단이 "바인드 마운트"다.

 

📍 바인드 마운트(Bind Mount)

• 호스트 컴퓨터 파일 시스템의 디렉터리 -> 컨테이너 파일 시스템의 디렉터리 만들기
• 호스트 컴퓨터의 파일 시스템을 컨테이너 데이터로 사용할 수 있다.
• 양방향으로 동작 (컨테이너 파일을 호스트 컴퓨터에서 수정 가능 + 호스트 파일을 컨테이너에서 수정 가능)
• 바인드 마운트 사용하면 호스트 컴퓨터 파일에 접근하기 위해 권한 상승 필요(USER 인스트럭션 사용해 권한 부여)

docker container run --mount type=bind, source = <source>, target = <target> <option> <image>

바인드 마운트 적용해 컨테이너 실행, 호스트 컴퓨터의 <target>디렉터리를 컨테이너 안에서 사용한다.

 

📍읽기전용으로 연결한 바인드 마운트

파일에 쓰기 작업이 필요 없는 경우 호스트 컴퓨터의 디렉터리를 읽기 전용으로 컨테이너에 연결할 수 있다.

docker container run todo-configured <option> --mount type=bind, source = <source>, target = <target>, readonly <image>

 

---

4. Bind Mount 한계

 

1️⃣ 컨테이너의 마운트 대상 디렉터리가 이미 존재하고 이미지 레이어에 해당 디렉터리의 파일이 포함돼 있다면?

이미 존재하는 대상 디렉터리에 마운트 하면 마운트의 원본 디렉터리가 기존 디렉터리를 완전히 대체하여,

이미지에 포함돼 있던 원래 파일은 사용할 수 없다.

 

아래의 예제에서,

마운트가 없는 컨테이너 실행해서 파일 확인하고

마운트 지정한 컨테이너 실행해서 원본 디렉터리의 파일 목록이 출력되는 지 확인해보자.

그림 6-12

=> 기존 디렉터리가 있는 경로에 바인트 마운트 적용하면 원래 원본 디렉터리가 기존 디렉터리를 대체하는 것을 확인할 수 있다.

 

2️⃣ 호스트 컴퓨터의 파일 하나를 컨테이너에 이미 존재하는 디렉터리로 마운트하면 어떻게 될까?

디렉터리 파일이 합쳐져 이미지에서 온 파일과 호스트에서 마운트된 파일이 모두 나타난다. 

하지만 윈도 컨테이너에서는 동작하지 않는다.

=> 단일 파일 마운트는 리눅스에서 동작하지만 윈도에서는 동작하지 않는다.

 

3️⃣ 분산 파일 시스템을 컨테이너에 바인드 마운트하면?

분산 파일 시스템 사용하면 네트워크 상의 모든 컴퓨터에 접근 가능하지만,

로컬 컴퓨터 운영체제의 파일 시스템과 다른 경우가 많다.

 

=> 분산 파일 스토리지를 컨테이너에 마운트하면 일반적인 파일 시스템의 기능 중에서 지원하지 않는 기능이 있을 수 있다.