はじめに

Docker は開発・本番環境の構築を効率化するために広く使われていますが、テスト環境と本番環境で適切な構成を選ぶことが重要です。

本記事では、Golang を使ったテスト用・本番用の Dockerfile の違いを解説し、それぞれの用途や最適な活用方法について紹介します。

書こうと思ったきっかけ

Golang で開発を進める中で、テスト環境ではコード変更を即時反映できるホットリロードが便利ですが、本番環境では軽量でセキュアなコンテナが求められます。

そのため、異なる Dockerfile を用意することが一般的です。

しかし、初心者にとっては「どのような構成が適切なのか」「なぜ分けるのか*」がわかりにくいことがあります。

そこで、テスト用と本番用の Dockerfile を比較し、それぞれの役割を明確にする記事を書こうと思いました。

テスト用と本番用の Dockerfile の違い

テスト用 Dockerfile

FROM golang:1.23.5-alpine3.21  # Golang 1.23.5 + Alpine Linux 3.21の軽量なイメージをベースにする
WORKDIR /usr/src/app            # コンテナ内の作業ディレクトリを設定

COPY go.mod go.sum ./           # 依存関係の管理ファイル (go.mod, go.sum) をコンテナにコピー
RUN go mod download             # 依存関係をダウンロード

COPY . .                        # アプリケーションのソースコードをすべてコンテナにコピー

RUN go install github.com/air-verse/air@latest  # Air（ホットリロードツール）をインストール

特徴・ポイント:

開発・テスト向けの構成
- Goの公式イメージを利用し、ソースコードをそのままコンテナに取り込む
- go mod download で依存関係を解決
- air をインストールすることで、コード変更時に自動リロードできるようにしている

用途:

ローカル開発環境やテスト実行用（air を使ってコード変更のたびに即時反映可能）

本番用 Dockerfile

# === ビルド用ステージ ===
FROM golang:1.23.5-alpine3.21 AS builder  # ビルド専用のステージ
WORKDIR /usr/src/app

COPY go.mod go.sum ./  # 依存関係の管理ファイルをコピー
RUN go mod download    # 依存関係をダウンロード

COPY . .               # アプリケーションのソースコードをコピー

RUN CGO_ENABLED=0 GOOS=linux go build -o server .  # 静的バイナリを作成（軽量化）

# === 実行用ステージ ===
FROM alpine:3.21  # 実行時の軽量な Alpine Linux イメージ
COPY --from=builder /usr/src/app/server .  # ビルド済みバイナリのみをコピー
CMD ["./server"]  # アプリケーションを起動

特徴・ポイント:

マルチステージビルドを使用
- golang:1.23.5-alpine3.21 を使ってアプリケーションをビルド（builder ステージ）
- 実行時は alpine:3.21 のみを使用し、最小限のサイズに抑える
静的リンクバイナリを作成
- CGO_ENABLED=0 GOOS=linux go build -o server . により、Cライブラリ依存をなくし、どこでも動く軽量なバイナリを生成
- ビルド後は server バイナリのみをコピーし、余計なツールやライブラリを排除（セキュリティ向上＆コンテナサイズ削減）
実行環境の最適化
- Alpine Linux は軽量でセキュリティが高いため、本番運用に適している
- CMD ["./server"] でシンプルにアプリを起動

用途:

本番環境向けの最適化されたコンテナ
- 不要な開発ツールを含めず、軽量なバイナリを実行するだけの構成

まとめ

項目	テスト用	本番用
目的	開発・テスト用 (ホットリロード)	本番運用用（軽量＆最適化）
ベースイメージ	`golang:1.23.5-alpine3.21`	`golang:1.23.5-alpine3.21` → `alpine:3.21`
コード変更の反映	`air` によりリアルタイムで反映	一度ビルドしたバイナリのみ使用
サイズ	Goツール類を含むため重い	マルチステージビルドで最小限に
セキュリティ	開発ツールを含むためややリスクあり	実行に不要なツールを排除し安全

開発環境ではテスト用の Dockerfile を使い、動作確認が取れたら本番用の Dockerfile で最適化されたコンテナをデプロイする流れとなります。

改めて記事として体系的にまとめたことで、自分自身の理解も深まりました！