【Day 26】docker compose up / down / build の実務コマンド完全マスター 〜バックグラウンド起動（-d）、差分再ビルド（--build）、ログ監視、コンテナ・ボリューム完全初期化（down -v）の実務頻出ワークフローとC#開発サイクル〜

▲ Day 26: docker compose up / down / build の実務コマンド完全マスター

🐳

「C#コードを直したのにコンテナに反映されない…」「DBを初期状態にやり直したい…」と悩んでいませんか？

Windows ServerやIIS、物理サーバーで長年システム構築・運用に携わってきたベテランエンジニアにとって、「サービスの再起動」や「設定反映」「テストデータ初期化」は、GUIツールや手動バッチで行うのが日常茶飯事でした。
しかしDocker Composeを導入すると、「docker compose up を叩いても古いイメージのまま起動する」「ターミナルがログ出力で埋まって次の操作ができない」「コンテナを消したのに前回の古いDBデータがゾンビのように残っている」という独特の挙動に戸惑う方が続出します。
本講義では、実務の現場で毎日何十回と叩くことになる up / down / build / ps / logs の黄金オプションとライフサイクル を徹底解説し、C#/.NET開発における超高速でクリーンな開発サイクルを確立します！

INDEX 本日の講義カリキュラム

1. 最速・確実な起動コマンド: docker compose up -d --build の全貌
2. データの運命を分ける停止コマンド: down vs down -v の決定的な違い
3. 状態監視とトラブルシューティング: docker compose ps と logs -f
4. Gitブランチ運用と連動するC#現場の最短開発ワークフロー
5. 実務頻出 Compose CLI クイックリファレンス早見表
6. 本日のまとめと理解度チェック

① 最速・確実な起動コマンド: docker compose up -d --build の全貌

Docker Compose環境で日々の開発を始めるとき、あるいはソースコードを修正したとき、最も頻繁に叩く基本コマンドが docker compose up です。
しかし、オプションを指定せずに単に docker compose up と実行すると、開発現場では以下の2大問題が確実に発生します。

▲ 【図解①】docker compose up -d --build の3ステップ差分再ビルド＆バックグラウンド起動フロー

⚠️ 単純な docker compose up の2大落とし穴

• 落とし穴1（ターミナル占有）: デフォルトではフォアグラウンド実行となり、全コンテナのログがターミナル画面を埋め尽くします。コンソールがロックされ、次のコマンド入力ができなくなってしまいます。
• 落とし穴2（古いイメージの再利用）: Composeは「既にローカルにビルド済みイメージが存在する場合、Dockerfileの変更がない限り再ビルドをスキップする」という最適化を行います。そのため、C#の .cs コードを変更しても古いバイナリのままコンテナが起動してしまいます。

この2つの問題を一撃で解決するのが、-d（デタッチ） と --build（再ビルド強制） の組み合わせです。

# 実務で毎日10回以上叩く鉄板コマンド

docker compose up -d --build

このコマンドを実行すると、Composeは以下の3ステップを自動で高速実行します：

1. ① ソースコードの差分検知: Dockerfileやコンテキスト内のC#ファイルに変更があるサービスのみを識別します。
2. ② 差分再ビルド（--build）: 変更のあったコンテナイメージのみをDockerキャッシュを活用して数秒でリビルドします（変更のないSQL ServerやRedisはビルドをスキップ）。
3. ③ バックグラウンド起動（-d）: コンテナをバックグラウンド（デーモン）プロセスとして立ち上げ、ターミナルの制御を即座にユーザーへ返却します。

② データの運命を分ける停止コマンド: down vs down -v の決定的な違い

コンテナの運用を終了するとき、あるいは環境をリセットしたいときに使うのが docker compose down です。
ここで絶対に押さえておくべきが、「down 単体」 と 「down -v」 の決定的な動作の違いです。

▲ 【図解②】通常の停止（down） vs ボリューム完全初期化（down -v）の決定的な違いと用途

両者の違いを表形式で明確に整理しておきましょう。

比較項目	docker compose down（通常）	docker compose down -v（ボリューム破棄）
コンテナとネットワーク	安全に停止して削除	安全に停止して削除
データベースのデータ（Volume）	保持される（データ消えない）	完全に消去される（初期化）
主な利用シーン	一日の作業終了、PCの再起動前	EF Coreマイグレーションのやり直し、Gitブランチ切替時
オンプレミス換算の作業	サービスの停止・開始	DROP DATABASE ＋ CREATE DATABASE ＋ 初期データ投入

💡 C# Entity Framework Core 開発での絶大な威力

チーム開発で別ブランチから最新コードをプルした際、データベースのスキーマとC#モデルクラスの定義が食い違ってマイグレーション例外（SqlException）が発生することがあります。
そんな時は迷わず docker compose down -v ➡ docker compose up -d を実行してください。
壊れたスキーマが瞬時に消滅し、クリーンなSQL Serverがわずか数秒で再構築されます。オンプレ時代のようにSQL Server Management Studio（SSMS）を開いてテーブルを手動DROPする手間は完全にゼロになります！

③ 状態監視とトラブルシューティング: docker compose ps と logs -f

バックグラウンド（-d）で立ち上げた複数コンテナが「本当に元気に動いているのか？」を確認し、トラブル発生時に原因を特定するための2大監視コマンドをマスターしましょう。

▲ 【図解③】docker compose ps（死活監視）と logs -f（リアルタイムログ監視）のトラブルシューティング

1. コンテナの健康診断: docker compose ps

docker compose ps を実行すると、YAMLファイルで定義されたすべてのサービスの状態が一括表示されます。

$ docker compose ps NAME IMAGE COMMAND SERVICE STATUS PORTS docker-webapi-1 docker-webapi "dotnet DockerApi.dll" webapi Up 2 minutes 0.0.0.0:5000->8080/tcp docker-sqlserver-1 mcr.microsoft.com "/opt/mssql/bin/sqls…" sqlserver Up 2 minutes (healthy) 0.0.0.0:1433->1433/tcp docker-redis-1 redis:7-alpine "docker-entrypoint.s…" redis Up 2 minutes (healthy) 0.0.0.0:6379->6379/tcp

注目すべきは STATUS 列 です。Up と表示されていれば正常稼働中、前回設定した healthcheck が成功していれば (healthy) と表示されます。
もし設定ミスや例外で起動に失敗しているコンテナがあれば、Exit 1 や restarting と表示され、異常が一瞬で判明します。

2. リアルタイムログ追跡: docker compose logs -f

「Web APIが起動しない」「500 Internal Server Errorが発生した」という場合は、logs コマンドで出力を確認します。

# 全コンテナのログを色分けしてリアルタイム監視（Ctrl+Cで終了）

docker compose logs -f

# Web APIコンテナだけに絞り込み、直近50行からストリーム追跡

docker compose logs -f --tail=50 webapi

-f（follow）オプションを付けることで、Linuxの tail -f と同様に新規出力されるログをリアルタイムで追跡できます。
さらにサービス名（webapi など）を指定すれば、SQL Serverなどの余計なログを排除して、C#アプリケーションの例外スタックトレースだけを集中して監視できます。

④ Gitブランチ運用と連動するC#現場の最短開発ワークフロー

Composeコマンドを単体で知っていても、実際のチーム開発フローに組み込めなければ意味がありません。
C#実務の現場でブランチを切り替えて機能開発を進める際の、「事故ゼロ・最短黄金サイクル」 を図解と手順でマスターしましょう。

▲ 【図解④】Gitブランチ切り替えからコンテナ反映・マイグレーション適用までのC#現場最短ワークフロー

プロが実践する3大シチュエーション別コマンド集

シナリオA: Gitブランチを切り替えて別機能のレビューを行うとき

# 1. 前のブランチのコンテナとDBボリュームを完全破棄
docker compose down -v

# 2. 対象ブランチにスイッチ＆最新コード取得
git switch feature/order-api
git pull origin feature/order-api

# 3. 新ブランチのコードで差分ビルド＆起動
docker compose up -d --build

💡 ポイント: ブランチ切り替え前に down -v を実行することで、古いブランチで適用されたDBマイグレーションの残骸が新ブランチに悪影響を及ぼす事故を100%防止できます。

シナリオB: C#コード（ControllersやServices）を編集した直後の動作確認

# C#コードを保存したら、この1コマンドを叩くだけ！
docker compose up -d --build webapi

💡 ポイント: 末尾に webapi とサービス名を指定することで、SQL ServerやRedisを一切触らず、Web APIコンテナだけをピンポイントで最速再ビルド＆再起動できます。

シナリオC: 設定ファイル（appsettings.Development.json）だけを変更したとき

# 再ビルド不要！わずか1秒でプロセスだけ再起動
docker compose restart webapi

💡 ポイント: ホスト側のボリュームマウント（Bind Mount）で設定を渡している場合、再ビルドは不要です。restart コマンドでプロセスのみを再起動すれば即座に新設定がロードされます。

⑤ 実務頻出 Compose CLI クイックリファレンス早見表

日常の開発でデスクトップに貼っておきたい「Compose実務コマンド一覧表」です。迷ったときはこの表を参照してください。

コマンド	動作と効果	頻度
docker compose up -d --build	差分を再ビルドし、バックグラウンドで全サービス起動	★★★★★（最頻出）
docker compose down	コンテナ・ネットワークを停止・削除（DBデータは保持）	★★★★☆
docker compose down -v	コンテナに加え、DBボリュームも完全削除（完全初期化）	★★★★☆
docker compose ps	稼働中コンテナの一覧、ヘルスチェック状態、ポート表示	★★★★☆
docker compose logs -f [srv]	リアルタイムで標準出力ログを監視（サービス絞り込み可）	★★★★★
docker compose restart [srv]	指定したコンテナのみを再ビルドなしで即座に再起動	★★★☆☆
docker compose exec [srv] [cmd]	稼働中コンテナ内でコマンド実行（例: dotnet ef ...）	★★★☆☆

⑥ 本日のまとめと理解度チェック

💡 本日の重要ポイント総まとめ

• 起動の標準形（up -d --build）: ターミナルを解放する -d と、コード差分を確実に反映する --build をセットで運用する。
• データの保持と破棄（down vs down -v）: PC終了時は通常の down でデータを保護し、マイグレーション不整合やブランチ切替時は down -v でボリュームごとクリーンリセットする。
• 状態監視（ps と logs -f）: 異常終了は ps で即座にあぶり出し、例外スタックトレースは logs -f [サービス名] でリアルタイム追跡する。
• C#開発の黄金ループ: 「Gitブランチ切替 ➡ down -v で初期化 ➡ up -d --build 起動」により、オンプレミス時代の手動DB管理から完全に解放される。

次回【Day 27】予告:
第6部 データ永続化編突入！『コンテナを破棄するとデータが消える！？ データの永続化の原理（Volume & Bind Mount）』〜UnionFS/OverlayFSの書き込みレイヤーの仕組みと、ホストOS側にデータを逃がすボリューム設計を完全図解〜