도커 교과서 6장 도커 볼륨을 이용한 퍼시스턴트 스토리지

6장 도커 볼륨을 이용한 퍼시스턴트 스토리지

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

• 컨테이너의 디스크 역시 이미지 레이어를 순서대로 합쳐 만든 가상 파일 시스템이다.
• 모든 컨테이너는 독립된 파일 시스템을 갖는다.
• 즉, 한 컨테이너에서 파일 시스템을 통해 파일을 수정하더라도 다른 컨테이너는 영향을 받지 않는다.
• 컨테이너를 종료해도 파일 시스템은 삭제되지 않는다.

$ docker container run --name rn1 diamol/ch06-random-number

$ docker container run --name rn2 diamol/ch06-random-number

$ docker container cp rn1:/random/number.txt number1.txt
$docker container cp rn2:/random/number.txt number2.txt

$ cat number1.txt
12370
$ cat number2.txt
254

• 컨테이너의 파일 시스템은 단일 디스크다. (Linux: /dev/sda1, Window: C:\)
• 이 디스크는 도커가 여러 출처로부터 합쳐 만들고 컨테이너에 전달한 가상 파일 시스템이다.
• 이 출처는 기본적으로 이미지 레이어와 컨테이너의 기록 가능 레이어로 구성된다.
• 이미지 레이어는 모든 컨테이너가 공유하지만 기록 가능 레이어는 컨테이너마다 다르다.
• 이미지 레이어는 읽기전용이고, 각 컨테이너가 따로 갖는 기록 가능 레이어는 컨테이너와 같은 생애주기를 갖는다.
• 이미지 레이어는 이미지를 내려받는 순간부터 삭제할 때까지 로컬 컴퓨터의 이미지 레이어에 존재한다.
• 쓰기 가능 레이어는 컨테이너를 실행할 때 생성되며 컨테이너를 삭제할 때 함께 삭제된다. 즉, 컨테이너를 종료하는 것으로는 삭제되지 않는다.

도커의 기록 중 복사 (copy-on-write)

• 도커의 이미지 레이어는 읽기 전용이다.
• 그러나, 도커는 기록 중 복사(copy-on-write) 라는 방법을 사용해서 읽기 전용 레이어의 파일을 수정할 수 있다.
• 수정할 파일을 쓰기 가능 레이어로 복사한 후, 쓰기 가능 레이어에서 수정한다.
• 이 방법이 도커가 스토리지를 매우 효율적으로 사용할 수 있는 비법이다.

$ docker container run --name f1 diamol/ch06-file-display

...

<https://www.manning.com/books/learn-docker-in-a-month-of-lunches>

$ echo “<http://eltonstoneman.com>” > url.txt

$ docker container cp url.txt f1:/input.txt

$ docker container start --attach f1
<http://eltonstoneman.com>

• 로컬 컴퓨터에서 컨테이너로 파일을 복사하여 재 실행시 출력값이 변경되었다.
• 컨테이너 속 파일을 수정하면 컨테이너의 동작에 영향을 미친다.
• 그러나, 이미지를 공유하는 다른 컨테이너나 이미지는 영향을 받지 않는다.
• 수정된 파일을 해당 컨테이너의 기록 가능 레이어에만 존재하기 때문이다.
• 또한, 새로운 컨테이너는 이미지로부터 받은 최초의 내용을 담은 파일시스템을 가지며, f1 컨테이너가 삭제되면 수정된 파일도 사라진다.

$ docker container run --name f2 diamol/ch06-file-display

# 기존 이미지의 파일내용인 것을 확인 가능.
<https://www.manning.com/books/learn-docker-in-a-month-of-lunches>

$ docker container rm -f f1

$ docker container cp f1:/input.txt .

# 컨테이너 삭제 시 파일 시스템의 내용도 삭제된 것을 확인 가능.
Error response from daemon: No such container: f1

• 컨테이너 파일 시스템은 컨테이너와 같은 생애주기를 갖는다.
• 컨테이너가 삭제되면 이 컨테이너의 기록 가능 레이어와 수정된 데이터도 함께 삭제된다.
• 도커 사용에 있어 컨테이너 삭제는 빈번하게 일어난다.
• 따라서, 컨테이너 내부 데이터를 영속적으로 관리하기 위해서는 도커 볼륨(Docker Volume), 마운트(Mount) 를 활용해야 한다.
• 도커 볼륨과 마운트는 컨테이너와는 별개의 생애주기를 갖으므로 컨테이너가 대체되더라도 데이터를 지속적으로 관리할 수 있다.

6.2 도커 볼륨을 사용하는 컨테이너 실행하기

• 도커 볼륨은 도커에서 스토리지를 다루는 단위다.
• 볼륨은 컨테이너와 독립적으로 존재하며, 별도의 생애주기를 갖는다.
• 퍼시스턴시가 필요한 애플리케이션을 컨테이너로 실행하려면 볼륨을 사용해야 한다.
• 애플리케이션을 새로운 컨테이너로 생성해도 다시 볼륨을 연결하면 데이터를 유지할 수 있다.

컨테이너에서 볼륨을 사용하는 방법

• 수동으로 직접 볼륨 생성해서 컨테이너에 연결 하는 방법과 Dockerfile 스크립트에서 VOLUME 인스트럭션을 사용하는 방법이 있다.
• VOLUME 인스트럭션과 docker container --volume 플래그는 별개의 기능이다.
• VOLUME 인스트럭션은 항상 새로운 볼륨을 함께 생성한다.
• --volume 플래그는 이미지에 볼륨이 정의되어 있더라도 항상 지정된 볼륨을 컨테이너에 마운트한다.
• --volume-from [container-name] 이라는 명령어를 통해 하나의 볼륨을 여러개의 컨테이너가 공유할 수 있다.
• 즉, 이미지에 VOLUME 인스트럭션이 정의되어 있더라도 --volume 플래그를 사용할 경우, 새로운 볼륨을 생성하지 않고 지정된 볼륨을 사용한다.
• 볼륨은 컨테이너 간 파일 공유보다는 업데이트 간 상태를 보존하기 위한 용도로 사용되어야 한다.
• 또한, 이미지에서 정의하는 것보다는 명시적으로 관리하는 편이 더 낫다.

FROM diamol/dotnet-aspnet
WORKDIR /app
ENTRYPOINT ["dotnet", "ToDoList.dll"]

# /data 디렉토리의 내용은 볼륨에 영구적으로 저장.
VOLUMN /data
COPY --from=builder /out/ .

$ docker container run --name todo1 -d -p 8010:80 diamol/ch06-todo-list
$ docker container inspect --format '{{.Mounts}}' todo1
[{volume 4441e43e17902fb5792ebdfa8c643b4bada7c81eaa7e501f84fc86fbb599c7df /var/lib/docker/volumes/4441e43e17902fb5792ebdfa8c643b4bada7c81eaa7e501f84fc86fbb599c7df/_data /data local  true }]
$ docker volume ls
DRIVER    VOLUME NAME
local     4441e43e17902fb5792ebdfa8c643b4bada7c81eaa7e501f84fc86fbb599c7df
...

# 새로운 볼륨과 함께 생성
$ docker container run --name todo2 -d diamol/ch06-todo-list

$ docker container exec todo2 ls /data

# todo1 컨테이너의 볼륨을 공유
$ docker container run -d --name t3 --volumes-from todo1 diamol/ch06-todo-list

$ docker container exec t3 ls /data

# 복사 대상 경로 환경변수 정의
$ target='/data'

# 볼륨 생성
$ docker volume create todo-list

# 컨테이너 실행
$ docker container run -d -p 8011:80 -v todo-list:$target --name todo-v1 diamol/ch06-todo-list

# <http://localhost:8011> 데이터 추가

# v1 컨테이너 삭제
$ docker container rm -f todo-v1

# v1 이 사용하던 볼륨 연결
$ docker container run -d -p 8011:80 -v todo-list:$target --name todo-v2 diamol/ch06-todo-list:v2

6.3 파일 시스템 마운트를 사용하는 컨테이너 실행하기

• 볼륨은 호스트 컴퓨터에 존재하지만, 컨테이너와는 분리되어 있다.
• 볼륨의 장점은 컨테이너와 스토리지의 생애주기를 분리하면서도 도커를 사용하는 방식 그대로 스토리지를 다룰 수 있다는 점이다.

바인드 마운트(bind mou)란?

• 바운드 마운트는 호스트 컴퓨터 파일 시스템의 디렉터리를 컨테이너 파일 시스템의 디렉터리로 만든다.
• 바운드 마운트를 사용하면 호스트 컴퓨터의 파일 시스템을 명시적으로 지정해 컨테이너 데이터로 사용할 수 있다.
• 바인드 마운트는 양방향으로 동작한다.
• 컨테이너에서 만든 파일을 호스트에서 수정할 수도 있고, 호스트에서 만든 파일을 컨테이너에서 수정할 수 있다.

$ source="$(pwd)/databases" && target='/data'

$ mkdir ./databases

$ docker container run --mount type=bind,source=$source,target=$target -d -p 8012:80 diamol/ch06-todo-list

$ curl <http://localhost:8012>

$ ls ./databases

• 컨테이너는 보통 호스트 시스템에 대한 영향력을 최소화하기 위해 루트 권한이 아닌 일반 사용자로 실행된다.
• 그러나, 바인드 마운트를 사용하면 호스트 컴퓨터 파일에 접근하기 위해 권한 상승 필요하다.
• 그래서, Dockerfile 스크립트에서 USER 인스트럭션을 사용해 컨테이너에 관리자 권한을 부여한다.
• 파일에 쓰기 작업을 할 필요가 없다면 호스트 컴퓨터의 디렉터리를 읽기 전용으로 컨테이너에 연결할 수도 있다.
• 이 방법은 주로 conf 같이 설정파일을 호스트에 마운트해두고, 이미지의 변경없이 호스트의 conf 파일 수정만으로 컨테이너를 설정을 변경하기 위해 많이 사용된다.

$ cd ./ch06/exercises/todo-list

# 경로 문자열을 환경 변수로 정의
$ source="$(pwd)/config" && target='/app/config'             # 리눅스

# 바인드 마운트를 적용해 컨테이너 실행
$ docker container run --name todo-configured -d -p 8013:80 --mount type=bind,source=$source,target=$target,readonly diamol/ch06-todo-list

# 애플리케이션 작동 여부 확인
$ curl <http://localhost:8013>

# 컨테이너 로그 확인
# 호스트의 로그 레벨 설정 파일을 읽어서 DEBUG 로그가 출력됨
$ docker container logs todo-configured

• 호스트 컴퓨터가 접근할 수 있는 스토리지라면 무엇이든 바운드 마운트를 통해 컨테이너에 연결할 수 있다.
• 예를 들어 /mnt/nfs 와 같이 NFS 시스템 경로를 마운트하여 분산 스토리지를 컨테이너에 연결해 사용하여 신뢰성을 크게 개선할 수 있다.

6.4 파일 시스템 마운트의 한계점

• 바인드 마운트와 볼륨을 효율적으로 활용하려면 각 요소의 핵심 사용 시나리오와 한계점을 이해해야 한다.

첫 번째 시나리오 - 컨테이너의 마운트 대상 디렉터리가 이미 존재하고 이미지 레이어에 이 디렉터리의 파일이 포함돼 있는 경우.

# 환경변수 지정
$ source="$(pwd)/new" && target='/init'

# 컨테이너 실행
$ docker container run diamol/ch06-bind-mount
abc.txt
def.txt

# 마운트 경로 변경
$ # docker container run --mount type=bind,source=$source,target=$target diamol/ch06-bind-mount
._123.txt
._456.txt
123.txt
456.txt

• 이미 존재하는 대상 디렉터리에 마운트하면, 마운트의 원본 디렉터리가 기존 디렉터리를 완전히 대체한다.
• 즉, 이미지에 포함돼 있던 원래 파일은 사용할 수 없다.
• 처음 실행에서는 abc.txt , def.txt 를 출력되었다,
• 이 파일은 이미지 레이어에서 컨테이너로 전달된 파일이다.
• 두 번째 컨테이너는 이미지 레이어에서 받는 파일이 마운트된 파일로 대체되었으며, 파일 목록이 123.txt , 456.txt 로 바뀌었다.

두번째 시나리오 - 호스트 파일 하나를 컨테이너 이미 존재하는 디렉토리로 마운할 경우

• 이미지 레이어 부터의 파일과 호스트 마운트 된 경로의 파일이 모두 나타난다.
• 단, 윈도우 컨테이너는 해당 기능을 제공하지 않는다.
• 윈도우 컨테이너와 리눅스 컨테이너의 동작이 일치하지 않는 몇 안되는 영역이다.

# 호스트 마운트 경로와 컨테이너 내부 경로 파일 모두 출력됨.
$ docker container run --mount type=bind,source="$(pwd)/new/123.txt",target=/init/123.txt diamol/ch06-bind-mount
123.txt
abc.txt
def.txt

세 번째 시나리오 - 분산 파일 시스템을 컨테이너에 바운드 마운트 하는 경우.

• 분산 파일 시스템을 사용하면 네트워크상의 모든 컴퓨터에서 데이터에 접근할 수 있다.
• 분산 파일 시스템을 컨테이너에 마운트하면 일반적인 파일 시스템의 일부처럼 보이지만, 지원하지 않는 동작이 있을 수 있다.
• 예를들어, Azure Files 는 하드 링크 기능을 제공하지 않기 때문에, PostgreSQL 가 해당 Azure Files 를 마운트하여 사용할 경우 오류가 발생할 수 있다.
• 이러한 경우는 매우 드문 경우이지만, 한번 발생하면 해결이 힘들다.
• 또한, 많은 컨테이너가 분산 시스템에 마운트되어 있고, 해당 컨테이너들이 많은 File IO 가 일어날 경우가 있다.
• 따라서, 컨테이너에 분산 스토리지를 마운트할 계획이라면, 컨테이너들의 마운트 목적과 컨테이너와 분산 시스템의 관계를 충분히 고려해야 한다

6.5 컨테이너의 파일 시스템은 어떻게 만들어지는가?

• 모든 컨테이너는 도커가 다양한 출처로부터 모아 만든 단일 가상 디스크로 구성된 파일 시스템을 갖는다.
• 이 파일 시스템을 유니언 파일 시스템(Union File System) 이라 한다.
• 유니언 파일 시스템은 OS 마다 다른 방식으로 구현되어 있지만, 도커는 호스트의 운영체제에 맞게 최선의 구현을 선택해주기 때문에 이것에 대해서는 신경 쓸 필요가 없다.
• 컨테이너는 유니언 파일 시스템을 통해 물리적 위치가 서로 다른 파일과 디렉토리에 마치 단일 디스크를 사용하듯 접근할 수 있다.
• 컨테이너 내부 애플리케이션의 입장에서는 단일 디스크만을 바라보지만, 도커의 경우 여러 레이어(이미지, 마운트 볼륨)를 통해 구성된 것이다.
• 그러나, 기록 가능 레이어는 단 하나이다.

기록 가능 레이어

비용이 비싼 계산이나 네트워크를 통해 저장해야 하는 데이터의 캐싱 등 단기 저장에 적합하다.

각 컨테이너마다 독립적인 기록 가능 레이어를 가지며, 컨테이너가 삭제되면 저장된 데이터는 유실된다.

• 로컬 바인드 마운트
  • 호스트 컴퓨터와 컨테이너 간 데이터를 공유하기 위해 사용한다.
  • 호스트의 설정파일을 공유하여 사용함으로써, 이미지 빌드 없이 즉시 컨테이너로 전달할 수 있다.
• 분산 바인드 마운트:
  • 네트워크 스토리지와 컨테이너 간에 데이터를 공유하기 위해 사용한다.
  • 가용성이 높지만 로컬 디스크와 비교해 지원하지 않는 파일 시스템 기능이 있거나 성능 면에서 차이가 있을 수 있다.
  • 읽기 전용으로 설정 파일을 전달하거나 공유 캐시로 활용할 수 있으며, 읽기 쓰기 가능으로 데이터를 저장해 동일 네트워크상의 모든 컨테이너나 컴퓨터와 데이터를 공유하는 데 적합하다.
• 볼륨 마운트
  • 컨테이너와 도커 객체인 볼륨 간에 데이터를 공유하기 위해 사용된다.
  • 볼륨 마운트를 사용하면 애플리케이션이 볼륨에 데이터를 영구적으로 저장한다.
  • 컨테이너를 교체하는 방식으로 애플리케이션을 업데이트해도, 이전 버전 컨테이너의 데이터를 그대로 유지할 수 있다.

이미지 레이어

• 이미지 레이어는 컨테이너의 초기 파일 시스템을 구성한다.
• 레이어는 적층 구조를 갖는데, 후속 레이어와 이전 레이어의 내용이 서로 충돌하는 경우 후속 레이어의 내용이 적용된다.
• 레이어는 읽기 전용이며 여러 컨테이너가 공유한다.

6.6 연습문제

• 문제: 기존에 할 일이 등록된 상태로 시작되는 컨테이너를, 초기화된 상태로 시작하도록 설정.
• 해결 방안: 컨테이너 내부의 설정 파일을 외부에서 관리하고, 컨테이너 실행 시 이 파일을 마운트하여 초기화된 상태로 만들어야 한다.

# 실행중인 모든 컨테이너 삭제
$ docker rm -f $(docker ps -aq)

# 컨테이너 실행
$ docker container run -d -p 8081:80 diamol/ch06-lab

# <http://host:8081> 접속 후 todo list 4개 등록되어있는거 확인

# 컨테이너 내부 접속
$ docker exec -it d6ef8f670f7f /bin/bash

# 이미지 레이어에서 가져온 설정파일 확인.
$ cat appsettings.json
{
  "ConnectionStrings": {
    "ToDoDb": "Filename=/init-data/todo-list.db"
  }
}

$ exit

# 문제 설정 파일 경로 이동
$ cd /ch06/lab/solution

# 문제 설정파일 확인
$ cat config.json 
{
  "ConnectionStrings": {
    "ToDoDb": "Filename=/new-data/todo-list.db"
}
$ cd ..

# 볼륨 생성
$ docker volume create ch06-lab

# 마운트 경로 환경 변수 등록
$ configSource="$(pwd)/solution" && configTarget='/app/config' && dataTarget='/new-data'

# 컨테이너 실행
$ docker container run -d -p 8016:80 --mount type=bind,source=$configSource,target=$configTarget,readonly --volume ch06-lab:$dataTarget diamol/ch06-lab