WordPress向けDocker：分離されたコンテナがすべてを変える理由

従来のWordPressホスティングでは、複数のサイトを1つのサーバーに配置します。PHPを共有し、ファイルシステムへのアクセスを共有し、多くの場合データベースサーバーを共有します。これは問題ない限りは問題ありません。問題が発生した場合、それは深刻な問題となります。

PAGEnzaは、各WordPressサイトを独自のDockerコンテナでプロビジョニングします。この記事では、それが実際に何を意味し、なぜ複数のクライアントサイトを管理するエージェンシーにとって重要なのかを説明します。

共有ホスティングの問題

典型的な共有ホスティングプランや、複数のWordPressをインストールした基本的なVPSでも同様です。

リソース競合: あるサイトでトラフィックが急増すると、サーバー上の他のすべてのサイトが遅くなります。サイトAの最適化されていないプラグインは、サイトBのパフォーマンスを低下させます。

セキュリティの波及: 脆弱なプラグイン、弱いパスワード、または古いコアバージョンを介してWordPressのインストールが侵害された場合、ファイルシステムへのアクセス権を取得した攻撃者は、同じサーバー上の他のサイトのファイルを読み取ることができる場合があります。

PHPバージョンの競合: サイトAは古いプラグインのためにPHP 7.4を必要とします。サイトBは新しいプラグインのためにPHP 8.2を必要とします。共有ホスティングでは、どちらか一方を選択する必要があります。

データベースの露出: 共有データベースサーバーは、1つの設定ミスしたユーザー権限が他のサイトのデータを公開する可能性があることを意味します。

Dockerコンテナは、これらすべてをインフラストラクチャレベルで解決します。

コンテナとは何か

Dockerコンテナは、独自の以下のものを持つ、軽量で分離されたプロセスです。

• ファイルシステム（コンテナは境界外のファイルを見ることができません）
• ネットワークスタック（独自のIPアドレス、独自のポート）
• プロセス空間（他のコンテナのプロセスを見ることができません）
• リソース制限（CPUおよびメモリの上限）

ホストカーネルは他のコンテナと共有しますが、カーネルより上のすべては分離されています。完全な仮想マシンではありません。数秒で起動し、数分ではなく、リソースのごく一部しか使用しません。

WordPressの場合、単一のコンテナでNginx、PHP-FPM、およびWordPressファイルが実行されます。データベースは別のコンテナで実行され、その特定のWordPressコンテナにのみ接続されます。

PAGEnzaがサイトをプロビジョニングする方法

PAGEnzaで新しいクライアントサイトを作成すると、45秒未満で次のようになります。

1. ベースのWordPressイメージから新しいDockerコンテナが起動されます。
2. WordPressは、共有MariaDBインスタンス上に新しいデータベース（そのコンテナの認証情報に分離されています）で設定されます。
3. PAGEnzaプラグインが自動的にインストールされ、有効化されます。
4. Nginx仮想ホストがクライアントのサブドメインで設定されます。
5. Let's Encryptを介してSSLが発行されます。
6. コンテナは、正しいルーティングルールとともにリバースプロキシに登録されます。

クライアントは、"サイト作成"をクリックしてから45秒以内に、clientname.pagenza.comのようなURLにアクセスできるようになります。手動のサーバー設定、SSH、DNSの待機時間（サブドメインの場合。カスタムドメインのDNS伝播は別途です）は不要です。

コンテナの分離の実践

メモリ制限: 各コンテナには設定可能なメモリ上限があります。暴走したプラグインが1つのクライアントサイトでメモリスパイクを引き起こした場合でも、他のコンテナに割り当てられたメモリを消費することはできません。サイトは遅くなるか、503エラーを返すかもしれませんが、他のクライアントには影響しません。

ファイルシステム分離: クライアントAのWordPressファイルは、クライアントBのコンテナからは完全に不可視です。クライアントAのサイトで侵害されたプラグインは、クライアントBのファイルにアクセスするパスを持ちません。

ネットワーク分離: コンテナは定義されたネットワークブリッジを介してのみ通信します。クライアントAのデータベースコンテナは、システム上の他のコンテナからではなく、クライアントAのWordPressコンテナからの接続のみを受け入れます。

コンテナごとのPHP: 各コンテナは独自のPHP-FPMインスタンスを実行するため、クライアントごとに異なるPHPバージョンを実行できます。PHP 7.4を必要とするクライアントAのレガシープラグインは、PHP 8.2でクライアントBの最新スタックと並行して問題なく実行されます。

カスタムドメイン

デフォルト設定では、各クライアントに*.pagenza.comのサブドメインが提供されます。独自のドメインを希望するクライアントの場合、プロセスは次のとおりです。

1. クライアントはドメインのAレコードをPAGEnzaサーバーIPに向けます。
2. PAGEnzaダッシュボードでカスタムドメインを入力します。
3. リバースプロキシ設定が自動的に更新されます。
4. Let's Encryptを介してカスタムドメインのSSLが発行されます。

WordPressのsiteurlとhomeオプションが一致するように更新されます。クライアントの視点からは、サブドメインが表示されるリダイレクトなしで、ドメインでサイトが機能します。

エージェンシーにとっての意味

複数のクライアントサイトを実行するエージェンシーにとっての実用的なメリットです。

オンボーディング速度: 新しいクライアントサイトのプロビジョニングは1分未満で完了します。サーバー設定、cPanel、手動のWordPressインストールは不要です。

クライアント分離: 各クライアントのサイトは真に分離されています。問題のあるプラグインをインストールしたクライアントは、自身のサイトにのみ影響します。

スケーラビリティ: 新しいクライアントを追加しても、新しいサーバーをプロビジョニングする必要はありません。コンテナインフラストラクチャはホストの容量にスケーリングされ、容量の追加はホストノードの追加の問題です。

災害復旧: 各サイトはコンテナ化されているため、バックアップと復元はコンテナレベルで動作します。単一のクライアントサイトを復元しても、他のクライアントには影響しません。

トレードオフとして、コンテナホスティングは共有ホスティングよりもサイトあたりのコストが高くなります。しかし、サイトの信頼性とクライアント分離が譲れないエージェンシーにとっては、特にプロビジョニング時間の節約を考慮すると、経済的に成り立ちます。