[부트캠프 - 34일차] 2/6.금 - Docker

developowl·2026년 2월 6일

docker 부트캠프 현대오토에버 모빌리티 SW스쿨 클라우드

부트캠프

목록 보기

24/29

건강 이슈로 [33일차 - 2/5.목] 수업 내용은 이번 포스트에 포함시켰습니다.😷

Dockerfile

코드형 인프라 (Infrastructure as Code, IaC)

수동으로 배포했을 때 문제점
- 커맨드 기반의 인프라 구성 시 사용자 실수 등의 인적 오류 가능성이 높은데 APM(Apache + PHP + MySQL)을 구축하는 경우 설치 순서와 상호 연관성 등을 고려하여 각종 라이브러리와 함께 복잡한 명령어를 고민해야 함
- 각종 환경 설정 정보와 설치 프로그램을 요구사항에 맞게 살펴봐야 하는데 만일 설치 이후에 잘못된 설정이 있다면 수정해야 하고 때로는 재설치도 불가피
개요
- 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것
  
  프로비저닝 - IT 인프라나 사용자 계정을 필요에 맞춰 구성, 배포 및 관리하여 즉시 사용할 수 있도록 준비하는 과정
- 인프라 사양을 담은 구성 파일이 생성되므로 구성을 편집하고 배포하기가 쉬워지고 동일한 환경을 프로비저닝 하도록 보장
- 구성 사양을 코드화 하고 문서화함으로써 구성 관리를 지원하며 구성 변경 사항을 문서화 하지 않고 임시로 변경하는 일을 막을 수 있음
- 버전 제어는 IaC의 중요한 부분으로 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 버전 제어가 필요
- 코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다는 의미
- 인프라 구성 요소를 수동으로 프로비저닝 하고 관리할 필요가 없어지고, 인프라를 코드화 하여 템플릿을 만들고 프로비저닝 할 때 이 템플릿을 사용하면 됨
- IaC 지원 도구로 도커, 앤서블, 쿠버네티스 등이 있음

Dockerfile

DockerImage 를 생성(Application Packaging)하기 위한 스크립트(설정 파일)
여러 명령어를 토대로 Dockerfile 을 작성한 후 빌드하면 Docker는 Dockerfile에 나열된 명령문을 차례대로 수행하며 DockerImage를 생성

[Dockerfile] → Build → [Docker Image] → Run → [Docker Container]

Dockerfile을 사용했을 때의 장점

이미지가 어떻게 만들어졌는지를 기록
배포에 용이
컨테이너(이미지)가 특정 행동을 수행하도록 할 수 있음

최적의 Dockerfile

경량의 컨테이너 서비스를 제공 - 빠른 컨테이너 배포를 위해 최소한의 설정과 구성을 권장
Dockerfile에 담기는 레이어(계층) 최소화 - 작성하게 될 Dockerfile 명령어 수와 이미지 레이어 수는 동일하므로 레이어 수를 줄일 수 있도록 Dockerfile 명령어 사용 방법을 정확히 알고 작성
하나의 애플리케이션은 하나의 컨테이너
- 하나의 컨테이너에 2개 이상의 애플리케이션을 설정하게 되면 애플리케이션의 결합성이 높고 확장성을 저해하게 됨
- 하나의 컨테이너에 하나의 애플리케이션이 동작하도록 하면 컨테이너 간의 독립성을 보장함과 동시에 애플리케이션 버전 관리, 소수 코드 모듈화 등에서 이점이 있으므로 모놀리식 구성보다는 decouple applications(결합 해제된 애플리케이션) 설계 또는 마이크로서비스 지향적 설계를 고려
IaC 환경 개발은 디렉토리 단위 - 이미지 빌드와 상관없는 파일이 포함되지 않도록 별도의 디렉토리를 생성
캐시(Cache) 기능 활용
- Dockerfile을 통해 이미지를 빌드하면 자동으로 각 명령어 단위로 캐싱되므로 동일한 명령의 실행은 캐싱을 통해 재사용 되어서 빌드 속도를 빠르게 함
- 도커의 이미지 레이어가 특정한 순서대로만 배치된다고 가정하기 때문에 중간에 있는 레이어가 변경되면 변경된 레이어보다 위에 오는 레이어를 재사용할 수 없음
- 도커는 캐시에 일치하는 레이어가 있는지 확인하기 위해 해시 값을 이용하는데 Dockerfile 스크립트의 인스트럭션과 인스트럭션에 의해 복사되는 파일의 내용으로부터 계산됨
- 기존 이미지 레이어에 해시 값이 일치하는 것이 없다면 캐시 미스가 발생, 해당 인스트럭션이 실행되는데 한 번 인스트럭션이 실행되면 그 다음에 오는 인스트럭션은 수정된 것이 없더라도 모두 실행됨
서버리스 환경으로 개발
- 서버리스 애플리케이션 구축은 개발자가 클라우드에서든 온프레미스에서든 서버 및 런타임의 관리 및 운영에 필요한 업무량을 줄이고 핵심 개발에 집중할 수 있다는 것을 의미
- 오버헤드가 줄어들면 개발자는 확장성과 안정성을 갖춘 좋은 제품을 개발하는데 시간과 열정을 쏟을 수 있음

Dockerfile 작성 명령어

FROM

필수 항목으로 image 의 바탕이 될 베이스 image 를 지정
태그를 선택할 때 작은 크기의 이미지(slim)와 리눅스 배포판인 알파인(alpine) 이미지를 권장하지만 모든 애플리케이션이 동일하지는 않음
태그를 넣지 않으면 latest 로 지정

FROM 베이스이미지

MAINTAINER

이미지를 빌드한 작성자 이름과 이메일을 작성

MAINTAINER 작성자이름 이메일

LABEL

이미지 작성 목적으로 버전, 타이틀, 설명, 라이선스 정보를 작성
여러 개 작성 가능

LABEL version = '버전 정보'
LABEL description = '설명'

RUN

설정된 기본 이미지에 패키지 업데이트, 각종 패키지 설치, 명령 실행 등을 작성
여러 개 작성 가능
권장 사항
- 다단계 빌드 사용 권장 - 각 이미지 별로 개별 Dockerfile 로 빌드
- RUN 명령어의 개별 명령 수를 최소화하기 위해 여러 설치 명령을 연결하면 이미지의 레이어 수 감소
- autoremove, autoclean, rm -rf/var/lib/apt/lists/* 을 사용하면 저장되어 있는 apt 캐시가 삭제되므로 이미지 크기가 감소

# exec 방식
RUN [”/bin/bash”, ”-c”, ’’apt update”]

# shell 방식
RUN apt update && apt install -y nginx \
git \
vim \
curl && \
apt clean -y && \
apt autoremove -y && \
rm -rfv /tmp/* /var/lib/apt/lists/* /var/tmp/*

CMD

생성된 이미지를 컨테이너로 실행할 때 실행되는 명령이고 ENTRYPOINT 명령문으로 지정된 커맨드에 디폴트로 넘길 파라미터를 지정할 때 사용
여러 개의 CMD를 작성해도 마지막 하나만 처리
일반적으로 이미지의 컨테이너 실행 시 애플리케이션 데몬이 실행되도록 하는 경우 유용

# ex
CMD [“/usr/sbin/apachectl”, “-D”, “FOREGROUND”’]
CMD ["python", ’’app.py”]

ENTRYPOINT

CMD와 마찬가지로 생성된 이미지가 컨테이너로 실행될 때 사용되지만 컨테이너가 실행될 때 명령어 및 인자 값을 전달하여 실행한다는 점이 다름
여러 개의 CMD를 사용하는 경우 ENTRYPOINT 명령문과 함께 사용
커맨드를 지정하고 CMD는 기본 명령을 지정하면 탄력적으로 이미지를 실행할 수 있음
Docker 컨테이너 실행 시 항상 수행해야 하는 명령어를 지정(웹 서버나 데이터베이스 등의 데몬 실행)하는데 이용하고 CMD는 Docker 컨테이너 실행 시 다양한 명령어를 지정하는 경우 유용

# python 명령을 기본으로 runapp.py 코드를 실행하는 경우
ENTRYPOINT ["python"]
CMD ["runapp.py"]

# 동일 환경에 entrypoint.sh 셸 스크립트를 이미지에 넣고(ADD) 
# 실행 권한 설정(RUN) 후 컨테이너 실행 시 entrypoint.sh를 실행(ENTRYPOINT)
ADD ./entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT [“/bin/bash”, “/entrypoint.sh”]

COPY

호스트 환경의 파일, 디렉토리를 이미지 안에 복사하는 경우 작성
단순한 복사 작업만 지원
빌드 작업 디렉토리 외부의 파일은 COPY 할 수 없음

COPY index.html /usr/share/nginx/html
COPY ./runapp.py /

# 작업 영역 전체를 COPY하므로 비효율적
COPY . /app

ADD

호스트 환경의 파일, 디렉토리를 이미지 안에 복사하는 경우 뿐만 아니라 URL 주소에서 직접 다운로드 하여 이미지에 넣을 수도 있고, 압축 파일(tar, tar.gz)인 경우에는 지정한 경로에 압축을 풀어서 추가

ENV

이미지 안에 각종 환경 변수를 지정하는 경우 작성
애플리케이션 사용을 쉽게 하기 위해 사전에 구성되어야 하는 환경 변수들이 있는 경우 사용
자바 홈 디렉토리, 특정 실행 파일의 경로를 보장하기 위해 절대 경로 지정을 위한 PATH 설정, 프로그램 버전 등을 사전에 설정
반복된 표현이 사용되는 경우에도 환경 변수 설정을 권장
Dockerfile 에서 ENV 를 설정하면 RUN, WORKDIR 등에서 환경 변수를 사용해 반복을 피할 수 있음

ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
ENV PATH /usr/local/nginx/bin:$PATH
ENV Python 3.9
ENV NODE_VERSION V15.1.0
RUN curl -SLO "http://nodejs.org/dist/$N0DE_VERSI0N/node-
$NODE_VERSI0N-linux-x64.tar.gz" && tar -xzf "node-$NODE_VERSION-linux-
x64.tar.gz" -C /usr/local ••“strip-cc*nponents=l \ && rm "node-
$NODE_VERSI0N-linux-x64.tar.gz"

EXPOSE

이미지가 컨테이너로 실행될 때 어떤 포트를 사용할 예정인지 명시하는 '안내문' 역할
nginx 나 apache 는 기본 포트로 HTTP 80번과 HTTPS 443번 포트를 사용
이미지 내에 애플리케이션이 사용하는 포트를 사전에 확인하고 호스트와 연결되도록 구성하는 경우에 설정하고 docker run 사용 시 -p 옵션을 통해 포트포워딩을 해서 사용

EXPOSE 80 또는 EXPOSE 80/tcp
EXPOSE 443
EXPOSE 8080/udp

VOLUME

볼륨을 이미지 빌드에 미리 설정하는 경우 작성
Docker 컨테이너에서 사용된 파일과 디렉토리는 컨테이너 삭제와 함께 사라지기 때문에 사용자 데이터의 보존과 지속성을 위해 볼륨 사용을 권장
VOLUME 으로 지정된 컨테이너의 경로는 볼륨의 기본 경로 /var/lib/docker 와 자동으로 연결

VOLUME /var/log
VOLUME /var/www/html
VOLUME /etc/nginx

# HOST OS의 Volume 기본 경로와 container 내부의 /project 연결
VOLUME ["/project”]

USER

컨테이너의 기본 사용자는 root
애플리케이션이 권한없이 서비스를 실행할 수 있다면 USER 를 통해 다른 사용자로 변경하여 사용

RUN ["useradd”, ”adam”]
USER adam
RUN ["/bin/bash”, ’’-c”, "date”]
# 또는
RUN groupadd -r mongodb && useradd –no-log-init –r –g mongodb
mongodb

WORKDIR

컨테이너상에서 작업할 경로(디렉토리) 전환을 위해 작성
WORKDIR 을 설정하면 RUN, CMD, ENTRYPOINT, COPY, ADD 명령문은 해당 디렉토리를 기준으로 실행
지정한 경로가 없으면 자동 생성되고 컨테이너 실행 이후 컨테이너에 접속(

docker exec -it my_container bash) 하면 지정한 경로로 연결

WORKDIR /workspace
WORKDIR /usr/share/nginx/html
WORKDIR /go/src/app

ARG

docker build 시점에서 변수의 값을 전달하기 위해 --build-arg=인자 를 정의하여 사용
비밀키, 계정 비밀번호 같은 민감한 정보 사용 시 이미지에 그대로 존재하여 노출될 위험이 있음

# Dockerfile에 ARG 변수를 정의
ARG db_name

# docker build 시 변수의 값을 저장하면 이미지 내부로 인자가 전달
docker build –build-arg db_name=adam_db .

# 입력받은 변수의 값을 명령에 사용
CMD db_start.sh -h 127.0.0.1 -d ${db_name}

ONBUILD

처음 이미지 빌드에 포함하지만 실행되지 않고 해당 이미지가 다른 이미지의 기본 이미지로 사용되는 경우 실행될 명령을 지정할 때 작성
ONBUILD 명령은 부모 Dockerfile 이 자식 Dockerfile 에 명령을 전달하고자 할 때 사용
1차 개발에서 환경을 만들어주고 2차 개발에서 ONBUILD 에 지정된 소스를 실행
1차 Dockerfile 빌드 시 ONBUILD 포함
- ONBUILD ADD websource.tar.gz /usr/share/nginx/html/
2차 Dockerfile 에 1차에서 생성된 이미지를 지정하면 ONBUILD 에 지정된 ADD 명령이 실행되어 새로운 이미지로 생성

STOPSIGNAL

docker stop 명령은 컨테이너에게 SIGTERM 을 보내 정지시킴
다른 시그널을 넣고자 하는 경우 작성
- STOPSIGNAL SIGKILL 시그널번호(or 이름)

SHELL

Dockerfile 내부에서 사용할 기본 셸을 지정하는 경우 작성
기본값으로 /bin/sh 가 지정

SHELL [’’/bin/bash”, ”-c"]
RUN echo "Docker world!"

HEALTHCHECK

컨테이너의 프로세스 상태를 체크하고자 하는 경우에 작성
HEALTHCHECK 는 하나의 명령만이 유효하고 여러 개가 지정된 경우 마지막에 선언된 HEALTHCHECK 가 적용
옵션
- --interval=(초)
  - 헬스 체크 간격으로 기본값은 30s
- --timeout=(초)
  - 타임 아웃으로 기본값을 30s
- --retries=N
  - 타임 아웃 횟수로 기본값은 3
상태 코드
- 0: success
  - 컨테이너 정상 작동
- 1: unhealthy
  - 컨테이너가 올바르게 작동하지 않는 상태
- 2: strating
  - 예약된 코드

Dockerfile 명령어 작성 방법

일반적으로 시작은 FROM 명령부터 작성하는데 그 다음 명령부터는 순서가 없지만 명령 순서는 빌드 캐시의 무효화와 연관되므로 변경 빈도수가 적은 명령을 먼저 배치하는 것을 권장

Dockerfile 스크립트로 이미지 생성

이미지 생성 명령

docker build [옵션] 생성할_이미지_이름[:태그] \
Dockerfile_파일_디렉토리경로 | URL | 압축파일

옵션
- -t:(tag)
  - 이미지명: 태그를 지정하는 경우
- -f(file)
  - Dockerfile이 아닌 다른 파일명을 사용하는 경우
  - -f Dockerfile_nginx
- 동시에 여러 저장소를 생성하려면 -t를 반복해서 사용
  - docker build -t mypyapp:2.0 -t mypyapp:init.
이미지명:태그
- 생성할 이미지 이름과 태그를 지정
- 태그는 버전 관리 차원
경로
- 디렉토리 단위 개발을 권장
- 현재 경로에 Dockerfile 이 있다면 . 을 사용
URL
- Dockerfile 이 포함된 깃허브 URL 을 제공하는 경우
  - docker build -t phpserver:2.0 github.com/brayanlee/docker-phpserver
압축 파일
- 압축 파일 내에 Dockerfile 이 포함된 경우
  - docker build -f app1/Dockerfile http://server/appl.tar.gz

Dockerfile 이 필요한 이유

우분투에서 PHP 웹 페이지 연동

서버 직접 구축
- 호스트 운영체제에 이와 같은 설치와 설정을 통해 환경을 구성하고 개발 팀에서 제공하는 웹 소스를 이용해 애플리케이션 서비스를 수행
- 이러한 인프라 구축 작업은 규모가 클수록 인프라 구성 관리에 대한 부담도 늘어남

컨테이너 실행 후 내부에서 직접 환경 구성 등을 통해 베이스 이미지를 생성하는 작업

베이스 이미지를 만들기는 했지만 매번 아파치 서비스를 수동으로 시작해야 된다면 서버에 설치해서 사용하는 것과 다르지 않음
해결 방법은 생성한 베이스 이미지가 컨테이너로 실행될 때 자동으로 서비스를 시작하게 하는 것으로 이를 위해서 Dockerfile 의 CMC 를 활용
인프라 구성 정보를 코드로 관리해 두면 애플리케이션 개발 시 버전 관리 차원의 소스 코드 관리가 가능해져 변경 이력을 관리할 수 있음
소스 코드를 통해 전체 구성을 한눈에 파악할 수 있고, 사용자 의존성을 배제할 수 있는 것이 인프라 구성을 코드로 관리하는 것이 Dockerfile 을 사용하는 이유

이미지 빌드 과정

이미지 빌드가 필요한 이유

도커 허브로부터 다운로드 한 이미지는 불변
빌드가 완료된 이미지는 그 내용을 수정할 수 없기 때문에 이미지로부터 컨테이너를 생성하여 변경 사항을 추가하고 다시 docker commit 명령을 통해 새로운 이미지를 생성하는 방법으로 변경할 수 있지만, 이 작업은 변경 사항을 추가하여 새로운 이미지를 만드는 것이지 기존 이미지를 수정한 것은 아님
필요한 애플리케이션을 컨테이너로 서비스 하려면 이미지가 필요한데, 만족할 만한 이미지를 도커 허브가 모두 보유하고 있는 것은 아니기 때문에 애플리케이션 요구사항을 만족할 수 있는 인프라 환경을 직접 구성하려면 서비스에 필요한 인프라 설계 요구서와 여러 환경 변수 등을 고려한 작업 시트를 작성하여 Dockerfile 을 생성해야 함

Dockerfile 작성 Life Cycle

Dockerfile 은 인프라 구성을 위해 필요한 명령을 담은 일반 텍스트 문서
Dockerfile 은 docker build 명령을 통해 작성한 명령을 순서대로 읽으며 자동으로 이미지를 빌드
이때 주의할 점은 빌드는 사용자와의 대화식 처리가 아닌 자동화된 빌드라는 것
자동화된 빌드
- Dockefile 작성
- 이미지 빌드
- 이미지 빌드 에러
- 자동화된 빌드
- Dockerfile 수정
- 이미지 빌드
- 이미지 빌드 에러
- Dockerfile 수정
- 이미지 빌드
- 이미지 빌드 성공
docker build를 실행하는 현재 작업 중인 디렉토리를 빌드 컨텍스트라고 부르는데, Dockerfile 은 새로운 빈 디렉토리에서 생성하여 빌드하는 것을 권장
이미지 빌드가 시작되면 Dockerfile 위치와 상관없이 현재 디렉토리에 있는 모든 파일과 디렉토리의 컨텐츠는 Docker 데몬에 빌드 컨텍스트로 전달
이때 현재 디렉토리에 있는 파일과 디렉토리 중 빌드 컨텍스트에서 제외 대상이 있다면 .dockerignore 파일에 작성
이미지 빌드도 문법적 오류나 오타가 포함되면 빌드 과정에서 에러가 출력되는데 Docker 데몬은 Dockerfile 빌드를 시작하면 Dockerfile에 포함된 모든 내용을 읽어와 유효성 검사를 수행하여 오류를 내보냄
-f 옵션으로 현재 디렉토리가 아닌 다른 경로 지정 가능
Docker 이미지는 Dockerfile 의 명령어 단위로 실행할 때마다 읽기 전용 레이어를 생성하여 최종 이미지로 생성
docker build 는 빌드 속도 향상을 위해 실행 중간에 있는 이미지 캐시를 사용
기본적으로 첫 번째 빌드 과정에서 단계별로 캐시를 생성하고 이 빌드 캐시는 동일한 이미지 작업으로 제한
빌드 과정에서 캐시를 사용하지 않는 경우 --no-cache 를 지정하여 빌드
다른 이미지로부터 만들어진 빌드 캐시를 사용해 빌드하려면 --cache-from 옵션을 통해 수행할 수 있음
Buildkit 기능
- 빌드 과정을 병렬 처리하여 더 빠른 빌드를 제공
- 사용되지 않는 빌드 단계를 찾아 비활성화
- 비밀번호 등의 민감한 데이터가 포함되는 경우 secret 구축이 가능
- 빌드 중 빌드 정보에 따라 변경된 파일만 전송
- 자동 빌드 시 빌드 캐시의 우선 순위를 정할 수 있음

Application Image

ADD 명령어의 자동 압축 해제 기능 활용

# 웹 소스 코드 다운로드
git clone https://github.com/brayanlee/webapp.git

# 디렉토리 이동
cd webapp

# 디렉토리 생성 및 이동
mkdir dockerfiles

# dockerfiles 디렉토리에 Dockerfile 작성

# 이미지 빌드
docker build -t webapp:5.0 -f ./dockerfiles/Dockerfile

# 실행
docker run -dit -p 8008:80 --name=webapp5 webapp:5.0

# 확인
curl http://localhost:8008

이미지 용량 절감

apt 를 이용한 패키지 업데이트와 설치 시 남게 되는 캐시를 제거하여 생성되는 이미지의 용량이 감소됨을 확인
캐시 삭제 관련 명령
- apt clean
  - 설치에 사용한 패키지 라이브러리, 임시 파일, 오래된 파일을 삭제하는데 autoclean 을 사용하면 더 이상 설치되어 있지 않은 패키지들의 .deb 까지 삭제
- apt autoremove
  - 다른 패키지들의 종속성을 충족시키기 위해 자동으로 설치된 패키지를 삭제
- rm -rfv /tmp/* /var/lib/apt/lists/* /var/tmp/*
  - apt 와 연관된 캐시 파일을 모두 삭제하는데 이미지의 시스템 소프트웨어를 다시 업데이트할 계획이 있다면 삭제하지 않는 것이 좋음

다단계 빌드

빌드를 여러 단계로 나누어 빌드하는 것
각 빌드 단계는 FROM 명령어로 시작되며 필요한 경우 빌드 단계에서 AS 파라미터를 이용해 이름을 붙일 수 있음
빌드가 여러 단계로 나뉘어 있다고는 하지만 최종 산출물은 마지막 단계의 내용물을 담은 도커 이미지
각 빌드 단계는 독립적으로 실행되지만 앞선 단계에서 만들어진 디렉터리나 파일을 복사할 수 있음
멀티 스테이지 Dockerfile 스크립트를 통해 빌드 과정을 세밀하게 조정하며 최종 산출물인 이미지를 가능한 작게 유지할 수 있음
비단 컴파일러에만 국한된 내용은 아님
어떤 도구든지 그 도구가 사용되는 단계만으로 도구의 포함 여부를 국한시킬 수 있음
최종 산출물인 이미지에 불필요한 도구는 빼버릴 수 있는 것

이미지 크기 최소화 (Lightweight)

이미지가 무거우면 배포 속도가 느려지고 저장 공간을 많이 차지함
경량 베이스 이미지 사용
레이어 수 줄이기
- Dockerfile 명령어의 수와 도커 이미지 레이어 수는 동일한데 레이어 수가 많을수록 이미지를 생성하는 빌드 시간은 길어질 것이고 파일 용량도 커짐
- RUN 명령어를 여러 번 쓰기보다 && 를 사용해 하나로 합치면 이미지 레이어 수가 줄어 용량이 최적화됨
불필요한 파일 삭제
- 패키지 설치 후 캐시 파일 등을 즉시 삭제

빌드 캐시(Build Cache) 활용

도커는 빌드 시 변경되지 않은 레이어를 재사용하므로 이 효율을 극대화
순서가 중요
- 자주 바뀌는 소스 코드 복사는 뒷부분에, 잘 바뀌지 않는 의존성 설치는 앞부분에 배치
- .dockerignore 파일 작성
  - .git, 로그 파일, 로컬 노드 모듈 등 빌드에 필요 없는 파일 이미지에 포함되지 않도록 설정

보안 및 관리 설정

Root 계정 사용 지양
- 보안을 위해 USER 명령어를 사용하여 별도의 일반 사용자 계정으로 프로세스를 실행하는 것이 안전
명확한 태그 사용
- latest 태그는 버전 관리가 어려우므로 명확한 버전 태그를 지정
Multi-stage Build
- 빌드 도구(컴파일러 등)는 빌드 단계에서만 쓰고 최종 이미지에는 실행 파일만 남겨 보안과 용량을 동시에 최적화

도커의 철학: 하나의 애플리케이션은 하나의 컨테이너에

하나의 컨테이너에 2개 이상의 애플리케이션을 설정하게 되면 애플리케이션의 결합성이 높고 확장성을 저해
하나의 컨테이너에 하나의 애플리케이션 동작은 컨테이너 간의 독립성을 보장함과 동시에 애플리케이션 버전 관리, 소스 코드 모듈화 등에서 이점이 있음
모놀리식 구성보다는 decouple applications 설계나 마이크로서비스 지향적 설계를 고려해야 장애가 발생해도 애플리케이션 자체가 유지될 수 있음

IaC 환경 개발은 디렉터리 단위로

Dockerfile로 이미지 빌드 시 현재 위치로부터 하위 경로의 모든 디렉터리와 파일을 도커 컨텍스트context에 저장한 뒤 작업이 진행하는데 이를 빌드 컨텍스트라고 하는데 이미지 빌드와 상관없는 파일이 포함되지 않도록 별도의 디렉터리를 생성한 뒤 독립된 환경에서 빌드가 이루어져야 빌드 성능에 도움이 됨

서버리스 환경으로 개발

Dockerfile 을 통해 미리 설정된 환경을 서버리스 애플리케이션 환경이라고 하고 이러한 환경은 사용자가 서버를 프로비저닝, 확장 및 관리할 필요가 없음

Docker Compose

분산 애플리케이션을 기준으로 보면 Dockerfile은 애플리케이션의 한 부분을 패키징 하는 수단
공통의 목적을 갖는 애플리케이션 스택을 yaml 코드로 정의해서 한 번에 서비스를 올리고 관리할 수 있는 도구가 docker compose
docker compose 파일은 애플리케이션의 원하는 상태 즉, 모든 컴포넌트가 실행 중일 때 어떤 상태여야 하는지를 기술하는 파일
docker container run 명령으로 컨테이너를 실행할 때 지정하는 모든 옵션을 한데 모아 놓은 형식의 파일
docker compose 가 컨테이너, 네트워크, 볼륨 등 필요한 모든 docker 객체를 만들도록 docker API 에 명령을 내림

docker-compose

docker-compose 로 실행된 컨테이너는 독립된 기능을 가지며 공통 네트워크로 구성되기 때문에 컨테이너 간 통신이 쉬움
- 하나의 네트워크로 묶을 수 있기 때문에 불필요하게 외부로 노출시킬 필요가 없음
docker-compose 는 테스트, 개발, 운영의 모든 환경에서 구성이 가능한 오케스트레이션 도구 중 하나이지만 다양한 관리 가능을 갖고 있지 않기 때문에 테스트와 개발환경에 적합함 → 운영은 제외!
실제 운영 환경은 많은 관리적 요소가 필요하기 때문에 도커 스웜이나 쿠버네티스와 같은 오케스트레이션 도구가 가지고 있는 자동 확장, 모니터링, 복구 등의 운영에 필요한 기능과 함께 사용하는 것을 권장
docker-compose 로 실행되는 컨테이너는 독립된 기능을 가지며, 공통 네트워크로 구성되기 때문에 컨테이너 간 통신이 쉽고 빠른 런타임 환경을 제공

yaml 포맷으로 기술된 설정 파일을 이용해서 여러 컨테이너 간의 실행이나 관계를 설정
시스템을 일괄 실행 또는 일괄 종료 및 삭제할 수 있는 도구
컨테이너나 볼륨을 어떠한 설정으로 만들지에 대한 항목이 기재돼 있는데, 작성 내용은 docker 명령어와 비슷하지만 docker 명령어는 아님

developowl

Don’t get mad at the computer.

이전 포스트

[부트캠프 - 32일차] 2/4.수 - Docker

다음 포스트

[부트캠프 - 34일차] 2/6.금 - Docker

부트캠프

Dockerfile

Dockerfile

코드형 인프라 (Infrastructure as Code, IaC)

Dockerfile

Dockerfile을 사용했을 때의 장점

최적의 Dockerfile

Dockerfile 작성 명령어

FROM

MAINTAINER

LABEL

RUN

CMD

ENTRYPOINT

COPY

ADD

ENV

EXPOSE

VOLUME

USER

WORKDIR

ARG

ONBUILD

STOPSIGNAL

SHELL

HEALTHCHECK

Dockerfile 명령어 작성 방법

Dockerfile 스크립트로 이미지 생성

이미지 생성 명령

Dockerfile 이 필요한 이유

우분투에서 PHP 웹 페이지 연동

컨테이너 실행 후 내부에서 직접 환경 구성 등을 통해 베이스 이미지를 생성하는 작업

이미지 빌드 과정

이미지 빌드가 필요한 이유

Dockerfile 작성 Life Cycle

Application Image

ADD 명령어의 자동 압축 해제 기능 활용

이미지 용량 절감

다단계 빌드

이미지 크기 최소화 (Lightweight)

빌드 캐시(Build Cache) 활용

보안 및 관리 설정

도커의 철학: 하나의 애플리케이션은 하나의 컨테이너에

IaC 환경 개발은 디렉터리 단위로

서버리스 환경으로 개발

Docker Compose

docker-compose

[부트캠프 - 32일차] 2/4.수 - Docker

[부트캠프 - 35일차] 2/9.월 - Docker

0개의 댓글