[4] Docker Data Storage 관리(Application,Temporary, Persistent)

Intro

이번 게시글에서는 Docker에서 다루는 다양한 데이터 특성에 따라서 어디서 공간을 어떻게 확보하며 실제 Host와 각자의 공간이 어떤 관계를 가지는 지에 대해 담았다. 본 게시글은  Udemy에서 제공되는 Docker&Kubernetes 실전가이드를 토대로 공부하고 부족한 부분은 gpt와 searching을 통해 작성한 내용이다.

---

 

Volume이란?

 Docker Engine이 관리하는 Storage 영역에서 관리되는 공간이다. 이는 Docker Engine 내 파일시스템의 일부 공간이지만 컨테이너 자체에서는 외부의 특정 폴더인 공간과 연결된 Docker 컨테이너 내부의 폴더/파일를 의미한다. Volume은 Docker에서 관리되고 Container 외부 Host 파일시스템 상 어떠한 경로에 존재는 하겠지만 이는 Docker Engine에 의해 관리되는 영역이기에 알 수 없다.

이러한 성질을 가진 Volume도 크게 두가지로 나뉜다. 바로 공간에 이름을 적어 정의하는가? 그렇지 않는가이다. 이처럼 Container 외부 공간에 정의된 데이터 공간을 여러 Container에서 사용하기 위해서는 그 위치가 특정한 이름으로서 기억될 수 있는 공간으로 정의해줘야할 것이다. 

---

Anonymous Volume

 그전에 먼저 기억되지 않는 공간(Anonymous Volume)에 대해서 이야기해보겠다. Volume은 Data를 저장하는 Docker Engine이 관리하는 Storage이다.  익명 볼륨(Anonymous Volume)는 Container의 생애주기에 맞춰 관리 될 수 있다. 익명 볼륨은 docker run -v 명령어를 통하거나 Dockerfile 상에서 Volume이라는 명령어를 통해서 생성할 수 있다. 또한 --rm으로 컨테이너가 제거되면 익명 볼륨도 제거할 수 있다. 다만 --rm으로 제거하지 않은 경우에는 익명 볼륨이 그대로 남아서 메모리를 효율적으로 관리할 수 없다. 따라서 Container 외부 경로보다 컨테이너 내부 경로의 우선순위를 높혀야할 때 이런 익명 볼륨을 사용할 수 있다.

 

 또한 --rm을 통해 docker container를 생성하지 않으면 Anonymous Volume은 레거시로 그대로 남아있기 때문에 효율적인 자원 운용을 위해 이런 Volume들은 docker volume prune을 통해 활성화되지 않은 볼륨을 제거할 수 있다.

---

Named Volume

 Anonymous Volume과 달리 이름이 정의된 볼륨들은 여전히 Docker Engine에 의해 관리되지만 Container 외부 폴더에 데이터를 저장해두었기에 해당 데이터를 여러 Container에서 사용할 수 있다. 이는 데이터를 영구적으로 보관하기 때문에 기존의 Container를 닫고 새롭게 Container를 build하더라도 해당 volume을 연동해줬을 때, 실제로 남아있는 데이터를 활용할 수 있다.

 

이렇게 데이터를 영구적으로 관리할 수 있다는 특징은 내 분야와 접목시켜보면, 원본 데이터를 전처리하고 Named Volume에 저장한 뒤, 다른 Container를 통해 또 다시 Named Volume에 저장된 데이터에 접근하여 해당 데이터를 토대로 예측이나 모델 학습에 활용해볼 수 있다는 점이다.

---

Bind Mount 그리고 Copy

위 두가지 Volume들은 Docker Engine이 관리하는 Stroage 상에서 관리되는 공간과 연결하는 케이스들에 대한 이야기라면, 지금부터 소개할 Bind Mount는 Docker Engine이 격리시켰던 Host OS 기반의 공간과 Container가 연결되는 경우를 말한다.

 

 Bind Mount가 사용되는 예시는 Local에서 Application을 구현하고 이를 기배포한 Image를 통해 Container의 Layer로 활용된 경우를 살펴볼 수 있다. Image가 read-only data라는 특성상 host측에서 코드를 수정하더라도 re-build되지 않는 이상 Container에 반영될 수 없다. 그러나 Bind Mount를 통해 Host Working Directory를 현재 작업중인  Container의 Working Directory와 직접적으로 Binding해주면 re-build없이 Host에서 작성한 변동사항을 Container에 즉각적으로 반영할 수 있다. 이때 Container의 변동사항이 Host에도 반영되는 경우와 오로지 Host의 변동사항만 반영케하는 방법이 있다. 아래를 참조하자.

-v <Host Address> : <Container Address> : ro	read-only로 Host의 변동사항만 Container에 적용됨
-v <Host Address> : <Container Address> : rw	read-write로 Host, Container 모두의 변동사항이 상호 간 적용될 수 있음

 

 그러나 ro이던 rw이던 왜 Host의 변동사항을 Container로 복사하는 개념이 아닌가? 라고 생각한다면 한가지 궁금증이 생긴다. 왜 Container의 변동사항이 Host에 반영되지? 답은 간단하다. 복사가 아니라 연결이기 때문이다.

 

바인딩 마운트는 user가 직접 호스트 폴더에 직접 연결되는 것이므로 docker가 별도로 관리하지 않으나, 임의로 주소를 할당하여 익명 또는 명명 볼륨은 Docker에서 할당한 것이므로 Docker가 관리한다는 차이가 있다. (docker volume ls로 확인가능)

 

 Bind Mount쓰면 그냥 Override가 되는데 그래도 COPY . . 를 쓰는 이유가 뭘까? Local과 해당 Container가 계속 연결되어있는 상황이면 상관없는데 우리가 이를 Cloud나 다른 환경에서 사용할 때는 반드시 snapshot을 통해 소스를 가져와야할 것이다. 소스코드가 Binding되지 않는 상황에서 image를 build할 때 copy명령이 없으면 해당 image 내 appllication source code layer는 container에 옮겨갈 수 없다. 그래서 copy를 써서 관리하는 것이다.

 

gitignore처럼 Docker에서도 image상의 데이터 전부를 copy하지 않게 할 수 있다.

 

권한 설정에 유의해야한다.

---

누가 Volume을 관리하는가?

바인딩(Binding)이라는 것은 기본적으로 무언가를 서로 묶어 연결하는 과정을 이야기한다고 한다. 지금까지 우리가 배웠던 Anonymous, Named, Binding Mount는 무언가를 누가 엮었는지에 따라서 차이가 발생하게 된다. 아래 표를 참고해보자.

 

-v <container의 특정 주소>	Anonymous Volume	Docker에서 관리되며, Docker 내에서 임의로 Binding됨
-v <name>:<container의 특정 주소>	Named Volume	Docker에서 관리되며, Docker 내에서 임의로 Binding됨
-v <Host Address>:<container의 특정 주소>	Binding Mount	User가 직접 Host Address로 Binding해서 Docker 관리 X

 

이처럼 Host Address 정보를 직접 주어주는가? 아닌가?에 따라서 누가 관리할지가 나뉘게 된다. 너무도 당연한 말인게 Docker가 Binding했으니까 Docker에서 그 Volume을 관리하는게 이해 타당하다.

---

Outro (번외)

docker-compose에서 사용한다면?
docker-compose stop = container : 제거 , network : 유지, volume : 유지

docker-compose down = container : 제거, network : 제거, volume :유지

docker-compose down -v = container : , network : 제거, volume :제거

 

인스타 주소 🎗

https://www.instagram.com/f.inn_sharp/