그누보드 - [번역]Dockerfile 레퍼런스 #2

[번역]Dockerfile 레퍼런스 #2 정보

[번역]Dockerfile 레퍼런스 #2

본문

Environment replacement

환경 변수 (ENV 문으로 선언)는 특정 명령어에서 Dockerfile이 해석 할 변수로 사용될 수도 있습니다. 변수형 구문을 문자 그대로 명령문에 포함시키기 위해 이스케이프도 처리됩니다.

환경 변수는 Dockerfile에서 $variable_name 또는 ${variable_name}으로 표시됩니다. 이들은 동일하게 취급되며 중괄호 구문은 일반적으로 ${foo}_bar와 같이 공백이 없는 변수 이름 관련 문제를 해결하는 데 사용됩니다.

${variable_name} 구문은 아래에 지정된 몇 가지 표준 bash 수정자를 지원합니다.

${variable:-word}는 변수가 설정되면 결과가 해당 값이됨을 나타냅니다. 변수를 설정하지 않으면 단어가 결과가됩니다.
${variable:+word}는 변수가 설정되면 단어가 결과가되고 그렇지 않으면 결과가 빈 문자열임을 나타냅니다.

모든 경우에, 단어는 추가 환경 변수를 포함하여 모든 문자열이 될 수 있습니다.

이스케이프는 변수 앞에 \를 추가하여 가능합니다: 예를 들어, \$foo 또는 \${foo}는 각각 $foo 및 ${foo} 리터럴로 변환됩니다.

예 (구문 분석 표현은 # 뒤에 표시됨):

FROM busybox  
ENV foo /bar  
WORKDIR ${foo}   # WORKDIR /bar  
ADD . $foo       # ADD . /bar  
COPY \$foo /quux # COPY $foo /quux

환경 변수는 Dockerfile의 다음 명령어 목록에서 지원됩니다.

ADD
COPY
ENV
EXPOSE
FROM
LABEL
STOPSIGNAL
USER
VOLUME
WORKDIR
또한
ONBUILD (위의 지원되는 지침 중 하나와 결합 된 경우)

참고 : 1.4 이전의 ONBUILD 명령어는 위에 나열된 명령어와 결합 된 경우에도 환경 변수를 지원하지 않았습니다.

환경 변수 대체는 전체 명령어에서 각 변수에 대해 동일한 값을 사용합니다. 즉,이 예에서

ENV abc=hello  
ENV abc=bye def=$abc  
ENV ghi=$abc

def는 bye이 아닌 hello 값을 갖습니다. 그러나 ghi는 abc를 bye로 설정한 동일한 명령의 일부가 아니므로 bye의 값을 갖습니다.

.dockerignore file

docker CLI 가 컨텍스트를 docker 데몬으로 보내기 전에 컨텍스트의 루트 디렉토리에서 .dockerignore라는 파일을 찾습니다. 이 파일이 존재하면 CLI 는 파일과 일치하는 파일 및 디렉토리를 제외하도록 컨텍스트를 수정합니다. 이는 크고 민감한 파일과 디렉토리를 불필요하게 데몬에 보내고 ADD 또는 COPY를 사용하여 이미지에 추가하는 것을 방지합니다.

CLI 는 .dockerignore 파일을 줄 바꿈으로 구분 된 패턴 목록으로 해석하고 Unix 쉘의 파일 글로브와 유사합니다. 일치를 위해 컨텍스트의 루트는 작업 디렉토리와 루트 디렉토리로 간주됩니다. 예를 들어, /foo/bar 및 foo/bar 패턴은 모두 PATH의 foo 서브 디렉토리 또는 URL에있는 Git 저장소의 루트에서 bar라는 파일 또는 디렉토리를 제외합니다. 다른 것도 배제하지 않습니다.

.dockerignore 파일의 행이 열 1 에서 #으로 시작하면이 행은 주석으로 간주되며 CLI 에서 해석하기 전에 무시됩니다.

다음은 .dockerignore 파일의 예입니다.

# comment  
*/temp*  
*/*/temp*  
temp?

이 파일은 다음과 같은 빌드 동작을 발생시킵니다.

Rule	Behavior
`# comment`	무시되.
`/temp`	루트의 직접적인 서브 디렉토리에서 이름이 `temp`로 시작하는 파일 및 디렉토리를 제외하십시오. 예를 들어, 일반 파일 `/somedir/temporary.txt`는`/somedir/temp` 디렉토리와 같이 제외됩니다.
`//temp*`	루트 아래 두 레벨에있는 서브 디렉토리에서 `temp`로 시작하는 파일 및 디렉토리를 제외하십시오. 예를 들어 `/somedir/subdir/temporary.txt`는 제외됩니다.
`temp?`	이름이 `temp`의 한 문자 확장자인 루트 디렉토리에서 파일과 디렉토리를 제외하십시오. 예를 들어 `/tempa`와 `/tempb`는 제외됩니다.

일치는 Go 의 파일 경로를 사용하여 수행됩니다. 전처리 단계는 선행 및 후행 공백을 제거하고 제거합니다. Go 의 파일 경로를 사용하는 요소 .와 ..는 전처리 후 빈 줄은 무시됩니다.

Docker 는 Go 의 파일 경로를 넘어서고, 일치 규칙을 통해 여러 디렉토리 (0 포함)와 일치하는 특수 와일드 카드 문자열 **을 지원합니다. 예를 들어 **/*. go는 빌드 컨텍스트의 루트를 포함하여 모든 디렉토리에있는 .go로 끝나는 모든 파일을 제외합니다.

!로 시작하는 줄 (느낌표)를 사용하여 제외를 제외 할 수 있습니다. 다음은이 메커니즘을 사용하는 .dockerignore 파일의 예입니다.

 *.md  
 !README.md

README.md를 제외한 모든 마크 다운 파일은 컨텍스트에서 제외됩니다.

! 예외 규칙의 배치는 동작에 영향을줍니다. 특정 파일과 일치하는 .dockerignore의 마지막 행에 포함 여부가 결정됩니다. 다음 예제를 고려하십시오.

 *.md  
 !README*.md  
 README-secret.md

README-secret.md 이외의 README 파일을 제외하고 컨텍스트에 마크 다운 파일이 포함되어 있지 않습니다.

이제 이 예제를 고려하십시오.

 *.md  
 README-secret.md  
 !README*.md

모든 README 파일이 포함되어 있습니다. !README*.md가 README-secret.md와 일치하고 마지막에 오므로 중간 행은 효과가 없습니다.

.dockerignore 파일을 사용하여 Dockerfile 및 .dockerignore 파일을 제외 할 수도 있습니다. 이 파일들은 작업을 수행해야하기 때문에 여전히 데몬으로 전송됩니다. 그러나 ADD 및 COPY 명령어는 이미지에 복사하지 않습니다.

마지막으로, 제외 할 파일이 아닌 컨텍스트에 포함 할 파일을 지정할 수 있습니다. 이를 달성하려면 *를 첫 번째 패턴으로 지정한 다음 하나 이상의 ! 예외 패턴을 지정하십시오.

참고 : 역사적 이유로 패턴 .는 무시됩니다.

FROM

FROM [--platform=]  [AS ]

또는

FROM [--platform=] [:] [AS ]

또는

FROM [--platform=] [@] [AS ]

FROM 명령어는 새 빌드 단계를 초기화하고 후속 명령어에 대한 기본 이미지를 설정합니다. 따라서 유효한 Dockerfile은 FROM 명령으로 시작해야합니다. 이미지는 유효한 이미지 일 수 있습니다. 특히 공용 리포지토리에서 이미지를 가져 와서 쉽게 시작할 수 있습니다.

ARG는 Dockerfile에서 FROM 앞에 올 수 있는 유일한 명령어입니다. ARG와 FROM의 상호 작용 이해를 참조하십시오.
FROM은 하나의 Dockerfile 내에 여러 번 나타날 수 있으며 여러 이미지를 만들거나 한 빌드 단계를 다른 종속성으로 사용합니다. 각각의 새로운 FROM 명령 전에 커밋에 의해 출력된 마지막 이미지 ID 를 간단히 기록하십시오. 각 'FROM'명령어는 이전 명령어로 생성된 모든 상태를 지웁니다.
선택적으로 FROM 명령어에 AS name을 추가하여 새로운 빌드 단계에 이름을 부여 할 수 있습니다. 이 이름은 후속 FROM 및 COPY --from = 명령에서 사용되어 이 단계에서 빌드된 이미지를 참조할 수 있습니다.
tag 또는 digest 값은 선택 사항입니다. 둘 중 하나를 생략하면 빌더는 기본적으로 latest태그를 가정합니다. 빌더는 'tag'값을 찾을 수 없으면 오류를 리턴합니다.

FROM이 다중 플랫폼 이미지를 참조하는 경우 선택적 --platform 플래그를 사용하여 이미지의 플랫폼을 지정할 수 있습니다. 예를 들어, linux/amd64, linux/arm64 또는 windows/amd64입니다. 기본적으로 빌드 요청의 대상 플랫폼이 사용됩니다. 글로벌 빌드 인수는이 플래그의 값으로 사용될 수 있습니다. 예를 들어 자동 플랫폼 ARG 를 사용하면 스테이지를 기본 빌드 플랫폼(--platform=$BUILDPLATFORM)으로 강제하고 스테이지를 사용하여 스테이지 내의 대상 플랫폼으로 크로스 컴파일 할 수 있습니다.

Understand how ARG and FROM interact

FROM 명령어는 첫 번째 FROM 전에 발생하는 ARG 명령어로 선언된 변수를 지원합니다.

ARG  CODE_VERSION=latest  
FROM base:${CODE_VERSION}  
CMD  /code/run-app  
  
FROM extras:${CODE_VERSION}  
CMD  /code/run-extras

FROM 이전에 선언 된 ARG는 빌드 단계 외부에 있으므로 FROM 이후에는 어떤 명령에도 사용할 수 없습니다. 첫 번째 FROM 전에 선언된 ARG의 기본값을 사용하려면 빌드 단계 내부에 값이 없는 ARG 명령어를 사용하십시오.

ARG VERSION=latest  
FROM busybox:$VERSION  
ARG VERSION  
RUN echo $VERSION > image_version

RUN

RUN 에는 두 가지 형태가 있습니다.

RUN (shell 형식, 명령은 쉘에서 실행되며 기본적으로 Linux 에서는 /bin/sh -c, Windows 에서는 cmd /S /C입니다)
RUN ["executable", "param1", "param2"] (exec form)

RUN 명령은 현재 이미지 위에 새 레이어의 명령을 실행하고 결과를 커밋합니다. 결과 커밋 된 이미지는 Dockerfile의 다음 단계에 사용됩니다.

RUN 명령어를 계층화하고 커밋을 생성하는 것은 커밋이 저렴하고 소스 제어와 같이 이미지 기록의 어느 시점에서든 컨테이너를 만들 수있는 Docker 의 핵심 개념을 따릅니다.

exec 형식을 사용하면 지정된 셸 실행 파일이없는 기본 이미지를 사용하여 셸 문자열 뭉치를 방지하고 명령을 실행할 수 있습니다.

쉘 양식의 기본 쉘은 SHELL 명령을 사용하여 변경할 수 있습니다.

shell 양식에서 \ (백 슬래시)를 사용하여 다음 행으로 단일 RUN 명령을 계속할 수 있습니다. 예를 들어 다음 두 줄을 고려하십시오.

RUN /bin/bash -c 'source $HOME/.bashrc; \  
echo $HOME'

함께 그들은 이 한 줄과 같습니다:

RUN /bin/bash -c 'source $HOME/.bashrc; echo $HOME'

참고: ‘/bin/sh’ 이외의 다른 셸을 사용하려면 원하는 셸에 전달되는 exec 양식을 사용하십시오. 예를 들면 다음과 같습니다. RUN ["/bin/bash", "-c", "echo hello"]

참고 : exec 양식은 JSON 배열로 구문 분석되므로 작은 따옴표 ( ')가 아닌 단어 주위에 큰 따옴표 (“)를 사용해야합니다.

참고 : shell 양식과 달리 exec 양식은 명령 쉘을 호출하지 않습니다. 이는 정상적인 쉘 처리가 발생하지 않음을 의미합니다. 예를 들어,RUN ["echo", "$ HOME"]은 $HOME에서 변수 대체를 수행하지 않습니다. 쉘 처리를 원한다면 shell 양식을 사용하거나 직접 쉘을 실행하십시오 (예: RUN ["sh", "-c", "echo $ HOME"]). 쉘 양식의 경우와 같이 exec 양식을 사용하고 쉘을 직접 실행하는 경우도 도커가 아닌 환경 변수 확장을 수행하는 쉘입니다.

참고 : JSON 양식에서는 백 슬래시를 이스케이프해야합니다. 이는 백 슬래시가 경로 구분 기호 인 Windows 에서 특히 관련이 있습니다. 다음 행은 유효한 JSON이 아니기 때문에 shell 형식으로 처리되며 예기치 않은 방식으로 실패합니다. RUN ["c:\ windows\system32\tasklist.exe"] 이 예제의 올바른 구문은 다음과 같습니다: RUN ["c:\\windows\\system32\\tasklist.exe"]

RUN 명령에 대한 캐시는 다음 빌드 중에 자동으로 무효화되지 않습니다. RUN apt-get dist-upgrade -y와 같은 명령어의 캐시는 다음 빌드 중에 재사용됩니다. --no-cache 플래그를 사용하여RUN 명령어의 캐시를 무효화 할 수 있습니다 (예: docker build --no-cache).

자세한 내용은 Dockerfile 모범 사례 안내서를 참조하십시오.

RUN 명령어의 캐시는 ADD 명령어로 무효화 될 수 있습니다. 자세한 내용은 아래를 참조하십시오.

Known issues (RUN)

문제 783는 AUFS 파일 시스템을 사용할 때 발생할 수 있는 파일 권한 문제에 관한 것입니다. 예를 들어, 파일을 'rm'으로 만들려고 시도하는 동안 이를 알 수 있습니다.
최근 aufs 버전이있는 시스템 (즉,dirperm1 마운트 옵션 설정 가능)의 경우, docker 는 dirperm1 옵션으로 레이어를 마운트하여 문제를 자동으로 해결하려고 시도합니다. dirperm1 옵션에 대한 자세한 내용은 aufs man page에 있습니다.
시스템이dirperm1을 지원하지 않는 경우이 문제는 해결 방법을 설명합니다.

CMD

CMD 명령은 세 가지 형식으로 구성됩니다.

CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)

Dockerfile에는 CMD 명령이 하나만있을 수 있습니다. 둘 이상의 CMD를 나열하면 마지막 CMD 만 적용됩니다.

CMD의 주요 목적은 실행 컨테이너에 대한 기본값을 제공하는 것입니다. 이러한 기본값은 실행 파일을 포함하거나 실행 파일을 생략 할 수 있으며, 이 경우 ENTRYPOINT 명령도 지정해야 합니다.

참고 : CMD를 사용하여 ENTRYPOINT 명령어에 대한 기본 인수를 제공하는 경우 CMD 및 ENTRYPOINT 명령어 모두 JSON 배열 형식으로 지정해야합니다.

참고 : exec 양식은 JSON 배열로 구문 분석되므로 작은 따옴표 ( ')가 아닌 단어 주위에 큰 따옴표 (“)를 사용해야합니다.

참고 : 셸 양식과 달리 exec 양식은 명령 셸을 호출하지 않습니다. 이는 정상적인 쉘 처리가 발생하지 않음을 의미합니다. 예를 들어, CMD [ "echo", "$ HOME"]는 $HOME에서 변수 대체를 수행하지 않습니다. 쉘 처리를 원하면 쉘 양식을 사용하거나 직접 쉘을 실행하십시오 (예: CMD [ "sh", "-c", "echo $ HOME"]). 쉘 양식의 경우와 같이 exec 양식을 사용하고 쉘을 직접 실행하는 경우도 커가 아닌 환경 변수 확장을 수행하는 쉘입니다.

쉘 또는 exec 형식으로 사용되는 경우 CMD 명령은 이미지를 실행할 때 명령이 실행되도록 설정합니다.

CMD의 쉘 형식을 사용하면 `` 는 /bin/sh -c에서 실행됩니다.

FROM ubuntu
CMD echo "This is a test." | wc -

쉘없이 `` 를 실행하려면 명령을 JSON 배열로 표시하고 실행 파일의 전체 경로를 제공해야합니다. 이 배열 형식은 선호하는 CMD 형식입니다. 추가 매개 변수는 배열에서 개별적으로 문자열로 표시되어야합니다.

FROM ubuntu
CMD ["/usr/bin/wc","--help"]

컨테이너가 매번 동일한 실행 파일을 실행하도록하려면 CMD와 함께 ENTRYPOINT를 사용하는 것이 좋습니다. 진입 점을 참조하십시오.

사용자가 docker run에 인수를 지정하면 CMD에 지정된 기본값을 무시합니다.

참고 : RUN과 CMD를 혼동하지 마십시오. RUN은 실제로 명령을 실행하고 결과를 커밋합니다. CMD는 빌드시 아무 것도 실행하지 않지만 이미지의 의도된 명령을 지정합니다.

LABEL

LABEL === ...

LABEL 명령어는 메타 데이터를 이미지에 추가합니다. LABEL은 키-값 쌍입니다. LABEL 값 내에 공백을 포함 시키려면 명령 행 구문 분석에서와 같이 따옴표와 백 슬래시를 사용하십시오. 몇 가지 사용 예 :

LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"
LABEL version="1.0"
LABEL description="This text illustrates \
that label-values can span multiple lines."

이미지에는 둘 이상의 레이블이있을 수 있습니다. 한 줄에 여러 레이블을 지정할 수 있습니다. Docker 1.10 이전에는 최종 이미지의 크기가 줄어들었지만 더 이상 그렇지 않습니다. 다음 두 가지 방법 중 하나를 사용하여 단일 명령으로 여러 레이블을 지정할 수 있습니다.

LABEL multi.label1="value1" multi.label2="value2" other="value3"

LABEL multi.label1="value1" \
      multi.label2="value2" \
      other="value3"

기본 또는 상위 이미지 (FROM 행의 이미지)에 포함 된 레이블은 이미지에서 상속됩니다. 레이블이 이미 있지만 다른 값을 가진 경우 가장 최근에 적용된 값이 이전에 설정된 값보다 우선합니다.

이미지의 레이블을 보려면 docker inspect 명령을 사용하십시오.

"Labels": {
    "com.example.vendor": "ACME Incorporated"
    "com.example.label-with-value": "foo",
    "version": "1.0",
    "description": "This text illustrates that label-values can span multiple lines.",
    "multi.label1": "value1",
    "multi.label2": "value2",
    "other": "value3"
},

MAINTAINER (deprecated)

MAINTAINER

MAINTAINER 명령어는 생성 된 이미지의 Author 필드를 설정합니다. LABEL 명령어는 이보다 훨씬 유연한 버전이므로 필요한 메타 데이터를 설정할 수 있으므로 docker inspect와 같이 쉽게 볼 수 있으므로 대신 사용해야합니다. MAINTAINER 필드에 해당하는 레이블을 설정하려면 다음을 사용할 수 있습니다.

LABEL maintainer="*** 개인정보보호를 위한 이메일주소 노출방지 ***"

그러면 다른 레이블을 사용하여 docker inspect 에서 볼 수 있습니다.

EXPOSE

EXPOSE  [/...]

EXPOSE 명령은 Docker 에게 컨테이너가 런타임에 지정된 네트워크 포트에서 수신함을 알려줍니다. 포트가 TCP 또는 UDP 에서 수신 대기하는지 여부를 지정할 수 있으며 프로토콜이 지정되지 않은 경우 기본값은 TCP 입니다.

EXPOSE 명령어는 실제로 포트를 게시하지 않습니다. 이미지를 작성하는 사람과 컨테이너를 실행하는 사람 사이에서 공개할 포트에 대한 문서 유형으로 작동합니다. 컨테이너를 실행할 때 실제로 포트를 공개하려면 docker run에서 -p 플래그를 사용하여 하나 이상의 포트를 공개하고 맵핑하거나 -P 플래그를 사용하여 노출 된 모든 포트를 공개하고 상위 포트에 맵핑하십시오.

기본적으로 EXPOSE는 TCP 를 가정합니다. UDP 를 지정할 수도 있습니다.

EXPOSE 80/udp

TCP 와 UDP 모두에 노출 시키려면 다음 두 줄을 포함하십시오.

EXPOSE 80/tcp
EXPOSE 80/udp

이 경우 docker run과 함께 -P를 사용하면 TCP 에 대해 한 번, UDP 에 대해 한 번 노출됩니다. -P는 호스트에서 임시의 high-ordered 호스트 포트를 사용하므로 TCP 및 UDP 에서 포트가 동일하지 않습니다.

EXPOSE 설정에 관계없이 런타임시 -p 플래그를 사용하여 설정을 대체 할 수 있습니다. 예를 들어

docker run -p 80:80/tcp -p 80:80/udp ...

호스트 시스템에서 포트 리디렉션을 설정하려면 -P 플래그 사용을 참조하십시오. docker network 명령은 네트워크에 연결된 컨테이너가 모든 포트를 통해 서로 통신 할 수 있기 때문에 특정 포트를 노출하거나 게시할 필요없이 컨테이너 간 통신을위한 네트워크 생성을 지원합니다. 자세한 내용은이 기능의 개요를 참조하십시오.

ENV

ENV 
ENV = ...

ENV 명령어는 환경 변수 를 값으로 설정합니다. 이 값은 빌드 단계의 모든 후속 명령에 대한 환경에 있으며 인라인으로 대체 할 수도 있습니다.

ENV 명령어는 두 가지 형태가 있습니다. 첫 번째 형식 인 ENV 는 단일 변수를 값으로 설정합니다. 첫 번째 공백 뒤의 전체 문자열은 공백 문자를 포함하여 `` 으로 취급됩니다. 값은 다른 환경 변수에 대해 해석되므로 이스케이프하지 않으면 따옴표 문자가 제거됩니다.

두 번째 형식 인 ENV = ...를 사용하면 한 번에 여러 변수를 설정할 수 있습니다. 두 번째 양식은 구문에서 등호 (=)를 사용하지만 첫 번째 양식은 사용하지 않습니다. 명령 행 구문 분석과 같이 따옴표와 백 슬래시는 값 내에 공백을 포함하는 데 사용될 수 있습니다.

예를 들면 다음과 같습니다.

ENV myName="John Doe" myDog=Rex\ The\ Dog \
    myCat=fluffy

그리고

ENV myName John Doe
ENV myDog Rex The Dog
ENV myCat fluffy

최종 이미지에서 동일한 순 결과를 얻을 수 있습니다.

ENV를 사용하여 설정 한 환경 변수는 결과 이미지에서 컨테이너가 실행될 때 지속됩니다. docker inspect를 사용하여 값을보고 docker run --env =를 사용하여 값을 변경할 수 있습니다.

참고 : 환경 지속성으로 인해 예기치 않은 부작용이 발생할 수 있습니다. 예를 들어, ENV DEBIAN_FRONTEND noninteractive는 데비안 기반 이미지에서 apt-get 사용자를 혼동 할 수 있습니다. 단일 명령의 값을 설정하려면 RUN =를 사용하십시오.

ADD

ADD 에는 두 가지 형태가 있습니다.

ADD [--chown=:] ...
ADD [--chown=:] ["",... ""] (이 형식은 공백이 포함 된 경로에 필요합니다)

참고: --chown 기능은 Linux 컨테이너를 빌드하는 데 사용되는 Dockerfile 에서만 지원되며 Windows 컨테이너에서는 작동하지 않습니다. 사용자 및 그룹 소유권 개념은 Linux 와 Windows 간에 변환되지 않으므로 사용자 및 그룹 이름을 ID 로 변환하기 위해 /etc/passwd 및 /etc/group을 사용하면 이 기능이 Linux OS 기반의 컨테이너에서만 실행 가능하도록 제한됩니다.

ADD 명령어는 에서 새 파일, 디렉토리 또는 원격 파일 URL을 복사하여 경로에서 이미지의 파일 시스템에 추가합니다.

여러 `` 자원을 지정할 수 있지만 파일 또는 디렉토리 인 경우 해당 경로는 빌드 컨텍스트의 소스를 기준으로 해석됩니다.

각 `` 는 와일드 카드를 포함 할 수 있으며 일치는 Go 의 파일 경로를 사용하여 수행됩니다. 예를 들면 다음과 같습니다.

ADD hom* /mydir/        # adds all files starting with "hom"
ADD hom?.txt /mydir/    # ? is replaced with any single character, e.g., "home.txt"

`` 는 소스가 대상 컨테이너 내부에 복사 될 절대 경로 또는 WORKDIR에 상대적인 경로입니다.

ADD test relativeDir/          # adds "test" to `WORKDIR`/relativeDir/
ADD test /absoluteDir/         # adds "test" to /absoluteDir/

특수 문자 (예: [및 ])를 포함하는 파일 또는 디렉토리를 추가 할 때 일치하는 패턴으로 취급되지 않도록 Golang 규칙에 따라 해당 경로를 이스케이프해야 합니다. 예를 들어, arr[0].txt라는 파일을 추가하려면 다음을 사용하십시오.

ADD arr[0].txt /mydir/    # copy a file named "arr[0].txt" to /mydir/

선택적 --chown 플래그가 추가 된 컨텐츠의 특정 소유권을 요청하기 위해 지정된 사용자 이름, 그룹 이름 또는 UID/GID 조합을 지정하지 않는 한 모든 새 파일 및 디렉토리는 UID 및 GID 가 0 으로 작성됩니다. --chown 플래그의 형식은 사용자 이름 및 그룹 이름 문자열 또는 임의의 조합으로 직접 정수 UID 및 GID 를 허용합니다. 그룹 이름이없는 사용자 이름 또는 GID 가없는 UID 를 제공하면 GID 와 동일한 숫자 UID 가 사용됩니다. 사용자 이름 또는 그룹 이름이 제공되면 컨테이너의 루트 파일 시스템 /etc/passwd 및 /etc/group 파일이 각각 이름에서 정수 UID 또는 GID 로 변환하는 데 사용됩니다. 다음 예제는 --chown 플래그에 유효한 정의를 보여줍니다.

ADD --chown=55:mygroup files* /somedir/
ADD --chown=bin files* /somedir/
ADD --chown=1 files* /somedir/
ADD --chown=10:11 files* /somedir/

컨테이너 루트 파일 시스템에 /etc/passwd 또는 /etc/group 파일이없고 --chown 플래그에 사용자 또는 그룹 이름이 사용되면 ADD 작업에서 빌드가 실패합니다. 숫자 ID 를 사용하면 조회 할 필요가 없으며 컨테이너 루트 파일 시스템 내용에 의존하지 않습니다.

`` 가 원격 파일 URL 인 경우 대상의 권한은 600 입니다. 검색중인 원격 파일에 HTTP Last-Modified 헤더가 있으면 해당 헤더의 타임 스탬프가 대상 파일의 mtime을 설정하는 데 사용됩니다. 그러나 ADD 중에 처리 된 다른 파일과 마찬가지로 mtime은 파일 변경 여부를 결정하는 데 포함되지 않으며 캐시를 업데이트해야합니다.

참고 : STDIN (docker build- **참고** : URL 파일이 인증을 사용하여 보호되는 경우 ADD명령이 인증을 지원하지 않으므로RUN wget, RUN curl` 을 사용하거나 컨테이너 내에서 다른 도구를 사용해야 합니다.

참고: `` 의 내용이 변경된 경우 첫 번째로 발생한 ADD 명령어는 Dockerfile 에서 다음의 모든 명령어에 대한 캐시를 무효화합니다. 여기에는 RUN 명령에 대한 캐시 무효화가 포함됩니다. 자세한 내용은 Dockerfile 모범 사례 안내서를 참조하십시오.

ADD는 다음 규칙을 준수합니다.

`` 경로는 빌드의 context 안에 있어야합니다. docker build의 첫 번째 단계는 컨텍스트 디렉토리 (및 서브 디렉토리)를 docker 데몬에 전송하는 것이므로 ADD ../something / something을 사용할 수 없습니다.
가 URL이고 가 슬래시로 끝나지 않으면 파일이 URL 에서 다운로드 되어 `` 에 복사됩니다.
가 URL이고 가 슬래시로 끝나는 경우 파일 이름이 URL 에서 유추되고 파일이 /으로 다운로드됩니다. 예를 들어 ADD http://example.com/foobar /는 /foobar 파일을 만듭니다. 이 경우 적절한 파일 이름을 찾을 수 있도록 URL 에 중요한 경로가 없어야합니다 (http://example.com).
`` 가 디렉토리이면 파일 시스템 메타 데이터를 포함하여 디렉토리의 전체 내용이 복사됩니다.

참고 : 디렉토리 자체는 내용 만 복사되지 않습니다.

`` 가 인식된 압축 형식 (ID, gzip, bzip2 또는 xz)의 local tar 아카이브 인 경우 디렉토리로 압축 해제됩니다. 원격 URL 의 리소스는 압축 해제되지 않습니다. 디렉토리를 복사하거나 압축을 풀면 tar -x와 같은 동작을하며 결과는 다음과 같습니다.
1. 목적지 경로에 존재했던 것
2. 소스 트리의 내용은 파일별로 "2."를 선호하여 충돌이 해결되었습니다.
참고 : 파일이 인식 된 압축 형식으로 식별되는지 여부는 파일 이름이 아니라 파일 내용만을 기반으로 수행됩니다. 예를 들어, 빈 파일이 .tar.gz로 끝나는 경우 압축 파일로 인식되지 않고 압축 해제 오류 메시지가 생성되지 않고 파일이 대상으로 복사됩니다.
가 다른 종류의 파일이면 메타 데이터와 함께 개별적으로 복사됩니다. 이 경우 가 슬래시/로 끝나면 디렉토리로 간주되며 `` 의 내용은 /base ()에 기록됩니다.
직접 또는 와일드 카드 사용으로 여러자원이 지정된 경우는 디렉토리여야 하며 슬래시 /로 끝나야합니다.
가 슬래시로 끝나지 않으면 일반 파일로 간주되며 의 내용은 `` 에 기록됩니다.
`` 가 없으면 경로에 누락 된 모든 디렉토리와 함께 작성됩니다.

COPY

COPY 에는 두 가지 형태가 있습니다.

COPY [--chown=:] ...
COPY [--chown=:] ["",... ""] (이 형식은 공백이 포함 된 경로에 필요합니다)

참고: --chown 기능은 Linux 컨테이너를 빌드하는 데 사용되는 Dockerfile 에서만 지원되며 Windows 컨테이너에서는 작동하지 않습니다. 사용자 및 그룹 소유권 개념은 Linux 와 Windows 간에 변환되지 않으므로 사용자 및 그룹 이름을 ID 로 변환하기 위해 /etc/passwd 및 /etc/group을 사용하면 이 기능이 Linux OS 기반 컨테이너에서만 실행 가능하도록 제한됩니다.

COPY 명령은 에서 새 파일이나 디렉토리를 복사하여 경로에 있는 컨테이너의 파일 시스템에 추가합니다.

여러 개의 `` 자원이 지정될 수 있지만 파일 및 디렉토리의 경로는 빌드 컨텍스트의 소스와 관련하여 해석됩니다.

각 `` 는 와일드 카드를 포함 할 수 있으며 일치는 Go 의 filepath.Match 규칙을 사용하여 수행됩니다. 예를 들면 다음과 같습니다.

COPY hom* /mydir/        # adds all files starting with "hom"
COPY hom?.txt /mydir/    # ? is replaced with any single character, e.g., "home.txt"

`` 는 소스가 대상 컨테이너 내부에 복사 될 절대 경로 또는 WORKDIR에 상대적인 경로입니다.

COPY test relativeDir/   # adds "test" to `WORKDIR`/relativeDir/
COPY test /absoluteDir/  # adds "test" to /absoluteDir/

특수 문자 (예: [및 ])가 포함 된 파일 또는 디렉토리를 복사 할 때, 일치하는 패턴으로 취급되지 않도록 Golang 규칙에 따라 해당 경로를 이스케이프해야합니다. 예를 들어, arr[0].txt라는 파일을 복사하려면 다음을 사용하십시오.

COPY arr[0].txt /mydir/    # copy a file named "arr[0].txt" to /mydir/

선택적 --chown 플래그가 복사된 컨텐츠의 특정 소유권을 요청하기 위해 지정된 사용자 이름, 그룹 이름 또는 UID/GID 조합을 지정하지 않는 한, 모든 새 파일 및 디렉토리는 UID 및 GID 가 0 으로 작성됩니다. --chown 플래그의 형식은 사용자 이름과 그룹 이름 문자열을 허용하거나 모든 정수 UID 및 GID 를 직접 조합할 수 있습니다. 그룹 이름이 없는 사용자 이름 또는 GID 가없는 UID 를 제공하면 GID 와 동일한 숫자 UID 가 사용됩니다. 사용자 이름 또는 그룹 이름이 제공되면 컨테이너의 루트 파일 시스템 /etc/passwd 및 /etc/group 파일이 각각 이름에서 정수 UID 또는 GID 로 변환하는 데 사용됩니다. 다음 예제는--chown 플래그에 대한 유효한 정의를 보여줍니다.

COPY --chown=55:mygroup files* /somedir/
COPY --chown=bin files* /somedir/
COPY --chown=1 files* /somedir/
COPY --chown=10:11 files* /somedir/

컨테이너 루트 파일 시스템에 /etc/passwd 또는 /etc/group 파일이 없고 --chown 플래그에 사용자 또는 그룹 이름이 사용되면 COPY 작업에서 빌드가 실패합니다. 숫자 ID 를 사용하면 조회할 필요가 없으며 컨테이너 루트 파일 시스템 내용에 의존하지 않습니다.

참고: STDIN (docker build-로 작성)로 설정하여 대신 사용될 --from=플래그를 허용합니다. 사용자가 보낸 빌드 컨텍스트 또한 플래그는 FROM 명령으로 시작된 모든 이전 빌드 단계에 지정된 숫자 인덱스를 허용합니다. 지정된 이름의 제작 단계를 찾을 수없는 경우 동일한 이름의 이미지를 대신 사용하려고합니다.

'COPY'는 다음 규칙을 따릅니다.

`` 경로는 빌드의 context 안에 있어야합니다. docker build '의 첫 번째 단계는 컨텍스트 디렉토리 (및 서브 디렉토리)를 docker 데몬으로 보내는 것이므로 COPY ../something /something` 은 불가능합니다.
`` 가 디렉토리이면 파일 시스템 메타 데이터를 포함하여 디렉토리의 전체 내용이 복사됩니다.

참고 : 디렉토리 자체는 내용만 복사되지 않습니다.

가 다른 종류의 파일이면 메타 데이터와 함께 개별적으로 복사됩니다. 이 경우 가 슬래시 /로 끝나면 디렉토리로 간주되며 `` 의 내용은 /base()에 기록됩니다. .
직접 또는 와일드 카드 사용으로 여러 자원이 지정된 경우 는 디렉토리 여야하며 슬래시 /로 끝나야합니다.
가 슬래시로 끝나지 않으면 일반 파일로 간주되며 의 내용은 `` 에 기록됩니다.
`` 가 없으면 경로에 누락된 모든 디렉토리와 함께 작성됩니다.

공감
1

[번역]Dockerfile 레퍼런스 #2 > 서버관리자

서버관리자