Docker Imageの最適化：Multi-stage Buildを活用したサイズ削減とセキュリティ強化ガイド – ITFROMZERO

Table of Contents

はじめに：Dockerイメージが「肥大化」したとき

Dockerを使い始めた頃、私は何でもかんでも一つのDockerfileに詰め込めば良いと思っていました。コンパイラ、開発ライブラリ、デバッグツールなど、あらゆるものを一つのイメージにインストールしていました。レジストリにイメージをプッシュした後、数百MB、時には数GBにもなるサイズを見て、冷や汗をかいたものです。その時になって初めて最適化の方法を探し始めました。Multi-stage Buildこそが私が見つけた「救世主」であり、本番環境に導入して6ヶ月以上経った今、その非常に有用性を実感しています。

Multi-stage Buildは、イメージサイズを大幅に削減するだけでなく、アプリケーションのセキュリティも強化します。この技術を使えば、ビルド環境（多くのツールが必要な場所）とランタイム環境（アプリケーションの実行のみが必要な場所）を分離できます。結果として、アプリケーションの実行に本当に必要なものだけを含む、軽量な最終イメージが作成されます。

Multi-stage Buildが必要な理由

イメージサイズの削減：これが最も顕著なメリットです。イメージが小さくなることで、プッシュ/プルプロセスが高速化され、ストレージ容量と帯域幅を大幅に節約できます。
セキュリティの強化：ビルドツール、不要なライブラリ、さらにはソースコードを最終イメージから削除することで、潜在的な攻撃対象領域を大幅に減らすことができます。
キャッシュの最適化：個別のステージにより、Dockerはキャッシュをより効果的に活用できるようになり、その後のビルド速度が向上します。
Dockerfileの簡素化：各ステップを明確に分離することで、Dockerfileが読みやすく、管理しやすくなります。

お待たせしました。それでは、Multi-stage Buildをすぐに適用する方法を解説します。

クイックスタート：5分でイメージを最適化

まず、具体的な例を見ていきましょう。Goは静的バイナリにコンパイルされるため、イメージサイズの明確な違いを示すのに非常に適しているため、シンプルなGoアプリケーションを使用します。

1. Goアプリケーションの準備

新しいディレクトリ（例：my_go_app）を作成し、以下の内容でmain.goファイルを作成します。

package main

import (
	"fmt"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "Hello from Multi-stage Docker Build!")
	})

	fmt.Println("Server starting on port 8080...")
	http.ListenAndServe(":8080", nil)
}

2. 従来のDockerfile（シングルステージ）

同じディレクトリにDockerfile.singleファイルを作成します。

# ビルドと実行のために完全なgolangイメージを使用
FROM golang:1.22

WORKDIR /app

# 全ソースコードをイメージにコピー
COPY . .

# go modを初期化（まだの場合）し、依存関係をダウンロード
RUN go mod init example.com/myapp || true
RUN go mod tidy

# アプリケーションをコンパイル
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/myapp .

# ポートを開放
EXPOSE 8080

# アプリケーションを実行
CMD ["/app/myapp"]

イメージをビルドしてサイズを確認します。

docker build -t my-go-app-single -f Dockerfile.single .
docker images | grep my-go-app-single

イメージサイズが数百MBにもなるなど、かなり大きいことがわかるでしょう。

3. Multi-stage Buildを使用したDockerfile

同じディレクトリにDockerfile.multiファイルを作成します。

# Stage 1: ビルド環境
FROM golang:1.22 AS builder

WORKDIR /app

COPY . .

RUN go mod init example.com/myapp || true
RUN go mod tidy

# アプリケーションをコンパイル
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/myapp .

# Stage 2: 軽量なランタイム環境
FROM alpine:latest

WORKDIR /app

# 'builder'ステージからコンパイル済みバイナリのみをコピー
COPY --from=builder /app/myapp .

EXPOSE 8080

CMD ["./myapp"]

イメージをビルドしてサイズを確認します。

docker build -t my-go-app-multi -f Dockerfile.multi .
docker images | grep my-go-app-multi

my-go-app-multiイメージのサイズが、わずか数MBと大幅に小さくなっていることがわかるでしょう！これこそがMulti-stage Buildの力です。

アプリケーションを実行するには：

docker run -p 8080:8080 my-go-app-multi

ブラウザを開き、http://localhost:8080にアクセスして確認してください。

詳細解説：Multi-stage Buildの仕組み

Multi-stage Buildは、1つのDockerfile内で複数のステージを定義することで機能します。各ステージはFROMコマンドで始まり、AS <ステージ名>で名前を付けることができます。重要な点は、前のステージから次のステージへ成果物（例：コンパイル済みファイル、設定）をコピーできることです。これを行うには、COPY --from=<ステージ名>コマンドを使用します。

重要なのは、最終ステージのみが完全なDockerイメージを作成するステージであるということです。他の中間ステージはビルドプロセス中にのみ存在し、最終イメージには保存されません。これにより、コンパイラ、SDK、開発ライブラリ、キャッシュなど、ランタイムには不要なすべてを削除できます。

Multi-stage Buildの基本構造

# Stage 1: ビルド
FROM some_build_image AS builder
WORKDIR /app
COPY . .
RUN build_command

# Stage 2: テスト（オプション）
FROM some_test_image AS tester
WORKDIR /app
COPY --from=builder /app/build_output .
RUN test_command

# Stage 3: 最終ランタイム
FROM some_runtime_image
WORKDIR /app
COPY --from=builder /app/build_output .
EXPOSE port
CMD ["./app"]

ご覧のように、複数の異なるステージを定義できます。testerステージはbuilderからの出力を取得してテストを実行できます。その後、最終ステージはbuilder（または適切であればtester）から必要なものだけを取得してランタイムイメージを作成します。

具体的なメリット

超小型イメージサイズ： Multi-stage Buildは、レジストリ上のストレージ容量を大幅に削減し、イメージのプル/プッシュ時間を短縮します。特にGo、Rust、C/C++アプリケーションでは、イメージサイズを数百MBから数MBにまで削減できます。
セキュリティの強化： 最終イメージには、アプリケーションと最小限のランタイムライブラリのみが含まれます。コンパイラ、開発ツール、元のソースコードは含まれません。これにより、潜在的な攻撃対象領域が減少し、悪意のある攻撃者が脆弱性を悪用したり、ソースコードを抽出したりすることがより困難になります。
Dockerfileの簡素化： 一見すると長くなるように見えますが、各ステージには明確な目的があります。これにより、Dockerfileははるかに読みやすく、保守しやすくなります。
効果的なキャッシュの活用： ソースコードのみが変更された場合でも、Dockerはビルドステージでの依存関係インストールステップのキャッシュを再利用できるため、ビルドプロセスが高速化します。

発展編：Multi-stage Buildでさらに最適化

基本的な知識を習得したところで、Multi-stage Buildをさらに効果的に最適化するための高度なテクニックをいくつか見ていきましょう。

1. 複数のビルドステージを使用する

アプリケーションによっては、複数の種類の依存関係や複雑なビルドステップを持つ場合があります。このような場合、複数のビルドステージを作成してそれらを分離できます。例えば、NPMの依存関係のインストールに特化したステージ、フロントエンドをビルドするための別のステージ、そしてバックエンドをビルドするための3番目のステージを作成するといった具合です。

# Stage 1: Node.jsの依存関係をインストール
FROM node:18-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

# Stage 2: フロントエンドをビルド（例：React/Angular/Vue）
FROM node:18-alpine AS frontend_builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build:frontend

# Stage 3: バックエンドをビルド（例：NestJS/Express）
FROM node:18-alpine AS backend_builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build:backend

# Stage 4: 最終ランタイムイメージ
FROM node:18-alpine
WORKDIR /app

# ビルド済みのフロントエンドとバックエンドをコピー
COPY --from=frontend_builder /app/dist/frontend ./dist/frontend
COPY --from=backend_builder /app/dist/backend ./dist/backend

# バックエンドのプロダクション依存関係のみをインストール
COPY package.json package-lock.json ./
RUN npm ci --only=production

EXPOSE 3000
CMD ["node", "./dist/backend/main.js"]

2. ビルド引数（ARG）を活用する

ARGを使ってビルドプロセスに変数を渡すことができます。これは、Dockerfileを修正せずにビルド中にツールやライブラリのバージョンを変更したい場合に特に便利です。

ARG NODE_VERSION=18-alpine

# Stage 1: 依存関係
FROM node:${NODE_VERSION} AS deps
# ... （依存関係のインストールステップ）

# Stage 2: 最終ランタイム
FROM node:${NODE_VERSION}
# ... （アプリケーションのコピーと実行ステップ）

ビルド時に、デフォルト値を上書きできます。

docker build --build-arg NODE_VERSION=20-alpine -t my-app .

3. キャッシュの最適化

DockerはDockerfile内のコマンドの順序に基づいてレイヤーをキャッシュします。Multi-stage Buildを最適化するには、変更の少ないコマンドを先に配置します。

ソースコードより先に依存関係： 必ずpackage.json/go.modをコピーし、全てのソースコードをコピーする前に依存関係のインストールコマンドを実行してください。ソースコードのみが変更された場合、Dockerは依存関係のレイヤーを再利用します。
インストールステップの分離： Dockerfileに複数のRUNコマンドがある場合、それらをまとめることを検討してください。これは、密接に関連しており、頻繁に一緒に変更されるコマンドに適用され、不要なレイヤーの数を減らすことを目的としています。

実践的なヒントと個人的な経験

本番環境でDockerをデプロイする際に何度も「頭を悩ませた」結果、Multi-stage Buildに関連するいくつかの「血と汗の結晶」とも言える経験をあなたと共有したいと思います。

適切なベースイメージの選択：
- ビルドステージの場合： コンパイルに必要なツールが通常含まれているため、より完全なイメージ（例：golang:1.22、node:18）を使用することをお勧めします。
- ランタイムステージの場合： 常にalpine（例：alpine:latest、node:18-alpine、scratch）のような超小型イメージを優先してください。scratchは空のイメージで、Goのような完全に静的なバイナリにのみ使用できます。アプリケーションがglibcやその他のライブラリを必要とする場合は、alpineが優れた選択肢です。
中間ステージでは常にクリーンアップ： 次のステージにCOPY --fromする前に、現在のステージで一時ファイル、キャッシュ、または不要なツールをすべて削除したことを確認してください。これにより、コピーされる「成果物」のサイズが削減されます。Dockerは最終ステージで使用されないレイヤーを自動的に削除しますが、積極的にクリーンアップすることは良い習慣です。
ファイルパーミッションの確認： COPY --fromを使用すると、ファイルのパーミッションが意図したとおりにならない場合があります。必要に応じてパーミッションを再設定することを忘れないでください（例：RUN chmod +x /app/myapp）。
.dockerignoreの使用： これは多くの初心者が見落としがちな非常に重要なファイルです。.dockerignoreは、ローカルのnode_modules、.git、.env、distなどの不要なファイルやディレクトリをDockerビルドのコンテキストから除外するのに役立ちます。これにより、ビルドプロセスが高速化されるだけでなく、無関係なものが最終イメージにコピーされるのを防ぎます。
EXPOSEとCMD/ENTRYPOINTを忘れないで： 最終ステージで、アプリケーションがリッスンする正しいポート（EXPOSE）とアプリケーションを起動するコマンド（CMDまたはENTRYPOINT）が宣言されていることを確認してください。
Multi-stage Buildのデバッグ： 中間ステージでエラーが発生した場合、そのステージまでビルドして確認できます。例えば、builderステージをデバッグするには：
```
docker build --target builder -t my-app-builder-debug .
docker run -it my-app-builder-debug bash
```
これにより、そのステージのコンテナ内に入り、ファイルを確認したり、コマンドを実行したりして、エラーの原因を特定できます。

まとめると、Multi-stage Buildは非常に強力な技術であり、本番環境でDockerを扱う上では欠かせない「ベストプラクティス」です。この技術は、コンパクトで高速なイメージを作成するだけでなく、アプリケーションのセキュリティも大幅に強化します。躊躇せず、今日からあなたのプロジェクトに適用してみてください！