4. 이미지빌드

이미지빌드란?

 

이미지가 어떻게 저장되는지, 이미지를 효율적으로 저장하는 레이어드 구조

이미지를 만드는 방법: 커밋, 빌드

• 빌드를 하기 위해서 도커 파일이라는 명세서 작성
• 더 효율적인 이미지 빌드 방식: 멀티 스테이징 방식

 

1. 이미지와 레이어

이미지는 컨테이너 실행 위한 읽기 전용 파일이며, 도커 이미지는 레이어드 파일 시스템으로 구성된다.

레이어란 여러개의 층으로 구성된 것 중 하나의 층으로, 레이어드 구조는 재사용하기 좋은 구조이다.

이 레이어들이 모여서 하나의 이미지로 구성되는 것이다. 즉, 각 레이어는 이미지의 일부분이다.

 

• 왜 하나의 이미지를 여러 레이어로 구성할까?
  • -> 공간을 효율적으로 사용할 수 있어 이미지 저장&전송 시 스토리지와 네트워크 사용량을 절약할 수 있다.

 

건축도면을 생각하자

투명한 도면을 여러 장 준비하여 각 주제별로 한장씩 그려 이 용지들을 합치면 하나의 건물에 대한 설계도가 완성된다.

전기 부분에 변경사항이 있다면 재활용이 유리한 구조이다. 도면 전체를 변경하는 것이 아니라 전기 관련 도면만 변경하면 된다.

또한 설계도 A와 B가 전기 부분만 다르다고 하였을 때, 겹치는 나머지 레이어는 재사용할 수 있다.

즉, 레이어드 구조이면 나머지 겹치는 구조를 재사용 가능하다.

이미지 레이어는 직전 단계 레이어의 변경 사항만 저장된다.

 

위의 그림처럼 서버에 간단한 페이지를 출력하는 Nginx를 설치한다고 생각해보자.

먼저 OS를 설치하고 Nginx 소프트웨어를 설치한다. 이때, OS의 특정 폴더에 Nginx 소프트웨어 관련된 파일들이 추가되고 이렇게 기존 레이어에서 변경되는 것들은 기존 레이어를 수정하는 것이 아니라 기존 레이어 위에 변경된 내용들이 새로운 레이어로 저장된다. 

그래서 기존 OS 파일시스템에 Nginx소프트웨어가 추가된 부분만 따로 가지고 있고,  이전 레이어와 비교해서 추가되거나 변경된 부분만 다음 레이어로 저장된다.

이미지에서 한 번 저장된 레이어는 변경불가, 변경사항 있을 시 새로운 레이어로 저장해야 한다.

 

• 이번에는 index.html까지 이미지 A를 완성 하였는데, 이미지 B를 새로만든다고 해보자, 전체 과정은 똑같고, 마지막 단계에서 index.html을 변경하는 것이다.
• 이때 그전 단계까지는 동일하게 설정하면 같은 레이어를 재사용하게 된다.
• 마지막 index.html 레이어만 새롭게 추가하여 이미지 B가 완성된다.

 

정리하면 이미지 레이어는 순차적으로 쌓이고, 각 레이어는 이전 레이어에서 변경된 부분을 저장하고 있다.

같은 변경이 일어난 레이어는 공유해서 재사용 가능하다.

이미지 레이어는 이전 파일에서 변경된 사항을 저장하기에 구성 순서가 다르면 완전히 다른 레이어로 구성되는 것이다.

Docker run 명령으로 컨테이너를 실행하면 이미지의 가장 마지막 레이어 위에서 새로운 읽기/쓰기 가능 레이어가 추가된다. 이 추가된 레이어가 컨테이너 레이어이다.

애플리케이션에서 로그가 쌓이거나 컨테이너가 실행 중에 생기는 모든 변경사항이 이 새로운 레이어에 저장된다.

 

이미지 레이어와 컨테이너 레이어의 역할은 완전히 다르다.

• 이미지 레이어(읽기전용): 컨테이너를 실행하기 위한 save point 역할
• 컨테이너 레이어(읽기, 쓰기): 실제로 이 이미지를 컨테이너로 실행한 다음에 프로세스가 변경하는 내용을 기록하는 레이어

컨테이너 레이어 한장이 이미지 레이어 상단에 추가되어 컨테이너 실행 중에 변경되는 내용만 기록한다. 이미지 A로 두번째 컨테이너인 컨테이너2를 실행하면 컨테이너2에 읽기 쓰기 레이어가 생성된다.

Container1, 2는 이미지가 같기에 동일한 읽기 전용 레이어를 공유하게 된다.

따라서 컨테이너 실행 시 전체 레이어를 복사하는 것이 아니라 이미지 위에 새로운 컨테이너 레이어만 하나씩 추가

 

정리하면 모든 컨테이너는 각자 자기만의 읽기 쓰기 레이어 한장을 가지고, 컨테이너 만들 때 사용된 이미지에 따라 이미지의 읽기 전용 레이어 전체 or 일부를 공유 할 수 있다.

장점: 이미지의 읽기 전용 레이어를 활용하면 컨테이너 실행 시 전체 공간 복사하지 않아도 되기에 컨테이너 빠르게 실행하고, 컨테이너가 늘어나면서 사용하는 공간을 작게 관리할 수 있다.

이미지 레이어는 이전 파일에 서 변경된 사항을 저장하기에 구성 순서가 다르면 완전히 다른 레이어로 구성되는 것이다.

 

• 레이어링: 각 레이어는 이전 레이어 위에 쌓이며, 여러 이미지 간 공유될 수 있다. 레이어 방식은 중복 데이터를 최소화하고, 빌드 속도를 높이며, 저장소를 효율적으로 사용 가능
• Copy-on-Write: 다음 레이어에서 이전 레이어 수정 시, 해당 파일의 복사본을 만들어서 변경 사항을 적용, 변경된 모든 것들은 컨테이너 레이어에 저장됨. 이미지 레이어를 copy해서, 컨테이너 레이어에서 write함
• 불변 레이어: 이미지의 각 레이어는 불변 -> 이미지의 일관성 유지
• 캐싱: 레이어 캐시를 통해, 이미 빌드된 레이어 재사용 가능

 

2. 이미지 커밋

이미지를 만드는 2가지 방식

• 커밋: 현재 컨테이너의 상태를 기반으로 수동으로 커밋하여 이미지로 저장
• 빌드: Dockerfile을 이용해 여러 단계의 변경 사항을 자동으로 커밋하면서 이미지를 생성하는 방식

 

커밋을 통해 컨테이너의 상태를 이미지로 저장, 빌드 또한 커밋을 응용한 방식

지금까지는 이미지에서 컨테이너로 실행만 했고, 이번에는 커밋으로 컨테이너의 상태를 이미지로 저장

 

docker commit <컨테이너_ID> <새로운_이미지이름>:<태그>

# 컨테이너 실행과 동시에 터미널 접속, 이미지 내부의 파일 시스템을 확인하거나 디버깅하는 용도
docker run -it --name my_container ubuntu bin/bash
# 실행 중인 컨테이너를 이미지로 생성
docker commit -m "패키지 업데이트 완료" my_container my_custom_image:v1

 

 

3. 이미지 빌드

 

IaC: 인프라를 코드를 통해서 관리

이미지 빌드: IaC 방법을 활용하여 코드로 이미지를 관리하는 방식

사람이 직접 인프라를 컨트롤 -> 실수 가능 -> DOckerfile이라는 소스코드를 사용하여 인프라 상태를 저장하는 이미지를 만들어 사용

 

• 커밋의 경우
  • 이미지를 만들 때마다 컨테이너를 실행해야 되고 사용자가 명령어를 직접 입력, 커밋 하나당 이미지의 레이어가 하나가 추가되기 때문에 여러 개의 레이어를 추가하고 싶을 때는 여러 번의 커밋이 필요
• 빌드의 경우
  • 이미지 제작자가 도커가 이해할 수 있는 문법에 따라서 도커 파일을 작성하면 도커는 임시로 컨테이너를 실행하고 사용자가 정의한 작업을 수행한 뒤에 커밋을 실행. -> 여러 개의 레이어도 쉽게 추가가능

 

빌드를 통해 레이어를 한 장 추가한 다음에 다시 그 레이어로 만든 이미지를 컨테이너로 만들고 그 컨테이너 위에서 변경 작업을 한 다음에 추가로 커밋하는 것을 도커가 알아서 반복

docker build -t 이미지명 Dockerfile경로 : 도커파일을 통해 이미지 빌드

# Dockerfile
FROM 이미지명 : 베이스 이미지(시작점)를 지정
COPY 파일경로 복사할경로 : 파일을 레이어에 복사
CMD ["명령어"] : 컨테이너 실행 시 명령어 지정

FROM nginx:1.23
COPY index.html /usr/share/nginx/html/index.html
CMD ["nginx", "-g", "daemon off;"]

# 1. 현재 경로에서 Dockerfile 기반으로 이미지 빌드  
docker build -t 레지스트리계정명/buildnginx .

# 2. 컨테이너 실행 
docker run -d -p 80:80 --name build-nginx 레지스트리계정명/buildnginx

정리하면 도커는 IaC 방식에 따라서 이미지를 도커 파일이라는 소스 코드로 관리하고 이는 코드이기 때문에 애플리케이션 소스 코드와도 함께 관리할 수 있고 버전 관리 가능 , 도커 파일에는 이미지를 어떻게 만드는지에 대한 내용있어서 도커가 이를 해석해서 이미지 제작한다.

커밋은 사용자가 직접 새로운 이미지를 만드는 방법, 빌드는 도커 데몬이 도커 파일에 적힌 지시어를 사용해서 이미지를 자동으로 만들어주는 방법

하나의 커밋은 기존 레이어에 새로운 레이어를 추가하기에, 커밋 완료한 이미지를 새로운 컨테이너로 만들고 다시 커밋을 해야하지만, 도커파일로 이 작업들을 자동으로 해결 가능

 

빌드 컨텍스트

 

빌드 컨텍스트란?

• 도커 이미지 빌드에 필요한 파일과 Dockerfile이 포함된 폴더
• docker build 실행 시, 해당 폴더 전체가 Docker 데몬에 전달됨
• 일반적으로 . (현재 디렉토리)를 사용하여 빌드 컨텍스트 지정

docker build -t my-image .

➡️ 현재 폴더(.)를 빌드 컨텍스트로 사용하여 이미지 빌드

 

.dockerignore 파일이란?

• 빌드 컨텍스트에서 제외할 파일 및 폴더를 지정
• 불필요한 파일을 제외하여 빌드 속도를 최적화하고, 이미지 크기 최소화 가능

 

빌드 컨텍스트를 적절히 관리하는 이유

• ✅ 빌드 속도 최적화 → 불필요한 파일을 제외하면 Docker 데몬에 전달되는 데이터가 줄어들어 빌드 시간이 단축됨
• ✅ 이미지 크기 최소화 → 불필요한 파일이 포함되지 않아 불필요한 레이어가 생성되지 않음
• ✅ 보안 강화 → .git, .env 등 민감한 파일이 이미지에 포함되지 않도록 방지

 

멀티스테이지 빌드

 

• 정의: 도커 파일에서 여러 개의 베이스 이미지를 사용하여 빌드와 실행 단계를 나누는 방법
• 목표: 이미지 빌드와 실행을 분리하여, 불필요한 빌드 환경을 최종 이미지에 포함하지 않고 최소화된 실행 환경만을 포함하도록 만드는 방법
• 장점
  • 이미지 크기 최적화: 빌드 환경을 포함하지 않기 때문에 최종 이미지 크기가 작아짐
  • 불필요한 파일 제외: 빌드 도구와 환경이 최종 이미지에서 제외되므로 보안과 성능이 개선됨
  • 효율적인 빌드: 빌드 환경은 임시로 사용되며, 실제 애플리케이션 실행에 필요한 파일만 포함되므로 빌드와 실행을 분리

 

멀티스테이지 빌드 과정

1. 빌드 스테이지 (Build Stage)
   • 애플리케이션을 빌드하는 데 필요한 환경 준비
2. 2. 실행 스테이지 (Run Stage)
   • 실제 실행에 필요한 환경만을 준비하고 빌드된 파일을 실행

 

멀티스테이지 vs 싱글 스테이지

 

• 싱글 스테이지 빌드
  • 하나의 베이스 이미지를 사용하여 빌드와 실행을 모두 포함
  • 빌드 환경과 실행 파일이 모두 포함된 이미지를 생성
•  멀티스테이지 빌드
  • 빌드 스테이지와 실행 스테이지를 분리하여 최종 이미지에서 불필요한 빌드 환경을 제외
  • 실행 파일만 포함된 최적화된 이미지가 생성