DevOps

docker compose watch・profiles・include の使いどころ：書き方が変わった5つの機能

Docker Compose を「コンテナをまとめて起動するもの」として使っているだけだと、いつの間にか増えた機能を取りこぼします。ここ数年で入って、実際に手元の書き方が変わったものを5つ挙げます。

1. docker compose watch でマウントを卒業する

bind mount の遅さやファイル権限の問題は、コンテナ開発で最初にぶつかる壁です。watch は、ホスト側の変更を検知してコンテナへ反映する仕組みで、マウントとは別の解き方をします。

services:
  web:
    build: .
    develop:
      watch:
        - action: sync
          path: ./web
          target: /app/web
          ignore:
            - node_modules/
        - action: rebuild
          path: package.json

docker compose watch で起動すると、ソースの変更は同期だけで済み、package.json が変わったときだけリビルドが走ります。ホットリロードが効きにくい構成でも、この使い分けができます。

2. profiles で「普段は起動しないもの」を分ける

pgAdmin や MailHog のようなデバッグ用サービスは、常に立ち上げたいわけではありません。

services:
  app:
    image: my-app

  db-admin:
    image: dpage/pgadmin4
    profiles:
      - debug

通常の docker compose up では db-admin は起動せず、--profile debug を付けたときだけ立ち上がります。docker-compose.override.yml を分けて管理していたのが不要になります。

3. include でファイルを分割する

肥大化した Compose ファイルを分けるのに、extends や -f の連結を使っていたところは include で書けます。

# compose.yaml
include:
  - path: ./infra/compose.yaml
  - path: ./backend/compose.yaml

services:
  proxy:
    image: nginx
    depends_on:
      - backend

別チームが持っている Compose ファイルを、パス指定だけで自分のプロジェクトに取り込めます。

4. depends_on だけでは待ってくれない

「DB が立ち上がる前にアプリが起動して落ちる」は depends_on では防げません。depends_on が保証するのは起動順であって、中のプロセスが接続を受けられる状態かどうかは見ていないからです。

healthcheck と組み合わせます。

services:
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

  backend:
    build: .
    depends_on:
      db:
        condition: service_healthy

これで pg_isready が通るまで backend は起動しません。再起動ループを眺める時間がなくなります。

5. name でプロジェクト名を固定する

Compose はデフォルトでフォルダ名をプロジェクト名に使います。つまりディレクトリをリネームすると別プロジェクト扱いになり、それまでのボリュームが見えなくなります。

name: my-super-project
services:
  ...

トップレベルに name を書いておけば、置き場所に関係なく同じプロジェクトとして扱われます。CI のようにディレクトリ名が変わりうる環境では特に効きます。

ついでに、version: '3' は書く必要がなくなっています。今も残っているファイルは、消しても動きます。