DockerでJava環境構築｜Dockerfile例と手順

Javaの開発環境構築、「新人のPCにJDKを入れて環境変数を設定して…」「私のPCでは動くのに他の人のPCでは動かない…」に半日以上費やしていませんか。

結論から言うと、DockerでJava環境を作るなら、公式イメージ eclipse-temurin をFROMに指定したDockerfileを1枚書き、docker build と docker run（複数コンテナなら docker compose up）を実行するだけです。

ホストPCにJDKを入れなくても、Java開発環境を(1)数分で構築し(2)チーム全員で完全に同じ状態にし(3)本番環境へもそのまま持っていけます。

私自身、プロジェクト参加のたびに環境構築へ半日〜1日を費やしていましたが、Dockerを導入してからはこの悩みがなくなりました。

DockerfileとJavaアプリのコンテナ化の基本から、docker composeでのDB連携、ホットリロード・デバッグ環境の構築、本番デプロイまで、実際に手を動かしながら理解できる内容です。

この記事でわかること

DockerでJava開発環境を数分で構築する具体的な手順
チーム全員が同じ環境を再現し、本番環境へもそのまま持っていく方法
よくあるDockerエラーの原因と対処法

PARTS LIST ／目次

DockerとJavaの関係を理解しよう
DockerでJava環境を構築する手順
Java＋Dockerでの開発を効率化するコツ
よくあるエラーと対処法
Docker＋Javaを活用した応用事例
よくある質問
まとめ｜Dockerを使えばJava開発はもっと楽になる
- 開発環境の再現性と保守性が向上

DockerとJavaの関係を理解しよう

Dockerのコンテナ技術の基本と、Java開発でDockerを使う4つのメリット、仮想マシンとの違いを解説します。

そもそもDockerとは？コンテナ技術の基本

Dockerとは、「コンテナ」と呼ばれる技術を使って、アプリケーションの実行環境をかんたんに構築・管理するためのプラットフォームです。

コンテナをひとことで例えるなら、「軽量な、アプリ専用の実行環境」です。

従来の開発では、自分のPC（ホストOS）に直接Java (JDK) やデータベース (MySQLなど) をインストールしていました。

Dockerを使うと、OS上に「コンテナ」という隔離された箱をいくつも作れます。

そして、「Java 17が入った箱」「MySQL 8.0が入った箱」のように、必要なソフトウェアを箱ごとに分けて管理できるのです。

この「箱」には、Javaアプリの実行に必要なもの（JDK、ライブラリ、アプリ本体）がすべてパッケージングされています。

そのため、この箱（コンテナ）をどこへ持っていっても、まったく同じように動作します。

正直に言うと、私が初めてDockerに触れたときは「コンテナに入る」という表現の意味がまったくピンときませんでした。

ホストPCの中にもう1台独立したPCが入っているような感覚がイメージできず、しばらくは公式ドキュメントを読んでも腑に落ちなかったのを覚えています。

転機になったのは、実際に docker exec -it でコンテナの中に入り、ls や cat /etc/os-release を打ってみたときでした。

ホストPCとはまったく別のファイルシステム・別のOS情報が返ってきました。

「本当に隔離された環境がここにある」と体感できた瞬間、コンテナという概念が一気に理解できるようになったのです。

Dockerの概念を頭だけで理解しようとして詰まっている方は、細かい理屈より先に一度コンテナの中に入ってコマンドを叩いてみることをおすすめします。

Java開発にDockerを使うメリット

Java開発でDockerを使うメリットは多く、とくに以下の4点が大きいです。

メリット

環境の「再現性」が手に入ります。これが最大のメリットです。「私のPCでは動くのに」という問題がなくなります。「Dockerfile」という設定ファイルに環境の定義をすべて記述します。チーム全員が同じファイルを使うため、誰のPCでも（CPUアーキテクチャの違いなどを除けば）ほぼ同じ環境が動きます。
環境構築が「高速」になります。新しいPCでプロジェクトを始める場合、従来はJDK、Maven、IDE、DB…と多くのインストールが必要でした。Dockerなら、docker compose up というコマンドひとつで、JavaアプリもDBもすべて起動します。文字どおり、数分で開発を開始可能です。
環境を「分離」できます。「プロジェクトAではJava 8とMySQL 5.7が、プロジェクトBではJava 17とPostgreSQL 14が必要」という状況も簡単に解決します。Dockerはコンテナごとに環境を隔離します。ホストPCを汚すことなく、複数の異なるバージョンのミドルウェアを同時に動かせるのです。
本番環境への移行が「スムーズ」になります。開発環境で使ったコンテナの「設計図」をそのまま本番環境でも使えます。開発環境と本番環境の差異（OSの違い、ライブラリのバージョン違いなど）による「デプロイしたら動かない」という事故を防げます。

仮想マシンとの違いをわかりやすく比較

Dockerのコンテナとよく比較されるのが「仮想マシン (VM)」です。どちらも環境を隔離する技術ですが、仕組みが異なりいます。

仮想マシン

仮想マシン (VM)は、「OSまるごと」を仮想化します。

ホストOS (WindowsやmacOS) の上に、Hypervisorという土台を置き、そこにゲストOS (Linuxなど) をインストールします。

例えるなら「一軒家」です。土地（ハードウェア）の上に、まるごと家（ゲストOS）を建てます。
長所: OSレベルで完全に隔離されます。
短所: 起動に数分かかり、メモリやディスクの消費が大きいです。

コンテナ

コンテナ (Docker)は、ホストOSの「カーネル」というOSの核となる部分を共有します。

OSまるごとを仮想化するのではなく、プロセスやファイルシステムだけを隔離します。

例えるなら「マンションの部屋」です。建物（ホストOSカーネル）は共有しつつ、各部屋（コンテナ）は独立しています。
長所: 起動が数秒と高速で、メモリ消費も少ないです。
短所: OSレベルでの隔離はVMに劣ります（ただし開発用途では十分すぎます）。

Java開発においては、起動が速くリソース消費の少ないDockerコンテナが圧倒的に便利です。

DockerでJava環境を構築する手順

必要なツールの準備からDockerfileの作成、イメージのビルド、コンテナの実行まで、Java環境をDockerで構築する一連の手順を解説します。

Java開発に必要なツール｜Docker DesktopとJDKの要不要

DockerでJava環境を動かすために準備するものは多くありません。

Docker Desktop：WindowsやmacOSでDockerを使うための公式アプリケーションです。これひとつインストールすれば、Dockerの実行環境がすべて整います。Linuxの場合はDocker Engineをインストールします。
テキストエディタ (またはIDE)Dockerfile などの設定ファイルを書くために必要です。VS CodeやIntelliJ IDEAなど、普段お使いのもので問題ありません。

注意
ここでよくある誤解が「JDK」です。

Dockerコンテナ内でJavaアプリを動かす場合、ホストPCにJDKをインストールする必要はありません。

Java (JDK) は、コンテナの中にインストールするからです。

ただし、mvn package や gradle build コマンドを使ってJavaアプリを .jar ファイルにビルドする作業をホストPCで行う場合は、ホストPCにもJDKやMaven/Gradleが必要です。

（このビルド作業自体もDockerコンテナ内で行う「マルチステージビルド」という高度なテクニックもあります）

Javaアプリを動かすためのDockerfileの書き方

Dockerコンテナの「設計図」となるのが Dockerfile という名前のテキストファイルです。

Javaアプリを動かすための、シンプルなDockerfileの例を見てみましょう。

target/my-app-1.0.0.jar という名前でビルド済みのSpring Bootアプリがある前提です。

# 1. ベースイメージの指定
# Eclipse Temurin 21 (LTS) の軽量版 (jre) を土台にします
# ※Docker公式openjdkイメージは2022年に非推奨化されたためTemurinを使用
FROM eclipse-temurin:21-jre-noble

# 2. コンテナ内の作業ディレクトリを指定
WORKDIR /app

# 3. ホストのjarファイルをコンテナにコピー
# ホストの target/my-app-1.0.0.jar を
# コンテナの /app/app.jar としてコピーします
COPY target/my-app-1.0.0.jar app.jar

# 4. ポートの公開
# Spring Boot がデフォルトで使う 8080 ポートを
# コンテナの外に公開するよう指定します
EXPOSE 8080

# 5. コンテナ起動時に実行するコマンド
# java -jar app.jar コマンドでアプリを起動します
ENTRYPOINT ["java", "-jar", "app.jar"]

このファイルをプロジェクトのルートディレクトリに Dockerfile という名前で保存します。

たったこれだけの記述で、「Java 21がインストールされ、指定したjarファイルを実行する」環境が定義できました。

マルチステージビルドでイメージを軽量化する方法

先ほどのDockerfileは「ビルド済みのjarファイルをコピーする」前提でしたが、jarファイルのビルド自体もDockerコンテナ内で行いたい場合があります。

そのときに使うのがマルチステージビルドです。

マルチステージビルドとは、1つのDockerfile内に「ビルド用のステージ」と「実行用のステージ」を分けて記述する手法です。

ビルド用ステージではMaven/GradleとJDKのフルセットを使ってjarファイルを生成し、実行用ステージにはビルド済みのjarファイルだけをコピーします。

これにより、最終的なイメージにはMaven/GradleやビルドツールのキャッシュファイルといったJava実行に不要なものが一切含まれなくなり、イメージサイズの削減と攻撃対象領域の縮小（余分なツールが入っていない分、脆弱性のリスクも減る）を同時に実現できます。

# ステージ1: ビルド用（Maven + JDKのフルセット）
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml ./
COPY src ./src
RUN mvn package -DskipTests

# ステージ2: 実行用（軽量なJREのみ）
FROM eclipse-temurin:21-jre-noble
WORKDIR /app
COPY --from=build /app/target/my-app-1.0.0.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

なお、後述の「ホットリロード・デバッグ環境の構築方法」で紹介したDockerfileはMaven/Gradle経由で直接実行する開発用の構成であり、マルチステージビルドは使いません。

開発時はホットリロードを優先した軽量な構成、本番配布時はマルチステージビルドで最小限のイメージ、というように用途で使い分けるのが基本です。

マルチステージビルドで、最終イメージに残るもの

STAGE 1 ／ビルド用maven:3.9-eclipse-temurin-21JDK・Maven・ソースコードのフルセットで、mvn package を実行して JAR を作る

→

STAGE 2 ／実行用＝最終イメージeclipse-temurin:21-jre-nobleJava ランタイム（JRE）と、コピーした JAR だけで起動する

NOTEステージ1からステージ2へ渡すのは JAR だけです。Maven やビルド用の道具は最終イメージに入らないので、イメージが小さくなり、攻撃対象領域も小さくなります。

コンテナをビルドして実行する流れ

Dockerfile を作成したら、次に2つのステップを実行します。

前述のマルチステージビルドを使った場合、ソースコードがコンテナとして起動するまでの流れは次のとおりです。

ソースコードがコンテナとして起動するまで

SOURCE ／ソースコードpom.xml ＋ src/

docker build -t my-java-app .

BUILD ／ステージ1：ビルド用maven:3.9-eclipse-temurin-21mvn package で JAR を生成

JAR だけをコピー

BUILD ／ステージ2：実行用eclipse-temurin:21-jre-noble

IMAGE ／ Dockerイメージmy-java-appJDK・Maven は含まない

docker run -p 8080:8080 -d

RUN ／コンテナ起動localhost:8080 でアクセス

NOTE2〜3は、1回の docker build の中で順に実行されます。

イメージのビルド：Dockerfile (設計図) から、コンテナの元となる「Dockerイメージ」を作成します。ターミナルで Dockerfile があるディレクトリに移動し、以下のコマンドを実行します。docker build -t my-java-app .

-t my-java-app は、作成するイメージに my-java-app という名前（タグ）を付ける指定です。
. (ドット) は、Dockerfile が今いるディレクトリにあることを示します。

コンテナの実行作成したイメージを元に、コンテナを起動します。docker run -p 8080:8080 -d my-java-app

-p 8080:8080 は、ホストPCの 8080 番ポートと、コンテナの 8080 番ポート（EXPOSEで指定したもの）を接続する設定です。（ホスト側）:（コンテナ側） の順で書きます。
-d は、コンテナをバックグラウンドで（デタッチモードで）実行するオプションです。
my-java-app は、先ほどビルドしたイメージの名前です。

これでコンテナが起動しました。

ホストPCのブラウザから http://localhost:8080 にアクセスすれば、コンテナ内で動いているJavaアプリに接続できるはずです。

docker ps コマンドを実行すると、現在起動中のコンテナ一覧が確認できます。

ホスト⇄コンテナ間のファイル共有方法

コンテナは基本的に隔離されていますが、ホストPCのファイルやディレクトリをコンテナ内から参照したい場合があります。

たとえば、「コンテナ内で出力されるログファイルを、ホストPCの使い慣れたエディタで見たい」といったケースです。

この場合、「ボリュームマウント」という機能を使います。

docker run コマンドに -v オプションを追加します。

docker run -p 8080:8080 -v /Users/myname/projects/my-app/logs:/app/logs -d my-java-app

: の前が「ホストPCのディレクトリパス（絶対パス）」
: の後が「コンテナ内のディレクトリパス」です。

このように指定すると、コンテナ内の /app/logs ディレクトリへの書き込みが、実際にはホストPCの /Users/myname/projects/my-app/logs ディレクトリに書き込まれます。

コンテナを削除してもログファイルがホストPCに残るため便利です。

-v でホストとつなぐと何が残るか

CONTAINER ／コンテナ（起動中）/app/logs にログを書き込む

-v で同じディレクトリとして接続

HOST ／ホストPC＝実体の保存先/Users/myname/projects/my-app/logs実体はホストPC側。使い慣れたエディタで見られる

コンテナを削除しても

HOST ／ホストPCログファイルはホストPCに残る

NOTEパスは本文のコマンド例と同じです。

Java＋Dockerでの開発を効率化するコツ

docker composeによるマルチコンテナ管理、ホットリロード・デバッグ環境の構築、チーム運用のルールを解説します。

docker-composeでマルチコンテナ環境を管理

docker run コマンドは、ポートやボリュームの指定が増えると長くなり、管理が大変です。

また、Javaアプリは通常、データベースなど他のサービスと連携して動作します。

「Javaアプリのコンテナ」と「PostgreSQLのコンテナ」を同時に、かんたんに起動・停止したい。

この問題を解決するのが docker compose です。

docker compose は、複数のコンテナ構成を docker-compose.yml というYAML形式のファイルに定義して、まとめて管理できるツールです。

Compose V2ではハイフンなしのdocker composeが標準コマンドです（V1のdocker-composeは2023年6月にサポート終了）。

（Docker Desktopには標準で含まれています。LinuxのDocker Engineでは、Composeプラグインを別途インストールします）

docker-compose.yml の例を見てみましょう。

# docker-compose.yml
# Compose V2ではversion属性は非推奨（省略可・自動で最新スキーマを使用）

services: # ここに起動したいコンテナ(サービス)を定義
  
  # 1. Javaアプリ (Spring Boot)
  app:
    build: . # カレントディレクトリのDockerfileを使ってビルド
    ports:
      - "8080:8080" # ホストの8080とコンテナの8080を接続
    environment:
      # Javaアプリに渡す環境変数
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/mydb
      - SPRING_DATASOURCE_USERNAME=user
      - SPRING_DATASOURCE_PASSWORD=pass
    depends_on:
      - db # dbコンテナを先に起動する（DBの準備完了までは待たない）

  # 2. PostgreSQLデータベース
  db:
    image: postgres:18 # Docker HubのPostgreSQL 18イメージを使用
    ports:
      - "5432:5432" # ホストの5432とコンテナの5432を接続
    environment:
      # PostgreSQLコンテナに渡す環境変数
      - POSTGRES_DB=mydb
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass

このファイルをプロジェクトルートに保存し、ターミナルで以下のコマンドを実行するだけです。

# 起動 (ビルドも自動で実行)
docker compose up -d

# 停止・削除
docker compose down

docker compose を使えば、JavaアプリとDBの面倒な連携設定や起動順序をすべて自動化できます。

ホットリロード・デバッグ環境の構築方法

Java開発では、コードを修正するたびに docker build を実行するのは非効率です。

Spring Boot DevTools のようなホットリロード（自動再起動）を Docker環境でも実現したいものです。

これは、先ほど紹介した「ボリュームマウント」を応用することで実現できます。

docker-compose.yml に volumes を追加し、ホストPCのソースコード（またはビルド成果物）をコンテナ内にマウントします。

# docker-compose.yml (抜粋)
services:
  app:
    build: .
    ports:
      - "8080:8080"
    volumes:
      # ホストのカレントディレクトリをコンテナの/appにマウント
      - .:/app 
    # ... (environment, depends_on)

さらに、Dockerfile の ENTRYPOINT を .jar の実行から、Maven/Gradle経由での実行に変更します（Spring Boot DevToolsを有効にするため）。

# Dockerfile (ホットリロード用)
FROM eclipse-temurin:21-jdk-noble
WORKDIR /app

# 先に依存関係だけコピーしてインストール (ビルド高速化のテクニック)
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline

# ソースコード全体をコピー
COPY src ./src

# 実行コマンド (jarではなくmvn spring-boot:run)
CMD ["./mvnw", "spring-boot:run"]

こうすることで、ホストPCでJavaのソースコードを変更・保存すると、それが即座にコンテナ内に反映されます。

pom.xml に spring-boot-devtools を依存関係として追加しておけば、コンテナ内のSpring Boot DevToolsがクラスパス上のファイルの変更を検知し、アプリケーションを自動で再起動してくれます。ただし検知対象はコンパイル済みのクラスなので、.java を保存しただけでは再起動しません。IDEの自動ビルドを有効にするか、ホスト側で ./mvnw compile を実行して target/classes を更新する必要があります。

また、デバッグも可能です。

Dockerfile や docker-compose.yml でJavaのデバッグポート (例: 5005) を開ける設定を追加します。

# docker-compose.yml (抜粋)
    ports:
      - "8080:8080"
      - "5005:5005" # デバッグポートを追加
    environment:
      # JVMのデバッグオプションを有効化
      - JAVA_TOOL_OPTIONS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

これにより、IntelliJ IDEAなどのIDEから localhost:5005 にリモートデバッグ接続し、コンテナ内で動いているJavaアプリにブレークポイントを張ることができます。

チーム開発でのDocker運用ポイント

チーム全員がDockerの恩恵を受けるためには、いくつかのルールを決めておくとスムーズです。

Dockerfile と docker-compose.yml をGitで共有するこれら2つのファイルこそが「環境の定義書」です。これをGitリポジトリに含めることで、新しいメンバーは git clone して docker compose up するだけで、誰でも同じ開発環境を即座に起動できます。
.dockerignore ファイルを活用するDockerfile で COPY . . のようにディレクトリ全体をコピーすると、不要なファイルまでコンテナ内にコピーされてしまいます。target ディレクトリや .git ディレクトリ、IDEの設定ファイル (.idea, .vscode) などはビルドに不要です。.gitignore と同じ書式で .dockerignore ファイルを作成し、不要なファイルを除外します。これにより、Dockerイメージのビルドが高速になり、イメージサイズも小さくなります。
ベースイメージのバージョンを固定するDockerfile の FROM で指定するイメージは、eclipse-temurin:21 のような「メジャーバージョン指定」ではなく、eclipse-temurin:21.0.12_8-jre-noble のような「マイナーバージョンまで含めた指定」を推奨します。メジャーバージョン指定だと、ある日突然ベースイメージが更新され、ライブラリの互換性問題などでビルドが通らなくなる可能性があるためです。

Dockerイメージのセキュリティ対策｜脆弱性スキャンの基本

eclipse-temurin:21-jre-noble のようなベースイメージには、Javaランタイム以外にもOSレベルのパッケージ群が含まれています。

これらには既知の脆弱性（CVE）が発見されることがあり、ベースイメージを長期間更新しないまま使い続けると、コンテナ経由での攻撃リスクが高まります。

そこで役立つのが脆弱性スキャンです。

Docker Desktopには docker scout コマンドが標準搭載されており、以下のようにイメージをスキャンできます。

# ビルドしたイメージの脆弱性をスキャン
docker scout cves my-java-app

# OSS製の Trivy を使う場合
trivy image my-java-app

スキャン結果で重大度の高い脆弱性が見つかった場合は、前述の「ベースイメージのバージョンを固定する」運用と組み合わせて、ベースイメージのマイナーバージョンを最新に更新することで多くの脆弱性を解消できます。

CI/CDパイプラインにこのスキャンコマンドを組み込み、脆弱性が見つかったビルドを自動で失敗させる運用も有効です。

よくあるエラーと対処法

Docker daemon未起動、ポート競合・メモリ不足、コンテナの即時終了という3つの代表的なエラーの原因と対処法を解説します。

「Cannot connect to the Docker daemon」と出た場合

これは初心者が最も遭遇するエラーのひとつです。

原因:Dockerの本体（デーモンと呼ばれるサービス）が起動していません。
対処法:
- Windows / macOS の場合: Docker Desktop アプリケーションを起動してください。タスクトレイ（やメニューバー）のクジラのアイコンがアニメーションせず、安定している状態になれば起動完了です。
- Linux の場合: systemctl status docker でサービスの状態を確認し、停止していれば sudo systemctl start docker で起動します。また、一般ユーザーでdockerコマンドを実行するには、ユーザーを docker グループに追加する必要があります。

ポート競合・メモリ不足エラーの原因と解決策

ポート競合エラー (address already in use)
- 原因: docker-compose.yml や docker run で指定したホスト側のポート（例: 8080）が、すでに別のアプリケーションによって使用されています。ホストPCで別のJavaアプリを起動しっぱなしにしている、などのケースが多いです。
- 対処法:
  1. 競合しているプロセスを停止する。
  2. docker-compose.yml などのポートマッピング設定を変更する (例: ports: - "8081:8080" に変え、localhost:8081 でアクセスする)。
メモリ不足エラー (OOM / Out of Memory)
- 原因: Javaアプリ (JVM) が、コンテナに割り当てられたメモリ上限を超えて使用しようとしました。
- 対処法:
  1. Docker Desktop の設定 (Settings > Resources) を開き、Dockerが使用できるメモリの割り当て量を増やします。
  2. Dockerfile や docker-compose.yml の environment で、Javaのヒープサイズ (-Xmx) を明示的に指定し、コンテナのメモリ上限内に収まるよう調整します。

コンテナがすぐ終了する場合のチェックポイント

docker compose up -d を実行したのに、docker ps で見るとコンテナが一覧に表示されない（すぐに終了している）場合があります。

原因:コンテナは、ENTRYPOINT や CMD で指定されたメインのプロセスが終了すると、自動的に停止します。つまり、Javaアプリが起動に失敗してクラッシュしている可能性が高いです。
対処法:
1. docker ps -a コマンドで、停止したコンテナを含む全コンテナのID（または名前）を調べます。
2. docker logs [コンテナID] コマンドを実行します。
3. コンテナの標準出力（ログ）が表示されます。Javaの起動時エラー（設定ファイルが見つからない、DBに接続できない、ClassNotFoundException など）が出力されているはずです。そのエラーメッセージを読んで、Javaアプリや Dockerfile の設定を修正します。

Docker＋Javaを活用した応用事例

Spring Bootアプリの本番デプロイ、CI/CDパイプラインとの連携、AWS・GCPのクラウド環境への展開という3つの応用事例を解説します。

Spring BootアプリをDocker化してデプロイする例

Dockerの真価は、開発環境だけでなく本番環境へのデプロイ（展開）で発揮されます。

docker build で作成した「Dockerイメージ」は、開発PCから本番サーバーへかんたんに持ち運べます。

イメージの登録 (Push)Docker Hub や、AWSの ECR, GCPの Artifact Registry といった「コンテナレジストリ」に、ビルドしたJavaアプリのイメージをアップロード（push）します。
サーバーでの実行 (Pull & Run)本番サーバー（クラウド上のVMなど）で、レジストリからイメージをダウンロード（pull）し、docker run または docker compose up で実行します。

本番サーバーにはJDKやMavenをインストールする必要が一切ありません。Dockerが動く環境さえあればよいのです。

これにより、OSやミドルウェアのバージョン差異に悩まされることなく、確実なデプロイが実現します。

CI/CD環境（GitHub Actionsなど）との連携

DockerはCI/CD (継続的インテグレーション/継続的デリバリー) パイプラインと相性が良いです。

GitHub Actions や Jenkins, GitLab CI といったツールと連携し、以下の流れを自動化できます。

開発者がソースコードをGitにPushする。
CIツールが変更を検知し、自動でテスト (mvn test) を実行する。
テストが通ったら、自動で docker build を実行し、JavaアプリのDockerイメージを作成する。
作成したイメージをコンテナレジストリ (ECRなど) にPushする。
（CD）本番環境（ECSなど）に対し、新しいイメージを使ってサービスを更新するよう命令する。

この仕組みを構築することで、開発者はコードを書くことに集中でき、ビルドからデプロイまでの面倒な手作業をすべて自動化できます。

クラウド環境（AWS・GCP）への展開

現代のクラウドプラットフォーム (AWS, GCP, Azure) は、Dockerコンテナを実行するためのマネージドサービスを強力にサポートしています。

AWS: ECS (Elastic Container Service) や EKS (Elastic Kubernetes Service)
GCP: GKE (Google Kubernetes Engine) や Cloud Run

これらのサービスを使えば、docker run を手動で実行する必要すらありません。

たとえばGCPの Cloud Run は、Dockerイメージを指定するだけで、自動でスケーリング（負荷に応じてコンテナ数を増減）し、HTTPS化まで行ってくれるサーバーレスのコンテナ実行環境です。

Java + Dockerで作成したイメージは、こうした最新のクラウドサービスへ移行するための「パスポート」の役割を果たします。

よくある質問

Q1. Docker上でJavaアプリを動かすのにホストPCへのJDKインストールは必要ですか？

A1. いいえ、不要です。JDKはコンテナの中にインストールするため、コンテナ内でJavaアプリを実行するだけならホストPCにJDKを入れる必要はありません。ただし、mvn packageやgradle buildによるビルド作業をホストPC側で行う場合は、ホストPCにもJDKとMaven/Gradleが必要です。

Q2. docker-composeとdocker composeの違いは何ですか？

A2. docker-compose（ハイフンあり）はCompose V1のコマンドで、2023年6月にサポートが終了しました。現在標準のCompose V2ではdocker compose（スペース区切り）を使います。docker-compose.ymlというファイル名自体は変更されていません。

Q3. Dockerのベースイメージにopenjdk:17-slimを使ってもいいですか？

A3. 推奨しません。Docker Hub公式のopenjdkイメージは2022年7月に非推奨化され、セキュリティ更新が止まっています。代わりにAdoptiumプロジェクトが提供するeclipse-temurinイメージを使ってください。

Q4. マルチステージビルドはなぜ必要ですか？

A4. Java実行に不要なビルドツール（Maven/Gradle）を最終イメージから除外し、イメージサイズと脆弱性リスクを減らすためです。ビルド用ステージと実行用ステージを分けてDockerfileに記述することで実現できます。

Q5. Dockerコンテナがすぐに終了してしまうのはなぜですか？

A5. ENTRYPOINTやCMDで指定したメインプロセスが終了すると、コンテナは自動的に停止します。docker logs [コンテナID]でログを確認し、Javaアプリの起動エラー（設定ファイル未検出やDB接続エラーなど）を特定してください。

Q6. Docker DesktopとJDKはどちらも必須ですか？

A6. コンテナ内でJavaアプリを実行するだけなら、Docker Desktop（またはLinuxのDocker Engine）だけで十分です。JDKはコンテナの中にインストールされるため、ホストPCへの追加インストールは不要です。

Q7. Java 17と最新のJava 25、Dockerで使うならどちらがいいですか？

A7. 既存プロジェクトとの互換性を優先するならJava 17、最新機能や最長サポートを重視するなら2025年9月リリースの最新LTSであるJava 25がおすすめです。DockerfileのFROM行を書き換えるだけでどちらにも切り替えられます。なお、本記事のサンプルは対応ライブラリ・ミドルウェアが揃ったLTSであるJava 21（eclipse-temurin:21）で統一しています。

まとめ｜Dockerを使えばJava開発はもっと楽になる

Dockerを導入することで、環境構築の再現性と保守性が向上し、チーム全員が数分で同じ開発環境を再現できるようになります。

開発環境の再現性と保守性が向上

Dockerは、Java開発における「環境」の悩みを根本から解決します。

Dockerfile と docker-compose.yml という2つのファイルが、アプリケーションの実行環境のすべてを定義します。

これにより、チームの誰もが数分で同じ開発環境を再現できるようになります。

環境構築にかかっていた数時間、あるいは数日といった時間を、本来のアプリケーション開発に使えるようになるのです。

また、Javaのバージョンを17から21、あるいは2025年9月にリリースされた最新LTSのJava 25に上げたい場合も、Dockerfile の FROM 行を書き換えてビルドし直すだけです。

環境の保守性が劇的に向上します。

REVISIONS ／ 改訂履歴

REV.	DATE	内容
5	2026-10-15	図解を描き直し（図面のデザインにそろえた）
4	2026-10-14	タイトルを見直し。雰囲気だけの挿絵を外した
3	2026-10-06	記載内容の事実確認と修正
2	2026-08-22	2026年8月時点の情報で全体を見直し（古い記述を7件更新）
1	2025-11-09	初版