도커 파일의 "볼륨" 지침 이해
아래는 제 "도커 파일"의 내용입니다.
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" ]
이 파일에서 나는 기대하고 있습니다.VOLUME . /usr/src/app호스트에 에 대한 지침을 참조하십시오./usr/src/app컨테이너 폴더입니다.
이것이 올바른 방법인지 알려주시기 바랍니다.
간단히 말해서: 아니, 너의.VOLUME지침이 올바르지 않습니다.
도커일VOLUME컨테이너 측 경로가 지정된 하나 이상의 볼륨을 지정합니다.그러나 이미지 작성자는 호스트 경로를 지정할 수 없습니다.호스트 측에서는 Docker 루트 내부에 매우 긴 ID와 같은 이름으로 볼륨이 생성됩니다.에는 내기계에서이것은은▁is이것▁on▁this▁machine▁my내/var/lib/docker/volumes.
참고: 자동 생성된 이름은 매우 길고 인간의 관점에서 의미가 없기 때문에 이러한 볼륨은 종종 "이름 없음" 또는 "익명"으로 지칭됩니다.
'.' 문자를 사용하는 예제는 점을 첫 번째 또는 두 번째 인수로 만들더라도 내 컴퓨터에서 실행되지 않을 것입니다.다음 오류 메시지가 표시됩니다.
도커: 데몬의 오류 응답: oci 런타임 오류: container_linux.go:265: 컨테이너 프로세스 시작으로 인해 "process_linux.go:368: 컨테이너 초기화로 인해 "open /dev/ptmx: 해당 파일 또는 디렉터리 없음"이 발생했습니다.
.VOLUME그리고.-v그리고 그것은 확실히 여러분이 성취하려고 노력하는 것에 대한 해결책을 제공하지 않습니다.그래서, 바라건대, 다음의 사례들이 이러한 문제들에 대해 좀 더 조명해 줄 것입니다.
자습서:볼륨 지정
이 도커 파일이 지정된 경우:
FROM openjdk:8u131-jdk-alpine
VOLUME vol1 vol2
(이튜토리얼의 는, (으)로 차이가 없습니다.vol1 vol2또는/vol1 /vol2가 Docker이기 입니다./)
빌드:
docker build -t my-openjdk
실행:
docker run --rm -it my-openjdk
에서 컨이너안실니다행합에서테다를 실행합니다.ls에 두 즉, 명줄에디가있습니다리토렉./vol1그리고./vol2.
컨테이너를 실행하면 호스트 측에 두 개의 디렉토리 또는 "볼륨"이 생성됩니다.
컨테이너를 실행하는 동안 실행docker volume ls호스트 시스템에서 다음과 같은 내용을 볼 수 있습니다(간단하게 설명하기 위해 이름의 중간 부분을 세 개의 점으로 대체했습니다).
DRIVER VOLUME NAME
local c984...e4fc
local f670...49f0
컨테이너로 돌아가서 실행합니다.touch /vol1/weird-ass-file(해당 위치에 빈 파일을 저장합니다.)
이 파일은 이제 호스트 시스템의 이름 없는 볼륨 중 하나에서 사용할 수 있습니다.첫 번째 나열된 볼륨을 처음 시도했기 때문에 두 번 시도했지만 호스트 시스템에서 다음 명령을 사용하여 두 번째 나열된 볼륨에서 파일을 찾았습니다.
sudo ls /var/lib/docker/volumes/f670...49f0/_data
마찬가지로 호스트에서 이 파일을 삭제하려고 하면 컨테이너에서도 삭제됩니다.
참고: The_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!");
}
}
다음 도커 파일을 빌드합니다.
FROM openjdk:8u131-jdk-alpine
WORKDIR /src
ENTRYPOINT javac Hello.java && java Hello
다음 명령을 실행합니다.
docker run -v $(pwd)/src:/src my-openjdk
"Hello, World!"가 인쇄됩니다.
가장 좋은 점은 이미지 =를 다시 빌드하지 않고도 두 번째 실행 시 다른 출력에 대한 새 메시지로 .vmdk 파일을 완전히 수정할 수 있다는 것입니다.
마지막 발언
저는 도커에 대해 잘 알지 못하며, 앞서 언급한 "튜토리얼"은 3일간의 명령 줄 해커톤에서 수집한 정보를 반영합니다.저는 제 진술을 뒷받침하는 명확한 영어 문서에 대한 링크를 제공하지 못한 것이 거의 부끄럽지만, 솔직히 저는 이것이 개인적인 노력이 아니라 문서 부족 때문이라고 생각합니다.예제는 "Windows 10 -> Vagrant 2.0.0 -> Docker 17.09.0-ce"라는 현재 설정을 사용하여 광고된 대로 작동합니다.
자습서에서는 "어떻게 도커 파일에서 컨테이너의 경로를 지정하고 실행 명령으로 호스트 경로만 지정할 수 있습니까?"라는 문제를 해결하지 않습니다.방법이 있을지도 몰라요, 그냥 못 찾았어요.
마지막으로, 나는 직감적으로 그것을 특정합니다.VOLUMEDocker를 것이 이지 않을 만 아니라 Docker를 사용하는 것이 좋은 입니다.VOLUME 이유로두 가지 이유 때문에.이미 확인한 첫 번째 이유는 다음과 같습니다.호스트 경로를 지정할 수 없습니다. 이는 도커 파일이 호스트 시스템의 세부 사항에 매우 구애받지 않아야 하기 때문에 좋은 일입니다.하지만 두 번째 이유는 사람들이 사용하는 것을 잊어버릴 수도 있기 때문입니다.--rm컨테이너를 실행할 때 옵션을 선택합니다.컨테이너를 제거하는 것은 기억하지만 볼륨을 제거하는 것은 잊어버릴 수 있습니다.또한 인간의 기억력을 최대한 활용하더라도 익명의 모든 볼륨 중 어떤 것을 제거해도 안전한지 파악하는 것은 어려운 작업일 수 있습니다.
공식 도커 튜토리얼은 다음과 같이 말합니다.
데이터 볼륨은 Union File System을 우회하는 하나 이상의 컨테이너 내에서 특별히 지정된 디렉토리입니다.데이터 볼륨은 영구 또는 공유 데이터에 대해 다음과 같은 몇 가지 유용한 기능을 제공합니다.
볼륨은 컨테이너가 생성될 때 초기화됩니다.지점의 경우, "Container Base Image"는
볼륨 시 기존 데이터가 새 볼륨으로 복사됩니다.
호스트를 마운트할 때는 해당되지 않습니다.
디렉토리).컨테이너 간에 데이터 볼륨을 공유하고 재사용할 수 있습니다.
데이터 볼륨을 직접 변경합니다.
이미지를 업데이트할 때 데이터 볼륨에 대한 변경 사항은 포함되지 않습니다.
컨테이너 자체를 삭제하더라도 데이터 볼륨은 유지됩니다.
Dockerfile컨테이너 내부 볼륨의 대상만 지정할 수 있습니다./usr/src/app.
할 때 docker run --volume=/opt:/usr/src/app my_image장착 지점을 지정할 필요는 없습니다(/opt)이가) 시스템에 을(를) 참조하십시오.을 하지 않은 --volume인수를 지정하면 마운트 지점이 자동으로 선택됩니다. 일반적으로 다음과 같습니다./var/lib/docker/volumes/.
VOLUME도커 파일의 줄은 이미지에 메타데이터를 약간 구성하지만 메타데이터가 어떻게 사용되는지가 중요합니다.
먼저, 이 두 줄은 무엇을 했습니까?
WORKDIR /usr/src/app
VOLUME . /usr/src/app
그WORKDIR하고 일부 이미지 경로를 지정합니다. 이와 " 여에있라를만고들않존리는, 경다같명에령대상경모현업메지이대일로를한함기를니합터트다정데이이지데미타록부도하와 같은 명령어의 디렉토리도 합니다.RUN그 장소에 있을 겁니다VOLUME선은 두 볼륨을 지정합니다. 하나는 상대 경로입니다..는 그고또하는나리입니다./usr/src/app둘 다 우연히 같은 디렉토리입니다.대부분의 경우VOLUME의 디렉터리를 array. 수도 .
Docker 파일에는 볼륨 소스를 지정할 수 없습니다.도커 파일에서 볼륨을 지정할 때 일반적으로 혼동되는 원인은 이미지 빌드 시 소스 및 대상의 런타임 구문과 일치하려고 시도하는 경우이며, 이는 작동하지 않습니다.도커 파일은 볼륨의 대상만 지정할 수 있습니다.누군가가 도커 허브의 공통 이미지를 업데이트하여 루트 디렉터리를 컨테이너에 마운트한 다음 /etc/passwd에 로그인을 추가하고 시스템d가 비트코인 최소값을 실행하도록 구성하는 진입점의 일부로 컨테이너 내부의 백그라운드 프로세스를 시작할 수 있기 때문에 볼륨의 소스를 정의할 수 있다면 사소한 보안 악용이 될 수 있습니다.다음 재부팅 시 er. 또는 파일 시스템에서 원격 사이트로 보낼 신용 카드, SSN 및 개인 키를 검색합니다.
VOLUME 라인은 무엇을 합니까?위에서 언급한 것처럼 이미지 내부의 디렉터리가 볼륨이라는 일부 이미지 메타데이터를 설정합니다.이 메타데이터는 어떻게 사용됩니까?이 이미지에서 컨테이너를 만들 때마다 도커는 해당 디렉토리를 볼륨으로 강제 설정합니다.실행 명령에 볼륨을 제공하지 않거나 파일을 작성하지 않으면 도커에 대한 유일한 옵션은 익명 볼륨을 만드는 것입니다.이 볼륨은 이름에 대한 고유 ID가 길고 생성된 이유나 포함된 데이터에 대한 다른 표시가 없는 로컬 명명된 볼륨입니다(익명 볼륨은 데이터가 손실되는 경우).명명된 볼륨 또는 호스트 볼륨을 가리키며 볼륨을 재정의하면 데이터가 대신 해당 볼륨으로 이동합니다.
볼륨은 모든 것을 파괴합니다.도커 파일에 정의된 볼륨은 비활성화할 수 없습니다.그리고 더 중요한 것은,RUN도커의 명령은 클래식 빌더와 함께 임시 컨테이너로 구현됩니다.그 임시 컨테이너들은 임시 익명 볼륨을 얻을 것입니다.해당 익명 볼륨은 이미지의 내용으로 초기화됩니다.의 에 있는 모든 .RUN해당 볼륨에 대한 명령이 수행됩니다. 때.RUN명령이 완료되고 이미지의 변경 내용이 저장되며 익명 볼륨의 변경 내용은 삭제됩니다.이 때문에, 저는 다음을 정의하지 않을 것을 강력히 권고합니다.VOLUMEDocker 파일 안에 있습니다.볼륨 위치의 초기 데이터로 이미지를 확장하려는 이미지의 다운스트림 사용자에게 예기치 않은 동작이 발생합니다.
볼륨을 지정하는 방법을 선택하십시오.이미지와 함께 볼륨을 포함할 위치를 지정하려면docker-compose.yml사용자는 볼륨 위치를 로컬 환경에 맞게 조정할 수 있으며 게시 포트 및 네트워킹과 같은 다른 런타임 설정을 캡처합니다.
누군가가 이것을 기록해야 합니다!네.Docker는 Docker 파일의 문서에 Volume 사용량에 대한 경고와 함께 런타임에 소스를 지정하라는 조언을 포함합니다.
- 도커 파일 내에서 볼륨 변경:볼륨이 선언된 후 볼륨 내에서 데이터를 변경하는 빌드 단계가 있으면 해당 변경 내용은 삭제됩니다.
...
- 호스트 디렉토리는 컨테이너 런타임에 선언됩니다.호스트 디렉토리(마운트 포인트)는 본질적으로 호스트에 종속됩니다.이는 지정된 호스트 디렉토리를 모든 호스트에서 사용할 수 있다고 보장할 수 없기 때문에 이미지 이동성을 유지하기 위한 것입니다.이러한 이유로 Docker 파일 내에서 호스트 디렉토리를 마운트할 수 없습니다.
VOLUME은 " 이령다음지것정지않습다니지원하" .host-dir할 때 .컨테이너를 만들거나 실행할 때 마운트 지점을 지정해야 합니다.
Docker 파일에서 VOLUME과 RUN 단계를 정의하는 동작은 빌드킷의 도입과 함께 변경되었습니다.여기 두 가지 예가 있습니다.먼저 도커 파일:
$ cat df.vol-run
FROM busybox
WORKDIR /test
VOLUME /test
RUN echo "hello" >/test/hello.txt \
&& chown -R nobody:nobody /test
다음은 빌드킷 없이 빌드하기입니다.RUN 단계의 변경 내용이 손실되는 방법에 주목합니다.
$ DOCKER_BUILDKIT=0 docker build -t test-vol-run -f df.vol-run .
Sending build context to Docker daemon 23.04kB
Step 1/4 : FROM busybox
---> beae173ccac6
Step 2/4 : WORKDIR /test
---> Running in aaf2c2920ebd
Removing intermediate container aaf2c2920ebd
---> 7960bec5b546
Step 3/4 : VOLUME /test
---> Running in 9e2fbe3e594b
Removing intermediate container 9e2fbe3e594b
---> 5895ddaede1f
Step 4/4 : RUN echo "hello" >/test/hello.txt && chown -R nobody:nobody /test
---> Running in 2c6adff98c70
Removing intermediate container 2c6adff98c70
---> ef2c30f207b6
Successfully built ef2c30f207b6
Successfully tagged test-vol-run:latest
$ docker run -it test-vol-run /bin/sh
/test # ls -al
total 8
drwxr-xr-x 2 root root 4096 Mar 6 14:35 .
drwxr-xr-x 1 root root 4096 Mar 6 14:35 ..
/test # exit
그런 다음 빌드킷으로 빌드합니다.RUN 단계의 변경 사항이 보존되는 방식을 확인합니다.
$ docker build -t test-vol-run -f df.vol-run .
[+] Building 0.5s (7/7) FINISHED
=> [internal] load build definition from df.vol-run 0.0s
=> => transferring dockerfile: 154B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 34B 0.0s
=> [internal] load metadata for docker.io/library/busybox:latest 0.0s
=> CACHED [1/3] FROM docker.io/library/busybox 0.0s
=> [2/3] WORKDIR /test 0.0s
=> [3/3] RUN echo "hello" >/test/hello.txt && chown -R nobody:nobody /test 0.4s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:8cb3220e3593b033778f47e7a3cb7581235e4c6fa921c5d8ce1ab329ebd446b6 0.0s
=> => naming to docker.io/library/test-vol-run 0.0s
$ docker run -it test-vol-run /bin/sh
/test # ls -al
total 12
drwxr-xr-x 2 nobody nobody 4096 Mar 6 14:34 .
drwxr-xr-x 1 root root 4096 Mar 6 14:34 ..
-rw-r--r-- 1 nobody nobody 6 Mar 6 14:34 hello.txt
/test # exit
더잘이기위해하를 더 잘 하기 위해volume도커 파일에 대한 지침, mysql 공식 도커 파일 구현에서 일반적인 볼륨 사용에 대해 알아보겠습니다.
VOLUME /var/lib/mysql
참조: https://github.com/docker-library/mysql/blob/3362baccb4352bcf0022014f67c1ec7e6808b8c5/8.0/Dockerfile
그/var/lib/mysql는 데이터 파일을 저장하는 MySQL의 기본 위치입니다.
테스트용으로만 테스트 용기를 실행할 때는 장착 지점을 지정할 수 없습니다(예:
docker run mysql:8
는 mysql 컨테인스지가정기된사로 합니다.volume 은 Docker 내에서 긴 와 같은 되며, 를 "이라고 합니다볼륨은 Docker 루트 내에서 매우 긴 ID와 유사한 이름으로 생성되며, 이를 "이름 없음" 또는 "익명" 볼륨이라고 합니다.기본 호스트 시스템 /var/lib/docker/volumes의 폴더에 있습니다.
/var/lib/docker/volumes/320752e0e70d1590e905b02d484c22689e69adcbd764a69e39b17bc330b984e4
이는 탑재 지점을 지정할 필요 없이 빠른 테스트를 위해 매우 편리하지만, 컨테이너 레이어가 아닌 데이터 저장소에 볼륨을 사용하면 최상의 성능을 얻을 수 있습니다.
정식으로 사용하려면 명명된 볼륨 또는 바인딩 마운트를 사용하여 마운트 경로를 지정해야 합니다.
docker run -v /my/own/datadir:/var/lib/mysql mysql:8
이 명령은 기본 호스트 시스템의 /my/own/dataadir 디렉토리를 컨테이너 내의 /var/lib/mysql로 마운트합니다.컨테이너가 삭제되더라도 데이터 디렉토리 /my/own/datadir는 자동으로 삭제되지 않습니다.
mysql 공식 이미지 사용("데이터 저장 위치" 섹션을 확인하십시오)
참조: https://hub.docker.com/_/mysql/
그VOLUME를 한대명으로 합니다.Dockerfile상당히 합법적이고, 완전히 관습적이며, 사용하기에 절대적으로 괜찮고, 어떤 식으로든 사용이 권장되지 않습니다.그냥 이해만 하면 됩니다.
컨테이너에 있는 앱이 많이 쓰는 디렉터리를 가리키기 위해 사용합니다.용사안을 .VOLUME구성 파일처럼 호스트와 컨테이너 간에 공유하고 싶기 때문입니다.
하나의 변수가 필요합니다. 는 명즉폴령 에 대 경 한 에 가 로 필 요 합 니 다 더 변 하 수 매 는 나 의 개 니 ▁to ▁the 다 합 필 , ▁relative 요 ▁to 명WORKDIR설정된 경우, 용기 내에서.그런 다음 도커가 그래프(/var/lib/docker)에 볼륨을 만들고 컨테이너의 폴더에 마운트합니다.이제 컨테이너는 고성능으로 쓸 수 있는 곳이 있을 것입니다.다음을 제외하고는VOLUME 속도는 . 컨테이너가 사용 중이기 때문입니다.copy on write용기 자체에 전략이 있습니다.copy on write전략은 볼륨이 존재하는 주요 이유입니다.
폴한위경으로 된 폴더 VOLUME. 왜냐하면 " " "이기 때문입니다. 다음 이유 때문입니다.VOLUME컨테이너가 시작될 때만 실행됩니다. 일종의.ENV.
으로 기적으로와 함께.VOLUME외부에서 볼륨을 마운트하지 않고도 성능을 얻을 수 있는 명령입니다.외부 마운트 없이도 컨테이너 실행 전반에 걸쳐 데이터를 저장할 수 있습니다.그리고 준비가 되면 그 위에 무언가를 올려놓기만 하면 됩니다.
가지 사례 다음과 같은 예가 .
통나무들
folders
일부 잘못된 사용 사례:
설정
저는 어떤 경우에도 VOLUME을 사용하는 것이 좋다고 생각하지 않습니다. 단, 사용자가 직접 이미지를 만들고 다른 사용자가 사용하지 않는 경우는 제외합니다.
확장한 기본 이미지에 노출된 볼륨 때문에 부정적인 영향을 받았고 이미지가 이미 실행된 후에야 문제에 대해 알게 되었습니다. 예를 들어 다음을 선언하는 워드프레스와 같습니다./var/www/html폴더를 볼륨으로 사용할 수 있으므로 빌드 단계에서 추가하거나 변경한 파일은 고려되지 않으며, 사용자가 알지 못하더라도 라이브 변경 사항은 유지됩니다.다른 위치에 웹 디렉터리를 정의하는 잘못된 해결 방법이 있지만, 이 방법은 훨씬 간단한 방법인 VOLUME 지시어를 제거하는 것에 대한 나쁜 해결 방법일 뿐입니다.
▁the를 사용하면 볼륨의 의도를 쉽게 할 수 .-v이 옵션을 사용하면 Docker 파일 및 상위 Docker 파일을 볼 필요 없이 컨테이너의 볼륨을 명확히 할 수 있을 뿐만 아니라 소비자가 볼륨을 사용할지 여부를 선택할 수 있습니다.
또한 다음과 같은 이유로 Volumes를 사용하는 것이 좋지 않습니다.
그러나 VOLUME 명령은 비용이 많이 듭니다.
- 이름 없는 볼륨이 생성되고 컨테이너가 제거된 후에도 Docker 호스트에서 저장 공간을 계속 차지하는 것을 모를 수 있습니다.
- 도커 파일에 선언된 볼륨을 제거할 방법이 없습니다.다운스트림 이미지는 볼륨이 있는 경로에 데이터를 추가할 수 없습니다.
후자의 문제는 다음과 같은 문제를 야기합니다.
볼륨 선언 해제 옵션이 있으면 도움이 되지만 이미지를 생성한 도커 파일(및 상위 도커 파일!)에 정의된 볼륨을 알고 있는 경우에만 유용합니다.또한 Docker 파일의 최신 버전에 볼륨을 추가하여 이미지 소비자가 예상치 못한 문제를 해결할 수 있습니다.
또 다른 좋은 설명(제거된 볼륨이 있는 오라클 이미지에 대한): 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을 사용하는 것은 가치가 없습니다.지속성이 필요한 사용자는 지정된 컨테이너를 실행할 때 볼륨 매핑을 제공해야 합니다.디렉터리의 소유권(/var/lib/influxdb)을 설정할 수 없는 제 문제가 InfluenceDB의 Docker 파일에 있는 VOLUME 선언 때문이라는 것을 추적하기가 매우 어려웠습니다.UNVOLUME 유형의 옵션이 없거나 옵션을 완전히 제거하지 않으면 지정된 폴더와 관련된 내용을 변경할 수 없습니다.특히 보안을 인식하고 특정 UID를 지정하려는 경우 호스트에서 소프트웨어를 실행하는 데 필요한 것보다 더 많은 권한을 가진 임의 사용자를 방지하기 위해 이미지를 실행해야 합니다.
VOLUME에 대해 제가 볼 수 있는 유일한 좋은 점은 설명서에 관한 것인데, (부작용 없이) 그렇게만 했다면 좋다고 생각합니다.
업데이트(2021-10-19)
mysql 공식 이미지와 관련된 문제가 하나 더 있습니다: https://github.com/docker-library/mysql/issues/255
업데이트(2022-01-26)
Volume 관련 문제를 설명하는 좋은 기사를 찾았습니다. 이미 몇 년이 지났지만 동일한 문제가 남아 있습니다.
https://boxboat.com/2017/01/23/volumes-and-dockerfiles-dont-mix/
TL;DR
저는 VOLUME의 가장 좋은 용도는 더 이상 사용하지 않는 것이라고 생각합니다.
비록 그것은 매우 오래된 게시물이지만, 나는 여전히 당신이 최신의 것을 확인하기를 원합니다.docker만약 당신이 사이에 약간의 혼란이 있다면 공식 문서.volume와 함께bind mounts
Bind mounts도커 초기부터 존재해 왔으며, "바인딩 마운트는 민감한 파일에 대한 액세스를 허용한다"와 같이 완벽한 디자인이 되어서는 안 된다고 생각합니다. 도커 관계자가 선호하는 정보를 얻을 수 있습니다.VOLUMEbind mounts.
여기에서 볼륨에 대한 유용한 사용 사례를 얻을 수 있습니다.
에 대한 참조
언급URL : https://stackoverflow.com/questions/41935435/understanding-volume-instruction-in-dockerfile
'sourcecode' 카테고리의 다른 글
| galera 클러스터를 시작할 수 없음 - bash: galera_new_cluster: 명령을 찾을 수 없음 (0) | 2023.09.05 |
|---|---|
| Gitlab CI + DinD + MySQL 서비스 권한 문제 (0) | 2023.09.05 |
| 정의되지 않은 행 선택 (0) | 2023.09.05 |
| 프로그래밍 방식으로 UI 세그먼트 컨트롤을 전환하는 방법은 무엇입니까? (0) | 2023.09.05 |
| 지정된 Laravel URL로 리디렉션 (0) | 2023.09.05 |