2024年Docker Compose 2.29+対応のFile Watch機能。File変更検知+Auto Sync+Auto Rebuild+Hot Reload+develop section設定+Tilt/Skaffold代替候補+開発体験改善搭載。
Docker Compose Watchは2024年Docker Compose 2.29+でstable昇格したFile Watch機能で、compose.yaml の develop section に watch 設定を記述するだけで、ローカルファイル変更を検知してContainer内のファイルを自動Sync+Auto Rebuild+Hot Reloadを実行する仕組み。従来のVolume Mount(ローカルファイルをContainerにバインド)+inotify-based Watcher(Library/Frameworks独自)の組み合わせを統合・標準化したもので、Docker公式のオールインワン開発体験ツール。Tilt(Apache 2.0)・Skaffold(Apache 2.0)等のKubernetes開発ツールが提供していた「ファイル変更→Container自動更新」のWorkflow をDocker Compose 単独で実現可能にし、Microservices開発の生産性向上に貢献。docker compose watch コマンドまたは --watch フラグで起動、CTRL+C で終了する単純なCLI。Sync(ファイル単位の同期)・Rebuild(イメージ再構築)・Sync+Restart(Sync後Container再起動)の3 Action型で、ファイル変更パターン別に動作切替可能。
compose.yaml 内に Watch ルール宣言、複数Service対応src/**/*.js、!**/test/** 除外)docker compose watch または docker compose up --watch| 項目 |
|---|
| Docker Compose Watch |
|---|
| Volume Mount+Hot Reload |
|---|
| Tilt |
|---|
| Skaffold |
|---|
| 設定場所 | compose.yaml develop section | docker-compose.yml volumes | Tiltfile(Starlark) | skaffold.yaml |
| 学習曲線 | 低 | 低(既知) | 中-高 | 中 |
| Auto Rebuild | ○ | × Manual | ○ | ○ |
| Multi-target対応 | ○ | △ | ○ | ○ |
| Kubernetes統合 | × | × | ○ Native | ○ Native |
| Bundle Size | Native(0KB) | 0KB | ~30MB | ~70MB |
| Watch効率 | inotify Native | OS Native | inotify | inotify |
| 設定複雑度 | シンプル | シンプル | 高 | 中 |
# compose.yaml
services:
web:
build: ./web
ports:
- "3000:3000"
develop:
watch:
- action: sync
path: ./web/src
target: /app/src
ignore:
- node_modules/
- .git/
- action: rebuild
path: ./web/package.json
- action: sync+restart
path: ./web/.env
target: /app/.env
api:
build: ./api
develop:
watch:
- action: sync
path: ./api
target: /app
ignore:
- "**/*.pyc"
- "__pycache__/"
- action: rebuild
path: requirements.txt
# CLI起動
docker compose watch
# または
docker compose up --watch
sync action+ Next.js webpack-dev-server連携で完全Hot Reloadsync action+uvicorn watcher組合せDocker Compose WatchはWeb/Microservices開発者向けの開発体験改善機能で、jisaku.com の VPS API(Hono on Bun + Docker Compose運用)では将来採用候補となる重要機能。jisaku.com 現状の compose.yaml でVolume Mountだけでもhot reloadは実現できているが、Watch機能採用で1)複数Service同時Hot Reload、2)Dockerfile変更時のAuto Rebuild、3).env変更時のRestart自動化のメリット得られる。Hono on Bun は bun run --watch で本体でHot Reload対応するが、Docker内で動作させる場合はDocker Compose Watch + bun --watch の二重Watch構成で確実な開発体験を構築可能。Tilt(¥フリー Apache 2.0)・Skaffold等の Kubernetes開発ツールに比べて、Docker Compose Watch は単一ツールで完結する点が魅力で、Kubernetes採用しないMonolith/Mini-Microservices開発には最適解。一方、Production環境での Watch機能利用は非推奨、docker compose up(Watch なし)で安定運用する。File Watch のオーバーヘッドはinotify Native実装で極小、CPU使用率向上はほぼなし。MacOS環境ではFSEvents経由、Linux ではinotify、Windowsは ReadDirectoryChangesW 経由で OS Native Watcher を活用、Cross-platform対応完備。
Volume Mount + Hot Reloadとの違い: Volume Mount は Hot Reloadフレームワーク(webpack-dev-server/uvicorn --reload等)に依存、Compose Watchは標準化されたAuto Sync+Rebuild+Restart の3Action型。Compose Watchの方が宣言的+Multi-Container対応で柔軟。 Tiltとの違い: Tilt(2018年〜)は Kubernetes 開発ツール、Compose Watchは Docker Compose 専用。Kubernetes 採用なら Tilt、Docker Compose 採用なら Compose Watch。学習曲線も Tilt(Tiltfile Starlark)より Compose Watch(yaml)が低い。
Q1: Volume Mount + nodemon と Docker Compose Watch どちらを選ぶ？ A: 単純なHot Reloadのみなら Volume Mount + nodemon で十分、Multi-Container対応 + Dockerfile変更時のAuto Rebuild + 複雑なPath Pattern対応 → Compose Watch。Compose 2.29+ 利用環境なら Watch 採用がより現代的。
Q2: Watch機能のCPU使用率は？
A: 極小。inotify Native実装でファイル変更通知のみ受信、Polling型(watchman等)よりはるかに効率的。1000ファイル監視でCPU使用率1%未満、Battery駆動 Mac でも問題なし。
Q3: ignoreパターンは正規表現対応？
A: gitignore互換のglobパターン+!否定構文対応。**/*.test.js(全test files)、!src/**/*.test.js(srcのtest除外)、node_modules/(全node_modules)等の柔軟な指定可能。正規表現は非対応、glob で十分。