Spring Bootで開発をしていると、
「自分の環境では動くのに、他の人の環境では動かない」
という経験は少なくありません。
Javaのバージョンや環境設定が原因で、開発環境の構築に時間がかかることもあります。
そこで、Spring BootアプリケーションをDocker化し、開発環境をコンテナで統一しました。
導入前
以前は各開発者のPCへ、
- Java
- Maven
- Gradle
などをインストールしていました。
起動も、
./gradlew bootRun
または
mvn spring-boot:run
を実行していました。
環境によってJavaのバージョンが異なり、ビルドエラーになることもありました。
導入後
Spring BootアプリケーションをDockerコンテナとして起動する構成に変更しました。
Docker
↓
Spring Boot
↓
Application
開発者はDockerがインストールされていれば、同じ環境でアプリケーションを起動できます。
Dockerfile
今回はマルチステージビルドを採用しました。
FROM gradle:8.7-jdk21 AS builder
WORKDIR /app
COPY . .
RUN gradle bootJar --no-daemon
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=builder /app/build/libs/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
ビルド用イメージと実行用イメージを分けることで、
最終的なイメージサイズを抑えています。
Docker Compose
ローカルではDocker Composeを利用しています。
services:
app:
build: .
ports:
- "8080:8080"
起動は、
docker compose up --build
だけです。
JavaやGradleをローカルへインストールする必要はありません。
環境変数
設定値は環境変数から取得しています。
environment:
SPRING_PROFILES_ACTIVE: local
Spring Bootでは、
spring.profiles.active
として利用できます。
環境ごとに設定を切り替えられるため、
開発・検証・本番で同じイメージを利用できます。
開発効率が向上
Docker化したことで、
新しいメンバーでも
docker compose up
だけで環境を起動できるようになりました。
JavaやGradleのセットアップ手順を説明することも減り、
環境構築の時間を短縮できました。
CIとの相性も良い
Dockerで動作するようになったことで、
CIでも同じイメージを利用できるようになりました。
例えば、
GitHub Actions
↓
Docker Build
↓
Docker Image
↓
テスト
↓
デプロイ
といったパイプラインを構築しやすくなります。
ローカルとCIの環境差異も少なくなりました。
導入して感じたこと
一番良かったのは、
開発環境が統一されたことです。
以前は、
「Java 17なら動く」
「Java 21だとエラーになる」
といった環境差異がありました。
Docker化してからは、
全員が同じコンテナを利用するため、
環境起因のトラブルはほとんどなくなりました。
まとめ
今回の構成では、
- Spring BootをDocker化
- マルチステージビルドを採用
- Docker Composeでローカル起動
- 環境変数で設定を切り替え
- CIでも同じコンテナを利用
という形にしました。
Dockerを導入したことで、開発環境の構築がシンプルになり、ローカル・CI・本番で同じ実行環境を利用できるようになりました。
特にチーム開発では、環境差異によるトラブルを減らせる点が大きなメリットだと感じています。