수색…


소개

Dockerfiles는 프로그래밍 방식으로 Docker 이미지를 작성하는 데 사용되는 파일입니다. Docker 이미지를 빠르고 재현성있게 만들 수 있으므로 공동 작업에 유용합니다. Dockerfiles에는 Docker 이미지를 작성하기위한 지침이 들어 있습니다. 각 명령은 한 행에 쓰여지고 <INSTRUCTION><argument(s)> 됩니다. Dockerfiles는 docker build 명령을 사용하여 Docker 이미지를 작성하는 데 사용됩니다.

비고

Dockerfiles는 다음 형식을 취합니다.

# This is a comment
INSTRUCTION arguments
  • 코멘트는 #
  • 지침은 대문자로만되어 있습니다.
  • 기본 이미지를 지정하려면 Dockerfile의 첫 번째 명령이 FROM 이어야합니다.

Dockerfile을 빌드 할 때 Docker 클라이언트는 Docker 데몬에 "빌드 컨텍스트"를 보냅니다. 빌드 컨텍스트에는 Dockerfile과 같은 디렉토리에있는 모든 파일과 폴더가 포함됩니다. COPYADD 조작은이 컨텍스트의 파일 만 사용할 수 있습니다.


일부 Docker 파일은 다음으로 시작될 수 있습니다.

# escape=`

이것은 사용하는 도커 파서 지시하는 데 사용되는 ` 대신 이스케이프 문자로 \ . 이것은 주로 Windows Docker 파일에 유용합니다.

HelloWorld Dockerfile

최소한의 Dockerfile은 다음과 같습니다 :

FROM alpine
CMD ["echo", "Hello StackOverflow!"]

이렇게하면 Docker가 Alpine ( FROM )을 기반으로하는 이미지와 컨테이너의 최소 배포판을 생성하고 결과 이미지를 실행할 때 특정 명령 ( CMD )을 실행하도록 지시합니다.

빌드하고 실행하십시오.

docker build -t hello .
docker run --rm hello

그러면 다음과 같이 출력됩니다.

Hello StackOverflow!

파일 복사 중

Docker 이미지의 빌드 컨텍스트에서 파일을 복사하려면 COPY 명령을 사용합니다.

COPY localfile.txt containerfile.txt

파일 이름에 공백이 있으면 대체 구문을 사용하십시오.

COPY ["local file", "container file"]

COPY 명령은 와일드 카드를 지원합니다. 예를 들어 모든 이미지를 images/ 디렉토리에 복사하는 데 사용할 수 있습니다.

COPY *.jpg images/

참고 :이 예에서는 images/ 가 존재하지 않을 수 있습니다. 이 경우 Docker가 자동으로 생성합니다.

포트 노출

Dockerfile에서 노출 된 포트를 선언하려면 EXPOSE 명령어를 사용하십시오.

EXPOSE 8080 8082

노출 된 포트 설정은 Docker 명령 줄에서 무시할 수 있지만 응용 프로그램의 기능을 이해하는 데 도움이되므로 Docker 파일에 명시 적으로 설정하는 것이 좋습니다.

Dockerfiles 최고의 pratices

그룹 공통 작업

Docker는 이미지를 레이어 컬렉션으로 만듭니다. 이 데이터에 파일이 삭제되었다고 표시 되더라도 각 레이어는 데이터 만 추가 할 수 있습니다. 모든 명령어는 새로운 레이어를 만듭니다. 예 :

RUN apt-get -qq update
RUN apt-get -qq install some-package

몇 가지 단점이 있습니다.

  • 두 개의 레이어를 만들어 더 큰 이미지를 만듭니다.
  • RUN 문에서 apt-get update 만 사용하면 캐싱 문제가 발생하고 이후 apt-get install 지침이 실패 있습니다. 나중에 추가 패키지를 추가하여 apt-get install 을 수정 한 다음 docker가 초기 및 수정 된 명령어를 동일하게 해석하고 이전 단계의 캐시를 다시 사용한다고 가정합니다. 결과적으로 apt-get update 명령은 캐시 된 버전이 빌드 ​​중에 사용되므로 실행 되지 않습니다 .

대신 다음을 사용하십시오.

RUN apt-get -qq update && \
    apt-get -qq install some-package

이는 하나의 레이어 만 생성하기 때문입니다.

관리자에게 언급

대개 Dockerfile의 두 번째 줄입니다. 누가 책임자이고 도움을 줄 수 있는지 알려줍니다.

LABEL maintainer John Doe <[email protected]>

이것을 건너 뛰어도 이미지가 손상되지 않습니다. 하지만 그것은 사용자에게 도움이되지 않습니다.

간결하게

Dockerfile을 짧게 유지하십시오. 복잡한 설정이 필요한 경우 전용 스크립트를 사용하거나 기본 이미지를 설정하는 것이 좋습니다.

사용자 지침

USER daemon

USER 명령은 이미지를 실행할 때 사용할 사용자 이름 또는 UID와 ENTRYPOINT 그 뒤에 ENTRYPOINT RUN , CMDENTRYPOINT 명령에 대해 Dockerfile 합니다.

작업 지시

WORKDIR /path/to/workdir

WORKDIR 명령어는 ENTRYPOINT 에서 그 뒤에 ENTRYPOINT 모든 RUN , CMD , ENTRYPOINT , COPYADD 명령어에 대한 작업 디렉토리를 설정합니다. WORKDIR 이 없으면 이후 Dockerfile 명령어에서 사용되지 않더라도 생성됩니다.

하나의 Dockerfile 에서 여러 번 사용할 수 있습니다. 상대 경로가 제공되면 이전 WORKDIR 명령어의 경로와 관련됩니다. 예 :

WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd

Dockerfile 에서 최종 pwd 명령의 출력은 /a/b/c 입니다.

WORKDIR 명령은 ENV 사용하여 이전에 설정 한 환경 변수를 해석 할 수 있습니다. Dockerfile 명시 적으로 설정된 환경 변수 만 사용할 수 있습니다. 예 :

ENV DIRPATH /path
WORKDIR $DIRPATH/$DIRNAME
RUN pwd

이 Dockerfile에서 최종 pwd 명령의 출력은 /path/$DIRNAME

볼륨 명령

VOLUME ["/data"]

VOLUME 명령은 지정된 이름으로 마운트 포인트를 작성하고이를 원시 호스트 또는 기타 컨테이너에서 외부 적으로 마운트 된 볼륨으로 유지하는 것으로 표시합니다. 값은 JSON 배열, VOLUME ["/var/log/"] 또는 VOLUME /var/log 또는 VOLUME /var/log /var/db 와 같은 여러 인수가있는 일반 문자열 일 수 있습니다. Docker 클라이언트를 통한 자세한 정보 / 예제 및 장착 지침은 볼륨 문서를 통한 공유 디렉토리를 참조하십시오.

docker run 명령은 새로 만든 볼륨을 기본 이미지의 지정된 위치에있는 데이터로 초기화합니다. 예를 들어 다음 Dockerfile 스 니펫을 고려해보십시오.

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

이 Dockerfile은 docker가 실행되는 이미지를 생성하고 / myvol에서 새 마운트 포인트를 작성하고 인사 장을 새로 작성한 볼륨으로 복사합니다.

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

참고 : 목록은 JSON 배열로 구문 분석됩니다. 즉, 작은 따옴표 ( ')가 아닌 단어 주위에 큰 따옴표 ( ")를 사용해야합니다.

COPY 명령

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

COPY <src>... <dest>
COPY ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

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

여러 <src> 리소스를 지정할 수 있지만 빌드 할 소스 디렉토리 (빌드의 컨텍스트)에 상대적이어야합니다.

<src> 에는 와일드 카드가 포함될 수 있으며 일치는 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"

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

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

모든 새 파일과 디렉토리는 UID와 GID가 0으로 작성됩니다.

참고 : stdin ( docker build - < somefile )을 사용하여 빌드하면 빌드 컨텍스트가 없으므로 COPY 사용할 수 없습니다.

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

  • <src> 경로는 빌드의 컨텍스트 내에 있어야합니다. 도커 빌드의 첫 번째 단계는 docker 데몬에 컨텍스트 디렉토리 (및 하위 디렉토리)를 보내기 때문에 ../something/ something을 COPY 할 수 없습니다.

  • <src> 가 디렉토리이면 파일 시스템 메타 데이터를 포함하여 디렉토리의 전체 내용이 복사됩니다. 참고 : 디렉토리 자체는 복사되지 않고 내용 만 복사됩니다.

  • <src> 가 다른 종류의 파일 인 경우 메타 데이터와 함께 개별적으로 복사됩니다. 이 경우 <dest> 가 슬래시 /로 끝나면 디렉토리로 간주되며 <src> 의 내용은 <dest>/base(<src>) 됩니다.

  • 여러 <src> 자원이 직접 지정되거나 와일드 카드를 사용하기 때문에 지정되는 경우 <dest> 는 디렉토리 여야하며 슬래시 ( / 로 끝나야합니다.

  • <dest> 가 슬래시로 끝나지 않으면 일반 파일로 간주되며 <src> 의 내용은 <dest> 기록됩니다.

  • <dest> 가 없으면 경로에 누락 된 모든 디렉터리와 함께 만들어집니다.

ENV 및 ARG 교육

ENV

ENV <key> <value>
ENV <key>=<value> ...

ENV 명령은 환경 변수 <key> 를 값으로 설정합니다. 이 값은 모든 "자손"Dockerfile 명령의 환경에 있으며 많은 경우에도 인라인으로 대체 될 수 있습니다.

ENV 명령에는 두 가지 형식이 있습니다. 첫 번째 형식 인 ENV <key> <value> 는 단일 변수를 값으로 설정합니다. 첫 번째 공백 다음의 전체 문자열은 공백 및 따옴표와 같은 문자를 포함하여 <value> 로 처리됩니다.

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

예 :

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 <key>=<value> 사용하여 값을 변경할 수 있습니다.

ARG

설정을 유지하지 않으려면 대신 ARG 사용하십시오. ARG 는 빌드 중에 만 환경을 설정합니다. 예를 들어,

ENV DEBIAN_FRONTEND noninteractive

apt-get 사용자가 docker exec -it the-container bash 를 통해 대화 형 컨텍스트에서 컨테이너에 들어갈 때 데비안 기반 이미지를 혼동 할 수 있습니다.

대신 다음을 사용하십시오.

ARG DEBIAN_FRONTEND noninteractive

다음 명령을 사용하는 경우에만 한 명령에 대한 값을 번갈아 설정할 수도 있습니다.

RUN <key>=<value> <command>

노출 지시

EXPOSE <port> [<port>...]

EXPOSE 명령은 컨테이너가 런타임에 지정된 네트워크 포트에서 수신 대기한다는 것을 Docker에 알립니다. EXPOSE 는 컨테이너의 포트를 호스트가 액세스 할 수 없도록합니다. 이를 수행하려면, -p 플래그를 사용하여 포트 범위를 공개하거나 노출 된 모든 포트를 공개하는 -P 플래그를 사용해야합니다. 이 플래그는 도 docker run [OPTIONS] IMAGE [COMMAND][ARG...] 를 실행하여 포트를 호스트에 노출시키는 데 사용됩니다. 하나의 포트 번호를 노출하고 다른 번호로 외부에 게시 할 수 있습니다.

docker run -p 2500:80 <image name>

이 명령은 이름이 <image> 인 컨테이너를 만들고 컨테이너의 포트 80을 호스트 시스템의 포트 2500에 바인드합니다.

호스트 시스템에서 포트 재 지정을 설정하려면 -P 플래그 사용을 참조하십시오. Docker 네트워크 기능은 네트워크 내의 포트를 노출 할 필요없이 네트워크 생성을 지원하므로 자세한 내용은이 기능 개요를 참조하십시오.

LABEL 명령어

LABEL <key>=<value> <key>=<value> <key>=<value> ...

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는 가능하면 레이블을 단일 LABEL 명령에 결합 할 것을 권장합니다. 각 LABEL 명령은 많은 레이블을 사용하면 비효율적 인 이미지가 될 수있는 새 레이어를 생성합니다. 이 예제는 단일 이미지 레이어를 생성합니다.

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

위의 내용은 다음과 같이 쓰여질 수도 있습니다 :

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

라벨은 FROM 이미지의 LABEL 포함하여 추가됩니다. Docker가 이미 존재하는 레이블 / 키를 발견하면 새 값은 동일한 키를 가진 이전 레이블을 덮어 씁니다.

이미지의 레이블을 보려면 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"
},

명령 명령

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 명령어의 기본 인수를 제공하는 경우 CMDENTRYPOINT 명령어를 모두 JSON 배열 형식으로 지정해야합니다.

참고 : exec 폼은 JSON 배열로 구문 분석됩니다. 즉, 작은 따옴표 ( ')가 아닌 단어 주위에 큰 따옴표 ( ")를 사용해야합니다.

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

쉘 또는 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 를 사용하는 것이 ENTRYPOINT . ENTRYPOINT 참조하십시오.

사용자가 도커 실행에 대한 인수를 지정하면 CMD 지정된 기본값보다 우선합니다.

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

MAINTAINER Instruction

MAINTAINER <name>

MAINTAINER 명령을 사용하면 생성 된 이미지의 작성자 필드를 설정할 수 있습니다.

MAINTAINER DIRECTIVE를 사용하지 마십시오.

Official Docker Documentation 에 따르면 MAINTAINER 명령은 더 이상 사용되지 않습니다. 대신, LABEL 명령을 사용하여 생성 된 이미지의 작성자를 정의해야합니다. LABEL 명령은보다 유연하고 메타 데이터 설정을 가능하게하며 docker inspect 명령을 사용하여 쉽게 볼 수 있습니다.

LABEL maintainer="[email protected]"

FROM 명령어

FROM <image>

또는

FROM <image>:<tag>

또는

FROM <image>@<digest>

FROM 명령은 후속 지침을 위해 기본 이미지를 설정합니다. 따라서 유효한 Dockerfile의 첫 번째 명령어는 FROM 이어야합니다. 이미지는 모든 유효한 이미지 일 수 있습니다. 특히 공개 리포지토리에서 이미지를 가져 와서 시작하는 것이 쉽습니다.

FROM 은 Dockerfile에서 주석이 아닌 첫 번째 명령이어야합니다.

여러 이미지를 만들려면 FROM 이 단일 Dockerfile 내에 여러 번 나타날 수 있습니다. 각각의 새 FROM 명령 전에 커밋에 의해 마지막 이미지 ID 출력을 기록하기 만하면됩니다.

태그 또는 다이제스트 값은 선택 사항입니다. 둘 중 하나를 생략하면 빌더는 기본적으로 최신으로 가정합니다. 빌더는 태그 값과 일치하지 않으면 오류를 리턴합니다.

실행 명령

RUN 에는 다음과 같은 두 가지 형식이 있습니다.

RUN <command> (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
RUN ["executable", "param1", "param2"] (exec form)

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

계층화 된 RUN 명령어와 커밋 생성은 Docker의 핵심 개념을 따르는 반면 커밋은 싸고 컨테이너는 소스 제어와 마찬가지로 이미지 히스토리의 어느 지점에서든 생성 할 수 있습니다.

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

쉘 양식의 기본 쉘은 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 배열로 구문 분석됩니다. 즉, 작은 따옴표 ( ' )가 아닌 단어 주위에 큰 따옴표 ( )를 사용해야합니다.

주 : 쉘 양식과 달리, exec 양식은 명령 쉘을 호출하지 않습니다. 이는 정상적인 쉘 처리가 발생하지 않음을 의미합니다. 예를 들어, RUN [ "echo", "$HOME" ]$HOME 에서 변수 대체를 수행하지 않습니다. 쉘 처리를 원할 경우, 쉘 양식을 사용하거나 직접 쉘을 실행하십시오 (예 : RUN [ "sh", "-c", "echo $HOME" ] .

참고 : JSON 형식에서는 백 슬래시를 이스케이프 처리해야합니다. 백 슬래시가 경로 구분 기호 인 Windows에서 특히 관련이 있습니다. 그렇지 않으면 다음 줄은 유효한 JSON이 아니기 때문에 셸 형식으로 처리되며 예상치 못한 방식으로 실패합니다. RUN ["c:\windows\system32\tasklist.exe"]

이 예제의 올바른 구문은 다음과 같습니다. RUN ["c:\\windows\\system32\\tasklist.exe"]

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

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

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

ONBUILD 교육

ONBUILD [INSTRUCTION]

ONBUILD 명령은 나중에 이미지가 다른 빌드의 기본으로 사용될 때 실행될 트리거 명령을 이미지에 추가합니다. 트리거는 다운 스트림 Dockerfile의 FROM 명령어 바로 다음에 삽입 된 것처럼 다운 스트림 빌드 컨텍스트에서 실행됩니다.

모든 빌드 명령어를 트리거로 등록 할 수 있습니다.

이는 다른 이미지 (예 : 응용 프로그램 빌드 환경 또는 사용자 별 구성으로 사용자 정의 될 수있는 디먼)를 빌드하기 위해 기본으로 사용될 이미지를 빌드하는 경우에 유용합니다.

예를 들어, 이미지가 재사용 가능한 파이썬 응용 프로그램 빌더 인 경우 응용 프로그램 소스 코드가 특정 디렉토리에 추가되어야하며 그 후에 빌드 스크립트가 호출되어야 할 수도 있습니다. 아직 응용 프로그램 소스 코드에 액세스 할 수 없으므로 ADDRUN 호출 할 수 없으며 응용 프로그램 빌드마다 다를 수 있습니다. 단순히 응용 프로그램 개발자에게 응용 프로그램에 복사하여 붙여 넣기 할 수있는 상용구 Dockerfile을 제공 할 수는 있지만 비효율적이며 오류가 발생하기 쉽고 응용 프로그램 관련 코드와 섞여 업데이트하기 어렵습니다.

해결책은 ONBUILD 를 사용하여 다음 빌드 단계에서 나중에 실행되도록 진행 지침을 등록하는 것입니다.

다음은 작동 방식입니다.

ONBUILD 명령을 발견하면 빌더는 트리거중인 이미지의 메타 데이터에 트리거를 추가합니다. 명령은 현재 빌드에 영향을주지 않습니다.

빌드가 끝나면 모든 트리거 목록이 OnBuild 키 아래 이미지 매니페스트에 저장됩니다. 그들은 docker inspect 명령으로 검사 할 수 있습니다. 나중에 FROM 명령을 사용하여 이미지를 새 빌드의 기반으로 사용할 수 있습니다. FROM 명령을 처리하는 과정에서 다운 스트림 빌더는 ONBUILD 트리거를 ONBUILD 등록 된 것과 동일한 순서로 실행합니다. 트리거 중 하나라도 실패하면 FROM 명령이 중단되고 빌드가 실패하게됩니다. 모든 트리거가 성공하면 FROM 명령이 완료되고 빌드가 평소와 같이 계속됩니다.

트리거는 실행 후 최종 이미지에서 삭제됩니다. 다른 말로하면 "그랜드 - 아이"빌드에 상속되지 않습니다.

예를 들어 다음과 같이 추가 할 수 있습니다.

[...]
ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src
[...]

경고 : 체인 연결 ONBUILD 사용 지침 ONBUILD ONBUILD 허용되지 않습니다.

경고 : ONBUILD 명령어는 FROM 또는 MAINTAINER 명령어를 트리거하지 않을 수 있습니다.

정지 신호 지시

STOPSIGNAL signal

STOPSIGNAL 명령어는 컨테이너로 보내져 나갈 시스템 호출 신호를 설정합니다. 이 신호는 커널의 syscall 테이블에있는 위치 (예 : 9) 또는 SIGAME (SIGKILL)과 같은 시그널 이름과 일치하는 유효한 부호없는 숫자 일 수 있습니다.

건강 관리 지침

HEALTHCHECK 명령에는 두 가지 형식이 있습니다.

HEALTHCHECK [OPTIONS] CMD command (check container health by running a command inside the container)
HEALTHCHECK NONE (disable any healthcheck inherited from the base image)

HEALTHCHECK 명령은 Docker에게 컨테이너가 아직 작동하는지 확인하기 위해 테스트하는 방법을 알려줍니다. 이렇게하면 서버 프로세스가 여전히 실행 중이더라도 무한 루프에 걸려 있고 새로운 연결을 처리 할 수없는 웹 서버와 같은 경우를 감지 할 수 있습니다.

컨테이너의 Healthcheck가 지정되면 정상 상태 외에도 상태가 유지됩니다. 이 상태는 처음에 시작됩니다. 건강 수표가 통과 할 때마다 건강 상태가됩니다 (이전의 상태). 일정한 횟수의 연속적인 실패 후에 그것은 건강에 해 롭습니다.

CMD 전에 나타날 수있는 옵션은 다음과 같습니다.

--interval=DURATION (default: 30s)
--timeout=DURATION (default: 30s)
--retries=N (default: 3)

상태 점검은 컨테이너가 시작된 후 간격 초 후에 실행되고, 이전 점검이 완료된 후 다시 간격으로 몇 초 후에 실행됩니다.

검사를 한 번 실행하는 데 시간 초과 (초)보다 오래 걸리면 검사는 실패한 것으로 간주됩니다.

컨테이너가 건강에 좋지 않은 것으로 간주되는 상태 점검을 연속적으로 실패하는 재 시도가 필요합니다.

하나있을 수 있습니다 HEALTHCHECK A의 명령 Dockerfile . 둘 이상의 항목을 나열하면 마지막 HEALTHCHECK 만 적용됩니다.

CMD 키워드 다음의 CMD 은 셸 명령 (예 : HEALTHCHECK CMD /bin/check-running ) 또는 exec 배열 (다른 Dockerfile 명령과 마찬가지로 자세한 내용은 ENTRYPOINT 참조) 일 수 있습니다.

명령의 종료 상태는 컨테이너의 상태를 나타냅니다. 가능한 값은 다음과 같습니다.

  • 0: success - 컨테이너가 건강하고 사용할 준비가되었습니다.
  • 1: unhealthy - 컨테이너가 올바르게 작동하지 않습니다.
  • 2: starting - 컨테이너가 아직 사용할 준비가되지 않았지만 올바르게 작동하고 있습니다.

컨테이너가 이미 "시작"상태에서 벗어 났을 때 프로브가 2 ( "시작")를 반환하면 대신 "건강에 좋지 않은"것으로 간주됩니다.

예를 들어 5 분마다 웹 서버가 3 초 이내에 사이트의 기본 페이지를 제공 할 수 있는지 확인하려면 다음을 수행하십시오.

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

실패한 프로브를 디버그하는 데 도움이되도록 명령이 stdout 또는 stderr에 쓰는 모든 출력 텍스트 (UTF-8로 인코딩 됨)는 상태에 저장되며 docker inspect 로 쿼리 할 수 ​​있습니다. 이러한 출력은 짧게 유지해야합니다 (처음 4096 바이트 만 현재 저장 됨).

컨테이너의 상태가 변경되면 새 상태로 health_status 이벤트가 생성됩니다.

Docker 1.12에 HEALTHCHECK 기능이 추가되었습니다.

쉘 지시

SHELL ["executable", "parameters"]

SHELL 명령을 사용하면 쉘 형식의 명령에 사용되는 기본 셸을 재정의 할 수 있습니다. Linux의 기본 쉘은 ["/bin/sh", "-c"] 이며 Windows의 ["cmd", "/S", "/C"] 입니다. SHELL 명령어는 Dockerfile에 JSON 형식으로 작성해야합니다.

SHELL 명령어는 Windows에서 특히 유용합니다. cmd와 powershell과 sh를 포함한 다른 쉘을 사용할 수 있습니다.

SHELL 명령은 여러 번 나타날 수 있습니다. 각 SHELL 명령은 이전의 모든 우선 SHELL 지침을, 이후의 모든 명령에 영향을 미칩니다. 예 :

FROM windowsservercore

# Executed as cmd /S /C echo default
RUN echo default

# Executed as cmd /S /C powershell -command Write-Host default
RUN powershell -command Write-Host default

# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]
RUN Write-Host hello

# Executed as cmd /S /C echo hello
SHELL ["cmd", "/S"", "/C"]
RUN echo hello

다음 지침에 의해 영향을받을 수 SHELL : 그들의 쉘 형태가 Dockerfile에 사용되는 명령 RUN , CMDENTRYPOINT .

다음 예제는 Windows에서 발견되는 공통 패턴으로 SHELL 명령어를 사용하여 능률화 할 수 있습니다.

...
RUN powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"
...

docker에 의해 호출되는 명령은 다음과 같습니다.

cmd /S /C powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"

이것은 두 가지 이유로 비효율적입니다. 첫째, 불필요한 cmd.exe 명령 프로세서 (일명 셸)가 호출됩니다. 둘째, 셸 형식의 각 RUN 명령어에는 명령 앞에 접두어가 붙는 여분의 powershell 명령이 필요합니다.

이것을보다 효율적으로하기 위해 두 가지 메커니즘 중 하나를 사용할 수 있습니다. 하나는 JSON 형식의 RUN 명령을 사용하는 것입니다.

...
RUN ["powershell", "-command", "Execute-MyCmdlet", "-param1 \"c:\\foo.txt\""]
...

JSON 양식은 모호하지 않으며 불필요한 cmd.exe를 사용하지 않지만 큰 따옴표와 이스케이프를 통해 자세한 표시가 필요합니다. 다른 방법은 SHELL 명령과 셸 형식을 사용하는 것입니다. 특히 Windows 사용자가 이스케이프 구문 분석기 지시문과 결합 할 때 더 자연스러운 구문을 만듭니다.

# escape=`

FROM windowsservercore
SHELL ["powershell","-command"]
RUN New-Item -ItemType Directory C:\Example
ADD Execute-MyCmdlet.ps1 c:\example\
RUN c:\example\Execute-MyCmdlet -sample 'hello world'

를 야기하는:

PS E:\docker\build\shell> docker build -t shell .
Sending build context to Docker daemon 3.584 kB
Step 1 : FROM windowsservercore
 ---> 5bc36a335344
Step 2 : SHELL powershell -command
 ---> Running in 87d7a64c9751
 ---> 4327358436c1
Removing intermediate container 87d7a64c9751
Step 3 : RUN New-Item -ItemType Directory C:\Example
 ---> Running in 3e6ba16b8df9


Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/2/2016   2:59 PM                Example


 ---> 1f1dfdcec085
Removing intermediate container 3e6ba16b8df9
Step 4 : ADD Execute-MyCmdlet.ps1 c:\example\
 ---> 6770b4c17f29
Removing intermediate container b139e34291dc
Step 5 : RUN c:\example\Execute-MyCmdlet -sample 'hello world'
 ---> Running in abdcf50dfd1f
Hello from Execute-MyCmdlet.ps1 - passed hello world
 ---> ba0e25255fda
Removing intermediate container abdcf50dfd1f
Successfully built ba0e25255fda
PS E:\docker\build\shell>

SHELL 명령은 쉘이 작동하는 방식을 수정하는 데 사용될 수도 있습니다. 예를 들어, Windows에서 SHELL cmd /S /C /V:ON|OFF 를 사용하면 지연된 환경 변수 확장 의미를 수정할 수 있습니다.

SHELL 명령어는 Linux에서 zsh, csh, tcsh 등과 같은 다른 쉘이 필요할 경우에도 사용할 수 있습니다.

SHELL 기능이 Docker 1.12에 추가되었습니다.

데비안 / 우분투 패키지 설치하기

단일 실행 명령으로 설치 프로그램을 실행하여 업데이트를 병합하고 설치하십시오. 나중에 더 많은 패키지를 추가하면 업데이트가 다시 실행되고 필요한 모든 패키지가 설치됩니다. 업데이트를 별도로 실행하면 캐시가 업데이트되고 패키지 설치가 실패 할 수 있습니다. 프론트 엔드를 비대화 형으로 설정하고 -y를 설치하여 전달하면 스크립트 설치가 필요합니다. 설치가 끝날 때 청소 및 퍼지 작업을 수행하면 레이어 크기가 최소화됩니다.

FROM debian

RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get install -y \
    git \
    openssh-client \
    sudo \
    vim \
    wget \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*


Modified text is an extract of the original Stack Overflow Documentation
아래 라이선스 CC BY-SA 3.0
와 제휴하지 않음 Stack Overflow