ホームサーバー上のPHPベースのDockerアプリを安全にアップデートする方法

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

コンテナ内のPHPセキュリティパッチは通常、イメージの再ビルドを通じて提供されます。そのイメージのダウンロードと、サービスへの適用は別の手順です。更新計画では、コンテナより長く存続するデータベースと永続ファイルも保護する必要があります。

イメージを変更する前に、アプリケーションデータ、該当する場合はデータベース、設定をバックアップしてください。サポート対象のパッチ適用済みリリースをプルしてサービスを再作成し、置き換え後のコンテナを確認してください。更新完了として記録する前に、重要なユーザー操作を確認してください。

1. 現在のデプロイ内容を記録する

docker compose psでプロジェクトディレクトリとサービス名を確認してください。docker compose imagesで現在のイメージタグとイメージIDを記録し、永続ボリュームとデータベースの保存場所も確認してください。共有ログに秘密情報を公開しないよう注意しながら、Compose設定の保護されたコピーを保存してください。

更新先イメージのリリースノートで、PHPの修正が含まれていることを確認してください。latestというタグは、特定のパッチが含まれている証拠にはなりません。ダイジェストを固定している場合は、確認済みの代替ダイジェストに変更する必要があります。

2. 整合性の取れたバックアップを作成する

アプリケーションの公式バックアップ方法を使用してください。設定、ファイル、整合性の取れた復旧時点のデータベースバックアップを保持してください。アプリケーションが必要とする場合は、書き込みの一時停止やメンテナンスモードを調整してください。稼働中のデータベースディレクトリをファイルシステム上でコピーしても、常に有効なデータベースバックアップの代わりになるわけではありません。

復旧用コピーはアプリケーションから書き込みできない場所に保管し、復元方法を把握しておいてください。以前の設定とイメージ参照も保持してください。ただし、古い脆弱なイメージを復元して、そのままインターネットに公開してはいけません。

3. 対象のサービスをプルして再作成する

メンテナーが公開しているイメージを使う場合は、サービスのイメージ参照を互換性のある固定リリースに更新してから、正しいプロジェクトディレクトリで次の例を実行してください。appはPHPアプリケーションのサービス名に置き換えてください。

docker compose pull app
docker compose up -d --no-deps app
docker compose ps
docker compose exec -T app php -v

Dockerのドキュメントによると、pullはコンテナを起動せずにイメージをダウンロードし、upはイメージや設定の変更を適用するため、コンテナを再作成します。ここで--no-depsを指定すると、変更対象を選択したサービスに限定できます。依存サービスがすでに正常に稼働し、互換性もある場合にのみ使用してください。

カスタムビルドの場合は、該当するPHPベースイメージまたはパッケージを更新し、通常のビルドパイプラインで再ビルドして、生成されたイメージをデプロイしてください。同じランタイムを使用するワーカーについても同様に更新します。一時的なコンテナのシェルでパッチを適用しても、コンテナの再作成後に修正が保持されるとは限りません。

4. アクセスを再開する前にアプリケーションを検証する

トークンや非公開のパスを共有せず、ローカルでログを確認して起動エラーがないか調べてください。Webランタイムを確認したうえで、ログイン、ファイルの閲覧、小さなファイルのアップロード、バックグラウンドタスクをテストします。ボリュームのパスと所有権が意図した構成と一致していることも確認してください。

外部からのアクセスを制限していた場合は、バージョンと機能の確認に合格してから再開してください。コンテナのステータスが正常なだけでは、アップロードやバックグラウンドジョブが動作するとは限りません。

5. 検証に失敗した場合は慎重に復旧する

調査中はサービスを隔離してください。アプリケーションの移行ルールで必要な場合は、アプリケーションのファイルとデータベースの状態を一緒に復元してください。スキーマのアップグレード後にイメージだけを変更すると、安全でない場合があります。名前付きボリュームが削除される可能性があるため、トラブルシューティングの近道としてdocker compose down -vを使用しないでください。

ZimaCube 2をお使いの場合は、アップデートの記録を大量のファイルとは分けて保管し、独立したバックアップを維持してください。アップデートが正常に完了した状態とは、実行時のバージョンが把握でき、アプリケーションの機能が動作し、復旧手順を説明できることです。

プライベートストレージやセルフホスト型アプリの環境構築には、ZimaCube 2 パーソナルクラウドホームNASをご覧ください。ソフトウェアのセキュリティは、インストールされているサービス、その設定、確認済みのアップデートによって異なります。

PHPセキュリティシリーズの続きを読む

情報源と対象範囲

2026年10月22日確認。デプロイに関する推奨事項は、使用するアプリケーションとベンダーのドキュメントに照らして確認してください。この記事では、特定製品の脆弱性については断定していません。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.