Web・DB・キャッシュと箱が増えたとき、docker run を何本も打つ代わりに compose.yaml に宣言としてまとめる。run のオプションが YAML の項目にそのまま対応すること、サービス名がホスト名になるネットワーク、up と down、そして Dockerfile・イメージ・コンテナ・ボリューム・レジストリ・compose がどうつながるかの全体像。
ここまでで、1つのコンテナを作って動かすところまで来ました。でも実際のアプリは、Web アプリ本体に加えてデータベース、キャッシュ、場合によっては Web サーバーやジョブ実行の仕組みなど、複数の部品で成り立っています。それぞれを別のコンテナとして動かすのが Docker の流儀です。1つの箱に全部詰めるより、部品ごとに箱を分けたほうが、差し替えも更新も楽だからです。
ただ、箱が3つになると docker run も3本になります。それぞれのオプションを覚え、起動の順番を守り、web から db へどう繋ぐかを設定する。手で打つのは面倒で、人によって打ち方がずれると「自分の環境では動くのに」が再発します。これを解決するのが docker compose です。
docker compose は、複数コンテナの構成を1つの YAML ファイル(compose.yaml、古い名前では docker-compose.yml)に書いて、1コマンドでまとめて上げ下げする道具です。
図を見ると、前のアニメモで見た docker run のオプションが、そのまま YAML の項目に対応しているのが分かります。使うイメージは image:、自分でビルドするなら build:、-p は ports:、-e は environment:、-v は volumes:。services: の下に並ぶ db・cache・web が、それぞれ1つのコンテナになります。
つまり compose.yaml は「run の指示書を複数まとめたもの」です。手で打っていたことを宣言として書き、ファイルごと Git に入れて共有できる。だからチーム全員が同じ構成で、同じコマンド1つで環境を立ち上げられます。
compose ならではの便利さが2つあります。1つ目がネットワークです。compose は up のときに専用の仮想ネットワークを自動で作り、全サービスをそこに繋ぎます。そしてサービス名がそのままホスト名になります。web のコンテナから見ると、db というホスト名で PostgreSQL に、cache というホスト名で Redis に届きます。
ここでよく戸惑うのが、設定ファイルに書くホスト名が localhost ではないことです。同じ PC の上で動いていても、コンテナはそれぞれ別のネットワーク空間に居るので、web にとっての localhost は web 自身です。DB に繋ぐなら db と書きます。
2つ目が depends_on で、起動の順番を指定できます。web は db と cache が立ち上がってから起動する、と書いておけます。また ports: を書いていないサービスは外から見えません。図の db と cache は web からだけ届き、ブラウザからは直接触れない。これが自然に守られるのも compose の利点です。
日常的に使うのは、ほぼ2つのコマンドです。docker compose up -d で、必要ならイメージをビルドまたは pull し、ネットワークを作り、depends_on の順にコンテナを起動します。docker compose down で、コンテナとネットワークを消します。ボリュームは残るので、翌日 up すれば DB のデータはそのままです。
ログは docker compose logs -f web のようにサービス名で絞って見られ、docker compose exec web sh で動いているコンテナの中に入ってコマンドを打てます。Dockerfile や依存を変えたときは up -d --build でビルドし直します。
前のアニメモで見た「環境とソースを分ける」考え方は、compose でも同じです。volumes: に .:/app のようにソースのマウントを書いておけば、コードを直すたびに up し直す必要はなく、ビルドし直すのは Dockerfile や依存が変わったときだけです。
3つのアニメモで見てきたことを1枚にまとめます。Dockerfile を build するとイメージができ、イメージを run するとコンテナが動く。コンテナの中のデータはボリュームに逃がし、外との通信はポート公開で開ける。複数のコンテナをまとめて扱うのが compose で、イメージを配るのがレジストリ。
そして一貫して効いていた考え方が「環境とソースを分ける」でした。環境(ランタイムと依存)は変わる頻度が低いのでイメージに焼いて配る。ソースは頻繁に変わるので、開発中はマウントし、本番向けには最後の薄い層として COPY する。会社のイメージはプロダクトそのものなので非公開レジストリに置き、CI も本番も手元も同じイメージを pull して使う。
実際のプロジェクトで迷ったら、Dockerfile と compose.yaml と CI の設定ファイルを開いて、「どのイメージを、どこから、どう使っているか」をこの5つの言葉に当てはめてみてください。たいていの疑問はそこで解けます。
