「JavaアプリをDocker化したいけど、Dockerfileはこれで合ってる？」
「イメージが重い…起動が遅い…これ普通？」
「本番で落ちない設定ってどうやるの？」
そんな疑問を持つJavaエンジニアのために、
この記事では JavaアプリをDocker化するためのベストプラクティス を徹底解説します。
初心者にもわかるようにやさしく。
でも内容は実務レベルです。
なぜJavaアプリをDocker化するのか？
まず大前提です。
Dockerとは、
アプリを「動く環境ごと」まとめて箱にする技術
です。
Javaは「どこでも動く」ことが強みですが、
- JDKのバージョン違い
- OS差異
- ミドルウェア依存
などで本番だけ動かない問題が起こります。
Dockerを使うと、
- 開発と本番の環境差をなくせる
- CI/CDと相性が良い
- スケールしやすい
というメリットがあります。
そして今、
Java × Docker はほぼ標準構成 です。
まずは基本のDockerfile
最もシンプルな例です。
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/app.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]
これで動きます。
しかし、
ここからが本番です。
ベストプラクティスその一：latestを使わない
NG例：
FROM openjdk:latest
これは危険です。
理由：
- いつのJavaか分からない
- 突然アップデートされる
- ビルドが再現できない
正しい例
FROM eclipse-temurin:17.0.10-jre
バージョンを固定しましょう。
再現性はプロの基本です。
ベストプラクティスその二：マルチステージビルド
ビルド用ツールを本番イメージに含めるのは無駄です。
悪い例
- JDK
- Maven
- ビルドキャッシュ
全部含まれる。
イメージが巨大になります。
良い例
# ビルド用
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests# 実行用
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=build /app/target/app.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]
これで、
- 軽量
- セキュア
- 高速
になります。
ベストプラクティスその三：.dockerignoreを使う
意外と忘れがちです。
.dockerignore を作りましょう。
.git
target
.idea
node_modules
不要ファイルを除外することで、
- ビルド時間短縮
- サイズ削減
- セキュリティ向上
が実現できます。
ベストプラクティスその四：非rootで実行する
コンテナ内とはいえrootは危険です。
RUN useradd -m appuser
USER appuser
これだけでセキュリティは大きく向上します。
プロジェクトで必須にすべき設定です。
ベストプラクティスその五：ENTRYPOINTの書き方
NG例：
ENTRYPOINT sh -c "java -jar app.jar"
これはPID1がshになります。
シグナルを正しく受け取れません。
正しい例
ENTRYPOINT ["java","-jar","app.jar"]
配列形式で書くこと。
これが重要です。
ベストプラクティスその六：コンテナ向けJVM設定
コンテナはメモリ制限があります。
Javaもそれを意識する必要があります。
例：
ENTRYPOINT ["java","-XX:MaxRAMPercentage=75.0","-jar","app.jar"]
これにより、
- コンテナ制限内でヒープを管理
- OOMリスクを低減
できます。
Javaはコンテナ対応が進んでおり、
この点でも優位性があります。
ベストプラクティスその七：ログは標準出力へ
コンテナでは、
ログ＝標準出力
が基本です。
ログファイルに書き続けると、
- ディスク圧迫
- 管理困難
になります。
Spring Bootなら、
デフォルトで標準出力です。
ベストプラクティスその八：設定は外に出す
Dockerfileにパスワードを書くのはNG。
環境変数を使いましょう。
environment:
SPRING_PROFILES_ACTIVE: prod
機密情報は必ず外部管理。
ベストプラクティスその九：ヘルスチェック
HEALTHCHECK --interval=30s \
CMD curl -f http://localhost:8080/actuator/health || exit 1
これにより、
- 死活監視
- 再起動制御
が可能になります。
Kubernetes環境では必須です。
ベストプラクティスその十：イメージを小さく保つ
小さいことは正義です。
理由：
- ダウンロードが速い
- 攻撃対象が少ない
- 起動が速い
マルチステージ＋軽量JREで
大きく改善できます。
よくあるアンチパターン
- openjdk:latest使用
- root実行
- ログをファイルに出力
- 巨大イメージ
- 設定ベタ書き
- マルチステージ未使用
これらを避けるだけでも、
かなりレベルが上がります。
Java×Dockerの強み
Javaは、
- 一度ビルドすれば安定
- JVMチューニングが豊富
- 大規模実績多数
Dockerとの相性は非常に良いです。
特にエンタープライズ分野では
Java＋Dockerは標準構成です。
学習ロードマップ
ステップ：
- Java基礎を固める
- シンプルなDockerfileを書く
- マルチステージを理解
- JVMチューニングを学ぶ
- Kubernetesへ発展
この順番がおすすめです。
まずはJava力を底上げ
Docker以前に、
Javaが書けなければ意味がありません。
絶対にJavaプログラマーになりたい人へ。
https://amzn.asia/d/3E1CYbv
基礎がある人はDocker理解も速いです。
本気で実務レベルを目指すなら
- Dockerfileレビューを受けたい
- JVMチューニングを学びたい
- 転職サポートも欲しい
そんな人はサイゼントアカデミー。
Java＋Dockerまで実践レベルで学べます。
まとめ
JavaアプリをDocker化するベストプラクティスは：
- ベースイメージ固定
- マルチステージビルド
- .dockerignore活用
- 非root実行
- 正しいENTRYPOINT
- コンテナ向けJVM設定
- ログは標準出力
- 設定外部化
- ヘルスチェック
- イメージ軽量化
すべて一度にやらなくていい。
一つずつ改善すればいい。
Dockerを理解したJavaエンジニアは、
市場価値が一段上がります。
あなたが
インフラもわかるJavaエンジニア になることを応援しています。
コメント