Docker入門：Dockerfile・Composeでローカル開発環境を完全コンテナ化

本記事には広告が含まれています

2025/06/20

Docker入門：Dockerfile・Composeでローカル開発環境を完全コンテナ化

ローカル開発がうまく動かない――そんな悩みをDockerで一気に解決します。Dockerfileの書き方からCompose連携、ボリューム管理まで順を追って解説します。

Dockerとは？メリットと基本概念

Dockerはアプリケーションとその実行環境をイメージという雛形に封入し、コンテナとして実行することで「動く・動かない」問題を根本から解消するプラットフォームです。

ローカルでも本番でも同じイメージを走らせるだけなので環境差異がほぼゼロになり、チーム開発やCI/CDが劇的にシンプルになります。

従来のローカル環境と Docker の違い

項目	従来のローカル環境	Docker コンテナ
構築速度	手動設定で数十分〜	イメージ展開で数秒〜数分^*1
再現性	PCごとに差異が出やすい	どこでも同じバイナリが動作
依存関係	バージョン衝突の恐れ	コンテナごとに完全隔離
共有方法	手順書を配布	イメージを配布

*1 展開時間はイメージサイズとネットワーク速度に依存します。

再現性と共有コストを比べると、プロジェクト規模が大きくなるほどDocker化のメリットも膨らみます。

イメージとコンテナの役割

イメージは実行環境のスナップショット、コンテナはそのイメージを元に起動した実プロセスと覚えるとわかりやすいです。ステージング環境やテスト環境を複製する際も、同一イメージから複数コンテナを起動するだけで済みます。

事前準備：Docker Desktop／代替ツールのインストール

対応 OS と最小要件

2025年6月時点のDocker Desktop公式要件は以下のとおりです。

Windows：Windows 10 64‑bit Home/Pro 22H2 (build 19045) 以上または Windows 11 22H2 以上
macOS：最新バージョンを含む直近3世代（現在は Sonoma / Ventura / Monterey）
Linux：Ubuntu, Debian, Fedora など主要ディストリビューション

メモリは4 GB以上が必須、8 GB以上で快適。CPUコア数は明示されていませんが、4コア相当でスムーズに動作します。

代替：Colima（macOS）の活用

macOSユーザーで軽量・オープンソースを求める場合は colima が人気です。Apple Silicon (M1/M2/M3) に最適化され、商用利用でも無料。

Homebrewなら brew install colima → colima start ですぐ起動できます。Docker Desktopが不要になるため、ライセンスコストやメモリ消費を抑えたい方に好適です。
参考：Colima GitHub

インストール後の確認

ターミナルで docker version を実行し、Client と Server の両方が表示されれば準備完了です。Windowsの場合はWSL2バックエンドを選択するとI/O性能が向上します。

Dockerfile の書き方：最小構成から始めよう

ベースイメージ選定のコツ

軽量サイズを重視するなら debian:bookworm-slim や alpine:latest が便利ですが、Alpineは musl libc ベースのため glibc 依存ライブラリが多い場合は ubuntu:24.04 などフルディストロを選ぶとトラブルを回避できます。

RUN / COPY / CMD の役割を理解する

RUN：ビルド時にコマンドを実行し、レイヤーを生成
COPY / ADD：ホストからコンテナへファイルを取り込む
CMD / ENTRYPOINT：コンテナ起動時に実行するデフォルトコマンド

レイヤーキャッシュを活かすため、依存インストールとアプリ配置を分けるのが高速化の基本です。

ベストプラクティス集

--no-install-recommends で不要パッケージを抑制
ビルド後に rm -rf /var/lib/apt/lists/* でキャッシュ削除
.dockerignore で余計なファイルを除外（例：node_modules/、.git/、*.log などを除くと、ビルドが軽量化されます）
USER app でroot権限を避ける

Docker Compose で複数サービスをつなぐ

compose.yaml の基本構造（versionフィールドは不要）

2024年以降、Compose Specificationに統合されversion:フィールドは無視されます。最小例は次のとおりです。

services:
  app:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
    depends_on:
      - db
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data:

PostgreSQLは最新安定版（執筆時点で17）を指定し、リリースサイクルの短い環境でも保守コストを抑えます。

環境変数とシークレットの扱い

公開してよい設定値は .env へ、機微情報はComposeの secrets セクションでファイルマウントする方法が推奨されています。SwarmでなくてもCompose単体で利用可能です。

サービス連携のサンプル

Redisを追加する場合は redis: サービスを追記し、アプリ側で REDIS_HOST=redis を設定します。Composeが生成するユーザー定義ブリッジネットワークではサービス名がそのままDNS解決されるため、redis:6379 で接続できます。

ボリュームとネットワーク設定：データ永続化と通信

ボリュームの正式分類

volumes（名前付き／匿名）: Docker管理領域に保存。バックアップが容易。
bind mounts: ホストディレクトリをそのままマウント。開発時のホットリロードに便利。
tmpfs: メモリ上のみ。テスト用の高速I/Oに。

開発ではbind mount、本番ではvolumesを使い分けるのが一般的です。

ネットワークモード

Composeはデフォルトでユーザー定義ブリッジネットワークを作成します。同一Composeファイル内のサービスはサービス名で相互にDNS解決され、ポート番号のみ指定すればOKです。パフォーマンス重視ならdriver: bridgeで専用ネットワークを作るか、シンプルな開発用途ではnetwork_mode: hostも選択肢になります（※このモードはLinux環境でのみ利用可能であり、macOSやWindowsではサポートされていません）。

デバッグと開発効率：快適なローカル開発のために

ログと状態確認

リアルタイムログは docker compose logs -f --tail 100 が便利。コンテナシェルに入るときは docker exec -it <container> /bin/bash を使います。

ホットリロードと自動再起動

Node.jsならnodemon、Pythonならwatchdogを使い、bind mountでコードを共有すると保存と同時にリロードされます。プロダクション向けDockerfileを汚さずに済むよう、Composeのprofiles機能で開発用サービスを有効・無効に切り替えると便利です。

Compose Override で環境ごとに調整

docker-compose.override.ymlはdocker compose up時に自動マージされます。CIでは--profile prodを指定し、不要サービスを除外することでパイプラインを高速化できます。

よくある質問（FAQ）

イメージサイズが肥大化したときは？: マルチステージビルドで不要ファイルを除外し、docker image pruneでキャッシュを整理してください。
コンテナがすぐ落ちる場合は？: docker logsでスタックトレースを確認し、エントリーポイントの戻り値や環境変数を見直します。
Windowsでパーミッションエラーが出るときは？: WSL2経由のファイル共有では改行コードと権限に注意してください。