Docker Compose - 複数コンテナアプリケーションの定義と実行ツール

2025年9月19日現在、Docker Compose、最新のv2.39.4が出てる。Docker Inc.が開発してるから安心だ。複数のDockerコンテナで構成されるアプリケーションを、単一のdocker-compose.yml YAMLファイルで定義・実行できる。Compose Specificationに従って標準化されており、公式ドキュメントでは詳細な仕様が説明されている。

なんでこんなに神ツールなのか

手動でコンテナ管理とか、今思うと頭おかしかった。WebアプリとPostgreSQLとRedisとNginx、全部別々にdocker runで起動して、ポート番号とか覚えてられないし、IP変わったら全部設定し直しだし。5個のコンテナ立ち上げるのに毎回1時間とかかかってた。

Docker Compose使ったら：

• docker-compose up一発で全部起動。終了。
• 依存関係？勝手に順番守って起動してくれる
• ネットワーク？コンテナ名で通信できる
• データ？ボリューム設定で永続化
• 設定？.envファイル一個で終わり

実際の使用例

前の会社でもメルカリでも使ってたし、友達がいるサイバーエージェントでも普通に使ってる。特に開発環境やCI/CDパイプラインで威力を発揮する。GitHub ActionsやGitLab CIでの自動化も簡単だ。

version: '3.8'
services:
  web:
    build: .
    ports:
      - \"3000:3000\"
    depends_on:
      - db
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: password

手動コンテナ管理の地獄

あの頃の俺らは何やってたんだろうな：

• ポート番号競合でEADDRINUSE、毎回lsof -ti:8080 | xargs kill
• コンテナ間通信？IPアドレス手動で調べて書き換えて
• 新人「環境構築できません」→俺「また？」の無限ループ
• 本番「DBに接続できません」→あ、ポート番号typoしてた
• docker run5回叩いてる間に他のコンテナ死んでる

Docker Composeならこの地獄が終わる。YAMLに書いてdocker-compose up。それだけ。

俺の黒歴史: 昔、5個のサービスを手動で起動してた。毎朝30分かけてdocker runコマンドを5回叩いて、ポート番号間違えて、DB接続URLタイポして、結局動かなくて1時間無駄にしてた。Docker Compose導入したら1コマンドで全部起動。あの苦労は何だったのか。

結論： 5個のサービスを手動で管理してたあの日々がウソみたいだ。今はYAMLファイル一個でWebアプリもDBもRedisもNginxも全部面倒見てくれる。

パフォーマンスとスケール

Docker ComposeはGoで書かれてて、起動がクソ速い。昔のPython版は重くて使い物にならなかった。

Kubernetesとかいう化け物と比較されがちだけど、正直99%の会社にK8sはオーバーキル。「将来Netflixレベルのスケールが」とか言ってK8s導入したプロジェクト、大体そのスケールに到達する前にチーム全員疲弊して転職してる。前の会社でも「k8s勉強会」とかやってたけど、結局Docker Composeで十分だった。

Docker Desktopでは、macOSやWindows上でもLinuxコンテナを動かせるので、日本のMacユーザーが多い開発現場でも問題なく使える。

なんで今さら学ぶ必要あるのか

コンテナは逃げられない。AWS ECS、Azure AKS、GCP GKE、どこもコンテナ前提。「俺はVMで十分」とか言ってたら、転職の時にポートフォリオ見せられない。

Docker Composeできれば、次にKubernetes触っても「あーこれComposeの複雑版ね」で理解できる。実際、Compose BridgeでComposeからK8sマニフェスト生成できるし。

要は、Docker Compose = コンテナ管理の基礎。これ分からずにK8s行くとか、ひらがな読めずに小説読むようなもん。

インストールと基本操作

Docker ComposeはDocker Desktopに標準で含まれている。Linuxの場合は個別にインストールが必要だ。詳しいインストール手順は公式ガイドを参照。

macOS/Windows（Docker Desktop）:

## 確認
docker-compose --version
## または新しい構文
docker compose version

Linux（スタンドアロン）:

sudo curl -L "https://github.com/docker/compose/releases/download/v2.39.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

実際にやってるワークフロー

俺らが毎日やってることは：

1. プロジェクト構造を作る

my-app/
├── docker-compose.yml
├── .env
├── app/
│   └── Dockerfile
└── db/
    └── init.sql

2. docker-compose.ymlを書く

version: '3.8'
services:
  app:
    build: ./app
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
      - NODE_ENV=production
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - ./app:/code
    deploy:
      resources:
        limits:
          memory: 512M
      
  db:
    image: postgres:13
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER}"]
      interval: 5s
      timeout: 5s
      retries: 5
    command: postgres -c log_statement=all

volumes:
  postgres_data:

運用で学んだハマりポイント

バージョン固定しろ、絶対に

latestタグとかいう悪魔を使うな。去年、node:latestで本番デプロイしたら、翌朝「サイト見れません」の連絡。Node 20になってて、ES modulesの扱いが変わってた。金曜夜にnode:18に戻して逃げたけど、2時間のダウンタイム。バージョン固定は宗教。

## ダメな例（本番で死ぬ）
image: node:latest
image: postgres

## まともな例
image: node:18
image: postgres:15

新人が.envファイルをcommitしちゃった話

新人が.envファイルcommitしちゃって、パスワードとかAPI keyが見えちゃってた。急いで履歴から消したけど冷や汗もの。GitHubにDB接続情報とかが普通に見える状態で2日くらい放置されてた。以降、新人には「.gitignore確認しろ」って口酸っぱく言ってる。

## .env
DB_PASSWORD=super_secret_password
REDIS_URL=redis://localhost:6379
API_KEY=your-api-key-here

ボリュームで3時間溶かした話

• Named volumeとbind mount？最初分からず適当に設定
• Linux権限地獄でpermission denied、chown 1000:1000で解決
• macOSで異常に遅い→cached指定で改善

ネットワークは自動でやってくれる

同じComposeの中なら、サービス名でアクセスできる。db:5432とかredis:6379とか。IPアドレス調べる必要なし。

ネットワークの理解:

networks:
  frontend:
  backend:
    internal: true

本番環境での考慮事項

Docker Composeを本番で使う場合の注意点：

セキュリティ:

• rootless Dockerの使用
• Secretsの適切な管理
• ネットワークセグメンテーション
• 本番運用ガイドを必ず読む

監視とログ:

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

バックアップ戦略:

## データベースバックアップの自動化
docker-compose exec db pg_dump -U user mydb > backup.sql

日本特有の問題

文字エンコーディングで死んだ話:
ユーザー名に日本語が入ってて、ログに文字化けが出てた。1週間気づかずに「なんで検索ヒットしないんだ？」って悩んでた。

environment:
  - LANG=ja_JP.UTF-8
  - LC_ALL=ja_JP.UTF-8

タイムゾーン:

environment:
  - TZ=Asia/Tokyo
volumes:
  - /etc/localtime:/etc/localtime:ro

CI/CDパイプラインでの活用:

Docker Composeは開発からテスト、本番デプロイまで一貫した環境を提供する。GitHubアクションやGitLab CIとの統合も簡単だ。

Docker Compose v2の新機能

2025年現在、v2系が主流で、いくつかの便利な機能が追加された：

• Profiles: 環境別の設定分離
• GPU support: AI/ML workloadに対応
• Better build caching: BuildKitとの統合
• Multi-platform builds: ARM64/AMD64対応
• develop.watch: ファイル監視機能（まあまあ便利）
• Volume management: docker-compose volume コマンド対応

services:
  ml-service:
    profiles: ["gpu"]
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

レジストリとの統合:

Docker HubやプライベートレジストリからのイメージPullや、ビルドしたイメージのPushもdocker-composeコマンドで管理できる。

このレベルの機能があれば、中小企業の開発・本番環境は十分回る。Kubernetesに移行する前に、まずDocker Composeを完全に理解することが重要だ。