English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية

Docker Dockerfile

Dockerfile이 무엇인가요?

Dockerfile은 이미지를 빌드하는 텍스트 파일로, 이미지를 빌드하는 데 필요한 명령어와 설명이 포함되어 있습니다。

Dockerfile을 사용한 이미지 커스터마이즈

여기서는 Dockerfile 파일을 통해 이미지를 커스터마이즈하는 방법을 설명합니다. 구체적인 Dockerfile 파일 내 명령어에 대한 설명은 다음 장에서 다룹니다. 여기서는 빌드 프로세스만 알면 됩니다.

1、다음은 nginx 이미지를 커스터마이즈하는 예제입니다(빌드된 이미지 내에 index.html 파일이 포함됩니다): /usr/share/nginx/html/index.html 파일)

공간이 없는 디렉토리에서 Dockerfile 파일을 새로 만들고, 파일 내에 다음 내용을 추가합니다:

FROM nginx
RUN echo '이는 로컬에서 빌드된 nginx 이미지입니다' > /usr/share/nginx/html/index.html

2、FROM과 RUN 명령어의 역할

FROM:커스터마이즈된 이미지는 FROM 이미지를 기반으로 합니다. 여기서 nginx는 커스터마이즈가 필요한 기본 이미지입니다. 이후의 작업은 nginx를 기반으로 합니다。

RUN:다음 명령행 명령어를 실행합니다. 두 가지 형식이 있습니다:

shell 형식:

RUN <명령행 명령어>
# <명령행 명령어>는 터미널에서 수행하는 shell 명령어와 동일합니다。

exec 형식:

RUN ["수행 파일", "파라미터1", "파라미터2"]
# 예를 들어:
# RUN ["./test.php", "dev", "offline"]는 RUN ./test.php dev offline

주의:Dockerfile의 명령어가 docker에서 매번 실행될 때마다 새로운 레이어를 생성합니다. 따라서 의미가 없는 많은 레이어는 이미지가 너무 두껍게膨胀하게 됩니다. 예를 들어:

FROM centos
RUN yum install wget
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz"
RUN tar -xvf redis.tar.gz
위의 실행은 생성됩니다 3 레이어 이미지。다음 형식으로 간단히 표현할 수 있습니다:
FROM centos
RUN yum install wget \
    && wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \
    && tar -xvf redis.tar.gz

위와 같이 && 기호로 명령어를 연결하면, 실행 후에만 생성됩니다 1 레이어 이미지。

이미지 빌드 시작

Dockerfile 파일이 저장된 디렉토리에서 빌드 작업을 수행합니다。

아래 예제에서, 디렉토리 아래의 Dockerfile을 통해 nginx:v3(이미지 이름: 이미지 태그)。

주의: 마지막  .  은 이번 실행의 컨텍스트 경로를 의미합니다. 다음 장에서는 이를 설명할 것입니다.

$ docker build -t nginx:v3 .

위의 출력은 이미지가 성공적으로 구축되었음을 의미합니다.

컨텍스트 경로

이전 장에서 명령어의 마지막  .  이 컨텍스트 경로라는 것을 언급했습니다. 그렇다면 컨텍스트 경로는 무엇인가요?

$ docker build -t nginx:v3 .

: 컨텍스트 경로는 docker가 이미지를 구축할 때, 때로는 로컬의 파일(예: 복사)을 사용하고 싶을 때, docker build 명령어가 이 경로를 알면 경로에 있는 모든 내용을 패키지로 만들어 전송합니다.

해석: docker의 실행 모드는 C/S. 우리의 로컬은 C, docker 엔진은 S입니다. 실제 구축 과정은 docker 엔진에서 완료됩니다. 따라서 이때 로컬의 파일을 사용할 수 없습니다. 따라서 docker 엔진에 사용할 수 있도록 로컬의 지정된 디렉토리의 파일을 모두 패키지로 제공해야 합니다.

마지막 매개변수를 명시하지 않았을 경우, 기본 컨텍스트 경로는 Dockerfile이 있는 위치입니다.

주의: 컨텍스트 경로에 불필요한 파일을 두지 마세요. 이유는 docker 엔진에 함께 전송되기 때문에 파일이 많으면 과정이 느리게 될 수 있습니다.

명령어 설명

COPY

복사 명령어는 컨텍스트 디렉토리에서 파일이나 디렉토리를 컨테이너의 지정된 경로로 복사합니다.

형식:

COPY [--chown=<user>:<group>] <원 경로1>...  <목적 경로>
COPY [--chown=<user>:<group>] ["<원 경로1>",...  "<목적 경로>"]

[--chown=<user>:<group>]: 선택 사항, 사용자가 컨테이너 내에 복사된 파일의 소유자와 그룹을 변경할 수 있습니다.

<원 경로>: 원 파일이나 원 디렉토리, 여기에는 와일드 카드 표현식이 사용될 수 있습니다. 와일드 카드 표현식의 규칙은 Go의 filepath.Match 규칙을 따릅니다. 예를 들어:

COPY hom* /mydir/
COPY hom?.txt /mydir/

<목적 경로>: 컨테이너 내의 지정된 경로, 이 경로는 사전에 만들어져 있지 않아도 됩니다. 경로가 존재하지 않으면 자동으로 생성됩니다.

ADD

ADD 명령어와 COPY의 사용 형식은 일관됩니다. (동일한 요구 사항에서는 공식적으로 COPY를 사용 권장합니다). 기능도 유사하지만 다음과 같은 차이가 있습니다:

  • ADD의 장점: <원 파일>이 tar 압축 파일이면, 압축 형식이 gzip, bzip입니다.2 xz의 경우, 자동으로 <목적 경로>에 복사하고 압축해제됩니다.

  • ADD의 단점: 압축해제되지 않은 상태에서 tar 압축 파일을 복사할 수 없습니다. 이미지 구축 캐시가 만료되어 이미지 구축이 느리게 될 수 있습니다. 사용 여부는 자동 압축이 필요한지 여부에 따라 결정할 수 있습니다.

CMD

RUN 명령어와 유사하지만 두 명령어가 실행되는 시점이 다릅니다:

  • CMD는 docker run에서 실행됩니다.

  • RUN은 docker build에서 사용됩니다.

작용:운영 중인 컨테이너에 기본적으로 실행되는 프로그램을 지정합니다. 프로그램이 종료되면 컨테이너도 종료됩니다. CMD 명령어로 지정된 프로그램은 docker run 명령 줄 파라미터로 지정된 프로그램에 덮어쳐질 수 있습니다。

주의:Dockerfile에서多个CMD指令存在时,仅最后一个生效。

형식:

CMD <shell 명령어> 
CMD ["<executable>","<param1>","<param2>",...] 
CMD ["<param1>","<param2>",...] # ENTRYPOINT 명령어로 지정된 프로그램에 기본 파라미터 제공

두 번째 형식을 추천합니다. 실행 과정이 명확합니다. 첫 번째 형식은 실행 중에 자동으로 두 번째 형식으로 변환되며, 기본 실행 파일은 sh입니다.

ENTRYPOINT

CMD 명령어와 유사하지만 docker run 명령 줄 파라미터로 지정된 명령어에 의해 덮어쳐지지 않으며, 이러한 명령 줄 파라미터는ENTRYPOINT 명령어로 지정된 프로그램에 파라미터로 전달됩니다。

하지만, docker run을 실행할 때 --entrypoint 옵션은 CMD 명령어로 지정된 프로그램을 덮어씁니다。

장점:docker run을 실행할 때ENTRYPOINT 실행에 필요한 파라미터를 지정할 수 있습니다。

주의:Dockerfile에서多个ENTRYPOINT指令存在时,仅最后一个生效。

형식:

ENTRYPOINT ["<executable>","<param1>","<param2>",...]

CMD 명령어와 함께 사용할 수 있습니다: CMD는 일반적으로 변동 파라미터를 사용할 때만 사용됩니다. 여기서의 CMD는ENTRYPOINT에 파라미터를 전달하는 것과 같습니다. 다음 예제에서 언급됩니다.

예제:

가상 컨테이너에 nginx:test 이미지를 이미 구축한 경우를 가정합니다:

FROM nginx
ENTRYPOINT ["nginx", "-c"] # 정적 파라미터
CMD ["/etc/nginx/nginx.conf"] # 파라미터

1파라미터 전달 없이 실행

$ docker run nginx:test

가상 컨테이너 내에서 기본적으로 다음 명령어가 실행되어 주 프로세스를 시작합니다.

nginx -c /etc/nginx/nginx.conf

2파라미터 전달 실행

$ docker run nginx:test -c /etc/nginx/new.conf

가상 컨테이너 내에서 기본적으로 다음 명령어가 실행되어 주 프로세스를 시작합니다 (/etc/nginx/new.conf: 가상 컨테이너 내에 이 파일이 이미 존재하는 것을 가정)

nginx -c /etc/nginx/new.conf

ENV

환경 변수를 설정합니다. 환경 변수가 정의되면, 후속 명령어에서 이 환경 변수를 사용할 수 있습니다.

형식:

ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...

이하 예제에서 NODE_VERSION을 설정합니다 = 7.2.0을 사용하여 후속 명령어에서 참조할 수 있습니다:

ENV NODE_VERSION 7.2.0
RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \
  && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc"

ARG

ARG는 ENV와 동일한 역할을 합니다. 하지만 작용 범위가 다릅니다. ARG로 설정된 환경 변수는 Dockerfile 내에서만 유효입니다. 즉, docker build 과정에서만 유효하며, 빌드된 이미지 내에는 이 환경 변수가 존재하지 않습니다.

docker build 명령어에서 사용할 수 있습니다. --build-arg <파라미터 이름>=<값>를 사용하여 덮어쓰습니다.

형식:

ARG <파라미터 이름>[=<기본 값>]

VOLUME

익명 데이터 볼륨을 정의합니다. 컨테이너를 시작할 때 데이터 볼륨을 마운트하지 않으면 자동으로 익명 볼륨에 마운트됩니다.

작용:

  • 중요한 데이터가 컨테이너가 재시작될 때마다 손실되지 않도록 합니다. 이는 매우 위험합니다.

  • 컨테이너가 계속 커지지 않도록 합니다.

형식:

VOLUME ["<경로1>", "<경로2>"...]
VOLUME <경로>

도커 런에서 컨테이너를 시작할 때, 다음과 같이 사용할 수 있습니다. -v 파라미터를 사용하여 마운트 포인트를 수정합니다.

EXPOSE

포트를 단순히 선언합니다.

작용:

  • 이미지 사용자가 이镜像 서비스의 셀렉터 포트를 이해하고, 매핑 설정을 쉽게 할 수 있도록 도와줍니다.

  • 도커 런에서 무작위 포트 매핑을 사용할 때, 즉 docker run -P를 사용할 때, EXPOSE된 포트는 자동으로 무작위로 매핑됩니다.

형식:

EXPOSE <포트1> [<포트>2>...]

WORKDIR

작업 디렉토리를 지정합니다. WORKDIR로 지정된 작업 디렉토리는 이미지를 빌드할 때마다 존재합니다. (WORKDIR로 지정된 작업 디렉토리는 사전에 생성된 것입니다).

docker build 이미지 생성 과정에서, 각 RUN 명령어는 새로운 레이어로 생성됩니다. WORKDIR로 생성된 디렉토리만이 항상 존재합니다.

형식:

WORKDIR <작업 디렉토리 경로>

USER

이후 명령어 실행을 위한 사용자와 그룹을 지정하는 용도로 사용됩니다. 이곳에서는 이후 명령어 실행을 위한 사용자만 변경됩니다. (사용자와 그룹은 사전에 존재해야 합니다).

형식:

USER <사용자 이름>[:<사용자 그룹>]

HEALTHCHECK

특정 프로그램이나 명령어를 사용하여 docker 컨테이너 서비스의 실행 상태를 모니터링하는 데 사용됩니다.

형식:

HEALTHCHECK [옵션] CMD <명령>:컨테이너 건강 상태를 확인하는 명령어를 설정합니다
HEALTHCHECK NONE:기본 이미지에 건강 검사 명령이 있으면 이 줄을 사용하여 건강 검사 명령을 차단할 수 있습니다
HEALTHCHECK [옵션] CMD <명령> : CMD 뒤에 따르는 명령어 사용 방법을 참고하세요.

ONBUILD

빌드 명령어 실행을 지연합니다. 간단히 말해서 Dockerfile에서 ONBUILD이 지정한 명령어는 이번 빌드 이미지 과정에서 실행되지 않습니다(이미지가 test라면)-build)。이전에 구축된 이미지 FROM test를 사용하는 새로운 Dockerfile이 있을 때-build은 새로운 이미지를 실행하는 Dockerfile을 구축할 때 test를 실행합니다.-build의 Dockerfile에서 ONBUILD이 지정한 명령어.

형식:

ONBUILD <기타 명령>