도커를 활용한 서비스 배포하기 (볼륨 및 바인딩 마운트) #7

도커를 활용하여 컨테이너를 이미지화하여 손쉽게 컨테이너를 배포하여 실 서버에 적용 할 수 있게 되었다

그런데 실 서버 적용 시 해당 컨테이너에서 사용 중인 이미지, 엑셀파일 등의 첨부파일들은 컨테이너가 교체 됨에 따라

기존에 사용자들이 올려놓은 정보가 사라지게 된다. DB와 같이 파일 시스템도 별도로 공간을 만들어서 보관해야 할 필요성이 느껴졌다.

 

---

현재 설계된 구조, 컨테이너 변경 시 기존 파일이 사라진다, Active, Standby가 변경되어도 데이터의 연속성이 없어진다!

 

해당 구조를 운영 서버에 적용했다가, 컨테이너를 교체했다고 생각해보자.

담당자는 바로 개발자를 호출 할 것이다. " 제가 홈페이지에 올려놓은 아주 중요한 파일이 사라졌는데요? "

이후의 일은 상상에 맡기겠다. 그런 일은 존재해선 안되므로 여러가지 방안을 찾아보았다.

Docker에서는 이러한 상황에 이미 대처 할 수 있는 시스템을 확보해두었는데.

아래는 Docker 공식 홈페이지에서 핵심내용만 발췌한 글이다 ( 파파고 번역 ) 

---

기본적으로 컨테이너 내부에 생성된 모든 파일은 쓰기 가능한 컨테이너 계층에 저장됩니다. 이는 다음을 의미합니다.

• 해당 컨테이너가 더 이상 존재하지 않으면 데이터가 지속되지 않으며, 다른 프로세스에서 필요한 경우 컨테이너에서 데이터를 꺼내기 어려울 수 있습니다.
• 컨테이너의 쓰기 가능한 계층은 컨테이너가 실행 중인 호스트 시스템에 단단히 연결됩니다. 데이터를 다른 곳으로 쉽게 이동할 수 없습니다.
• Docker에는 컨테이너가 호스트 시스템에 파일을 저장하는 두 가지 옵션이 있으므로 컨테이너가 중지된 후에도 파일이 유지됩니다. 볼륨 및 바인딩 마운트입니다.

---

Docker에서 제공하는 볼륨 및 바인딩 마운트를 활용해 아래와 같은 구조를 가질 수 있도록 설계하려고 한다.

Docker 볼륨

Docker 컨테이너(Container)를 생성하게 되면 아래와 같이 자동으로 1:1 연결된 볼륨(Voulme)이 생성되고 해당

볼륨에 데이터가 쓰여지게 된다.

컨테이너가 삭제되어도 볼륨은 임의로 삭제하지 않는 이상 남아있어, 해당 데이터를 다른 프로세스나 컨테이너에서 사용 할 수 있다! 이렇게 생성된 볼륨은 마운트를 통해 다른 프로세스에서도 사용이 가능하다.

출처 https://docs.docker.com/storage/

볼륨 생성 및 조회

볼륨은 Docker에서 가장 권장하는 방식이므로 먼저 서술해보려고 한다.

볼륨은 기본적으로 컨테이너를 생성할 때 함께 생성되지만, 임의로 생성하여 사용 할 수 있다.

 

docker volume create 를 통해 볼륨을 생성한다.

> docker volumne create upload

docker volume ls 커맨드를 실행하면 막 생성된 upload를 확인 할 수 있다.

> docker volume ls
DRIVER    VOLUME NAME
local     1f08c979c569992c2b17ad1c46d981d183d5d5dd50765da36c53231e9a566062
local     371fcdbed006e992029f17831674a6930e018da3644e88254ead617651ac0fb7
local     891f8b9aa5e1c6b422f70c4ba9d3d458b7b9257d7280ac0857cdb056c1e41eac
local     d095e48bef329140c364bd883033cedb8bdd38f2b98648db315de6891809c970
local     f41f241d5cf18a47a60eea28dac0bc7dcef474926aaae91e858dc72ae85feb4e
local     upload

 

볼륨 마운트(mount)

다른 컨테이너에서 생성된 upload 볼륨을 사용하기 위해서 마운트라는 작업을 해줘야한다.

볼륨을 마운트해주기 위해서는 컨테이너를 다시 생성해줘야한다.

 

기존의 컨테이너 생성 명령어에 -v upload:/app 내용을 추가해준다.

docker run -v upload:/app --privileged -itd --name container2 --net mynetwork --ip 172.16.0.101 -p 2022:22 apache_server:1.1 /sbin/init

서술해보면, upload 볼륨을 container2 컨테이너 내의 /app 경로에 마운트 한다는 내용이다.

 

확인해보면 app 폴더가 마운트 되어 있음을 알 수 있다.

[root@60d1d74de30f /]# ll
total 68
-rw-r--r--   1 root root 12114 Nov 13  2020 anaconda-post.log
drwxr-xr-x   2 root root  4096 Jun 20 01:25 app <<<<<<<<<<<<<<<<<<<<<
lrwxrwxrwx   1 root root     7 Nov 13  2020 bin -> usr/bin
drwxr-xr-x   3 root root  4096 Jun 17 06:22 boot
drwxr-xr-x  13 root root  3220 Jun 20 01:26 dev
drwxr-xr-x   1 root root  4096 Jun 20 01:26 etc
drwxr-xr-x   2 root root  4096 Apr 11  2018 home

동일한 방법으로 container3도 마운트를 해준 뒤 app 폴더 내 에 text.txt를 만들어준다.

# container2 /app 경로
[root@60d1d74de30f app]# ll
total 4
-rw-r--r-- 1 root root 9 Jun 20 01:25 text.txt

# container3 /app 경로
[root@6d2cbaf57add app]# ll
total 4
-rw-r--r-- 1 root root 9 Jun 20 01:25 text.txt

동일한 파일을 바라보는 것을 확인했다. 해당 방법으로 컨테이너가 삭제되더라도 데이터의 영속성을 보장 할 수 있게 되었다!

 

볼륨 삭제

해당 명령어로 볼륨을 삭제 할 수 있다. 주의 할 점은 해당 볼륨을 사용 중인 컨테이너를 전부 삭제해야 삭제가 가능하다는 점이다. 

> docker volume rm upload

볼륨 청소

사용되지 않는 볼륨을 청소해주는 기능이다.

> docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y

바인드 마운트

바인드 마운트는 볼륨에 비해 기능이 제한적이고, 호스트 시스템의 파일 또는 디렉토리가 마운트됩니다.

바인드 마운트는 민감한 파일에 대한 액세스를 허용합니다.
좋든 나쁘든 바인드 마운트를 사용하는 한 가지 부작용은 중요한 시스템 파일이나 디렉토리의 생성, 수정 또는 삭제를 포함하여 컨테이너 에서 실행되는 프로세스를 통해 호스트 파일 시스템을 변경할 수 있다는 것입니다. 이는 호스트 시스템의 비 Docker 프로세스에 영향을 미치는 것을 포함하여 보안에 영향을 줄 수 있는 강력한 기능입니다.

 docker run -d \
  -it \
  --name devtest \
  -v "$(pwd)"/target:/app \
  nginx:latest

해당 기능은 이번 작업에선 사용하지 않으므로 간단하게 정리만 해두었다.

 

 

정리는 해두었지만, 항상 정식 레퍼런스 사이트를 참조하길 바란다.

https://docs.docker.com/engine/reference/commandline/volume_create/

docker volume create