Docker Composeで複数コンテナ
実務のアプリはコンテナ1つでは完結せず、アプリ本体とデータベースのように複数のコンテナが組んで動くのが普通です。Docker Composeは、この「組」をYAML1枚で定義し、まとめて起動・停止できるようにする道具です。長いdocker runコマンドを何度も打つ生活から、宣言的な設定ファイルを読む・書く生活へ移る、実務コンテナ運用の入口になります。
アプリ本体だけが動いていても、実務ではそれで完結しないことが多い。裏にデータベースが必要だったり、キャッシュ用のコンテナが必要だったりする。
コンテナが2つ3つと増えていくと、docker run のコマンドをそれぞれ手で打つのはつらい。ネットワーク名・ポート番号・環境変数と、覚えることが増え、打ち間違いも増える。
📄 compose.yamlという1枚の設計図
Docker Composeは、複数のコンテナの構成をYAML形式の1つのファイルにまとめて書き、それをまとめて起動・停止できるようにする道具だ。ファイル名は慣習的にcompose.yaml（旧称docker-compose.yml）とする。
このファイルの中心はservicesという項目で、動かしたいコンテナを1つずつ「サービス」として定義していく。アプリ用のサービス、データベース用のサービスといった具合だ。
1つのサービスには、使うイメージ（imageまたはbuild）、公開するポート（ports）、永続化するボリューム（volumes）、渡す環境変数（environment）などを書いていく。
💾 volumesとportsの書き方
compose.yamlの中でも、volumesとportsはよく使う項目だ。volumesはホスト側のディレクトリやDocker管理下のボリュームをコンテナの中にマウントする指定で、データベースのデータを消えないようにするために欠かせない。
portsは、ホスト側のポート番号とコンテナ側のポート番号の対応をhost:container の形式で書く。この書き方はdocker run -pで指定するのと同じ意味を持つ。
▶️ 起動・停止・ログの確認
compose.yamlを書いたら、そのファイルがあるディレクトリでdocker compose upを実行するとservicesに書いた全コンテナがまとめて起動する。バックグラウンドで動かしたいときは-dオプションを付ける。
止めるときはdocker compose downを使う。これはコンテナを停止するだけでなく、Composeが作ったネットワークなども一緒に片付けてくれる。個別のコンテナのログを流し続けて見たいときはdocker compose logs -fが便利だ。
🔗 依存順序——depends_on
データベースを使うアプリの場合、アプリのコンテナがデータベースのコンテナより先に起動してしまうと、接続エラーで落ちることがある。この起動順序を制御するのがdepends_onだ。
depends_onにサービス名を書いておくと、Composeはそのサービスを先に起動してから対象のサービスを起動する。ただし、これは「先にコンテナが起動し始める」順序を保証するだけで、「中のアプリ（例えばデータベース）が接続を受け付けられる状態になった」ことまでは保証しない点に注意がいる。
🚀 コマンドの引数地獄からの卒業
ここまで見てきたように、Composeは「毎回長いdocker runの引数を打つ」という繰り返し作業を、「1枚のYAMLを読む・書く」という作業に置き換える。
複数のコンテナを組にして扱えるようになったら、次に気になるのは「コンテナ同士はどうやってお互いを見つけて話しているのか」という点だ。次のトピックではコンテナのネットワークの仕組みを見ていく。