아래는 "Dockerfile"의 내용입니다.

FROM node:boron

# Create app directory
RUN mkdir -p /usr/src/app

# change working dir to /usr/src/app
WORKDIR /usr/src/app

VOLUME . /usr/src/app

RUN npm install

EXPOSE 8080

CMD ["node" , "server" ]

이 파일에서 호스트의 현재 작업 디렉토리 내용을 컨테이너의 / usr / src / app 폴더에 마운트하는 "VOLUME. / usr / src / app"명령이 필요합니다.

이것이 올바른 방법인지 알려주십시오.

공식 도커 튜토리얼은 다음과 같이 말합니다.

데이터 볼륨은 Union File System을 우회하는 하나 이상의 컨테이너 내에서 특별히 지정된 디렉토리입니다. 데이터 볼륨은 지속적 또는 공유 데이터에 유용한 여러 가지 기능을 제공합니다.

• 컨테이너가 생성 될 때 볼륨이 초기화됩니다. 컨테이너의 기본 이미지에 지정된 마운트 지점
  의 데이터가 포함 된 경우 볼륨
  초기화 시 기존 데이터가 새 볼륨으로 복사됩니다 . (호스트를 마운트 할 때는 적용되지 않습니다.
  디렉토리를 .)

• 컨테이너간에 데이터 볼륨을 공유하고 재사용 할 수 있습니다.

• 데이터 볼륨은 직접 변경됩니다.

• 이미지를 업데이트하면 데이터 볼륨에 대한 변경 사항이 포함되지 않습니다.

• 컨테이너 자체가 삭제 된 경우에도 데이터 볼륨이 유지됩니다.

에서 Dockerfile당신은 볼륨의 대상을 지정할 수 있습니다 내부 컨테이너를. 예 /usr/src/app.

당신은 용기, 예를 실행하면 docker run --volume=/opt:/usr/src/app my_image, 당신은 할 수 있지만 설치 지점 (지정하지 않아도 / 옵션을 호스트 컴퓨터에서). --volume인수를 지정하지 않으면 일반적으로 아래에서 마운트 지점이 자동으로 선택됩니다 /var/lib/docker/volumes/.

한마디로 : 아니오, 귀하의 VOLUME지시가 정확하지 않습니다.

Dockerfile은 VOLUME컨테이너 측 경로가 지정된 하나 이상의 볼륨을 지정합니다. 그러나 이미지 작성자가 호스트 경로를 지정할 수 없습니다. 호스트 측에서 볼륨은 Docker 루트 내에 매우 긴 ID와 같은 이름으로 생성됩니다. 내 컴퓨터에서 이것은/var/lib/docker/volumes .

참고 : 자동 생성 된 이름은 매우 길고 사람의 관점에서 이해가되지 않기 때문에 이러한 볼륨을 "명명되지 않은"또는 "익명"이라고합니다.

'.'를 사용하는 예 점을 첫 번째 또는 두 번째 인수로 설정하더라도 문자가 내 컴퓨터에서 실행되지 않습니다. 이 오류 메시지가 나타납니다.

docker : 데몬의 오류 응답 : oci runtime error : container_linux.go : 265 : 컨테이너 프로세스를 시작하면 "process_linux.go : 368 : container init이 (가) \"open / dev / ptmx : no such file or directory \ ""입니다.

나는 무엇을이 시점 밝혔다 된 것은 아마도 이해하려고 사람에게 매우 가치없는 것을 알고 VOLUME그리고 -v그것은 확실히 당신이 달성하려고 무엇을위한 솔루션을 제공하지 않습니다. 따라서 다음 예제가 이러한 문제에 대해 더 많은 정보를 제공 할 수 있기를 바랍니다.

직감 : 음량 지정

이 Dockerfile이 주어지면 :

FROM openjdk:8u131-jdk-alpine
VOLUME vol1 vol2

(이 minitutorial의 결과를 위해, 우리가 지정 vol1 vol2하거나 /vol1 /vol2이유를 묻지 않으면 아무런 차이 가 없습니다)

그것을 빌드하십시오 :

docker build -t my-openjdk

운영:

docker run --rm -it my-openjdk

컨테이너 내부에서 ls명령 행을 실행 하면 두 개의 디렉토리가 있음을 알 수 있습니다. /vol1그리고 /vol2.

컨테이너를 실행하면 호스트 측에 두 개의 디렉토리 또는 "볼륨"이 생성됩니다.

컨테이너 실행하면서, 실행 docker volume ls상의 호스트 컴퓨터 와이 같은 것을 볼 수 있습니다 (I은 간결 세 가지 점 이름의 중간 부분을 대체했다)

DRIVER    VOLUME NAME
local     c984...e4fc
local     f670...49f0

컨테이너로 돌아가서 실행하십시오 touch /vol1/weird-ass-file(해당 위치에 빈 파일을 작성 함).

이 파일은 이제 호스트 시스템에서 이름이없는 볼륨 lol 중 하나로 사용 가능합니다. 첫 번째로 나열된 볼륨을 처음 시도했기 때문에 두 번의 시도가 필요했지만 결국 호스트 컴퓨터에서이 명령을 사용하여 두 번째로 나열된 볼륨에서 파일을 찾았습니다.

sudo ls /var/lib/docker/volumes/f670...49f0/_data

마찬가지로 호스트에서이 파일을 삭제하려고하면 컨테이너에서도 삭제됩니다.

참고 : _data폴더는 "마운트 포인트"라고도합니다.

컨테이너를 종료하고 호스트의 볼륨을 나열하십시오. 그들은 사라 졌어요. --rm컨테이너를 실행할 때 플래그를 사용 했으며이 옵션은 종료시 컨테이너뿐만 아니라 볼륨도 효과적으로 제거합니다.

새 컨테이너를 실행하지만 다음을 사용하여 볼륨을 지정하십시오 -v.

docker run --rm -it -v /vol3 my-openjdk

이렇게 하면 세 번째 볼륨 이 추가 되고 전체 시스템에 이름이 지정되지 않은 볼륨이 세 개 있습니다. 우리가 지정한 경우에만 명령이 충돌했을 것 -v vol3입니다. 인수는 컨테이너 내부 의 절대 경로 여야합니다 . 호스트 측에서 새 세 번째 볼륨은 익명이며의 다른 두 볼륨과 함께 있습니다 ./var/lib/docker/volumes/

앞서 Dockerfile런타임 중에 호스트에서 컨테이너로 파일을 가져 오려고 할 때 문제가되는 호스트 경로에 매핑 할 수 없다고 언급했습니다 . 다른 -v구문으로이 문제를 해결합니다.

프로젝트 디렉토리 에 컨테이너 내부와 ./src동기화하려는 하위 폴더가 있다고 상상해보십시오 /src. 이 명령은 트릭을 수행합니다.

docker run -it -v $(pwd)/src:/src my-openjdk

:캐릭터의 양쪽은 절대 경로를 기대합니다. 왼쪽은 호스트 시스템의 절대 경로이고 오른쪽은 컨테이너 내부의 절대 경로입니다. pwd"현재 / 작업 디렉토리 인쇄"명령입니다. 명령을 넣으면 $()명령이 괄호 안에 들어가서 서브 쉘에서 실행되고 프로젝트 디렉토리의 절대 경로가됩니다.

모두 합치면 ./src/Hello.java다음과 같은 내용으로 호스트 시스템의 프로젝트 폴더에 있다고 가정 하십시오.

public class Hello {
    public static void main(String... ignored) {
        System.out.println("Hello, World!");
    }
}

이 Dockerfile을 빌드합니다.

FROM openjdk:8u131-jdk-alpine
WORKDIR /src
ENTRYPOINT javac Hello.java && java Hello

이 명령을 실행합니다 :

docker run -v $(pwd)/src:/src my-openjdk

"Hello, World!"가 인쇄됩니다.

가장 좋은 부분은 이미지를 다시 빌드하지 않고도 두 번째 실행에서 다른 출력을 위해 새 메시지로 .java 파일을 자유롭게 자유롭게 수정할 수 있다는 것입니다.

최종 비고

저는 Docker를 처음 접했고 위에서 언급 한 "자습서"는 3 일 명령 행 해커 톤에서 수집 한 정보를 반영합니다. 나는 나의 진술을 뒷받침하는 명확한 영어와 같은 문서에 대한 링크를 제공 할 수 없었지만 거의 부끄러운 일이지만, 솔직히 이것은 문서가 부족하고 개인적인 노력이 아니라고 생각합니다. "Windows 10-> Vagrant 2.0.0-> Docker 17.09.0-ce"인 현재 설정을 사용하여 광고가 작동하는 것으로 알고 있습니다.

이 튜토리얼에서는 "Dockerfile에서 컨테이너의 경로를 지정하고 실행 명령 만 호스트 경로를 지정하게하는 방법"문제를 해결하지 못합니다. 방법이있을 수 있습니다, 나는 그것을 찾지 못했습니다.

마지막으로 VOLUMEDockerfile에서 지정하는 것은 드문 일이 아니라 결코 사용하지 않는 것이 가장 좋습니다 VOLUME. 두 가지 이유가 있습니다. 우리가 이미 확인한 첫 번째 이유 : 호스트 경로를 지정할 수 없습니다. Dockerfiles는 호스트 시스템의 특성에 매우 무관해야하기 때문에 좋은 방법입니다. 그러나 두 번째 이유는 사람들이 --rm컨테이너를 실행할 때 옵션 을 사용하는 것을 잊어 버릴 수 있기 때문입니다 . 컨테이너를 제거해야하지만 볼륨을 제거하는 것을 잊어 버릴 수도 있습니다. 또한 최고의 메모리를 사용하더라도 모든 익명 볼륨 중 제거 할 수있는 볼륨을 찾는 것은 어려운 작업 일 수 있습니다.

VOLUMEDockerfile에 줄을 지정하면 이미지에 약간의 메타 데이터가 구성되지만 메타 데이터가 사용되는 방식이 중요합니다.

먼저,이 두 줄은 무엇을 했습니까?

WORKDIR /usr/src/app
VOLUME . /usr/src/app

해당 WORKDIR라인은 디렉토리가 존재하지 않는 경우 디렉토리를 작성하고 RUN해당 위치에있는 명령의 현재 디렉토리와 함께 모든 상대 경로를 지정하도록 일부 이미지 메타 데이터를 업데이트합니다 . 이 VOLUME줄 은 두 개의 볼륨을 지정합니다 . 하나는 상대 경로 .이고 다른 하나는 /usr/src/app둘 다 동일한 디렉토리입니다. 대부분의 VOLUME행은 단일 디렉토리 만 포함하지만, 행한대로 여러 디렉토리를 포함하거나 json 형식의 배열 일 수 있습니다.

Dockerfile에서 볼륨 소스를 지정할 수 없습니다. Dockerfile에서 볼륨을 지정할 때 일반적인 혼동 소스가 이미지 빌드시 소스 및 대상의 런타임 구문과 일치하려고하는데 작동하지 않습니다 . Dockerfile은 볼륨의 대상 만 지정할 수 있습니다. 누군가가 도커 허브에서 공통 이미지를 업데이트하여 루트 디렉토리를 컨테이너에 마운트 한 다음 컨테이너 내에서 백그라운드 프로세스를 엔트리 포인트의 일부로 시작할 수 있기 때문에 볼륨의 소스를 정의 할 수 있다면 사소한 보안 문제가 될 수 있습니다. / etc / passwd에 로그인을 추가하거나, 다음에 다시 부팅 할 때 비트 코인 채굴기를 시작하도록 systemd를 구성하거나, 파일 시스템에서 신용 카드, SSN 및 개인 키를 검색하여 원격 사이트로 전송합니다.

VOLUME 라인은 무엇을합니까? 언급했듯이 이미지 내부의 디렉토리가 볼륨이라고 말하는 일부 이미지 메타 데이터를 설정합니다. 이 메타 데이터는 어떻게 사용됩니까? 이 이미지에서 컨테이너를 만들 때마다 docker는 해당 디렉토리를 볼륨으로 만듭니다. 실행 명령 또는 파일 작성에서 볼륨을 제공하지 않으면 docker의 유일한 옵션은 익명 볼륨을 작성하는 것입니다. 이름이 길고 고유 한 ID를 가진 로컬 이름이 지정된 볼륨이며 이름이 작성된 이유 또는 포함 된 데이터에 대한 다른 표시가 없습니다 (익명 볼륨은 데이터가 손실 됨). 명명 된 또는 호스트 볼륨을 가리키는 볼륨을 재정의하면 데이터가 대신 이동합니다.

볼륨이 깨짐 : Dockerfile에 정의 된 볼륨은 비활성화 할 수 없습니다. 더 중요한 것은 RUNdocker 의 명령은 임시 컨테이너로 구현됩니다. 이러한 임시 컨테이너는 임시 익명 볼륨을 갖습니다. 해당 익명 볼륨은 이미지의 내용으로 초기화됩니다. RUN명령 을 통해 컨테이너 내부에 쓰면 해당 볼륨에 기록됩니다. RUN명령이 완료 되면 이미지에 대한 변경 내용이 저장 되고 익명 볼륨에 대한 변경 내용이 삭제됩니다. 이 때문에 나는VOLUME Dockerfile 내부 . 볼륨 위치의 초기 데이터로 이미지를 확장하려는 이미지의 다운 스트림 사용자에게 예기치 않은 동작이 발생합니다.

볼륨을 어떻게 지정해야합니까? 이미지에 볼륨을 포함 할 위치를 지정하려면docker-compose.yml . 사용자는이를 수정하여 볼륨 위치를 로컬 환경에 맞게 조정할 수 있으며 게시 포트 및 네트워킹과 같은 다른 런타임 설정을 캡처합니다.

누군가 이것을 문서화해야합니다! 그들은 가지고있다. Docker는 Dockerfile 의 설명서에서 VOLUME 사용법에 대한 경고 와 런타임시 소스를 지정하기위한 조언을 제공합니다.

• Dockerfile 내에서 볼륨 변경 : 빌드 단계에서 볼륨이 선언 된 후 볼륨 내에서 데이터를 변경하면 해당 변경 사항이 삭제됩니다.

...

• 호스트 디렉토리는 컨테이너 런타임에 선언됩니다 . 호스트 디렉토리 (마운트 포인트)는 본질적으로 호스트에 따라 다릅니다. 지정된 호스트 디렉토리가 모든 호스트에서 사용 가능한 것은 아니기 때문에 이미지 이식성을 유지하기위한 것입니다. 이러한 이유로 Dockerfile 내에서 호스트 디렉토리를 마운트 할 수 없습니다. VOLUME 명령은 지정을 지원하지 않는 host-dir매개 변수를. 컨테이너를 만들거나 실행할 때 마운트 지점을 지정해야합니다.

의 VOLUME명령 Dockerfile은 완전히 합법적이고 완전히 관례 적이며 사용하기에 완벽하며 어쨌든 더 이상 사용되지 않습니다. 이해해야합니다.

컨테이너의 앱이 많이 쓸 디렉토리를 가리 키기 위해 사용합니다. 우리는 VOLUME설정 파일처럼 호스트와 컨테이너간에 공유하기를 원하기 때문에 사용하지 않습니다 .

이 명령에는 단순히 하나의 매개 변수가 필요합니다. WORKDIR컨테이너 내에서 폴더를 설정합니다 (설정된 경우). 그런 다음 docker는 그래프 (/ var / lib / docker)에 볼륨을 만들고 컨테이너의 폴더에 마운트합니다. 이제 컨테이너는 고성능으로 쓸 곳이 있습니다. VOLUME명령이 없으면 컨테이너가 copy on write컨테이너 자체 에서 전략을 사용하기 때문에 지정된 폴더에 대한 쓰기 속도가 매우 느려 집니다. 이 copy on write전략은 볼륨이 존재하는 주된 이유입니다.

VOLUME명령으로 지정된 폴더 위에 마운트 VOLUME하면 컨테이너가 시작될 때만 실행 되므로 명령이 실행되지 않습니다.ENV .

기본적으로 VOLUME명령을 사용하면 볼륨을 외부에 마운트하지 않고도 성능을 얻을 수 있습니다. 외부 마운트 없이도 컨테이너 런 전체에 걸쳐 데이터가 저장됩니다. 그런 다음 준비가되면 간단히 그 위에 무언가를 마운트하십시오.

좋은 사용 사례 :
-logs
-temp 폴더

일부 나쁜 사용 사례 :
-정적 파일
-구성
-코드

volumedockerfile 의 명령어 를 더 잘 이해하려면 mysql 공식 docker 파일 구현의 일반적인 볼륨 사용법을 배우십시오.

VOLUME /var/lib/mysql

참조 : https://github.com/docker-library/mysql/blob/3362baccb4352bcf0022014f67c1ec7e6808b8c5/8.0/Dockerfile

는 /var/lib/mysqlMySQL의 기본 위치를 저장하는 데이터 파일입니다.

테스트 컨테이너를 테스트 목적으로 만 실행할 경우 장착 지점을 지정할 수 없습니다 (예 :

docker run mysql:8

mysql 컨테이너 인스턴스는 volumedockerfile 의 명령으로 지정된 기본 마운트 경로를 사용합니다 . 볼륨은 Docker 루트 내에 매우 긴 ID와 같은 이름으로 만들어지며이를 "명명되지 않은"또는 "익명"볼륨이라고합니다. 기본 호스트 시스템 / var / lib / docker / volumes의 폴더에 있습니다.

/var/lib/docker/volumes/320752e0e70d1590e905b02d484c22689e69adcbd764a69e39b17bc330b984e4

이는 마운트 지점을 지정할 필요없이 빠른 테스트 목적으로 매우 편리하지만 컨테이너 계층이 아닌 데이터 저장소에 볼륨을 사용하여 최상의 성능을 얻을 수 있습니다.

공식적으로 사용하려면 명명 된 볼륨 또는 바인드 마운트를 사용하여 마운트 경로를 지정해야합니다. 예 :

docker run  -v /my/own/datadir:/var/lib/mysql mysql:8

이 명령은 기본 호스트 시스템에서 / my / own / datadir 디렉토리를 컨테이너 내의 / var / lib / mysql로 ​​마운트합니다. 컨테이너가 삭제 되더라도 데이터 디렉토리 / my / own / datadir은 자동으로 삭제되지 않습니다.

mysql 공식 이미지 사용법 ( "데이터 저장 위치"섹션을 확인하십시오) :

참조 : https://hub.docker.com/_/mysql/

본인이 직접 이미지를 만들고 다른 사람이 사용하지 않는 경우를 제외하고는 어떠한 경우에도 VOLUME 사용을 고려하지 않습니다.

확장 된 기본 이미지에 노출 된 VOLUME로 인해 부정적인 영향을 받았으며 /var/www/html폴더를 VOLUME 으로 선언하는 wordpress와 같이 이미지가 이미 실행 된 후에 만 ​​문제에 대해 알게 되었습니다. 이는 파일이 추가되거나 변경되는 것을 의미합니다. 빌드 단계는 고려되지 않으며, 모르는 경우에도 실시간 변경 사항이 유지됩니다. 다른 곳에서 웹 디렉토리를 정의하는 추악한 해결 방법이 있지만 이것은 VOLUME 지시문을 제거하는 더 간단한 방법에 대한 나쁜 해결책입니다.

-v옵션을 사용하여 쉽게 볼륨의 의도를 얻을 수 있습니다 . 이것은 컨테이너의 볼륨이 무엇인지 명확하게 할뿐만 아니라 (Dockerfile과 부모 Dockerfile을 보지 않고도) 소비자에게 옵션을 제공합니다. 볼륨을 사용하거나 사용하지 않습니다.

이 답변에 따르면 다음과 같은 이유로 VOLUMES를 사용하는 것은 기본적으로 좋지 않습니다 .

그러나 VOLUME 명령에는 비용이 듭니다.

• 사용자는 이름이 지정되지 않은 볼륨이 생성되는 것을 알지 못하고 컨테이너를 제거한 후에도 Docker 호스트의 스토리지 공간을 계속 차지합니다.
• Dockerfile에 선언 된 볼륨을 제거 할 방법이 없습니다. 다운 스트림 이미지는 볼륨이 존재하는 경로에 데이터를 추가 할 수 없습니다.

후자의 문제는 이와 같은 문제를 야기합니다.

• 도커 이미지에서 볼륨을“선언”하는 방법은 무엇입니까?
• Docker의 GitLab : 배포간에 사용자 데이터를 유지하는 방법은 무엇입니까?

볼륨을 선언하지 않는 옵션이 있으면 이미지를 생성 한 dockerfile (및 상위 dockerfiles)에 정의 된 볼륨 을 아는 경우에만 도움 이됩니다. 또한 VOLUME은 최신 버전의 Dockerfile에 추가되어 이미지 소비자에게 예기치 않게 문제가 발생할 수 있습니다.

(또 다른 좋은 설명 오라클 이미지를 가진 볼륨에 대한 한, 제거 ) : https://github.com/oracle/docker-images/issues/640#issuecomment-412647328

VOLUME이 사람들을 위해 물건을 부수는 더 많은 경우 :

• https://github.com/datastax/docker-images/issues/31
• https://github.com/docker-library/wordpress/issues/232
• https://github.com/docker-library/ghost/issues/195
• https://github.com/samos123/docker-drupal/issues/10

풀 요청은 폐쇄 된 특성을 (VOLUME 포함) 부모의 이미지를 다시 설정하는 옵션을 추가하고 논의되고 여기에 (당신이 볼 수있는 몇 가지 의 경우 의 사람들 이있는 때문에 dockerfiles에 정의 된 볼륨에 부정적인 영향을) 주석 좋은과를 VOLUME에 대한 설명 :

Dockerfile에서 VOLUME을 사용하는 것은 가치가 없습니다. 지속성이 필요한 사용자는 지정된 컨테이너를 실행할 때 볼륨 매핑을 제공해야합니다. 디렉토리 소유권 (/ var / lib / influxdb)을 설정할 수없는 문제는 InfluxDB의 Dockerfile의 VOLUME 선언으로 인한 것임을 추적하기가 매우 어렵습니다. UNVOLUME 유형의 옵션이 없거나 완전히 제거하지 않으면 지정된 폴더와 관련된 것을 변경할 수 없습니다. 이는 특히 보안을 인식하고 특정 UID를 지정하고자 할 때 임의의 사용자를 피하기 위해 필요한 것보다 많은 권한을 가지고 호스트에서 소프트웨어를 실행하는 것처럼 이미지를 실행해야 할 때 이상적입니다.

나는 또한 EXPOSE를 나쁜 것으로 생각하지만 부작용이 적습니다. VOLUME 및 EXPOSE에서 볼 수있는 유일한 장점은 문서에 관한 것입니다.

TL; DR

VOLUME을 가장 많이 사용하는 것은 더 이상 사용되지 않는 것으로 생각합니다.