도커 교과서 4장 애플리케이션 소스 코드에서 도커 이미지 까지

4. 애플리케이션 소스 코드에서 도커 이미지 까지

4.1 Dockerfile 이 있는데 빌드 서버가 필요할까?

• 팀 단위의 작업이 진행될 경우 빌드 도구 통일이 필요하다.
• 해당 작업은 유지 보수를 위한 큰 오버헤드가 발생한다.
• 그러나, Dockerfile 로 빌드 툴 체인을 한 번에 패키징해서 공유해서 사용한다면 유지 보수 비용이 대폭 감소하게 된다.

FROM diamol/base AS build-stage
RUN echo 'Building...' > /build.txt

FROM diamol/base AS test-stage
COPY --from=build-stage /build.txt /build.txt
RUN echo 'Testing...' >> /build.txt

FROM diamol/base
COPY --from=test-stage /build.txt /build.txt
CMD cat /build.txt

• 각 빌드 단계는 서로 격리돼 있다.
• 빌드 단계별로 기반 이미지도 다를 수 있으므로 사용할 수 있는 도구도 달라진다.
• 마지막 빌드 단계의 산출물은 이전 비드 단계에서 명시적으로 복사해 온 것만 포함할 수 있다.
• 한 단계라도 명령이 실패하면 전체 빌드가 실패한다.

$ docker image build -t multi-stage .
[+] Building 4.0s (9/9) FINISHED                                                                                                                                                             docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                                   0.0s
 => => transferring dockerfile: 566B                                                                                                                                                                   0.0s
 => WARN: DuplicateStageName: Duplicate stage name "test-stage", stage names should be unique (line 13)                                                                                                0.0s
 => [internal] load metadata for docker.io/diamol/base:latest                                                                                                                                          3.4s
 => [internal] load .dockerignore                                                                                                                                                                      0.0s
 => => transferring context: 2B                                                                                                                                                                        0.0s
 => [build-stage 1/2] FROM docker.io/diamol/base:latest@sha256:787fe221a14f46b55e224ea0436aca77d345c3ded400aaf6cd40125e247f35c7                                                                        0.0s
 => => resolve docker.io/diamol/base:latest@sha256:787fe221a14f46b55e224ea0436aca77d345c3ded400aaf6cd40125e247f35c7                                                                                    0.0s
 => => sha256:787fe221a14f46b55e224ea0436aca77d345c3ded400aaf6cd40125e247f35c7 1.40kB / 1.40kB                                                                                                         0.0s
 => => sha256:bd5e8ce69bca67190f789625870f8130d67069c4761b36ed7ecfa6dcbc6fdfd7 738B / 738B                                                                                                             0.0s
 => => sha256:e65ed3e91e579a862befe0d866ffe1e3377d64245c9e9fd82fffaf9e3c961f49 1.65kB / 1.65kB                                                                                                         0.0s
 => [build-stage 2/2] RUN echo 'Building...' > /build.txt                                                                                                                                              0.2s
 => [test-stage 2/3] COPY --from=build-stage /build.txt /build.txt                                                                                                                                     0.0s
 => [test-stage 3/3] RUN echo 'Testing...' >> /build.txt                                                                                                                                               0.1s
 => [stage-4 2/2] COPY --from=test-stage /build.txt /build.txt                                                                                                                                         0.0s
 => exporting to image                                                                                                                                                                                 0.0s
 => => exporting layers                                                                                                                                                                                0.0s
 => => writing image sha256:499c256287f9fa71674b34f0a2d3ea3b25af235104c75c473091ec53fca12b59                                                                                                           0.0s
 => => naming to docker.io/library/multi-stage                                                                                                                                                         0.0s

 2 warnings found (use docker --debug to expand):
 - DuplicateStageName: Duplicate stage name "test-stage", stage names should be unique (line 13)
 - JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals (line 19)

• 1단계. 의존 빌드 모듈을 내려받고 애플리케이션을 빌드한다.
• 2단계. 빌드 결과물을 복사한 후 테스트를 진행한다.
• 3단계. 테스트가 끝난 빌드 결과물을 복사한다.
• 이런 방법으로 애플리케이션의 진정한 이식성을 확보할 수 있다.
• 도커 이미지를 이용해 어떤 환경에서든 빌드 도구를 중앙 집중적으로 관리할 수 있다.
• 또한, 도커 허브를 통해 주요 애플리케이션의 빌드 도구가 포함된 이미지들이 있어. 해당 이미지를 사용하며 최신화 및 관리가 가능하다.

4.2 애플리케이션 빌드 실전 예제: 자바 소스 코드

# maven, OpenJDK 기반 이미지
FROM diamol/maven AS builder

# pom.xmnl 복사
WORKDIR /usr/src/iotd
COPY pom.xml .
# 필요한 의존성 다운로드
RUN mvn -B dependency:go-offline

# 나머지 소스코드 복사. 
# 도커 빌드가 실행 중인 디렉터리에 포함된 모든 파일과 서브 디렉터리를 현재 이미 내 작업 디렉토리로 복사
COPY . .
# 빌드 패키징
RUN mvn package

FROM diamol/openjdk

# 작업 디렉토리 생성
WORKDIR /app
# 작업 디렉토리에 빌드를 통해 나온 jar 파일 복사
COPY --from=builder /usr/src/iotd/target/iotd-service-0.1.0.jar .

# 80 포트 외부로 공개
EXPOSE 80
# jar 파일 실행
ENTRYPOINT ["java", "-jar", "/app/iotd-service-0.1.0.jar"]

$ docker build -t image-of-the-day .

$ docker network create nat

$ docker container run --name iotd -d -p 8080:80 --network nat image-of-the-day

• 최종적으로 생성되는 애플리케이션 이미지에 빌드 도구는 포함되지 안흔다.
• 애플리케이션 이미지에는 도커 파일에 정의된 빌드 단계 중 마지막 단계의 컨텐츠만 포함된다.
• 즉, 포함시키고 싶은 컨텐츠가 있다면 최종 단계에서 명시적을 콘텐츠를 복사해 와야 한다.

4.3 애플리케이션 빌드 실전 예제: Node.js 소스 코드

• Node.js 는 Java 의 컴파일 언어와는 다른 인터프리터형 언어로 별도의 컴파일 절차가 필요 없다.
• 컨테이너화된 Node.js 애플리케이션을 실행하려면 Node.js 런타임과 소스 코드가 애플리케이션 이미지에 포함되어야 한다.

FROM diamol/node AS builder

# 의존성이 정의된 package.json 파일 복사
WORKDIR /src
COPY sr/package.json .

# 의존성 다운로드
RUN npm install

#app
FROM diamol/node

EXPOSE 80
CMD ["node", "server.js"]

WORKDIR /app
# 호스트의 애플리케이션 아티팩트 모두 복사
COPY --from=builder /src/node_modules/ /app/node_modules/
COPY src/ .

• 위와 같이 정의하여 사용할 경우 의존성 모듈은 도커 이미지 레이어 캐시에 저장된다.
• 따라서, 별도의 의존 모듈 추가가 없을 경우 다음 번 빌드는 매우 빠르게 진행된다.

4.4 애플리케이션 빌드 실전 예제: Go 소스 코드

• Go 는 네이티브 바이너리로 컴파일되는 현대적인 크로스 플랫폼 언어다.
• 즉, 어떤 플랫폼(윈도우, 리눅스, amd64, ARM) 이든 해당 플랫폼에 맞는 바이너리를 컴파일 할 수 있다.
• 또한, 별도의 런타임이 필요없어 도커 이미지 크기가 매우 작아진다.
• Docker 또한 Go 언어로 구현되었다.

FROM diamol/golang AS builder

COPY main.go .
# 의존성 없이 바로 빌드
RUN go build -o /server

# app
FROM diamol/base

# 환경변수 설정
ENV IMAGE_API_URL="<http://iotd/image>" \\
		ACCESS_API_URL="<http://accesslog/access-log>"
CMD ["/web/server"]

WORKDIR web
COPY index.html .
COPY --from=builder /server .
RUN chmod +x server

$ docker image ls -f reference=diamol/golang -f reference=image-gallery
REPOSITORY      TAG       IMAGE ID       CREATED          SIZE
image-gallery   latest    412cedb50233   27 seconds ago   26.2MB
diamol/golang     latest    e0b7365f308e    2  hours   ago   803MB

• 위의 명령어를 통해 베이스 이미지의 선택이 얼마나 중요한지를 알 수 있다.
• 리눅스 환경 + 빌드 도구 포함된 이미지는 약 800MB 이지만, 도커 애플리케이션만 있는 이미지는 약 26MB 정도이다.
• Go 애플리케이션은 실행 시 별도의 빌드 도구가 필요하지 않으므로 위와 같이 이미지의 크기를 최소화 해서 Docker 의 특장점인 경량화를 살릴 수 있다.

4.5 멀티 스테이지 Dockerfile 스크립트 이해하기

• 멀티 스테이지 Dockerfile 스크립트의 동작 원리와 컨테이너 안에서 애플리케이션 빌드하는 것에 대한 이점

A. 표준화

• 개인의 운영체제 환경과 개인 로컬의 빌드 도구에 대한 제약이 없다.
• 모든 빌드 과정이 도커 컨테이너 내부에서 이뤄지기 때문이다.
• 도커 내부의 빌드 도구를 사용하기 때문에 표준화된 관리가 가능하다.
• 이는 서버 관리 및 개인 개발자 도구 버전 차이로 인한 빌드 실패 문제를 크게 줄일 수 있다.

B. 성능 향상

• 멀티 스테이지 빌드의 각 단계는 자신만의 캐시를 따로 갖는다.
• 도커는 빌드 중에 각 인스트럭션에 해당하는 캐시를 찾는다.
• Dockerfile 스크립트를 최적화 한다면 캐시 재사용을 통해 90% 이상의 빌드 단계에서 시간을 절약할 수 있다.

C. 작은 이미지

• 멀티 스테이지 Dockerfile 스크립트를 통해 최종 이미지의 크기를 가능한 작게 유지할 수 있다.
• 최적화 과정을 통해 실행에 필요한 도구만을 포함시킴으로써 최종 이미지는 가벼워지고, 모듈의 의존성이 작아지며 의존성에 대한 위험성 또한 작아진다.

4.6 연습문제

• Go 언어 멀티 스테이지 Dockerfil 를 수정하여 Linux 환경 이미지는 약 15MB, 윈도우 환경 이미지는 약 260MB 가 되도록 만들기.
• HTML 파일을 수정해도 재빌드 시 빌드 단계가 한 단계가 되도록 수정하기.

문제 Dockerfile 스크립트

FROM diamol/golang 

WORKDIR web
COPY index.html .
COPY main.go .

RUN go build -o /web/server
RUN chmod +x /web/server

CMD ["/web/server"]
ENV USER=sixeyed
EXPOSE 80

• 싱글 스테이지 빌드 → 멀티 스테이지 빌드로 변경.
• diamol/golang 의 경우 빌드에 필요한 빌드 도구를 가지고 있는 이미지 파일
• Go 언어의 경우 실행 시 빌드 도구가 필요 없으므로 diamol/base 이미지로 변경

나의 풀이

FROM diamol/golang AS builder

COPY main.go .
RUN go build -o /web/server

# app
FROM diamol/base

WORKDIR /web

ENV USER=sixeyed

EXPOSE 80
CMD ["./server"]

COPY index.html .
COPY --from=builder /web/server ./server

RUN chmod +x ./server

$ docker image build -t ch04-lab .

$ docker image ls
REPOSITORY                    TAG        IMAGE ID       CREATED              SIZE
ch04-lab                      latest     a21288fc2013   About a minute ago   25.9MB

정답

FROM diamol/golang AS builder

COPY main.go .
RUN go build -o /server
RUN chmod +x /server

# app
FROM diamol/base

EXPOSE 80
CMD ["/web/server"]
ENV USER="sixeyed"

WORKDIR web
COPY --from=builder /server .
COPY index.html .

• chmod 권한 명령의 경우에도 builder 로 옮겼으면 정말 근접했을 듯.