はじめに
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 で最適化されたコンテナをデプロイする流れとなります。
改めて記事として体系的にまとめたことで、自分自身の理解も深まりました！