ソースに基づく問題切り分け

ホストのアプリ編集が Workerman コンテナーに反映されない理由

同梱 Workerman 例のビルド入力と稼働中マウントを区別し、独自 Dockerfile を保全して、実行中イメージとパッケージを確認します。

約3分で読めます · 2026-03-23

更新日: 2026-10-30

app はコピー、マウントは logs のみ

生成する Dockerfile は app/ をイメージにコピーします。docker run のマウントは DATA_DIR/logs だけなので、DATA_DIR/app/start.php を編集しても稼働中コンテナーは変わりません。古い応答を Docker キャッシュのせいと判断する前に Mounts を確認します。

確認済みコードの反映にはイメージ再ビルドとコンテナー置換が必要です。スクリプトはビルド後に旧同名コンテナーを強制削除し、毎回ホスト Dockerfile を上書きします。独自ビルド手順、アプリ、復旧用イメージを保全してから維持手順を決めてください。

再ビルド前に実際のバージョンを確認

これは旧 PHP 7.2 互換用です。php:7.2-cli と composer:2.2 タグは可変で、アーカイブのビルドは APT 検証を緩めます。composer install 段階には composer.json だけを渡し、ホストの lock ファイルは使いません。イメージ名だけでは再現性や安全性を確認できません。

下記の読み取り確認では実際のコンテナー名を使います。イメージ ID、マウント、PHP、Workerman の実バージョンを記録します。HTTP 状態の成功だけでは修正コードや業務処理の実行は確認できません。独自リクエストの動作を確認してから試験してください。

  • docker inspect workerman3524 --format '{{.Image}} {{json .Mounts}}'
  • docker exec workerman3524 php -v
  • docker exec workerman3524 composer show workerman/workerman

関連トピック

Docker サービス: 接続口と残存データを確認

HTTP、SQL、キャッシュ、FastCGI、イメージ内アプリを、プロトコルとデータ・置換影響で選びます。

トピックを見る

旧 PHP: 互換性とアプリの準備状態を分けて確認

PHP 7.2 と Workerman 3.5.24 は、移行計画を伴う既存環境の互換性確認に限定してください。

トピックを見る

問題ページ

Workerman が完了表示でも HTTP 確認に失敗する場合

再置換する前に、ビルド・コンテナー起動・curl 確認・アプリ検証を切り分けます。

ページを見る