PowerCMS ブログ

はじめに

別の記事でもご紹介しましたが、PowerCMSは、静的HTML生成を特長とするCMSです。

このためエンタープライズ分野では、PowerCMSをLANなどのアクセス制限のあるネットワークに配置し、そこで編集・内容確認したWebコンテンツを公開側サーバーに転送する構成が多くなります。

PowerCMSは同時に、生成したWebサイト(公開Webサイト)で利用できる様々な機能を簡単に構築できることも特長です。例えば...

• サイト内検索
• お問い合わせなどのフォーム
• 会員サイト
• バナー管理
• Data API
• 動的コンテンツ(Dynamic MTML)

公開Webサイトでこれらの機能を利用することと、CMSサーバーと公開サーバーを分離することの両者を成立させるには、事前の検討が必要です。場合によっては要件定義で考慮しておく必要があります。本記事では、この検討の基礎となるノウハウを扱います。

前提構成

以降、次の構成を前提としてシステム構成およびソフトウェア・デプロイメントについて議論します。

CMSサーバー

ファイヤーウォール内側のLANに設置します。CMSが利用するデータベースも動作しています。CMSの機能は全て動作しています。CMSで生成したコンテンツはCopy2PublicまたはPowerSyncを用いて公開サーバーに転送します。

公開サーバー

DMZに設置します。Webサイトのビジターは、このWebサーバーのコンテンツにアクセスします。

また、先に挙げた機能のうち「動的コンテンツ(Dynamic MTML)」はPHPで実現されており、それ以外の機能はCGIで実現されています(以後「CGI機能」と呼びます)。このように、CGI機能と「動的コンテンツ(Dynamic MTML)」では実現方式が異なりますが、これ以降で議論するインフラ・レベルではほぼ同じモデルになりますので、以下代表としてCGI機能を中心に議論します。

この構成で公開サーバーでCGI機能を利用する場合、ソフトウェアをどのように配置し設定することになるのでしょうか。

代表的な対応例

簡潔に表現すると、以下のようになります。

1. 公開サーバーにPowerCMSをデプロイします。
2. Perlなどミドルウェアをインストールし、ApacheでCGI実行許可を行います。データベース・サーバーは必要ありません。
3. 設置したPowerCMSから、管理画面を提供する mt.cgiを物理的に削除します(PowerCMSのマニュアルやドキュメントでは、これを「PowerCMSモジュール」と表現しています)
4. (公開サーバーでPSGIを利用している場合) 公開サーバーの mt-config.cgi の環境変数 RestrictedPSGIApp に cms を指定します。また公開サーバーで動作させない他のCGIも指定します。
5. 設置したPowerCMSのmt-config.cgiに記載の環境変数 DBHost に、CMSサーバーのIPアドレスを指定します。

既にお気づきの方もいらっしゃるかと存じますが、論点が2つ出てきました。

1. ライセンス
2. 公開サーバーからLAN内データベースへの通信

それぞれ考えてみましょう。

ライセンス

PowerCMSはサーバー・ライセンスです。CMSサーバーだけではなく公開サーバーでもPowerCMSを利用することになりますので、追加ライセンスが必要となります(アドバンスト版は例外です)。

詳しくはステージング機能を利用しているとき、公開サーバ側でPowerCMSのモジュールを設置します。この場合、ライセンスは台数分必要ですか？をご参照ください。

公開サーバーからLAN内データベースへの通信

PowerCMSでは、利用するデータベースへの接続情報を設定ファイルmt-config.cgiに記載します。例を次に示します。

ObjectDriver DBI::mysql
Database     powercmsdb
DBUser       dbuser1
DBPassword   dbuser1
DBHost       192.168.11.100

これはDBHostで指定されたIPアドレス 192.168.11.100 に存在する、Databaseで指定されたMySQLデータベース powercmsdb に対して、 DBUserおよびDBPasswordの値を用いて接続する設定になります。

PowerCMSとMySQLが同一サーバーの場合はDBHostの値を localhost とするか、環境変数DBSocketを用いてUNIXドメインソケットで通信します。

今議論している、公開サーバーに設置したPowerCMS設定ファイルにおいては、そのサーバーから見たLAN内CMSサーバーのIPアドレスをDBHostに指定することになります。

なお、いわゆる MySQL over TLSはサーバーサイド暗号化、クライアントサイド暗号化ともサポートされておらず、CMSとDB間の通信は平文で流れることになります。

また、以下の2つに注意が必要です。

• 公開サーバーからCMSサーバー内のポート番号3306に対して通信可能か、ファイヤーウォールを確認すること
• MySQLで、CMSサーバーから見た公開サーバーのIPアドレスから、ユーザーdbuser1のアクセス(dbuser1@xxx.xxx.xxx.xxx)がpowercmsdbに対して許可されていること

対応策の検討

これまで、数多くのプロジェクトでインフラ構築を見てきました。そして、今回のような議論(サーバーの役割の分離とCGI機能の併用)になって、先述のような回答をすると、毎回プロジェクトに波紋を投げかけることになります。

私達にご依頼いただく前に、インフラ担当の事業者様によってインフラポリシーの策定、基本設計、場合によっては構築が完了していることが多々ありますが、この議論によって、そのポリシーや実装を修正しなければならないことがあるためです。

また、Webサイトの機能というコンテンツ側の要請が、インフラに影響する数少ない点であることも影響していると思われます。

その対応には、おおむね以下のようなパターンがあります。

パターン1: ネットワーク設定変更、別セグメント構築等でアクセス可能にする

既存のネットワーク構成そのものが簡易的であったり柔軟であることで、ルートが確保できるパターンです。アクセス元制限やファイヤーウォール・ルールの厳格化で意図しない通信を防ぐことが必要です。

パターン2: 公開サーバーからCMSサーバーにVPN接続しアクセス可能にする

パターン1に含まれますが、通信経路を暗号化することで通信可能となるケースです。

パターン3: 対応を見送る

セキュリティポリシーその他の制約で、公開ネットワークからCMSサーバーに対して通信できないため対応を見送る

現在ご検討中のプロジェクトでは、どの対応策が採用できるでしょうか？

別の対応例

CGI機能に限っては、別の対応例もあります。リバースプロキシを使います。対応手順を簡潔に表現すると、以下のようになります。

1. CMSサーバーでは、CMSの管理画面等で用いられているバーチャルホストとは別に、公開サーバーからリバースプロキシを受け付けるバーチャルホストを定義し、ApacheでCGI実行を許可するなどCGI機能が利用できるよう設定を行います。
2. 公開サーバーで何らかの名前解決を行うことで、CMSサーバーで用意したバーチャルホストにアクセス可能な設定を行います。
3. 公開サーバーでは、CGIに対するリクエストに限って、CMSサーバーにリバースプロキシで転送します。例えば公開サーバーがApacheで動作している場合は、 mod_proxyを利用します。

この例は「代表例な対応例」のパータン1で議論した、公開サーバーからCMSサーバーへのネットワーク通信が可能な場合に限られますが、公開サーバーからCMSサーバーへの通信がMySQLプロトコルではなくHTTP(S)プロトコルである点が特長です。公開サーバーから、あらゆるデータが含まれるCMSサーバー上のMySQLに対して通信可能とするよりは、ログが残しやすく、高レベルの入出力データのみが流れるHTTP(S)プロトコルの方が安全であると考えられるプロジェクトもありました。

この対応例の最大のメリットは、公開サーバー側にPowerCMSモジュールを配置しないため、追加のPowerCMSライセンスが必要ない点です。

デメリットとしては、以下の2つがあります。

• CMSサーバー側に、公開サーバーと同じ役割を持つバーチャルホストを設ける必要があります。結局、当初の「CMSサーバーと公開サーバーの分離による、公開情報と内部情報の分割」という意義が薄くなります。
• 公開サーバーを複数台構成にするなどして負荷分散を行っている場合でも、CGI機能の処理がバックエンドのCMSサーバーに集中します。

システム全体の可用性に関する確認事項

例えば公開Webサイトが静的ファイルのみで構成されていれば、LAN内に配置したCMSサーバーがダウンした場合にコンテンツの更新はできませんが、公開Webサイトには影響はありません。それぞれが独立した系(システム)であるためです。

今回ご紹介したケースでは、何れの対応例を採用しても、公開Webサイトの表示および機能の実現には直列に配置した複数のサーバーに依存しています。このシステム全体の稼働率は各サーバーの稼働率の積となり、サーバー1台構成にくらべ稼働率は低下します。

以上を踏まえて、CMSサーバーがダウンした場合の影響範囲やサービスレベルについて、あらかじめ関係者の確認を取ることが重要な場合が多くあります。

要件定義・インフラ設計での検討事項

ここまで議論してきた「対応策」は言わば事後対策になります。本記事のノウハウを事前に勘案し、要件定義やインフラ設計に活かすことで、インフラ側の制約がコンテンツ設計に影響することを避けることができます。