Docker 入門と実践

Docker は、アプリと、それが動くのに必要なもの（OS のライブラリ、Java などの実行環境、設定ファイル）を一つの箱（コンテナ）にまとめて、どこでも同じように動かすための仕組みです。2013年に公開され、いまではアプリの配布と実行の標準的な形になっています。

たとえるなら輸送用のコンテナです。中身が家具でも食品でも、規格の決まった箱に入れてしまえば、船・トラック・鉄道のどれでも同じように運べます。Docker のコンテナも、中身が Java のアプリでも DB でも、Docker があるマシンならどこでも同じ手順で起動できます。

「環境をまるごと用意する」なら、昔から仮想マシン（VM）がありました。違いは、OS をどこまで持つかです。

どちらが上というより、役割が違います。クラウドでも社内でも、「VM の上で Docker を動かす」のがごく普通の構成です。VM で機械を分け、コンテナでアプリを分ける、と考えるとわかりやすいでしょう。

イメージはOCIという業界標準の形式なので、Docker で作ったイメージは Podman や Kubernetes など、ほかの道具でもそのまま動きます。

ここからは、顧客向けの業務 Web システム（顧客管理などの CRM）を例にします。構成は、いまの Java 案件で多いSpring Boot（Java）の API と、Vue の画面、PostgreSQL の DBです。

この記事のサンプル（Spring Boot 4.1.1・Java 25、Vue 3、nginx 1.30、PostgreSQL 18）は、筆者が Docker Engine 29 と Compose v5 で、ビルドから起動、更新、ロールバックまで実際に動かして確かめたものです。

まずは一番効果が大きく、リスクの小さいところから。DB だけをコンテナにします。プロジェクトの直下に次の compose.yaml を置きます。

# crm/compose.yaml（開発用：DB だけ）
services:
  postgres:
    image: postgres:18          # 本番と同じメジャーバージョンに
    environment:
      POSTGRES_DB: crm
      POSTGRES_USER: crm
      POSTGRES_PASSWORD: secret
    ports:
      - "5432"                  # PC 側の空いている番号に自動で割り当て

Spring Boot には Docker Compose との連携機能（spring-boot-docker-compose）があります。依存関係に加えておくと、IDE でアプリを起動したときに Spring Boot が自動で docker compose up を実行し、DB の接続先もコンテナに合わせて設定してくれます。application.properties に接続先を書く必要すらありません。

# アプリを起動したときのログ（抜粋・実際の出力）
DockerComposeLifecycleManager : Using Docker Compose file .../crm/compose.yaml
DockerCli : Container crm-postgres-1 Started
DockerCli : Container crm-postgres-1 Healthy
DbMigrate : Migrating schema "public" to version "1 - create customer"
CrmApplication : Started CrmApplication in 7.271 seconds

テストでは Testcontainers が使えます。テストの実行中だけ本物の PostgreSQL を起動し、終わったら片づけます。Spring Boot なら @ServiceConnection を付けるだけで接続が設定されます。

// テスト用の設定（Spring Initializr が生成するものとほぼ同じ）
@TestConfiguration(proxyBeanMethods = false)
class TestcontainersConfiguration {
    @Bean
    @ServiceConnection
    PostgreSQLContainer postgresContainer() {
        return new PostgreSQLContainer(DockerImageName.parse("postgres:18"));
    }
}

次は Spring Boot のアプリそのものをイメージにします。ポイントはマルチステージビルド。ビルド用（JDK と Maven 入り）と実行用（JRE だけ）を分けて、本番のイメージにはコンパイラもソースも入れません。

# crm/Dockerfile
# syntax=docker/dockerfile:1

# ---- 1. ビルド用ステージ（JDK と Maven で jar を作る）----
FROM eclipse-temurin:25-jdk AS build
WORKDIR /src
COPY .mvn/ .mvn/
COPY mvnw pom.xml ./
RUN --mount=type=cache,target=/root/.m2 ./mvnw -B -q dependency:go-offline
COPY src/ src/
RUN --mount=type=cache,target=/root/.m2 ./mvnw -B -q -DskipTests package

# ---- 2. 実行用ステージ（JRE だけの小さなイメージ）----
FROM eclipse-temurin:25-jre
WORKDIR /app
RUN useradd --system --uid 10001 app
COPY --from=build /src/target/crm-*.jar app.jar
USER app
EXPOSE 8080
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]

• 依存ライブラリを先にコピー ── pom.xml が変わらなければ、ライブラリの取得はキャッシュが効いて飛ばされます。ソースを少し直しただけなら、ビルドは数秒〜数十秒
• root で動かさない ── 専用のユーザー（app）で実行し、万一のときの被害を小さく
• メモリは割合で ── -XX:MaxRAMPercentage=75 で、コンテナに割り当てたメモリの75%をヒープの上限に
• Dockerfile を書かない方法も ── Spring Boot の ./mvnw spring-boot:build-image なら、Buildpacks で自動的にイメージを作れます

画面（Vue）も同じ考え方です。node でビルドし、できた静的ファイルだけを nginx のイメージに入れます。

# web/Dockerfile
FROM node:24-alpine AS build
WORKDIR /web
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:1.30-alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /web/dist /usr/share/nginx/html

# web/nginx.conf
server {
    listen 80;
    root /usr/share/nginx/html;

    location / {                       # Vue の画面（SPA）
        try_files $uri $uri/ /index.html;
    }
    location /api/ {                   # API は Spring Boot のコンテナへ
        proxy_pass http://app:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

proxy_pass http://app:8080 の app は、次の Compose ファイルのサービス名です。IP アドレスを書かなくても、名前で相手に届きます。

サーバー1台で動かす規模なら、Docker Compose がいちばん手軽です。検証サーバーと本番サーバーに、同じ compose.yaml を置きます。

# deploy/compose.yaml（検証・本番用）
services:
  web:                      # Vue の画面 + 入口（nginx）
    image: registry.example.com/crm/web:${TAG}
    ports:
      - "80:80"
    depends_on:
      - app
    restart: unless-stopped

  app:                      # Spring Boot の業務アプリ
    image: registry.example.com/crm/app:${TAG}
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/crm
      SPRING_DATASOURCE_USERNAME: crm
      SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
      TZ: Asia/Tokyo
    depends_on:
      db:
        condition: service_healthy   # DB の準備ができてから起動
    restart: unless-stopped

  db:                       # PostgreSQL（データはボリュームに保存）
    image: postgres:18
    environment:
      POSTGRES_DB: crm
      POSTGRES_USER: crm
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      TZ: Asia/Tokyo
    volumes:
      - db-data:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U crm -d crm"]
      interval: 5s
      retries: 10
    restart: unless-stopped

volumes:
  db-data:

# deploy/.env（サーバーごとに置く。Git には入れない）
TAG=1.0.0
DB_PASSWORD=change-me

• バージョンは TAG の1か所だけ ── どの版を動かすかは .env で決まります
• パスワードはファイルの外へ ── Compose ファイルには書かず、.env や秘密情報の仕組みで渡します
• PostgreSQL 18 のボリューム ── 18 からはデータの場所が変わり、ボリュームは /var/lib/postgresql にマウントします（17 以前は /var/lib/postgresql/data）
• restart: unless-stopped ── サーバーの再起動後やアプリが落ちたときに、自動で立ち上がります

起動は docker compose up -d の一言です。記事冒頭の画面が、その実際の出力です。DB が healthy になるのを待ってからアプリが起動しているのがわかります。

バージョンアップは、.env の TAG を書き換えて、もう一度 docker compose up -d するだけ。変わったサービスだけが作り直され、DB はそのまま動き続けます。

データの持ち方が変わる更新（表の追加など）は、アプリの起動時に Flyway などで自動で反映するようにしておくと、イメージの入れ替えだけで済みます。ロールバックで DB をどう戻すかは、事前に決めておきましょう（戻せる変更にする、または更新前にバックアップを取る）。

運用

• 状態がひと目でわかる ── docker compose ps で全サービスの状態、docker compose logs -f app でアプリのログ。どのサーバーでも同じコマンド
• 自動で立ち直る ── 再起動ポリシーとヘルスチェックで、落ちたコンテナが自動で起動し直す
• 環境の違いによる障害が減る ── 「本番だけ文字化けする」「本番だけ動かない」の原因になりがちな、OS やライブラリの差がなくなる
• リソースを区切れる ── コンテナごとに CPU やメモリの上限を決められ、一つの暴走が全体を巻き込みにくい
• 規模が大きくなっても同じイメージ ── 利用者が増えたら、同じイメージのまま Kubernetes やクラウドのコンテナサービスへ移れる

保守

はじめから全部をコンテナにする必要はありません。おすすめの順番は、① 開発用の DB → ② テスト（Testcontainers）→ ③ CI でのイメージ作成 → ④ 検証環境 → ⑤ 本番。前の段階の効果を確かめながら、一歩ずつ進めましょう。