반응형
Dockerfile 작성 모범 사례
컨테이너의 설계 철학에 맞게 이미지를 만들어야 생산성이 높아지고 운영 중 겪게 될 문제를 사전에 예방할 수 있다.
종래의 오케스트레이션 도구인 Ansible이나 Chef 등은 서버들의 목표로 하는 상태로 만든다는 사고 방식으로 동작한다.
그리고 그 동작 방식은 멱등성(Idempotence)에 기초하여 몇 번을 배포해도 한결같이 목표로 하는 상태로 만들어 준다.
이들 도구들은 서버의 기동이나 설정에 오랜시간 걸리는 것을 고려하여 만들어졌다.
도커의 경우는 Dockerfile에 운영체제와 의존 패키지를 기술하여 이미지를 만들면 굉장히 짧은 시간에 컨테이너를 기동/교체/종료할 수 있다.
그리고 이미지에는 운영체제와 패키지가 이미 모두 포함되어 있으므로 배포 시 추가적인 시간이 발생하지 않아 짧게 사용하고 폐기한다는 사고방식이 유효하다.
애플리케이션에 변경 사항이 있는 경우에는 Dockerfile을 변경하여 이미지를 다시 만들면 그만인 것이다.
이러한 컨테이너의 특징은 다음과 같은 운영상의 장점으로 작용한다.
- 프로젝트에 새롭게 참가한 개발자가 개발 및 실행 환경에 대해 학습해야 할 시간과 노력을 줄여준다.
- 소프트웨어의 의존 관계를 컨테이너에 담아서 실행 환경 사이의 이동을 쉽게 해준다.
- 서버 관리나 시스템 관리의 부담을 줄여 준다.
- 개발 환경과 운영 환경의 차이를 줄여서 지속적 개발과 릴리즈를 쉽게 해준다.
- 같은 이미지를 사용하는 컨테이너 수를 늘림으로써 쉽게 처리 능력을 높일 수 있다.
컨테이너의 이점을 최대한 활용하기 위해서 가상 서버의 연장선 정도로 컨테이너를 생각하고 사용해서는 안된다.
컨테이너의 철학을 최대한 이해하고 Dockerfile을 작성하는 것이 좋다.
컨테이너의 철학은 쿠버네티스를 활용할 때도 여전히 유효하다.
Dockerfile 명령어 시트
커맨드 | 설명 |
FROM <이미지>[:태그] | 컨테이너의 베이스 이미지를 지정 |
RUN <커맨드> RUN ["커맨드", "파라미터1", "파라미터2"] |
FROM의 베이스 이미지에서 커맨드를 실행 |
ADD <소스> <컨테이너 내 경로> ADD ["소스", ... "<컨테이너 내 경로>"] |
소스(파일, 디렉터리, tar, 파일, URL)를 컨테이너 내 경로에 복사 |
COPY <소스> <컨테이너 내 경로> COPY ["소스", ... "<컨테이너 내 경로>"] |
소스(파일, 디렉터리)를 컨테이너 내 경로에 복사 |
ENTRYPOINT ["실행가능한것", "파라미터1", "파라미터2"] ENTRYPOINT 커맨드 파라미터1 파라미터2(셸 형식) |
컨테이너가 실행하는 파일을 설정 |
CMD ["실행 바이너리", "파라미터1", "파라미터2"] CMD <커맨드>(셸 형식) CMD ["파라미터1", "파라미터2"](ENTRYPOINT 의 파라미터) |
컨테이너 기동 시 실행될 커맨드를 지정 |
ENV <key> <value> ENV <key>=<value> ... |
환경 변수 설정 |
EXPOSE <port> [<port> ... ] | 공개 포트 설정 |
USER <유저명> | <UID> | RUN, CMD, ENTRYPOINT 실행 유저 지정 |
VOLUME["/path"] | 공유 가능한 볼륨을 마운트 |
WORKDIR /path | RUN, CMD, ENTRYPOINT, COPY, ADD의 작업 디렉터리 지정 |
ARG <이름>[=<디폴트값>] | 빌드할 때 넘길 인자를 정의 --build-arg <변수명>=<값> |
LABEL <key>=<value> <key>=<value> | 이미지의 메타데이터에 라벨을 추가 |
MAINTAINER <이름> | 이미지를 메타데이터에 저작권을 추가 |
참고
반응형
'Docker & Kubernetes' 카테고리의 다른 글
PHP 컨테이너와 MySQL 컨테이너의 연동 예시 (0) | 2021.11.26 |
---|---|
컨테이너와 네트워크 (0) | 2021.11.26 |
컨테이너 개발 (0) | 2021.11.26 |
컨테이너 다루기(2/2) (0) | 2021.11.26 |
컨테이너 다루기(1/2) (0) | 2021.11.25 |