Docker Composeの導入：複数コンテナの構成管理と起動の自動化（Docker入門）

本記事では、Docker Composeを用いた複数コンテナの構成管理と、システム起動の自動化について解説します。単体のコンテナを動かす段階から先に進み、Webサーバー、データベース、管理ツールといった複数のサービスが連携するシステムを、一つの設定ファイル（docker-compose.yml）で制御するための方法を示します。また、セキュリティ対策（.env）やコンテナ同士の連携を保証するヘルスチェック（自動待機）などについても取り扱います。

目次

• はじめに
• Docker Composeの導入と設定ファイルの概要
• 設定ファイルのフォーマット
  • コンテナの定義（services）
  • ボリュームの定義（volumes）
  • ネットワークの定義（networks）
• 設定ファイルの作成例
• 実行コマンド
  • システムの起動
  • システムの一括停止・削除
  • 起動状態の確認
  • 実行ログの確認
  • システムの停止
• 【実践】Docker Composeで環境を起動してみる
• 補足事項①：セキュリティの向上
  • .envファイルの活用
  • 外部通信の遮断
  • ネットワークの分割
  • リソース制限
  • 特権の制限
  • ボリュームの読み取り専用化
• 補足事項②：depends_onの制約
  • 手動リトライ
  • ヘルスチェックによる自動待機
• 設定ファイルの修正
• まとめ
• 関連記事

はじめに

Dockerは、イメージからコンテナを作成し、コンテナを起動してサービスを提供した後、停止、削除するのが一連の流れになります。この際、実際のプロジェクトは単一のプログラムで完結することは稀で、Webサーバー、アプリケーション、データベース、キャッシュなど、役割の異なる複数のコンテナが連携して一つのシステムを構成するのが一般的です。

これらを個別に管理しようとすると、運営コストが大きくなってしまいます。具体的には、ネットワーク設定、ボリューム割り当て、環境変数など、数十行に及ぶオプションをコンテナごとに打ち込む必要があり、人的エラーが発生しやすくなります。また、どの順番で、どの設定で起動すべきかを、誰かの記憶やドキュメントに頼ることになり、チーム内での環境を完全に一致させることが困難になります。

Docker Composeは、これらの設定を一つの設計図（docker-compose.yml）に集約し、コマンド一発でシステム全体を制御するためのツールです。

Docker Composeの導入と設定ファイルの概要

Docker Composeは、コンテナやボリューム、ネットワークなどに関する設定をYAML（YAML Ain’t Markup Language）形式のテキストファイルとして定義し、まとめて管理するためのツールです。設定された内容に基づいて、コンテナを一括実行したり、一括停止、削除したりできます。

単体のコンテナだけを動かすのであれば、docker runコマンドで十分ですが、複数ある場合に個別にコマンドを叩く手間を解消するのがDocker Composeの役割です。

Docker ComposeはDocker Engineとは別のソフトウェアであるため、インストールが必要です。ただし、Docker Desktopを使用する場合には、既に入っているため、別途インストールする必要はありません。それ以外の場合のインストール方法はこちら（公式ページ）に記載されています。

Docker Composeでは、docker runなどのコマンドのオプションとして渡していた内容をdocker-compose.ymlファイルに書き込みます。

例えば、docker runのコマンド

docker run --name apache_server -d -p 8000:80 -v C:\Test\my-site\:/usr/local/apache2/htdocs/ httpd 

を、Compose の設定ファイルの形（YAML形式）で書くと、以下のようになります。意味については後述するため、こんな感じに書くものだと受け取ってください。

services:              # サービス群（コンテナ実行）の宣言
   web_server:         # サービス名をweb_serverという名前に指定（論理名）
      image: httpd     # イメージとしてhttpdを使用
      ports:           # ポートの定義（複数あり得るのでリスト形式）
         - 8000:80 
      volumes:         # マウントの定義（複数あり得るのでリスト形式）
         - C:\Test\my-site\:/usr/local/apache2/htdocs/
      container_name: apache_server       # コンテナの物理名

このように構造化することで、「どの設定が、どのサービスに属しているか」をひと目でわかるようになり、多人数の開発でも設定の意図が正確に伝わるようになります。

設定ファイルのフォーマット

設定ファイル（docker-compose.yml）のフォーマットはYAML形式で、字下げによって情報の親子関係を表現します。ファイル名はオプション（-f）により変更することができますが、デフォルトではdocker-compose.ymlを使用します。

docker-compose.ymlの大項目（YAMLの一番上の階層）として、よく用いるのは次の3つです。

これらの大項目の直下には、論理名を記述します。

services:
   論理名:
      ～（各設定値） 
volumes:
   論理名:
      ～（各設定値） 
networks:
   論理名:
      ～（各設定値） 

この論理名はDocker Compose内で使われる名前で、Dockerエンジンが直接管理する物理的な名前とは異なります。

書き込める設定値は大項目（services, volumes, networksなど）ごとに異なります。

コンテナの定義（services）

servicesに書き込める代表的な項目は以下になります。まず、大項目の下には論理名を記述します。

そして、論理名の下には以下の設定値を指定することができます。

ボリュームの定義（volumes）

volumesに書き込める代表的な項目は以下になります。まず、大項目の下には論理名を記述します。

そして、論理名の下には以下の設定値を指定することができます。

ネットワークの定義（networks）

networksに書き込める代表的な項目は以下になります。まず、大項目の下には論理名を記述します。

そして、論理名の下には以下の設定値を指定することができます。

設定ファイルの作成例

例として、PostgreSQLのデータベースとデータベース管理マネージャーを起動するための設定ファイル（docker-compose.yml）を示します。名前付きボリューム（my-db-data）を定義することでデータベースの永続化を行い、データベースと管理マネージャーを同じネットワーク（db-net）に接続することで、サービス間の通信を可能にしています。構築の詳細は、前回の記事で解説した通りですが、今回はそれらをDocker Composeの形式に落とし込んでいます。打ち込んだ数々のオプションが、YAMLの各項目に翻訳されています。

services:
   db-server:
      image: postgres:18.3-alpine3.23
      volumes:
         - my-db-data:/var/lib/postgresql
      networks:
         - db-net
      environment:
         - POSTGRES_PASSWORD=password
   db-client:
      image: adminer
      ports:
         - 8080:8080
      networks:
         - db-net
      depends_on:
         - db-server
volumes:
   my-db-data:
networks:
   db-net: 

この設定ファイルで作成されるシステムの構成を下図に示します。

ブラウザ画面上でAdminerのサーバー名にdb-serverと入れるだけで繋がるのは、Docker Composeがこの名前を自動的にDNSサーバーに登録してくれるためです。DNSはネットワーク内で「どの名前が、どのIPアドレスか」を紐づけます。これにより、Adminer(db-client)から「db-serverという名前の相手に繋いで」とリクエストを送ると、Docker内部のDNSサーバーが「それは172.x.x.xというIPアドレスのコンテナ」と教えてくれるため、通信が可能になります。

実行コマンド

Docker Composeを用いるときによく使用するコマンドを以下に示します。

システムの起動

設定ファイルをもとに、システムを起動します。

docker compose -f <定義ファイルのパス> up <オプション>

-fにより定義ファイルのパスを指定できます。指定しない場合はカレントディレクトリにあるdocker-compose.ymlを使用します。よく使うオプションとしては次のものがあります。

システムの一括停止・削除

upで作成したリソース（コンテナやネットワーク）を停止し、さらに削除まで行うコマンドです。

docker compose -f <定義ファイルのパス> down <オプション>

単なる停止（stop）ではなく、downを使う最大の理由は「環境を一度まっさらな状態に戻すため」です。よく使うオプションとしては次のものがあります。

起動状態の確認

Docker Composeで管理されているコンテナ群が期待通り動いているかを一覧表示します。

docker compose ps

STATUSで状態を確認します。Upは稼働中で、ポートの転送も生きています。Exited (0)は正常に終了しています。Exited (1)などの0以外の場合には、何らかのエラーで落ちています。期待通りにUpにならないときは、すかさず--allオプションを付けて、どのコンテナがいつ落ちたのかを確認するのがよいです。

実行ログの確認

Dockerコンテナの中で何が起こっているか（エラーメッセージやデバッグ出力）を確認します。

docker compose logs <オプション>

バックグラウンド（-d）で起動した際、プラウザにエラーが出てもなぜ動かないかが分かりません。その際に、真っ先に叩くのがこのコマンドです。よく使うオプションとしては次のものがあります。

すべてのコンテナのログが混ざって見づらいときには、コマンドの最後にサービス名を書くことで、特定のコンテナのログだけ確認できます。

docker compose logs <オプション> <サービス名>

システムの停止

upで作成したリソース（コンテナやネットワーク）を削除せずに、停止します。

docker compose stop <オプション>

downと異なり、コンテナを停止させるだけで、ネットワークは維持されます。このため、一時的な中断に使用します。デフォルトでは、Dockerはコンテナに停止シグナルを送り、10秒待っても止まらない場合に強制終了させます。データベースなどの終了処理に時間がかかるサービスを扱っている場合、デフォルトの10秒では足りず、データが破損するリスクがあるため、その場合には-t <秒>オプションを使って、有路時間を変更できます。このオプションは、安全に、かつ確実にシャットダウンさせたいシステムを扱う際に重宝します。

stop で止めたら up でも start でも再開できますが、基本的には常に docker compose up -d を使う癖をつけておくのが、設定の反映漏れを防ぐ一番安全な方法です。docker compose startでも再開でき、若干速くなりますが、この場合にはdocker-compose.ymlを変更していた場合、その変更が反映されません。

【実践】Docker Composeで環境を起動してみる

前述のdocker-compose.ymlのサンプルをフォルダ（test）にコピーして、その中に移動した後にシステムを起動します。

cd test
docker compose up -d

ブラウザを開き、http://localhost:8080にアクセスするとデータベース管理マネージャーのログイン画面が表示されます。

Docker Composeの起動状態を確認してみます。

docker compose ps

NAME               IMAGE                      COMMAND                   SERVICE     CREATED         STATUS         PORTS
test-db-client-1   adminer                    "entrypoint.sh docke…"   db-client   2 minutes ago   Up 2 minutes   0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp
test-db-server-1   postgres:18.3-alpine3.23   "docker-entrypoint.s…"   db-server   2 minutes ago   Up 2 minutes   5432/tcp

STATUSを見るとUpになっており、PostgreSQLとデータベース管理ツール（Adminer）が起動していることを確認できます。また、物理名（NAME）を見ると、論理名の前にプロジェクト名としてフォルダ名（test）がついていることを確認できます。また、SERVICEを見ると、サービス名（論理名）が設定ファイルで指定した名前（db-clientとdb-server）になっていることを確認できます。

次に、設定ファイルに記述したネットワークとボリュームが存在しているかを確認してみます。

docker network ls

NETWORK ID     NAME          DRIVER    SCOPE
043b667e26b6   bridge        bridge    local
eff6adf01512   host          host      local
2e6c6af3fe23   none          null      local
1714d0ca723e   test_db-net   bridge    local

docker volume ls

DRIVER    VOLUME NAME
local     test_my-db-data

これにより、設定ファイルに記述されたネットワークと名前付きボリュームが作成されたことを確認できました。さらに、設計図通りにリソースが紐づいているかをより詳細に確認したい場合にはinspectを使用します。

docker network inspect test_db-net
docker volume inspect test_my-db-data

例えば、割り当てられたIPアドレスやボリュームのマウントポジションなどを確認できます。

さらに、ログをリアルタイムで表示してみます。

docker compose logs -f

このコマンドを実行した状態で、ブラウザをF5で更新すると、リアルタイムでログが追加されることを確認できます。

...
db-client-1  | [Sat May  9 13:26:24 2026] [::ffff:172.18.0.1]:56070 Accepted
db-client-1  | [Sat May  9 13:26:24 2026] [::ffff:172.18.0.1]:56070 [200]: GET /
db-client-1  | [Sat May  9 13:26:24 2026] [::ffff:172.18.0.1]:56070 Closing

次に、システムを停止して削除してみます。

docker compose down

停止したサービスを含めて状態を確認してみると、コンテナが削除されていることを確認できます。

docker compose ps --all

NAME      IMAGE     COMMAND   SERVICE   CREATED   STATUS    PORTS

また、docker volume lsとdocker network lsを実行してみると、ネットワークは削除されていますが、名前付きボリュームは削除されずに残っていることを確認できます。

docker volume ls

DRIVER    VOLUME NAME
local     test_my-db-data

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
043b667e26b6   bridge    bridge    local
eff6adf01512   host      host      local
2e6c6af3fe23   none      null      local

以上で、基本的なコマンドの動作を確認できました。

残ったイメージとボリュームは以下のコマンドで削除できます。

docker image rm adminer postgres:18.3-alpine3.23
docker volume rm test_my-db-data

補足事項①：セキュリティの向上

.envファイルの活用

前述のdocker-compose.ymlでは、データベースのパスワードを直接ファイル内に記述していましたが、パスワードを直接設定ファイルに書くのはリスクがあります。

具体的には、設定ファイルをGithubなどのソースコード管理ツールにプッシュすると、チームメンバーや公開設定によっては全世界にパスワードが公開されてしまいます。また、開発環境、本番環境でパスワードを変えたい場合、その都度YAMLファイルを書き換える必要があります。

これらのリスクや手間を避けるため、Docker Composeには、環境変数を別ファイル（.env）から読み込む仕組みがあります。

まず、docker-compose.ymlと同じフォルダに.envという名前のファイルを作成し、環境変数として機密情報を記述します。

DB_PASSWORD=password123

次に、docker-compose.ymlのパスワードの部分を${変数名}という形式に書き換えます。

environment:
   - POSTGRES_PASSWORD=${DB_PASSWORD}

このように設定ファイルと機密情報（.env）を分離することで、.envファイルさえGitの管理対象から外しておけば、安全に開発を行うことができます。すなわち、.gitignoreファイルに.envと記述し、絶対にリポジトリに含めないようにします。代わりに、チーム用には.env.example（値が空のテンプレート）を共有するのが定石です。また、環境ごとに.envの中身を書き換えるだけで、同じ設定ファイルを使いまわせるようになります。

外部通信の遮断

デフォルトでは、Dockerのネットワークはコンテナからインターネットへの外向きの通信を許可しています。しかし、データベースのような機密情報を扱うコンテナが、勝手に外部（クラッカーのサーバーなど）と通信できてしまうのは、セキュリティ上のリスク（データ流出の経路）になります。

このため、外部に公開する必要のないデータを扱うネットワークは外部から遮断するのがセキュリティレベルを上げるのに有効な手段です。外部から遮断するためには、対象のネットワークに対して、internalを設定します。

networks:
   db-net:
      internal: true # このネットワークに属するコンテナは外（インターネット）に出られない

これにより、万が一、脆弱性を突かれてコンテナを乗っ取られたとしても、ハッカーが外部のサーバーからスクリプトをダウンロードしたり、データを外部へ送信したりすることを物理的に遮断できます。

また、必要なポート以外は開けないというのも重要です。

ネットワークの分割

サービスが増えた場合は「表（Web）」と「裏（データベース）」でネットワークを分割するのがよいです。例えば、Webアプリとユーザーの間の通信をfrontend-net、Webアプリとデータベースの間の通信をbackend-netとするなどです。

これにより、ユーザーが触れるWebアプリが乗っ取られても、DBへは特定のネットワーク経由でしか辿りつけないため、攻撃を最小限に食い止められます。

リソース制限

DoS対策として、一つのコンテナが暴走してPC（サーバー）全体のCPUとメモリを使い果たさないように、上限を決めます。

services:
   [論理名]:
      deploy:
         resources:
            limits:
               cpus: '0.5'    # CPUを最大50%までに制限
               memory: 512M   # メモリを最大512MBまでに制限

特権の制限

コンテナ内のプログラムが、実行中に勝手に管理者権限（root）に昇格するのを防ぎます。

services:
   [論理名]:
      security_opt:
         - no-new-privileges:true

ボリュームの読み取り専用化

設定ファイルなど、書き換える必要がない場所は「読み取り専用」でマウントします。マウントポイントの指定において、末尾に:roを追加します。

services:
   [論理名]:
      volumes:
         - [ボリューム名]:[コンテナのパス]:ro

補足事項②：depends_onの制約

depends_onはコンテナを立ち上げる順番を制御するだけで、中身のソフトが使える状態になったかまでは見てくれません。

データベースは、コンテナが「Up（起動中）」になってから、内部でデータの初期化が終わるまで数秒の時間がかかります。そのため、起動直後にAdminerでログインしようとすると、接続エラーが発生することがあります。

手動リトライ

最もシンプルな方法は、手動でリトライする方法で開発環境ではこれで十分なことが多いです。

接続エラーが出ても焦らず、5～10秒ほど待ってからブラウザの更新ボタン（F5）を押します。データベースの準備が整えば、そのままつながります。

ヘルスチェックによる自動待機

データベースが本当に準備OKになるまで、Adminerの起動を待たせるという設定をDocker Composeの設定ファイルに書き込む方法です。

services:
  db-server:
    image: postgres:18.3-alpine3.23
    # DBが生きているかを確認するコマンドを指定
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s   # 5秒おきにチェック
      timeout: 5s    # 5秒でタイムアウト
      retries: 5     # 5回失敗したら「異常」とみなす
      start_period: 10s # 起動直後の10秒間は失敗をカウントしない

  db-client:
    image: adminer
    depends_on:
      db-server:
        condition: service_healthy # db-serverが「健康」になるまで待つ

healthcheckセクションは、診断ルールを定義するためのもので、診断される側（例：データベース）に記述する設定です。各項目の意味は次の通りです。

本記事の例では、PostgreSQLを使用しているため、今、クエリを受け付けられているかを尋ねるためのpg_isreadyコマンドを使用しています。例えば、データベースの起動に30秒かかる環境であれば、interval: 10s、retries: 3以上の猶予を持たせるなどのように数値を調整する必要があります

depends_onのconditionは、待機する側（例：adminer）に記述する設定で、起動のトリガーを指定します。

condition: service_healthy

通常のdepends_onは対象コンテナのプロセス開始のみを条件としますが、このconditionを追加することで、対象コンテナのステータスがhealthyに変わるまで、自身の起動をブロックするという制御が可能になります。

設定ファイルの修正

補足事項に書かれた内容を反映した最終的なdocker-compose.ymlは次のようになります。

services:
   db-server:
      image: postgres:18.3-alpine3.23
      deploy:
         resources:
            limits:
               cpus: '0.5'
               memory: 512M
      volumes:
         - my-db-data:/var/lib/postgresql
      networks:
         - backend-net # 隔離ネットワークを使用する
      environment:
         - POSTGRES_PASSWORD=${DB_PASSWORD}
      security_opt:
         - no-new-privileges:true
      healthcheck:
         test: ["CMD-SHELL", "pg_isready -U postgres"]
         interval: 5s
         timeout: 5s
         retries: 5
         start_period: 10s

   db-client:
      image: adminer
      ports:
         - 8080:8080
      networks:
         - frontend-net # ブラウザと話すための通常ネットワーク
         - backend-net  # DBと話すための隔離ネットワーク
      depends_on:
         db-server:
            condition: service_healthy

volumes:
   my-db-data:

networks:
   frontend-net: # 通常のネットワーク
   backend-net:
      internal: true # 隔離ネットワーク

起動コマンドは前述したとおりです。設定ファイルと.envファイルを作成した後に、それらのあるフォルダ内で次のコマンドを入力します。

docker compose up -d

ブラウザを開き、http://localhost:8080にアクセスするとデータベース管理マネージャーのログイン画面が表示されます。次のログイン情報を入力することでログインできます。

これで、.envで指定されたパスワードでログインできることも確認できます。

今回の例の場合、.envでパスワードを変更してもdownではボリュームが消えないことと、Postgresは初回しか環境変数を見ないため、.envの変更内容が反映されません。反映させたい場合はデータベースに入り、直接パスワードを変更するしかありません（docker compose down -vでボリュームごと削除すれば、.envの変更内容が反映されますが、その場合データベースが完全に削除されてしまいます）。

まとめ

本記事では、Docker Composeを利用して複数のコンテナをひとつのシステムとして統合管理する方法を解説しました。

単にコンテナを並べるだけではなく、以下のポイントも取り扱いました。

• IaC（Infrastructure as Code）：docker-compose.ymlというひとつの設計ファイルで、ネットワーク、ボリューム、環境変数を一括管理する方法。
• 動作順序の信頼性確保：healthcheckとconditionを組み合わせることで、データベースの準備が整うまで後続の起動を自動待機させる手順。
• 多層防御：.envによる機密情報の分離、internalネットワークを用いた二重ネットワーク構成によるデータベースの物理的な隔離。
• リソースの制御：deploy: limitsを設定し、特定のコンテナの暴走からホストマシンを守る安全装置の設定。

Docker Composeを使用することは、効率化以上に、誰がどこで実行しても、安全かつ確実に同じ環境が制限されるという品質保証の確保に役立ちます。

関連記事