一部リニューアルサイトでの導入

本ページは、以下の条件を同時に満たすCMSサイトにesparを導入する場合の解説です。

• (A) サイトリニューアルである
• (B) ただしリニューアルは一部のみで既存サイトは一部残る

既存の公開済みサイトに導入する場合や、サイト全体リニューアルでCMSを公開サイトと同じドメインで構築する場合は同一ドメイン方式での導入、それ以外は別ドメイン方式での導入をご覧ください。

CMSサーバと公開サーバの分離

別ドメイン方式での導入 と同様、一部リニューアルのサイトでも新たなCMSサーバには公開用ドメインと別のドメイン名をつけて、よりセキュアな構成とします。

CMS側に別ドメイン名をつけることにより、CMS側にアクセスする管理画面URLがサイト制作者や関係者のみ知っている情報となります。その結果、悪意ある第三者がCMSサーバを直接攻撃することは不可能となります。

上図の wp.example.com を悪意ある第三者が知る方法は(関係者からの情報漏えいを除いて)ありません。さらにCMSサーバは、Basic認証やIP制限をかけることでより強固にすることもできます。

既存コンテンツとの共存

サイトの一部ディレクトリ以下の既存コンテンツを残す場合は構成が複雑になります。分かり易いように具体例を使って順に解説します。例えば、「あるリニューアルサイトの espar 導入で、リニューアル前サイトのリクルート用ディレクトリ /recruit/ 配下だけは既存のまま残しておきたい」という場合について考えます。

espar導入前

espar導入前は以下の構成です。サイトには /recruit/ のほか /info/ や /services/ のページが存在しています。

全てのページはCMSサーバ単体で応答している状態です。サイトの閲覧者もサイトの管理者も(そして悪意ある第三者も)全員が唯一つのCMSサーバにアクセスしていることが分かります。

espar導入後

サイトリニューアルと同時にesparを導入し、/info/ と /services/ 以下のページは新CMSサーバ上の同じパス名で新しく制作したとします。しかし、/recruit/ は残したい旧CMSサーバに残したまま表示したいですので、新CMSサーバ上では制作していません。結果、以下のような構成となります。

リニューアルで作り直した /info/ と /services/ 以下は espar 導入後も期待どおり表示されます。esparによる静的化で新CMSサーバの内容がそのまま公開サーバ上に再現されるからです。

しかし一方、旧CMS上に残す予定の /recruit/ 以下はどうでしょうか。espar は、旧CMSサーバを一切静的化していないことに注目して下さい。espar では 静的化対象になるCMSサーバは1つに制限されますので、このまま何もしなければ https://www.exmaple.com/recruit/ は 404 not found となります。原則、静的化して公開サーバに転送しない限りページは表示されないからです。

espar ではこの課題を以下のようにして解決します。

公開サーバ側で https://www.example.com/recruit/ のアクセスを受けた際、公開サーバがブラウザの代わりに旧CMSサーバにアクセスし、その応答である /recruit/の内容をそのまま閲覧者のブラウザに返します。

これを リバースプロキシ(代理応答) と言います。公開サーバが一次受けをし、静的化対象ではない旧CMS上のコンテンツを代わりに取ってきて返してあげる格好になります。(厳密には「代わりに取ってくる」というより「中継する」なのですが詳細はここでは述べません)

なお、リバースプロキシはリダイレクトと異なることに注意して下さい。リダイレクトは、「自分でこのURLでアクセスし直して下さい」と閲覧者のブラウザに返す仕組みです。これに対してリバースプロキシは、閲覧社が旧CMS側にアクセスし直しているわけではありません。

さてでは、リバースプロキシ するパスとそうでないパスはどのように区別・設定するのでしょうか。

既存コンテンツと共存するために必要な情報

リバースプロキシは個別に設定を行います。旧CMS上に残すコンテンツ全てに対して必要です。espar 導入時に弊社が公開サーバ上に設定しますので、以下の情報の御提供をお願いしています。

• 旧CMSサーバに残したいコンテンツのパス (上記の例でいうと /recruit/)
• 旧CMSサーバのIPアドレス

なお、旧CMSサーバにIP制限をかけている場合には、公開サーバのIPアドレスを許可して頂く必要があります。詳しくは CMS側の許可IPについて をご覧下さい。また旧CMSサーバが AWS ELB のALBを使用している場合はAWSの仕様から稀な障害発生リスクがありますので、AWS ELB の利用についても併せて確認をお願い致します。

既存コンテンツを残す時の注意点

リバースプロキシで表示されるページのリソース(画像/CSS/JS等)のパスに注意して下さい。正しくパス指定されていないと、既存コンテンツの画像が表示されなかったり、CSSが読み込めずレイアウトが崩れる等の問題が発生します。

ここでも例を使って説明します。

上述の例で https://www.example.com/recruit/ の HTML 内に、以下の記述が含まれていたします。

<img src="/common/img/sample.png">

このときブラウザは /common/img/sample.png の画像ファイルを取得するのに、どのサーバにアクセスするでしょうか？

答えは、公開用サーバです。以下にその様子を図示します。

赤色点線で示される /common/img/sample.png を撮りに行くアクセスが、旧CMSサーバには向かわず、公開サーバに到達している点に注意して下さい。

ブラウザは常に公開サーバ上にファイルがあることを期待してアクセスします。HTMLが旧CMS上のHTMLなのだから…といって、そのHTMLが参照する画像ファイルは旧CMSから直接取得される…と期待するのは誤りです。

上記例のパス /common/img/sample.png の絶対URLは https://www.example.com/common/img/sample.png です。ブラウザはこのURLに画像を取りに行きます。つまり公開サーバに取りに行きます。よって公開サーバ側で /common/img/sample.png に応答しなければなりません。旧サーバに /common/img/sample.png があったところで参照されない点に注意が必要です。

公開サーバで /common/img/sample.png に応答する方法は3つあります。

	具体的な方法	作業が必要な人
A	/common/img/sample.png のファイルをWP側にも同一パスで設置し、espar で静的化対象ファイルとして指定して他の静的化ファイルと一緒に公開サーバ側へ転送させる	旧CMSサーバ上に残すコンテンツの制作者、または、リニューアルサイトの制作者
B	旧CMS上のHTML内で /common/img/sample.png の記述をやめる。/recruit/ 配下のパスになるように、つまり /recruit/ 配下で完結するように画像再配置と HTML の修正を行う	旧CMSサーバ上に残すコンテンツの制作者
C	/recruit/ 同様に /common/ 以下も旧CMSサーバにリバースプロキシを設定し、公開サーバで直接応答しない	弊社(公開サーバ上に追加設定)

最も推奨されるのはBです。

残したいコンテンツが /recruit/ 配下なら、/recruit/ 配下に画像もCSSもJSも全て配置するということです。/recruit/ ディレクトリ以下のみを残したいのですから、/recruit/ 以下のみでコンテンツが完結するよう構成することにより管理運用上のトラブルを少なくできます。

複雑な構成のサイトをうまく運用するコツ

1台のCMSサーバだけで全てを構成する従来手法の場合、考えることは少なくてすみました。

しかし本ページで解説するような複雑な構成になる場合は、画像/CSS/JavaScript等は対象のパス(例でいうと /recruit/)の配下に全て集めるのが運用時トラブルを避けるコツです。ある大きな意味を持ったディレクトリ配下に、その関連ファイルを全て集めることです。

これは espar に限らず、他の静的化ソリューションにも言えることです。また静的化の代わりに検討される、WAF や CDN でも同様です。

Bの方法が採用できない場合があります。例えば、残したいコンテンツの制作者と、リニューアルで新CMSを構築した制作者とが異なる場合です。旧CMSを改修したり直接ファイルを取得することが困難なケースもあるからです。そうした場合、Cがベターな選択肢となります。

方法Cを選ぶ場合の注意点

制作担当者的にはCが一番「楽」ですが、リバースプロキシするパスと同じパスが新CMSに存在してはならないという点に注意して下さい。

上記例でいうと、リバースプロキシを設定する /common/ というパスが新CMSサーバ上に存在してはなりません。/common/ 以下はリバースプロキシの設定により全て旧サーバ側にファイルを取りに行くからです。

以上のように、一部リニューアルのサイトにesparを導入する場合、構成が非常に複雑になります。「どのパスでどのサーバのファイルを取りに行くのか」を常に意識する必要があります。なお、esparの導入に要する工数も増すため別途費用が必要になりますのであらかじめご了承下さい。

導入の進め方

以下のような流れで進行します。○印がついたSTEPでお客様や制作会社様にご協力を頂く必要があります。STEPが進行する度に弊社担当者から都度ご連絡を差し上げております。

STEP	作業	作業内容
1		弊社でテスト用の環境構築と設定を行います。テスト環境については 導入途中の確認(テスト環境) をご覧下さい。
2	○	テスト環境で静的化結果をご確認頂きます。問題がなければ3へ進みます。問題があれば、問題がなくなるまで微調整を繰り返します。
3		2.の確認で問題なければ、弊社で本番用の環境構築と設定を行います。
4	○	続く手順5(証明書取得の準備)を実施頂ける候補日をお知らせ頂きます。
5		4.で頂いた日程直前に弊社でトークンを生成してお送りします。(本トークンはhttps対応用のサーバ証明書を取得するために必要なものです)
6	○	5.のトークンを設置(または設定)して頂きます。詳細は 証明書について をご覧下さい。
7		弊社で証明書の取得設定作業を行います。ここで本番環境の構築は完了となります。次の8に移る前に最終確認をしたい場合は 導入途中の確認(本番環境) をご覧下さい。(必須ではありません)
8	○	DNSの設定を弊社指定IPに変更して頂きます。変更が反映された後、esparの導入は完了となります。DNSについてのDNSの反映確認もご参照下さい。