데이터베이스 (예 : couchdb)를 도킹하려고한다고 가정 해 봅니다. 그런 다음 당신이 볼륨을 고려 적어도 두 자산이 있습니다 :도커 볼륨 컨테이너 전략
하자 추가로 개인 DB를-파일을 유지하지만 로그를 노출하고 싶은 말은 - 나중에 처리하기 위해 파일.
나는 문서를 알아 보았 마찬가지로 지금까지 두 가지 옵션이 있습니다
첫 번째 옵션을
두 번째 옵션
두 질문 :
대답 BR의 볼커는 예 모두 유효하고 가능 점이다.
질문 2에 대한 나의 대답은 내가 다른 접근법을 전적으로 고려할 것이며 이는 선택의 폭이 미션 크리티컬 한 시스템인지 여부와 데이터 손실을 피해야하는지 여부에 달려 있다고합니다.
미션 당신이 절대적으로 데이터를 잃을 수 없다면, 당신이 당신의 데이터베이스 컨테이너에 신뢰할 수있는 디스크를 마운트 결합하는 것이 좋습니다 것입니다
중요합니다. 바인드 마운트는 기본적으로 Docker Host 파일 시스템의 일부를 컨테이너에 마운트합니다.
그래서 위의 예를 통해 NFS를 통해 공유되고 Docker Host에 장착 된 신뢰할 수있는 디스크를 /reliable/disk에 작성했다고 가정 해 보겠습니다. 내 데이터베이스와 나는 다음과 같은 도커 명령을 실행 것이라고 사용하려면
docker run -d -v /reliable/disk:/data/db my-database-image
나는 데이터베이스 파일이 신뢰할 수있는 저장 장치에 기록되는 것을 알고이 방법을. Docker 호스트를 잃어 버렸을지라도 데이터베이스 파일을 가지고 있으며 NFS 공유에 액세스 할 수있는 다른 호스트에서 데이터베이스 컨테이너를 실행하여 쉽게 복구 할 수 있습니다.
당신은 데이터베이스 로그를 정확히 같은 일을 수행 할 수 있습니다
docker run -d -v /reliable/disk/data/db:/data/db -v /reliable/disk/logs/db:/logs/db my-database-image
또한 쉽게 분리 작업을 위해 다른 용기에이 볼륨을 마운트 바인딩 할 수 있습니다. 읽기 전용 다른 컨테이너로 데이터를 보호하기로 장착 결합하는 것이 좋습니다 :
docker run -d -v /reliable/disk/logs/db:/logs/db:ro my-log-processor
이는 미션 크리티컬 시스템의 경우이 내 권장되는 방법 일 것입니다.
하지 미션 크리티컬
시스템이 중요한 임무는하지 않고 데이터 손실에 대한 높은 잠재력을 견딜 수있는 경우에, 나는 당신이 원하는 무엇을 정확하게 사용 Docker Volume API에 보일 것이다 관리 컨테이너의 수명주기를 초과하여 살아야하는 데이터를위한 볼륨을 생성합니다.
docker volume 명령에 대한 좋은 점은 당신이라는 이름의 볼륨을 생성하고 당신이 그 (것)들을 잘 이름을 경우 그들이 사용하는 어떤 사람들에게 아주 명백한 될 수 있습니다 있다는 것입니다 :
docker volume create db-data docker volume create db-logs
그런 다음 수 명령 줄에서 컨테이너에이 볼륨을 마운트 :
docker run -d -v db-data:/db/data -v db-logs:/logs/db my-database-image
이 볼륨은 컨테이너와의 라이프 사이클을 넘어 살아남을 것입니다 Docker 호스트 인 경우 파일 시스템에 저장됩니다. 당신은 사용할 수 있습니다 : 데이터 저장 및 백업 해당 위치를 당신이 원한다면되는 위치
docker volume inspect db-data
은 확인하려면.
Docker Compose 같은 것을보고 싶다면이 모든 것을 하나의 파일에 선언 한 다음 단일 명령을 통해 전체 환경을 만들 수 있습니다.