Docker Compose（ドッカーコンポーズ）は、複数のコンテナで構成されるアプリケーションをYAMLファイル一枚で定義・起動・停止できるツールです。前身は2014年初頭にロンドンのOrchard Laboratoriesが開発した「Fig」というPython製ツールで、同年7月にDocker社がOrchardを買収し、翌2015年2月に「Docker Compose 1.0」として正式にDockerファミリーに編入されました。2020年代に入りGo言語で書き直されたdocker compose（v2）が主流となり、ローカル開発環境のデファクトスタンダードとして根強い人気を保っています。
この記事の目次
- 宣言・ネットワーク・ボリュームの三本柱
- FigからCompose v2まで
- 典型的なdocker-compose.yaml
- Kubernetesとの違い
- まとめ
宣言・ネットワーク・ボリュームの三本柱
Docker Composeの中心概念は、docker-compose.yamlという宣言的なYAMLファイルでアプリケーションの構成を記述することです。Webサーバ、APIサーバ、DB、キャッシュなど複数のサービスをservices:セクションに並べ、各サービスのイメージ、環境変数、ポート、ボリューム、依存関係を指定します。docker compose up一発でこれらが起動し、docker compose downで停止・クリーンアップされます。ローカル開発でPostgreSQL＋Redis＋API＋フロントエンドを一気に立ち上げる、といった典型的なシナリオで強さを発揮します。
Composeは内部で専用ブリッジネットワークを作成し、サービス名でDNS解決できるようにします。例えばdbという名前のサービスを定義すると、他のサービスからdb:5432という形でPostgreSQLに接続できます。ボリュームについても、ホストディレクトリのbindマウントと名前付きボリュームの両方を扱え、データ永続化と開発時のホットリロードの両立が容易です。Composeは「最小限の労力で本物そっくりの環境をローカルに再現する」ことを目的としたツールであり、その目的をシンプルに達成できる設計が支持されています。
FigからCompose v2まで
Docker Composeの歴史は、ロンドンのスタートアップOrchard Laboratoriesが2014年に公開したFigから始まります。Figは「YAMLでDockerコンテナを束ねる」というコンセプトをいち早く具現化したPython製ツールで、Dockerコミュニティで急速に人気を集めました。Dockerが急成長の最中だった2014年7月、Docker社はOrchardを買収し、Figの設計を取り込む形でDocker Composeとしてリブランドしました。2015年2月にDocker Compose 1.0として一般公開され、以降Dockerのオプションツールとして長く使われ続けました。
2020年頃からDocker Composeはピボットの時期を迎えます。Python版のレガシーな1.x系から、Go言語で書き直しDocker CLIに統合される2.x系（docker composeサブコマンド）への移行が始まり、2021年4月にDocker Compose v2.0.0が一般提供されました。コマンド名のスペースが変わるだけでなく、Compose Specという標準仕様にも準拠する形で公開され、PodmanやKubernetes周辺の各種ツールでも同じYAML形式が読めるようになりました。2023年にPython版v1系のサポートが終了し、現在は完全にv2系の世界となっています。
典型的なdocker-compose.yaml
Composeファイルの典型例として、PythonのDjangoアプリとPostgreSQL、Redisを束ねる構成を考えてみましょう。services:セクションの下にweb、db、redisの3つを並べ、webはbuild: .でDockerfileから組み立て、dbはimage: postgres:16-alpineを指定し、POSTGRES_PASSWORDなどをenvironmentで設定します。ホストからの開発時にコード変更を反映するため、webにvolumes: - .:/appとbindマウントを書き、depends_on: [db, redis]で起動順序を制御します。
docker compose up -dを実行すると、これらが順に立ち上がり、docker compose logs -f webでログをstreamできます。本番デプロイの場合は、同じYAMLからKubernetesマニフェストへ変換するkomposeツールや、Docker Swarmへのデプロイを行うdocker stack deployを使うこともできます。またCompose Spec準拠のため、PodmanやFinchでも同じYAMLが動き、ベンダーロックを避けつつローカル開発の生産性を高められる点が大きな魅力です。「YAMLが書ければ環境構築は終わる」と言える状況を作り出したのが、Docker Composeの最大の功績です。
Kubernetesとの違い
Docker ComposeとKubernetesはしばしば「コンテナオーケストレーター」として同じ括りで語られますが、想定する用途は対照的です。Composeは単一ホスト上で複数コンテナをまとめて起動する「開発・テスト向けツール」であり、スケール、ヘルスチェックによる自己修復、ローリングアップデートといった本番特有の機能は最小限です。一方Kubernetesは複数ノードクラスタを前提とし、Pod・Service・Deployment・StatefulSetなど多層の抽象を提供して、大規模本番運用に耐える設計です。
実務では「ローカルはCompose、本番はKubernetes」という棲み分けが定番です。Composeのdocker-compose.yamlをkomposeでKubernetesマニフェストへ変換したり、Skaffold・Tiltなどの開発者ツールでKubernetes向けのHot Reloadを行う構成も増えました。一方で、小規模サービスや個人プロジェクトでは「Compose＋単一VM」だけで本番運用するパターンも依然として多く、Composeは「シンプルさが必要な場面で最強」というポジションを今も保ち続けています。
まとめ
Docker Composeは2014年のFigを起源とし、2015年にDocker傘下で1.0、2021年にGo版v2となった複数コンテナ管理ツールです。YAML一枚で開発環境を再現できる手軽さから、ローカル開発のデファクトスタンダードとして定着しました。本番Kubernetesとの組み合わせも一般的で、コンテナ時代の入口として最も多く触れることになるツールの一つです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント