Docker Compose完全攻略！開発環境構築から運用まで主要コマンドとyml設定を徹底解説

Docker Composeの全体像：コンテナ連携の基本概念と導入メリット

Docker Composeが解決する「Works on my machine」問題

開発現場で「私の環境では動くのに！」という問題に直面したことはありませんか？これは、開発者ごとにOSやインストールされているミドルウェアのバージョンが異なるために発生する、典型的な「Works on my machine」問題です。Docker Composeは、この問題を根本から解決するために設計されました。複数のコンテナで構成されるアプリケーションの実行環境を、一つの設定ファイル（docker-compose.yml）で定義し、コマンド一つで一括して構築・起動・停止できます。これにより、チームメンバー全員が完全に同一の開発環境を瞬時に再現できるようになり、環境差異に起因するバグやトラブルを劇的に減少させることが可能です。結果として、開発者は環境構築の手間から解放され、本来のアプリケーション開発に集中できるようになります。

単一ファイルで複数コンテナを一括管理する仕組み

Docker Composeの核となるのは、宣言的な構成管理を実現するdocker-compose.ymlファイルです。このYAML形式のファイルに、Webサーバー、データベース、アプリケーションサーバーといった、アプリケーションを構成する個々のサービスを定義します。各サービスには、使用するDockerイメージ、ポートのマッピング、ボリューム（永続化データ）、環境変数、依存関係などを細かく指定できます。例えば、webサービスがdbサービスに依存する場合、depends_onオプションでその関係を明示することが可能です。このファイルを準備したら、あとはdocker compose up -dというシンプルなコマンドを実行するだけで、定義された全てのコンテナが依存関係に基づき自動的に起動します。これにより、複雑な多層アプリケーションの起動も手間なく実現し、環境の再現性が飛躍的に向上します。

導入がもたらす開発効率と運用メリット

現代のITインフラにおいて、コンテナ技術は不可欠な存在となっています。総務省の調査によると、令和6年8月末時点で日本国内企業の80.0％以上がクラウドサービスを利用しており、この傾向は今後も加速すると見込まれます。クラウド環境でのアプリケーション開発・運用において、Docker Composeは環境構築の標準化と効率化を強力に推進します。IDC Japanの2021年の調査では、日本国内企業の40.2％がコンテナの利用・導入を進行中と報告されており、コンテナ技術の普及が顕著です。Docker Composeを導入することで、開発環境のセットアップ時間を大幅に短縮し、開発者ごとの環境差異による不具合を未然に防ぎます。これにより、開発チーム全体の生産性が向上し、新しい機能のリリースサイクルを加速させることが可能です。また、本番環境に近い開発環境を容易に構築できるため、デプロイ後の問題発生リスクも低減できます。

出典：総務省、IDC Japan、Docker-docs-ja

実践！Docker Composeによる開発環境構築と主要コマンド操作手順

まずはここから！Docker Composeのインストールと基本操作

Docker Composeを使い始めるには、まずDocker Desktopをインストールするのが最も手軽な方法です。Docker DesktopにはDocker EngineとDocker Compose v2（スペース区切り）が統合されているため、個別にインストールする手間が省けます。インストールが完了したら、コマンドプロンプトやターミナルでdocker compose versionを実行し、バージョン情報が表示されれば準備完了です。最初のステップとして、NginxなどのシンプルなWebサーバーを起動してみましょう。作業ディレクトリにdocker-compose.ymlファイルを作成し、サービス定義を記述します。例えば、image: nginxとports: "80:80"を設定すれば、ホストの80番ポートでNginxコンテナにアクセスできるようになります。ファイルを保存後、そのディレクトリでdocker compose up -dを実行するだけで、コンテナがバックグラウンドで起動します。これで、ブラウザからhttp://localhostにアクセスすればNginxのデフォルトページが表示されるはずです。

開発で必須のコンテナ起動・停止・再構築コマンド

Docker Composeを用いた開発環境では、いくつかの主要コマンドを日常的に使用します。まず、アプリケーションを起動する際にはdocker compose upが基本です。-dオプションを付けるとバックグラウンドで起動し、ターミナルが占有されません。設定ファイルを変更した後にコンテナを再構築する場合は、docker compose up --buildを実行します。これにより、Dockerfileの変更が反映された新しいイメージがビルドされ、コンテナが再作成されます。コンテナを一時的に停止したい場合はdocker compose stop、完全に停止して関連リソース（ネットワーク、ボリュームなど）も削除したい場合はdocker compose downを使用します。downコマンドは開発終了時や環境をクリーンアップする際に特に便利です。また、特定のサービスだけを再起動したい場合はdocker compose restart [サービス名]を使うことで、全体のダウンタイムを最小限に抑えられます。

コンテナ内部へのアクセスとログ確認

コンテナ内部のデバッグや設定変更が必要になる場面は少なくありません。docker compose exec [サービス名] [コマンド]コマンドを使用すれば、起動中のコンテナ内で任意のコマンドを実行できます。例えば、docker compose exec web bashと入力すれば、Webサーバーコンテナのシェルにアクセスし、ファイルシステムの確認やパッケージのインストールなどを行えます。これにより、あたかも仮想マシンにログインしているかのように操作が可能です。また、コンテナの動作状況を把握するためにはログの確認が非常に重要です。docker compose logs [サービス名]コマンドを実行することで、特定のサービスの標準出力・標準エラー出力に書き出されたログを確認できます。-fオプションを付けると、リアルタイムでログを追跡できるため、問題発生時の挙動監視やデバッグに役立ちます。これらのコマンドを駆使することで、Docker Compose環境におけるトラブルシューティング能力を大きく向上させることができます。

出典：Docker-docs-ja

用途別Docker Compose ymlファイルの最適設計：設定項目とテンプレート集

ymlファイルで定義する主要なサービス設定項目

docker-compose.ymlファイルでは、アプリケーションを構成する各サービスに対して多様な設定を定義できます。最も基本的なのは、サービス名を定義するservicesブロックと、そのサービスが使用するイメージを指定するimageです。独自のイメージをビルドする場合はbuildを使用し、Dockerfileのパスを指定します。ホストOSとコンテナ間のポートマッピングにはportsを使い、"ホストポート:コンテナポート"形式で記述します。データの永続化にはvolumesを使用し、ホストOSのディレクトリをコンテナ内にマウントできます。また、コンテナ内で利用する環境変数はenvironmentで設定し、データベースの接続情報などを渡す際に便利です。サービス間の依存関係はdepends_onで指定することで、起動順序を制御できます。これらの設定項目を適切に組み合わせることで、複雑な多層アプリケーション環境も簡潔に定義することが可能です。

Webアプリケーション開発用ymlテンプレートの作成例

一般的なWebアプリケーション開発環境を構築するためのdocker-compose.ymlは、Webサーバー、アプリケーションサーバー、データベースの3つのサービスで構成されることが多いです。例えば、Nginx（Webサーバー）、Node.js（アプリケーションサーバー）、PostgreSQL（データベース）を組み合わせる場合、以下のような構成が考えられます。

version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./app:/var/www/html
    depends_on:
      - app
  app:
    build: ./app
    ports:
      - "3000:3000"
    volumes:
      - ./app:/usr/src/app
    environment:
      DATABASE_URL: postgres://user:password@db:5432/mydb
    depends_on:
      - db
  db:
    image: postgres:13
    volumes:
      - db_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
volumes:
  db_data:

このテンプレートでは、webがappに、appがdbに依存しており、起動順序が考慮されています。各サービスで必要なポートやボリューム、環境変数を設定することで、すぐに開発を開始できる環境を構築できます。特にvolumesでホストのアプリケーションコードをマウントすることで、ホスト側でコードを編集すると即座にコンテナ内のアプリケーションに反映され、開発効率が向上します。

データベース永続化と環境変数の安全な管理術

Docker Composeでデータベースを扱う際、コンテナを削除してもデータが失われないように「永続化」することが非常に重要です。これを実現するために、volumes設定を使用します。volumesには「名前付きボリューム」と「バインドマウント」の2種類があります。データベースのデータには、Dockerが管理する名前付きボリューム（上記の例ではdb_data）を使用するのが一般的です。これにより、ホストOSの特定パスに依存せず、Dockerが最適な場所にデータを保存してくれます。一方、アプリケーションのソースコードなど、ホスト側で頻繁に変更するファイルにはバインドマウント（./app:/usr/src/appのようにホストパスを指定）が適しています。また、データベースのパスワードなどの機密情報は、environmentで直接記述するのではなく、.envファイルに記述し、docker-compose.ymlから参照させる方法がより安全です。これにより、ymlファイルに直接機密情報が記述されるのを避け、バージョン管理システムへの誤ったコミットを防ぐことができます。

Docker Compose運用で陥りやすい落とし穴とトラブルシューティング

「起動しない」「アクセスできない」よくある原因と確認ポイント

Docker Composeで環境を構築する際、コンテナが期待通りに起動しなかったり、起動してもアプリケーションにアクセスできなかったりすることは少なくありません。よくある原因の一つはポートの競合です。ホストOSの同じポートを複数のアプリケーションやコンテナが使用しようとすると、後から起動したものがエラーになります。この場合、docker-compose.ymlのports設定を見直すか、ホストOSの他のアプリケーションを停止する必要があります。次に、イメージのビルド失敗も頻繁に起こります。Dockerfileの記述ミスや、必要なファイルが.dockerignoreで除外されている可能性があります。docker compose build --no-cacheでキャッシュを使わずに再ビルドし、エラーメッセージを詳細に確認することが解決の糸口になります。さらに、サービス間の依存関係の問題も考えられます。例えば、データベースが完全に起動する前にアプリケーションが接続を試みて失敗するケースです。depends_onは起動順序を保証しますが、サービスが実際に利用可能になるまで待つわけではないため、アプリケーション側でリトライロジックを実装することも検討しましょう。

データ永続化の失敗を防ぐボリューム設定の注意点

コンテナの最大の特性の一つは「使い捨て可能」であることですが、データベースのデータやユーザーがアップロードしたファイルなど、永続化が必要なデータも存在します。これらのデータがコンテナの削除と共に失われないように、適切にボリュームを設定することが非常に重要です。ボリュームには、名前付きボリュームとバインドマウントの2種類があります。名前付きボリュームはDockerが管理する領域にデータを保存し、コンテナを停止・削除してもデータは保持されます。一方、バインドマウントはホストOSの特定のディレクトリをコンテナ内にマウントするため、ホストのファイルシステムに依存します。データベースのデータなど、コンテナのライフサイクルとは独立してデータを管理したい場合は、名前付きボリュームの使用を強く推奨します。バインドマウントは開発中にソースコードを共有するのには便利ですが、本番環境での利用や、予期せぬホスト側の操作によるデータ破損のリスクを考慮する必要があります。誤ってボリュームを削除してしまうとデータが失われる可能性があるので、バックアップ戦略も検討することが重要です。

運用時に考慮すべきセキュリティとリソース管理

Docker Composeは開発環境構築に非常に便利ですが、運用段階に進むと「障害発生時の対応策」「セキュリティ対策」「データ管理」といった課題に直面することが、IDC Japanの調査（2021年）でも指摘されています。セキュリティ面では、使用するコンテナイメージが最新であるか、既知の脆弱性がないかを確認することが重要です。古いイメージや不明なソースのイメージは避けるべきでしょう。また、コンテナ内で不要なポートを開放していないか、機密情報（パスワードやAPIキー）が環境変数として適切に管理されているかなども確認が必要です。リソース管理においては、docker-compose.ymlのdeployセクションでCPUやメモリの使用制限を設定できます。これにより、特定のコンテナが過剰なリソースを消費して他のサービスやホストOS全体に影響を与えるのを防ぐことが可能です。運用設計では、単にツールを導入するだけでなく、障害監視、ログ管理、バックアップ、セキュリティパッチの適用プロセスなど、システム全体のライフサイクルを考慮した計画が求められます。厚生労働省の「job tag」でも、システムエンジニアには要件定義から運用までの一貫した知識が求められることが示されており、技術導入後の運用フェーズを見据えた準備が不可欠です。

出典：IDC Japan、厚生労働省

【ケース】サービス間通信ができない問題から学ぶネットワーク設定の重要性

ケース概要：バックエンドとデータベースが接続できない問題

ここでは、架空のケースとして、WebアプリケーションをDocker Composeで構築している開発者が直面した具体的な問題を取り上げます。アプリケーションは、Node.jsで書かれたバックエンドサービス（app）と、PostgreSQLデータベースサービス（db）の2つのコンテナで構成されていました。開発者はdocker compose up -dで両サービスを起動し、Webブラウザからアプリケーションにアクセスしました。しかし、バックエンドがデータベースへの接続を試みると、「Error: getaddrinfo ENOTFOUND db」というエラーが発生し、アプリケーションが起動しない問題に遭遇しました。このエラーは、バックエンドサービスが「db」というホスト名を解決できない、つまりデータベースに接続できないことを示しています。初見では、なぜ同じdocker-compose.ymlファイル内で定義されたサービス同士が通信できないのか、混乱しやすい状況でした。

Docker Composeの内部ネットワークとサービス名の解決

この問題の根本原因は、Docker Composeが提供する内部ネットワークの仕組みの理解不足にありました。Docker Composeは、docker-compose.ymlファイルで定義されたサービスのために、自動的にプライベートなブリッジネットワークを作成します。このネットワーク内で、各サービスは自身のサービス名をホスト名として利用できるようになります。つまり、appサービスからdbサービスにアクセスする場合、IPアドレスを直接指定する必要はなく、単にdbというホスト名で接続できます。これは、Docker Composeが内部でDNSサービスのような機能を提供し、サービス名を対応するコンテナのIPアドレスに解決してくれるためです。したがって、上記のケースでバックエンドが「db」というホスト名を解決できなかったのは、バックエンドの環境変数設定が誤っていたか、あるいは古いDocker Composeの知識に基づきIPアドレスを直打ちしようとしていた可能性が考えられます。正しい理解があれば、この問題は容易に解決できます。

問題解決へのステップ：設定確認とデバッグ手法

サービス間通信の問題に直面した場合、以下のステップでデバッグを進めることが推奨されます。まず、最も重要なのは、アプリケーションのバックエンドサービスがデータベースへの接続文字列で正しいホスト名（この場合はdb）を指定しているかを確認することです。多くの場合、アプリケーションの環境変数（例: DATABASE_HOST=db）が誤ってlocalhostやコンテナのIPアドレスに設定されていることが原因です。次に、docker compose psを実行して、両方のサービスコンテナが正常にUp状態にあることを確認します。もし片方でも起動に失敗していれば、そのサービスのログ（docker compose logs [サービス名]）を詳しく調査します。さらに、問題が解決しない場合は、docker compose exec app bash（またはsh）でバックエンドコンテナ内に入り、そこからデータベースサービスに対してping dbを実行してネットワーク接続性を確認したり、telnet db 5432（PostgreSQLのデフォルトポート）を実行してポートが開いているか確認することも有効です。これらの手順を踏むことで、ネットワーク設定の誤りやサービス間の通信障害の原因を特定し、解決に導くことができます。