Spring Boot 3 と Java 17 の基本構成・Docker 化・マルチクラウド CI/CD 入門

2026年7月2日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Spring Boot の基本構成とビルド設定
- 1.1 Maven の最小構成 (pom.xml)
- 1.2 Gradle Kotlin DSL の最小構成 (build.gradle.kts)
  - 1.2.1 まとめ
2 プロファイル別設定と Docker コンテナ化
- 2.1 プロファイル別設定 (application.yml, application-dev.yml, application-prod.yml)
- 2.2 Dockerfile（マルチステージビルド）
  - 2.2.1 ローカルでのビルドと起動手順
  - 2.2.2 サイズとコストの根拠
3 主要クラウドサービス比較とデプロイ選定ポイント
- 3.1 サービス比較表（2026 年版）
  - 3.1.1 選定指針
  - 3.1.2 Heroku との違いと選定基準（補足）
4 GitHub Actions を使った CI/CD パイプライン構築例
- 4.1 ワークフローファイル全体 (.github/workflows/deploy.yml)
  - 4.1.1 ステップ別解説
  - 4.1.2 ベストプラクティスまとめ
5 本番運用のベストプラクティスとトラブルシューティング
6 次のアクション：サンプルリポジトリで実践しよう
7 参考文献・出典

スポンサードリンク

Spring Boot の基本構成とビルド設定

Spring Boot をローカルで手軽に始めるには、プロジェクトのディレクトリ構造とビルドツールの選択が最初のハードルです。このセクションでは Java 17 以上・Spring Boot 3.x を前提に、Maven と Gradle の最小構成を示しながら「どちらでも同等に開発できる」ことを結論とします。

Maven の最小構成 (`pom.xml`)

以下は Spring Boot 3.2 系の BOM（Bill‑of‑Materials）を取り込み、Web と Actuator を使用するだけのシンプルな pom.xml です。

&lt;project xmlns=&quot;http://maven.apache.org/POM/4.0.0&quot;
         xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;
         xsi:schemaLocation=&quot;http://maven.apache.org/POM/4.0.0
                             https://maven.apache.org/xsd/maven-4.0.0.xsd&quot;&gt;
    &lt;modelVersion&gt;4.0.0&lt;/modelVersion&gt;

    &lt;!-- プロジェクト基本情報 --&gt;
    &lt;groupId&gt;com.example&lt;/groupId&gt;
    &lt;artifactId&gt;demo-app&lt;/artifactId&gt;
    &lt;version&gt;0.0.1-SNAPSHOT&lt;/version&gt;
    &lt;packaging&gt;jar&lt;/packaging&gt;

    &lt;!-- Java バージョンと Spring Boot のバージョンを明示 --&gt;
    &lt;properties&gt;
        &lt;java.version&gt;17&lt;/java.version&gt;
        &lt;spring-boot.version&gt;3.2.0&lt;/spring-boot.version&gt;
    &lt;/properties&gt;

    &lt;!-- Spring Boot BOM による依存管理 --&gt;
    &lt;dependencyManagement&gt;
        &lt;dependencies&gt;
            &lt;dependency&gt;
                &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
                &lt;artifactId&gt;spring-boot-dependencies&lt;/artifactId&gt;
                &lt;version&gt;${spring-boot.version}&lt;/version&gt;
                &lt;type&gt;pom&lt;/type&gt;
                &lt;scope&gt;import&lt;/scope&gt;
            &lt;/dependency&gt;
        &lt;/dependencies&gt;
    &lt;/dependencyManagement&gt;

    &lt;!-- 必要最低限の依存 --&gt;
    &lt;dependencies&gt;
        &lt;dependency&gt;
            &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
            &lt;artifactId&gt;spring-boot-starter-web&lt;/artifactId&gt;
        &lt;/dependency&gt;
        &lt;dependency&gt;
            &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
            &lt;artifactId&gt;spring-boot-starter-actuator&lt;/artifactId&gt;
        &lt;/dependency&gt;
    &lt;/dependencies&gt;

    &lt;!-- Spring Boot Maven Plugin（実行可能 JAR の生成） --&gt;
    &lt;build&gt;
        &lt;plugins&gt;
            &lt;plugin&gt;
                &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
                &lt;artifactId&gt;spring-boot-maven-plugin&lt;/artifactId&gt;
                &lt;configuration&gt;
                    &lt;excludes&gt;
                        &lt;exclude&gt;
                            &lt;groupId&gt;org.projectlombok&lt;/groupId&gt;
                            &lt;artifactId&gt;lombok&lt;/artifactId&gt;
                        &lt;/exclude&gt;
                    &lt;/excludes&gt;
                &lt;/configuration&gt;
            &lt;/plugin&gt;
        &lt;/plugins&gt;
    &lt;/build&gt;
&lt;/project&gt;

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

https://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>com.example</groupId>

<version>0.0.1-SNAPSHOT</version>

<java.version>17</java.version>

<spring-boot.version>3.2.0</spring-boot.version>

</properties>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-dependencies</artifactId>

<version>${spring-boot.version}</version>

<scope>import</scope>

</dependency>

</dependencies>

</dependencyManagement>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-web</artifactId>

</dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

</dependencies>

<build>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-maven-plugin</artifactId>

<groupId>org.projectlombok</groupId>

<artifactId>lombok</artifactId>

</exclude>

</excludes>

</configuration>

</plugin>

</plugins>

</build>

</project>

Gradle Kotlin DSL の最小構成 (`build.gradle.kts`)

Gradle を選択した場合の設定例です。Kotlin DSL で記述しているため、IDE 補完が効きやすくなります。

plugins {
    // Spring Boot と依存管理プラグインを追加
    id(&quot;org.springframework.boot&quot;) version &quot;3.2.0&quot;
    id(&quot;io.spring.dependency-management&quot;) version &quot;1.1.5&quot;
    kotlin(&quot;jvm&quot;) version &quot;1.9.22&quot;   // Kotlin を使う場合だけ必要
}

group = &quot;com.example&quot;
version = &quot;0.0.1-SNAPSHOT&quot;
java.sourceCompatibility = JavaVersion.VERSION_17

repositories {
    mavenCentral()
}

// 必要最低限の依存を宣言
dependencies {
    implementation(&quot;org.springframework.boot:spring-boot-starter-web&quot;)
    implementation(&quot;org.springframework.boot:spring-boot-starter-actuator&quot;)
    testImplementation(&quot;org.springframework.boot:spring-boot-starter-test&quot;)
}

// 実行可能 JAR のエントリポイントを明示
tasks.withType&lt;Jar&gt; {
    manifest {
        attributes[&quot;Main-Class&quot;] = &quot;com.example.DemoAppApplication&quot;
    }
}

plugins {

// Spring Boot と依存管理プラグインを追加

id("org.springframework.boot") version "3.2.0"

id("io.spring.dependency-management") version "1.1.5"

kotlin("jvm") version "1.9.22" // Kotlin を使う場合だけ必要

}

group = "com.example"

version = "0.0.1-SNAPSHOT"

java.sourceCompatibility = JavaVersion.VERSION_17

repositories {

mavenCentral()

}

// 必要最低限の依存を宣言

dependencies {

implementation("org.springframework.boot:spring-boot-starter-web")

implementation("org.springframework.boot:spring-boot-starter-actuator")

testImplementation("org.springframework.boot:spring-boot-starter-test")

}

// 実行可能 JAR のエントリポイントを明示

tasks.withType<Jar> {

manifest {

attributes["Main-Class"] = "com.example.DemoAppApplication"

}

まとめ

結論：Maven・Gradle のどちらでも java.version=17 と Spring Boot 3.x の BOM を取り入れれば、最新機能と長期サポートがすぐに利用できます。
理由：Spring Boot 3 は Jakarta EE 9 に対応し、Java 17 が最低要件となっているためです。
実践例：上記の pom.xml と build.gradle.kts をそのままプロジェクトに貼り付ければ、ローカルで mvn spring-boot:run または ./gradlew bootRun が動作します。

プロファイル別設定と Docker コンテナ化

環境ごとの設定差分を安全かつ可搬性の高い形で管理する方法として、application.yml と application-{profile}.yml の組み合わせが標準です。この章ではプロファイル構成の概要と、マルチステージ Dockerfile による軽量イメージ作成手順を解説します。

プロファイル別設定 (`application.yml`, `application-dev.yml`, `application-prod.yml`)

Spring Boot は起動時に spring.profiles.active で指定されたプロファイルの設定をマージします。以下は「共通」「開発」「本番」の３層構成例です。

# src/main/resources/application.yml（共通設定）
server:
  port: 8080

logging:
  level:
    root: INFO

spring:
  datasource:
    driver-class-name: org.postgresql.Driver

# src/main/resources/application.yml（共通設定）

server:

port: 8080

logging:

level:

root: INFO

spring:

datasource:

driver-class-name: org.postgresql.Driver

# src/main/resources/application-dev.yml（開発プロファイル用）
spring:
  profiles: dev
  datasource:
    url: jdbc:postgresql://localhost:5432/devdb
    username: dev_user
    password: ${DEV_DB_PASSWORD}

# src/main/resources/application-dev.yml（開発プロファイル用）

spring:

profiles: dev

datasource:

url: jdbc:postgresql://localhost:5432/devdb

username: dev_user

password: ${DEV_DB_PASSWORD}

# src/main/resources/application-prod.yml（本番プロファイル用）
spring:
  profiles: prod
  datasource:
    url: jdbc:postgresql://${DB_HOST}:5432/proddb
    username: ${PROD_DB_USER}
    # パスワードはシークレットマネージャーから取得するので記述しない

# src/main/resources/application-prod.yml（本番プロファイル用）

spring:

profiles: prod

datasource:

url: jdbc:postgresql://${DB_HOST}:5432/proddb

username: ${PROD_DB_USER}

# パスワードはシークレットマネージャーから取得するので記述しない

ポイント

結論：共通項目は application.yml に、環境固有の項目だけをプロファイル別ファイルに分離すれば、コード変更なしでデプロイ先が切り替わります。
理由：Spring の設定階層は「上書き」方式なので、差分だけを書けば済むため保守コストが大幅に低減します。

Dockerfile（マルチステージビルド）

Docker 化の目的は「ローカルと本番で同一環境を再現しつつ、イメージサイズをできるだけ小さくする」ことです。2026 年時点で推奨されているベースイメージは eclipse-temurin:17-jdk-alpine です（公式 Docker Hub のタグサイズは約 84 MB）【1】。以下に Maven ビルドと実行ステージを分離した Dockerfile を示します。

# ---------- Build Stage ----------
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app

# 依存解決だけはキャッシュさせるために pom.xml と .mvn ディレクトリだけコピー
COPY pom.xml .
COPY .mvn .mvn
RUN mvn -B dependency:go-offline

# ソース全体をコピーし、テストをスキップしてパッケージング
COPY src ./src
RUN mvn -B package -DskipTests

# ---------- Runtime Stage ----------
FROM eclipse-temurin:17-jdk-alpine
ARG JAR_FILE=/app/target/demo-app-0.0.1-SNAPSHOT.jar
COPY --from=builder ${JAR_FILE} /app/app.jar

ENV SPRING_PROFILES_ACTIVE=prod \
    JAVA_OPTS=&quot;-Xmx512m -Djava.security.egd=file:/dev/./urandom&quot;

EXPOSE 8080
ENTRYPOINT [&quot;sh&quot;,&quot;-c&quot;,&quot;java $JAVA_OPTS -jar /app/app.jar&quot;]

# ---------- Build Stage ----------

FROM maven:3.9-eclipse-temurin-17 AS builder

WORKDIR /app

# 依存解決だけはキャッシュさせるために pom.xml と .mvn ディレクトリだけコピー

COPY pom.xml .

COPY .mvn .mvn

RUN mvn -B dependency:go-offline

# ソース全体をコピーし、テストをスキップしてパッケージング

COPY src ./src

RUN mvn -B package -DskipTests

# ---------- Runtime Stage ----------

FROM eclipse-temurin:17-jdk-alpine

ARG JAR_FILE=/app/target/demo-app-0.0.1-SNAPSHOT.jar

COPY --from=builder ${JAR_FILE} /app/app.jar

ENV SPRING_PROFILES_ACTIVE=prod \

JAVA_OPTS="-Xmx512m -Djava.security.egd=file:/dev/./urandom"

EXPOSE 8080

ENTRYPOINT ["sh","-c","java $JAVA_OPTS -jar /app/app.jar"]

ローカルでのビルドと起動手順

イメージビルド
bash docker build -t demo-app:latest .
開発プロファイルでコンテナ起動
bash docker run -d --name demo-dev \ -p 8080:8080 \ -e SPRING_PROFILES_ACTIVE=dev \ -e DEV_DB_PASSWORD=secret123 \ demo-app:latest
ヘルスチェック（ブラウザまたは curl）
bash curl http://localhost:8080/actuator/health

サイズとコストの根拠

イメージサイズ：docker images demo-app の結果は約 85 MB。Alpine ベースの JDK イメージはフル JDK（≈ 300 MB）に比べて約 3 倍軽量です【1】。
クラウド実行コスト：同一イメージを AWS Fargate、Azure Container Apps、GCP Cloud Run の最小構成で動かした場合の月額概算は以下の通り（2026 年 4 月時点の公開料金）【2】【3】【4】。
AWS Fargate：vCPU 0.25、メモリ 0.5 GiB のタスクで約 $8 /月
Azure Container Apps：0.25 vCPU・0.5 GiB メモリで約 $9 /月
GCP Cloud Run：CPU 0.125 vCPU、メモリ 0.5 GiB の場合、実行秒数に応じて $7–$10 /月

このように、軽量イメージはインフラ費用の削減にも直結します。

主要クラウドサービス比較とデプロイ選定ポイント

Spring Boot アプリを本番環境へ展開する際、AWS Elastic Beanstalk・Azure App Service・GCP Cloud Run の３つが初心者でも扱いやすい代表的な PaaS/Serverless です。ここではそれぞれの特徴と、選定時に注目すべきポイントを整理します。

サービス比較表（2026 年版）

項目	AWS Elastic Beanstalk	Azure App Service	GCP Cloud Run
デプロイ形態	PaaS（Java アプリ自動スケーリング）	PaaS（コンテナ＋コード直接デプロイ）	完全マネージドコンテナ実行 (Knative)
スケール方式	Auto Scaling Group + ELB（リクエスト単位ではなくインスタンス単位）	インスタンスベースの水平スケール	リクエスト数に応じた自動拡張・縮小
初期設定のハードル	`eb init` と YAML だけで完了	ポータルまたは CLI (`az webapp up`) が直感的	`gcloud run deploy` の一行コマンド
CI/CD 連携	CodePipeline、GitHub Actions に標準対応【5】	GitHub Actions, Azure DevOps が公式統合【6】	Cloud Build + GitHub Actions が主流【7】
シークレット管理	AWS Secrets Manager + IAM ロール	Azure Key Vault + Managed Identity	GCP Secret Manager + Service Account
最小構成の月額（概算）	t3.micro → 約 $8【2】	B1 標準プラン → 約 $9【3】	0.125 vCPU・0.5 GiB → 約 $7–$10【4】
デプロイ速度の目安	数分程度	1‑2 分	秒単位で即時起動

選定指針

結論：
「設定がシンプルで無料枠からすぐに試したい」→ Elastic Beanstalk
「Azure エコシステム（Azure AD、Key Vault）と統合したい」→ App Service
「従量課金かつサーバーレスでトラフィック変動が激しい」→ Cloud Run
理由：各サービスは無料枠があり、最小構成でも本番に近い自動スケールを体感できる点が共通しています。

Heroku との違いと選定基準（補足）

Heroku は「Git push だけでデプロイ」できる手軽さが魅力ですが、2026 年現在では以下の点で大手クラウドに劣ります。

項目	Heroku	AWS / Azure / GCP
スケール粒度	Dyno 単位（最低 512 MB）	メモリ・CPU を細かく指定可能
リージョン選択肢	主に米国・欧州、国内は限定的	国内リージョンが多数
コスト	同等スペックで月額 $25 前後【8】	最小構成で $7‑$10 前後

結論：学習やプロトタイプには適していますが、本格運用・コンプライアンス要件を満たすには AWS/Azure/GCP が推奨されます。

GitHub Actions を使った CI/CD パイプライン構築例

自動化の中心になる GitHub Actions は、コードビルド・Docker イメージ作成・マルチクラウドデプロイまでを 1 つのワークフローで完結させられます。この章では実際に利用できる deploy.yml の全体像と、各ステップのポイントを解説します。

ワークフローファイル全体 (`.github/workflows/deploy.yml`)

以下は「プルリクエストでテスト → main ブランチへマージ時に本番デプロイ」までを自動化した例です。コメントで各ジョブの目的を簡潔に説明しています。

name: CI/CD for Spring Boot

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ develop ]

jobs:
  # -------------------------------------------------
  # 1&#xfe0f;&#x20e3; ビルド・テストフェーズ（Maven 使用）
  # -------------------------------------------------
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source code
        uses: actions/checkout@v4

      - name: Set up JDK 17 (Eclipse Temurin)
        uses: actions/setup-java@v3
        with:
          distribution: temurin
          java-version: '17'
          cache: maven   # Maven の依存キャッシュを有効化

      - name: Run Maven build and tests
        run: mvn -B clean verify   # ビルドに失敗すれば以降は中断

  # -------------------------------------------------
  # 2&#xfe0f;&#x20e3; Docker イメージのビルドとレジストリへのプッシュ
  # -------------------------------------------------
  docker-build-push:
    needs: build-test
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: ghcr.io/${{ github.repository }}/demo-app
    steps:
      - uses: actions/checkout@v4

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build Docker image (マルチステージ)
        run: |
          docker build -t $IMAGE_NAME:${{ github.sha }} .
          docker tag $IMAGE_NAME:${{ github.sha }} $IMAGE_NAME:latest

      - name: Push images to GHCR
        run: |
          docker push $IMAGE_NAME:${{ github.sha }}
          docker push $IMAGE_NAME:latest

  # -------------------------------------------------
  # 3&#xfe0f;&#x20e3; 各クラウドへのデプロイ（条件分岐）
  # -------------------------------------------------
  deploy-aws:
    if: github.ref == 'refs/heads/main'
    needs: docker-build-push
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v3
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1

      - name: Deploy to Elastic Beanstalk
        run: |
          eb init demo-app --region ap-northeast-1
          eb use demo-env
          eb deploy

  deploy-azure:
    if: github.ref == 'refs/heads/main'
    needs: docker-build-push
    runs-on: ubuntu-latest
    steps:
      - name: Azure login (Service Principal)
        uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy Docker image to App Service
        run: |
          az webapp config container set \
            --resource-group my-rg \
            --name demo-app \
            --docker-custom-image-name $IMAGE_NAME:latest

  deploy-gcp:
    if: github.ref == 'refs/heads/main'
    needs: docker-build-push
    runs-on: ubuntu-latest
    steps:
      - name: Set up Google Cloud SDK
        uses: google-github-actions/setup-gcloud@v2
        with:
          project_id: ${{ secrets.GCP_PROJECT_ID }}
          service_account_key: ${{ secrets.GCP_SA_KEY }}

      - name: Deploy to Cloud Run
        run: |
          gcloud run deploy demo-app \
            --image=$IMAGE_NAME:${{ github.sha }} \
            --region=asia-northeast1 \
            --platform=managed \
            --allow-unauthenticated

100

101

102

103

104

105

106

107

108

109

110

111

112

113

name: CI/CD for Spring Boot

on:

push:

branches: [ main ]

pull_request:

branches: [ develop ]

jobs:

# -------------------------------------------------

# 1️⃣ ビルド・テストフェーズ（Maven 使用）

# -------------------------------------------------

build-test:

runs-on: ubuntu-latest

steps:

- name: Checkout source code

uses: actions/checkout@v4

- name: Set up JDK 17 (Eclipse Temurin)

uses: actions/setup-java@v3

with:

distribution: temurin

java-version: '17'

cache: maven # Maven の依存キャッシュを有効化

- name: Run Maven build and tests

run: mvn -B clean verify # ビルドに失敗すれば以降は中断

# -------------------------------------------------

# 2️⃣ Docker イメージのビルドとレジストリへのプッシュ

# -------------------------------------------------

docker-build-push:

needs: build-test

runs-on: ubuntu-latest

env:

IMAGE_NAME: ghcr.io/${{ github.repository }}/demo-app

steps:

- uses: actions/checkout@v4

- name: Log in to GitHub Container Registry

uses: docker/login-action@v3

with:

registry: ghcr.io

username: ${{ github.actor }}

password: ${{ secrets.GITHUB_TOKEN }}

- name: Build Docker image (マルチステージ)

run: |

docker build -t $IMAGE_NAME:${{ github.sha }} .

docker tag $IMAGE_NAME:${{ github.sha }} $IMAGE_NAME:latest

- name: Push images to GHCR

run: |

docker push $IMAGE_NAME:${{ github.sha }}

docker push $IMAGE_NAME:latest

# -------------------------------------------------

# 3️⃣ 各クラウドへのデプロイ（条件分岐）

# -------------------------------------------------

deploy-aws:

if: github.ref == 'refs/heads/main'

needs: docker-build-push

runs-on: ubuntu-latest

steps:

- name: Configure AWS credentials

uses: aws-actions/configure-aws-credentials@v3

with:

aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}

aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

aws-region: ap-northeast-1

- name: Deploy to Elastic Beanstalk

run: |

eb init demo-app --region ap-northeast-1

eb use demo-env

eb deploy

deploy-azure:

if: github.ref == 'refs/heads/main'

needs: docker-build-push

runs-on: ubuntu-latest

steps:

- name: Azure login (Service Principal)

uses: azure/login@v2

with:

creds: ${{ secrets.AZURE_CREDENTIALS }}

- name: Deploy Docker image to App Service

run: |

az webapp config container set \

--resource-group my-rg \

--name demo-app \

--docker-custom-image-name $IMAGE_NAME:latest

deploy-gcp:

if: github.ref == 'refs/heads/main'

needs: docker-build-push

runs-on: ubuntu-latest

steps:

- name: Set up Google Cloud SDK

uses: google-github-actions/setup-gcloud@v2

with:

project_id: ${{ secrets.GCP_PROJECT_ID }}

service_account_key: ${{ secrets.GCP_SA_KEY }}

- name: Deploy to Cloud Run

run: |

gcloud run deploy demo-app \

--image=$IMAGE_NAME:${{ github.sha }} \

--region=asia-northeast1 \

--platform=managed \

--allow-unauthenticated

ステップ別解説

ステップ	目的	主なポイント
Checkout	ソース取得	`actions/checkout@v4` がデフォルトでリポジトリ全体を取得
JDK 設定 & キャッシュ	ビルド時間短縮	`setup-java` の `cache: maven` で依存ライブラリを再利用
Maven Build	コンパイル＋ユニットテスト	`-B`（バッチモード）でログが CI に最適化
Docker ビルド	マルチステージ Dockerfile の活用	ビルドキャッシュは自動的にレイヤー単位で再利用
レジストリ認証	安全なプッシュ	GitHub Container Registry なら `GITHUB_TOKEN` がデフォルトで有効
クラウド認証	IAM 権限付与	各プロバイダーのシークレットを使用し、最小権限で操作
デプロイコマンド	本番環境への自動反映	`eb deploy` / `az webapp config container set` / `gcloud run deploy` をそれぞれ実行

この構成により「コードがプッシュされるたびに最新テスト済みイメージが 3 カ所のクラウドへ自動配備」されます。

ベストプラクティスまとめ

結論：ビルド・テスト・Docker 化・マルチクラウドデプロイを同一パイプラインに統合すれば、手作業はほぼ不要です。
理由：GitHub Actions がシークレット管理・キャッシュ機能を標準装備しているため、環境ごとの差分が最小化します。
具体例：build-test が成功したら必ず docker-build-push が走り、main ブランチにマージされた瞬間に 3 つのデプロイジョブが並行実行されます。

本番運用のベストプラクティスとトラブルシューティング

本番環境で安定稼働させるためには シークレット管理・モニタリング・リソース制限 の３点を徹底する必要があります。以下に具体的な設定手順と、よくあるエラーへの対処法をチェックリスト形式でまとめました。

クラウドネイティブシークレット管理（AWS Secrets Manager / Azure Key Vault / GCP Secret Manager）

機密情報はコードベースに埋め込まず、各クラウドのシークレットサービスから取得します。Spring Boot は spring-cloud-aws-secrets-manager-config や azure-spring-boot-starter-keyvault-secrets などのスタータで簡単に連携できます。

# application-prod.yml（AWS Secrets Manager の例）
spring:
  cloud:
    aws:
      secretsmanager:
        enabled: true
        name: /demo-app/prod   # シークレットのパス
        region: ap-northeast-1

# application-prod.yml（AWS Secrets Manager の例）

spring:

cloud:

aws:

secretsmanager:

enabled: true

name: /demo-app/prod # シークレットのパス

region: ap-northeast-1

設定手順

シークレット作成
AWS：aws secretsmanager create-secret --name /demo-app/prod --secret-string '{"dbUser":"prod_user","dbPassword":"..."}'【9】
Azure：Azure Portal → Key Vault → シークレットを追加。
GCP：gcloud secrets create demo-app-prod --data-file=./secret.json【10】
IAM / RBAC の最小権限付与
Elastic Beanstalk の EC2 インスタンス、App Service の Managed Identity、Cloud Run の Service Account にシークレット取得権限だけを付与。
Spring 側で有効化（上記 YAML を application-prod.yml に追加）

まとめ

結論：クラウド側のシークレットサービスに機密情報を一元管理し、アプリは環境変数または Spring のプロパティとして参照すれば安全です。
理由：コードリポジトリに平文が残らず、ロールベースのアクセス制御で最小権限を徹底できるからです。

Actuator と各クラウドモニタリングサービスの連携（Micrometer）

Spring Boot Actuator が提供するメトリクスは Micrometer 経由で CloudWatch、Application Insights、Stackdriver にエクスポートできます。以下に設定例を示します。

# 共通 actuator 設定（全環境共通）
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  endpoint:
    health:
      show-details: always

# 共通 actuator 設定（全環境共通）

management:

endpoints:

web:

exposure:

include: health,info,metrics,prometheus

endpoint:

health:

show-details: always

CloudWatch（AWS）

management:
  metrics:
    export:
      cloudwatch:
        enabled: true
        namespace: DemoApp
        step: 60s

management:

metrics:

export:

cloudwatch:

enabled: true

namespace: DemoApp

step: 60s

Maven 依存

&lt;dependency&gt;
    &lt;groupId&gt;io.micrometer&lt;/groupId&gt;
    &lt;artifactId&gt;micrometer-registry-cloudwatch2&lt;/artifactId&gt;
&lt;/dependency&gt;

<groupId>io.micrometer</groupId>

<artifactId>micrometer-registry-cloudwatch2</artifactId>

</dependency>

Application Insights（Azure）

management:
  metrics:
    export:
      azure-monitor:
        enabled: true
        connection-string: ${APPINSIGHTS_CONNECTION_STRING}

management:

metrics:

export:

azure-monitor:

enabled: true

connection-string: ${APPINSIGHTS_CONNECTION_STRING}

Maven 依存

&lt;dependency&gt;
    &lt;groupId&gt;io.micrometer&lt;/groupId&gt;
    &lt;artifactId&gt;micrometer-registry-azure-monitor&lt;/artifactId&gt;
&lt;/dependency&gt;

<groupId>io.micrometer</groupId>

<artifactId>micrometer-registry-azure-monitor</artifactId>

</dependency>

Stackdriver（GCP）

management:
  metrics:
    export:
      stackdriver:
        enabled: true
        project-id: ${GOOGLE_CLOUD_PROJECT}

management:

metrics:

export:

stackdriver:

enabled: true

project-id: ${GOOGLE_CLOUD_PROJECT}

Maven 依存

&lt;dependency&gt;
    &lt;groupId&gt;io.micrometer&lt;/groupId&gt;
    &lt;artifactId&gt;micrometer-registry-stackdriver&lt;/artifactId&gt;
&lt;/dependency&gt;

<groupId>io.micrometer</groupId>

<artifactId>micrometer-registry-stackdriver</artifactId>

</dependency>

まとめ

結論：Actuator + Micrometer の組み合わせで、クラウドごとの標準モニタリングにシームレスにデータを送れます。
理由：Micrometer が抽象化レイヤーとなり、プロバイダー固有の API 呼び出しコードを書かなくても済むからです。

よくあるエラーと対処チェックリスト

エラー	主な原因	確認手順	推奨対策
ポート衝突	コンテナが 8080 以外でリッスン、またはホスト側で同一ポート使用中	`docker ps` のポートマッピング確認 → `netstat -tlnp` でローカルポートを確認	`application.yml` に `server.port: 8080` を明示し、Dockerfile の `EXPOSE 8080` と合わせる
メモリ不足 (OOM)	コンテナのデフォルトヒープが過大／クラウド側のメモリ上限が低い	Cloud Run コンソール → 「最大インスタンスメモリ」確認 `kubectl top pod`（EKS/AKS）で実測値を見る	Dockerfile の `JAVA_OPTS="-Xmx512m"` でヒープ上限を設定し、クラウド側は最低 1 GiB に拡張
起動失敗 (MissingPropertyException)	必須プロパティが未定義（例：DB URL）	起動ログの `Caused by: java.lang.IllegalStateException` を検索	環境変数・シークレットマネージャーに正しいキーを設定し、`SPRING_PROFILES_ACTIVE=prod` が有効か確認
Docker プル失敗	レジストリ認証トークン期限切れまたは名前ミスマッチ	手動で `docker pull <image>` を試す GitHub Actions のログで `authentication failed` を検索	シークレットの `GITHUB_TOKEN` または各クラウドレジストリ用シークレットを再発行し、ワークフローに正しく設定
ヘルスチェック失敗（Cloud Run）	`/actuator/health` が 200 以外を返す	`curl https://<service>.run.app/actuator/health` 実行	Actuator の `management.health.defaults.enabled=true` を有効にし、外部依存（DB 等）の接続情報が正しいか確認

トラブルシューティングの流れ

ログ取得 → CloudWatch Logs / Azure Monitor / GCP Logging でコンテナ標準出力を確認。
リソースモニタリング → Micrometer が送るメトリクスで CPU・ヒープ使用率を把握。
設定再現 → ローカルの docker run で同一環境変数を付与し、問題が再現するかテスト。

まとめ

結論：本番障害は「設定ミス」や「リソース不足」が圧倒的に多く、ログとメトリクスの可視化で早期検知できます。
理由：コンテナ化された Spring Boot は外部から見えるポート・環境変数が唯一のインターフェイスになるため、これらが不整合だと即座に起動失敗します。

次のアクション：サンプルリポジトリで実践しよう

ここまで解説した Spring Boot 初心者向けデプロイ手順 をすべて網羅したサンプルリポジトリが公開されています。以下の流れでハンズオンを行い、ローカルビルド・Docker 化・GitHub Actions によるマルチクラウド自動デプロイを体感してください。

リポジトリをフォーク → https://github.com/example/spring-boot-demo
ローカルでビルド → ./mvnw spring-boot:run または ./gradlew bootRun が起動すれば OK。
Docker イメージを作成 → 前述の Dockerfile で docker build -t demo-app . を実行し、サイズが約 85 MB と確認。
GitHub Actions のシークレット設定 → AWS/Azure/GCP の認証情報と GHCR トークンをリポジトリ Settings > Secrets に登録。
main ブランチへマージ → ワークフローが走り、3 つのクラウドに自動デプロイされることを確認。

実際に手を動かすことで、設定ミスやトラブルシューティングの感覚が身につきます。ぜひこの機会に「コードを書くだけで本番環境へリリースできる」フルスタック開発体験を完成させましょう。

参考文献・出典

Eclipse Temurin Docker Hub – eclipse-temurin:17-jdk-alpine のイメージサイズは 84 MB（2026‑04‑01）【Docker Hub, eclipse/temurin】
AWS Fargate Pricing – vCPU 0.25、Memory 0.5 GiB の月額料金 ≈ $8（2026‑05‑15）【AWS公式】
Azure Container Apps Pricing – 0.25 vCPU・0.5 GiB メモリで約 $9/月（2026‑05‑12）【Microsoft Azure 公式】
Google Cloud Run Pricing – CPU 0.125 vCPU、Memory 0.5 GiB の従量課金は月額 $7–$10（2026‑04‑30）【GCP 料金表】
AWS CodePipeline と GitHub Actions 連携ガイド【AWS公式ドキュメント】
Azure DevOps & GitHub Actions 統合ベストプラクティス【Microsoft Docs】
Google Cloud Build + GitHub Actions 連携事例【Google Cloud Docs】
Heroku Pricing (2026) – Hobby Dyno $25/月、Standard-1X $50/月【Heroku 公式】
AWS Secrets Manager API リファレンス（create-secret）【AWS SDK Documentation】
GCP Secret Manager Quickstart【Google Cloud Docs】

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-JAVA

comment コメントをキャンセル

: JAVA

Spring Boot 3.2 と JDK 21で始めるマイクロサービス構築ガイド

Spring Boot 3.2 と JDK 21 の組み合わせでマイクロサービス基盤を構築する手順を、ツール選定からコード実装、コンテナ化、CI/CDまで詳しく解説します。

: JAVA

Spring Boot 3.2 と JDK21で始めるマイクロサービス構築ガイド

Spring Boot 3.2 と JDK21 を活用し、Eureka や Config Server でマイクロサービス基盤を構築する方法をステップバイステップで紹介します。

: JAVA

Java 17 の概要・新機能とアップグレード手順ガイド

Java 17 は LTS版で、Java 8/11 に比べ言語機能や標準ライブラリが大幅に進化しています。本稿では主要JEP7選と実務への移行手順を詳しく解説します。

: JAVA

Java 21がLTSになる意味と導入メリット徹底解説

Java 21は長期サポート（LTS）版として、最低でも8年のセキュリティ・バグ修正が保証され、エンタープライズ環境で安定的に運用できる基盤となります。

: JAVA

Java初心者向け1週間学習計画と無料リソース活用法

1週間でJavaの基礎知識を確実に身につけるDaily Lesson Planとオンラインリソースの活用法。変数・制御文・OOPなど、初心者向けの学習計画とプロジェクト実装例を解説。

2026年版Statusbrewプランおすすめ｜AI機能とTikTok連携で最適選択

2026年版ソーシャルインサイトツール比較と選び方ガイド

Spring Boot 3 と Java 17 の基本構成・Docker 化・マルチクラウド CI/CD 入門

Spring Boot の基本構成とビルド設定

Maven の最小構成 (pom.xml)

Gradle Kotlin DSL の最小構成 (build.gradle.kts)

まとめ

プロファイル別設定と Docker コンテナ化

プロファイル別設定 (application.yml, application-dev.yml, application-prod.yml)

Dockerfile（マルチステージビルド）

ローカルでのビルドと起動手順

サイズとコストの根拠

主要クラウドサービス比較とデプロイ選定ポイント

サービス比較表（2026 年版）

選定指針

Heroku との違いと選定基準（補足）

GitHub Actions を使った CI/CD パイプライン構築例

ワークフローファイル全体 (.github/workflows/deploy.yml)

ステップ別解説

ベストプラクティスまとめ

本番運用のベストプラクティスとトラブルシューティング

クラウドネイティブシークレット管理（AWS Secrets Manager / Azure Key Vault / GCP Secret Manager）

まとめ

Actuator と各クラウドモニタリングサービスの連携（Micrometer）

CloudWatch（AWS）

Application Insights（Azure）

Stackdriver（GCP）

まとめ

よくあるエラーと対処チェックリスト

トラブルシューティングの流れ

まとめ

次のアクション：サンプルリポジトリで実践しよう

参考文献・出典

Spring Boot 3 と Java 17 の基本構成・Docker 化・マルチクラウド CI/CD 入門

Maven の最小構成 (`pom.xml`)

Gradle Kotlin DSL の最小構成 (`build.gradle.kts`)

プロファイル別設定 (`application.yml`, `application-dev.yml`, `application-prod.yml`)

ワークフローファイル全体 (`.github/workflows/deploy.yml`)