Docker アプリ導入

install_workerman3524_base_docker.sh

app と logs を作り、サンプルと composer.json はない場合だけ書きます。Dockerfile は毎回上書きします。可変の PHP 7.2/Composer タグからビルド後、同名コンテナーを強制置換し、logs のみをマウントします。

ワンライナー

curl -fL 'https://www.helper.sh/install_workerman3524_base_docker.sh' -o './install_workerman3524_base_docker.sh'

このコマンドは同梱ファイルをダウンロードするだけで、実行しません。保存したソースを確認し、バージョンを照合してから実行するか判断してください。

保存したファイルを照合

このページのビルドに同梱されたバイト列と照合します。ファイルはこのタブ内で処理し、この機能は送信・保存しません。上限は2 MiBです。

期待する SHA-256
e3f40b68c2dc6cc4c865d7498000d73352f373a589362c141e485e3567f7bbb4

同梱ファイルのバイト数: 5729

チェックサムファイルを保存

スクリプトとチェックサムを同じディレクトリに保存してください。GNU Coreutils のある Linux では次のコマンドでバイト列だけを検査できます。スクリプトは実行しません。コマンドには元のファイル名が必要です。

sha256sum --check './install_workerman3524_base_docker.sh.sha256'

まだ照合していません。

スクリプトとチェックサムは同じサイトから取得し、独立した署名ではありません。一致しても安全性、上流の真正性、ホストへの適合性は証明しません。可変の依存先は別途確認してください。

検証と制限を読む

実行条件

  • Linux ホスト
  • 稼働中の Docker
  • root または sudo 権限
  • 空いている2345番ポート
  • 書き込み可能な /data

適用場面

  • Workerman 3.5.24 に依存する旧アプリの互換性確認
  • /data/workerman3.5.24 でソースとログを確認
  • イメージに組み込むアプリの引き継ぎと再ビルド手順の確認

主なポイント

  • /data/workerman3.5.24/app と logs を作成
  • 存在しない場合のみサンプルアプリと composer.json を作成
  • php:7.2-cli から helper-workerman:3.5.24 をビルド
  • 2345番ポートを公開。準備確認の警告だけで処理が続く場合がある

推奨手順

  1. Docker と2345番ポート、既存の同名コンテナーを確認します。
  2. ファイルを取得・確認してから root での実行を判断します。
  3. ビルドされる Dockerfile と既存アプリを確認します。
  4. ホストの app を編集しただけでは稼働アプリは変わりません。再ビルドとコンテナー置換を計画します。

注意事項

  • Workerman 3.x と PHP 7.2 は旧構成です。互換性上必要な場合に用途を限定してください。
  • 旧 PHP のサービスは公開範囲と更新計画を審査してください。
  • 置換前に /data/workerman3.5.24 と現在のイメージを保全してください。

対応範囲と制限

  • systemd を使う Linux、Docker のビルド機能、root、書き込み可能な /data、空きホストポート(既定 2345)が必要です。旧 Workerman 3.5.24/PHP 7.2 互換用の例で、PHP 7.2 はサポート終了済みです。
  • 引数は --data-dir、--container-name、--port です。dry-run、バックアップ、自動復旧はありません。php:7.2-cli と composer:2.2 は可変タグです。生成する Dockerfile はイメージのビルド内で APT アーカイブ情報の期限確認を無効にし、安全性を確認できないリポジトリを許可します。
  • composer install の前には composer.json だけをコピーし、ホストの composer.lock ではその段階を固定しません。既存 composer.json を保持するため、要求する Workerman バージョンが変わる場合があります。上流の内容が変われば依存物を再確認してください。

変更されるファイル、サービス、データ

  • /data/workerman3.5.24/app と logs を作成し、app/start.php と composer.json はない場合だけ書きます。DATA_DIR/Dockerfile は毎回バックアップなしで上書きし、独自変更も失われます。
  • helper-workerman:3.5.24 を先にビルドし、同名コンテナーを強制削除して指定ホストポートからコンテナーの 2345 番を公開します。bind mount は logs のみで、アプリはイメージにコピーします。ホストの app を編集したら再ビルド・再作成が必要です。
  • ホストファイルをバックアップなしで再利用します。logs のマウントだけでは独自アプリがそこへ記録する保証はありません。TLS や公開範囲の制限は設定しません。

読み取り専用の確認

  • 名前・パスを変更したら読み替えます。`docker inspect workerman3524 --format '{{json .Mounts}} {{json .HostConfig.PortBindings}}'`、`docker ps --filter name=workerman3524`、`docker logs --tail 100 workerman3524` を確認します。
  • `docker exec workerman3524 php -v` と `docker exec workerman3524 composer show workerman/workerman` で実際のランタイムとパッケージ版を確認します。
  • 未変更のサンプルならループバックの HTTP 応答を別途確認します。curl の成功だけではアプリ検証にならず、独自ハンドラーには個別の確認が必要です。HTTP 確認失敗や curl 不在でも警告後に完了表示が出ます。

失敗した場合

ビルド失敗は旧コンテナー削除の前ですが、Dockerfile は上書き済みの場合があります。ホストファイルと既存イメージ・コンテナーの情報を保全し、依存物やアーカイブのエラーを確認してください。置換後の失敗では再ビルド前にポート競合、イメージ版、ログを調べます。独自 Dockerfile と app をバックアップしてください。旧コンテナーの自動復旧はありません。

PHP · Composer

実行前にダウンロードして内容を確認し、バージョンを検証してください。ハッシュはこのバイト列を識別するだけで、安全性を証明しません。pipe 実行は取得した内容を直ちに実行し、上流の依存関係は変化することがあります。

関連記事

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

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

関連トピック

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

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

トピックを見る

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

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

トピックを見る

問題ページ

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

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

ページを見る