DockerとネイティブPHPデプロイ、パッチ適用とメンテナンスが簡単なのはどちら？

エヴァ・ウォン

IceWhale author

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

Conceptual guide: TWO DEPLOYMENT PATHS. Image + recreate; Package + restart; Check live service.

Dockerではイメージによってアプリケーションのランタイムを再現可能にできる一方、ネイティブPHPは十分に保守されたOSパッケージの運用フローに適しています。どちらも簡単に運用できる場合がありますが、更新元が放棄されたり、構成が文書化されていなかったりすると、どちらも扱いが難しくなります。

保守されているアプリケーションイメージによって、サポート対象ランタイムと再現性のある置き換え手順が提供されるなら、Dockerで作業が便利になります。ディストリビューションが管理するサーバーには、ネイティブパッケージが適している場合があります。どちらの場合も、実際に稼働しているリビジョンを記録し、更新後に影響を受けるサービスを確認してください。

保守単位を比較する

項目	DockerベースのPHP	ネイティブPHP
更新単位	保守されているアプリケーションイメージ、または再ビルドしたカスタムイメージ	ディストリビューションまたは保守されているリポジトリのパッケージ
デプロイ手順	イメージ参照を置き換え、サービスを再作成する	パッケージをアップグレードし、影響を受けるサービスを再起動する
ランタイムの証跡	イメージダイジェストと稼働中サービスの確認	パッケージのリビジョンとWebハンドラーの確認
永続データ	ボリュームと外部データベースは別々に保護する必要がある	ファイルとデータベースは別々に保護する必要がある
よくある見落とし	新しいイメージをダウンロードしたが、古いコンテナがまだ稼働中	CLIは更新済みだが、Webワーカーや別のブランチが更新漏れ
復旧時の制約	古いイメージが移行済みデータに合わない可能性	古いパッケージが移行済みデータに合わない可能性

Dockerで作業が簡素化される場合

保守されているアプリケーションイメージには、既知のランタイムと依存関係一式をまとめられるため、マシンごとの差異を減らせます。ホスト上の同一インストールを共有せずに、サービスごとに互換性のある異なるPHPブランチを使用できます。

運用担当者は引き続きイメージのリリースを監視し、必要に応じてピン留めを変更し、関連するすべてのサービスを再作成して、ボリュームのマッピングを維持する必要があります。カスタムイメージではビルドの責任も生じます。ホストのパッケージを更新してもイメージは再ビルドされません。また、実行中のコンテナを編集しても、イメージを持続的に保守することにはなりません。

Dockerのセキュリティガイダンスでも、構成はセキュリティ境界の一部とされています。ホストの広範なマウント、過剰な権限、デーモンの制御などは、意図した分離を損なうおそれがあります。イメージベースの更新の利便性とは切り離して、これらの設定を個別に評価してください。

ネイティブPHPが適している場合

サポート対象のディストリビューションと、十分に理解されたWebサーバー構成を使うシンプルなホストなら、パッケージベースで直接更新できます。パッケージマネージャーによって、追跡可能なリビジョンとベンダーの勧告を確認できます。

インストール済みの各ブランチ、それを提供するリポジトリ、各サイトが使用するハンドラーを記録してください。シェルのデフォルトのバイナリが、サイトにサービスを提供しているバイナリとは限りません。ベンダーのバックポートにより、上流のバージョンを思わせる文字列よりもパッケージのリビジョンが重要な場合もあります。デプロイ後は、該当するサービスと長時間稼働するワーカーを再起動してください。

どちらの場合も、ロールバックはアプリケーションの問題

古いイメージやパッケージの参照情報を残しておくことは有用ですが、それだけでは完全なロールバック計画とはいえません。アプリケーションのアップデートで、データベースのスキーマ、設定、ファイル形式が変更されることがあります。実行ファイルだけを復元すると、サービスに不整合が生じる可能性があります。

互換性のある復旧用データ一式を保管し、アプリケーションの復元ドキュメントに従ってください。一時的に脆弱なソフトウェアに戻す必要がある場合は、修正版の互換リリースが利用できるまで、隔離した状態を保ってください。以前のバージョンが起動するというだけの理由で、サービスを再公開しないでください。

ZimaCube 2のホームサーバーにはどちらが適している？

使用したいアプリにメンテナンスされているイメージがあり、その設定、ボリューム、アップデートプロセスを管理できるなら、Dockerを選びましょう。OSとアプリに、自分が理解しているサポート対象のパッケージ提供経路があるなら、ネイティブパッケージを選びましょう。両方利用できる場合は、実際のメンテナーとリリースの根拠を比較してください。

ZimaCube 2でどの方式を使う場合も、アップデートの担当者を決め、独立した復旧用コピーを保管してください。実際の環境でパッチを適用し、検証し、復元できる方式が、より優れたデプロイ方法です。

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