docker volume을 적용해보는 김에 문서를 보며 간단하게 개념을 학습해보았다.
기본적으로 도커 컨테이너에 생성되는 모든 파일은 쓰기가능한 컨테이너 레이어에 생성된다.
해당 컨테이너가 더 이상 존재하지 않으면 데이터가 영속하지 않게 되어 다른 프로세스에서 사용하기 힘들다.
해당 컨테이너 계층은 호스트 시스템과 밀접하여 다른 곳으로 이동시키는 것이 힘들다.
해당 컨테이너 계층은 쓰기 작업을 위해 Storage Driver를 사용하여 Linux 커널을 통한 통합 파일 시스템을 제공하는데 이런 추가적인 추상화는 호스트파일에 직접 쓰기 작업을 하는 것에 비해 성능을 저하시킬 수 있다.
Volume & Bind Mount라는 옵션을 제공한다
해당 옵션을 사용해 컨테이너에 쓰기할 파일을 호스트에 직접 쓸 수 있게 되어 영속화 할 수 있다.
영속적이지 않은 파일에 대해 리눅스라면 tmps
마운트를 사용해 메모리에 파일을 저장할 수도 있다.
Docker
에 의해 관리되는 호스트의 특정 파일시스템에 저장되는 방식이다.
Linux
에서는 /var/lib/docker/volumes
에 저장된다.
Docker
가 아닌 프로세스에서는 접근하여 조작할 수 없으며 도커의 데이터를 저장하기 좋은 방법이다.
docker volume create [YOUR_VOLUME_NAME]
위와 같은 명령어로 컨테이너 동작과 별개로 생성할 수도 있고 컨테이너가 만들어질 때 생성할 수도 있다.
볼륨을 생성하고 이 볼륨을 Docker 컨테이너에 마운트하면 위의 Docker host 디렉터리에 저장되고 Docker에 의해 관리된다.
볼륨은 여러 컨테이너에 동시에 마운트 될 수도 있고 사용되지 않아도 직접 지우지 않는다면 자동으로 제거되지 않는다.
docker volume prune [OPTIONS]
호스트의 어떤 파일시스템에든 저장될 수 있다.
해당 파일을 도커가 아닌 프로세스에서도 접근하여 조작할 수 있다.
마운트 될 경우 호스트의 디렉터리와 서로 공유하며 컨테이너가 지워져도 호스트에 데이터가 보존된다.
문서에 따르면 바인드 마운트는 성능이 뛰어난 편이지만 특정 디렉터리 구조를 사용할 수 있는 호스트 파일 시스템에 의존하며 새로운 도커 어플리케이션을 개발할 경우 Volume 사용이 권장된다고 한다.
Docker CLI
명령어를 사용해 바인드 마운트를 직접 관리할 수 없다고 한다.
또한 장점이자 단점이 될 수 있는 것으로 컨테이너 프로세르를 통해 호스트의 중요한 디렉터리 생성,수정,삭제 등이 허용되기 때문에 사이드 이펙트가 있을 수 있다고 한다.
Volume
은 도커가 관리하는 특정 디렉터리 내에 생성되며 도커 프로세스로만 조작할 수 있지만 Bind Mount
는 호스트 파일 시스템 사용에 제한이 없고 마운트 된 파일을 다른 프로세스로도 조작할 수 있다.
Volume
은 Docker CLI로 관리가 쉽지만 Bind Mount
는 그렇지 않다.
공식 문서에서도 Volume
사용을 권장하고 있기 때문에 정말 다른 프로세스로 마운트 된 파일 조작이 필요한게 아니라면 어지간하면 Volume
을 사용하는 것이 적절해 보인다.
여러 도커 컨테이너들이 특정 데이터를 공유해야 할 경우
백업, 복구, 마이그레이션
I/O의 성능
Volumes on Docker Desktop have much higher performance than bind mounts from Mac and Windows hosts.
호스트와 컨테이너가 빌드설정 및 소스코드를 공유하는 경우
nextjs 애플리케이션에서 일부 서버사이드 동작에 로깅 설정을 해두었는데 컨테이너 내부에서 로그를 쓰면 확인하기 힘들고 다시 배포하면 사라질 것이기 때문에 Volume 설정을 해보았다.
# volume 생성
docker volume create next_log
version: "3.9"
services:
next:
image: myname/my-image:latest
ports:
- "port:port"
volumes:
- next_log:/app/logs
volumes:
next_log:
external: true
이미지를 만들 때 Work directory를 /app
으로 했기 때문에 /app/logs
로 마운트 해준다.
이렇게 로그 파일을 마운트하여 확인할 수 있게 되었다!
winston
을 사용해 SSR 페이지 요청, SSG 페이지 생성할 때 에러 발생과 SSR 페이지 응답시간 정도만 로깅해두었는데
이렇게 로그를 보존할 수 있게 된 상황을 어떻게 잘 활용할 수 있을지 생각해봐야겠다.
서버사이드렌더링 응답시간이 가끔 팍팍 튀는 경우가 있어서 시간을 로깅했는데 백엔드 api 요청 부분 하나가 약 1.2초 걸린 부분이 확인되었다.
placeholder
썸네일 이미지 목록을 생성하는 부분도 로깅했는데 예상보단 좀 느린것 같아서 없애거나 최적화를 고려해봐야겠다.