「サブディレクトリを別のWebサーバで公開する」
そげな方法があっとか探しっみっで!
仕事であったんでねー、現行のサイトがあって、それとは別にサブディレクトリで別サーバに作りたいと。
WebサーバはApacheではないかと推測して、本記事のカテゴリはApacheとした。
AWSならALBで実現可能
各サイトを別サーバで管理することは可能でしょうか?
~中略~http://example.com/
http://example.com/jp/
http://example.com/au/
まさに今、私がやりたいことと同じ主旨のご質問。
ご回答が
↓
AWSで構築するのであれば
ALB
を利用することでごく簡単にURLベースでサーバを分割することが可能です。
*ALBは最近使えるようになったL7ロードバランサーです。~中略~
サブドメインで分けておくのが様々な可能性に対応出来て楽かと思います。
![](https://it-afi.com/wp-content/uploads/cocoon-resources/blog-card-cache/bc04f2415c5118ce2a37ba959747a2ea.png)
サブドメインの方が楽ってのは絶対そうですよねー。
提案してみよ。
他のご回答を見ると、
運用の都合でサーバを分けたい場合は、サーバごとに別々のFQDNを持たせる。
ですよねー
サブディレクトリでわけて、リバースプロキシということもできますが
リバースプロキシを使うという案はいかがですか?
ふむふむ、やっぱり、LBかリバースプロキシを、ドメインを指定して接続して着弾した先に仕掛ける必要がありそうですな。
現行のサイトがAWSで運用されている場合、使える可能性があるけど、当然ながらAWSの知識が必要ですなー。
Apacheのmod_proxyで設定
現在のドメインを持ってるサーバでmod_proxyを有効にして設定する。
設定内容:
![](https://normalblog.net/system/wp-content/uploads/2015/12/apache.png)
ProxyPassReverseCookieDomain ってなんだ?
|
Set-Cookie ってなんだ?
Set-Cookie は HTTP のレスポンスヘッダーで、サーバーからユーザーエージェントへクッキーを送信するために使用され、ユーザーエージェントはそれを後でサーバーに送り返すことができます。
![](https://it-afi.com/wp-content/uploads/cocoon-resources/blog-card-cache/adec6b7fe735d4bf667370b32e75dcc6.png)
Cookieのために必要なんやな。おまじないとして覚えておくのが幸せやな。
Yahoo知恵袋にも似た手法がございますな。(上記の方のは他の手法も載せておられます)
リバースプロキシを使えばできます。
普通 htaccess というより、
httpd.conf
に設定します。
まず、apache の mod_proxy モジュールをロードするようにして、
LoadModule proxy_module modules/mod_proxy.so
あるロケーションで他のサーバーを参照する様に設定します。
<Location “/aaa”>
ProxyPass http://192.168.0.1
ProxyPassReverse http://192.168.0.1
ProxyPassReverseCookieDomain 192.168.0.1 hoge.com
ProxyPassReverseCookiePath / /aaa/
</Location>
なんて感じにすると、
内部ネットワークの
192.168.0.1 のサーバーBを
hoge.com/aaa/
から見える様にできます。
![](https://it-afi.com/wp-content/uploads/cocoon-resources/blog-card-cache/9b103cd3cd8276786bf86439067d7456.png)
Apache公式マニュアル
ProxyPass /mirror/foo/ http://backend.example.com/ ProxyPassReverse /mirror/foo/ http://backend.example.com/ ProxyPassReverseCookieDomain backend.example.com public.example.com ProxyPassReverseCookiePath / /mirror/foo/
こちらはLocationは使ってないですが、同じ動きになりますね。
<Location>
セクションの中で使われた場合は、 最初の引数は省略され、ローカルディレクトリは<Location>
から取得されます。
とのこと。
kinstaさんによるリバースプロキシの詳細な説明
![](https://it-afi.com/wp-content/uploads/cocoon-resources/blog-card-cache/c2c393accdd50b3ab1c08911c88a8839.jpeg)
- フォワードプロキシ・・・主にユーザーサイドで使用される。(ユーザーのIPを秘匿できる)
- リバースプロキシ・・・主にサーバーサイドで使用される。(LB的な使い方ができる)’
一般的なリバースプロキシは、主に負荷分散(ロードバランシング)の目的で使用されるため、「ロードバランサー」とも呼ばれます。
たしかにほぼLBだもんなー。
広域負荷分散(Global Server Load Balancing、GSLB)は、世界中に戦略的に配置した多くのサーバーにウェブサイトのトラフィックを分散する、高度な負荷分散手法です
リバースプロキシで、サブディレクトリを外部のサイト(LANの外)にあるWEBサーバにしていできるのか?という疑問がありましたが、できるみたいですね。
「高度な」というのが非常に気になりますが。
CloudFlareなどのCDNが使ってる手法みたいですね。
mod_proxyでできるのか?
→あとで検証しよう
→できました。この記事の下の方に結果を書きました。
リバースプロキシは、メインのサーバーに到達する前にすべてのトラフィックを受信するため、攻撃者やハッカーが、ウェブサイトにDDoS攻撃などのセキュリティ的な脅威を与えることが難しくなります。
あっ、そうなんだ。でもリバースプロキシが死ぬとかはないのかなー。
あー、Kinstaさんの提供しているリバースプロキシが超強力だからってことかな。
個人のサイトは弱いけどリバースプロキシが強いからDDoS食らっても耐えられると。
最も使用されてそうなリバースプロキシ
先述のKinstaさんの記事によると、
CDNがもっとも利用されてそう。(CDNとリバースプロキシは別だとの記述もされてますが→「CDNはリバースプロキシの発展型であり…」)
自分らで構築するならnginxが最もりようされてそう、な感じですな。
Apacheは、
Apache HTTP Server 以外にも
というのもあるんですね。知らんかった。
リバースプロキシ使用上の留意点
-
リバースプロキシは、通過するすべてのトラフィックを読み取って変更できるため、重大なセキュリティリスクとなります。HTTPSトラフィックをリバースプロキシ経由で渡す場合、リバースプロキシはデータの復号化と再暗号化を行います。すなわち、リバースプロキシはSSL/TLS証明書の秘密鍵を所有する必要があります。そのため、悪意のある第三者がリバースプロキシに侵入した場合、パスワードのログへの保存や、ウェブサイトへのマルウェアの注入が可能です。
リバースプロキシの段階でhttps化が必要だと。そらそうですよね。
そこの段階で暗号化しないと。
Apacheのmod_proxyを使って検証してみた
環境は、
Webサーバ2台使う。
1台目は、root権があるApacheが入ったサーバ
2台目は、XSERVER
1. dnf install httpd
インストール直後、確認したところ、最初からmod_proxyは有効になっていた
2. 1台目サーバのhttpd.confに設定
<Location "/bbb">
ProxyPass https://exmple.com/
ProxyPassReverse https://exmple.com/
ProxyPassReverseCookieDomain https://exmple.com/ test.com
ProxyPassReverseCookiePath / /bbb/
</Location>
上記設定して
httpd -k start
apache起動。
エラー出た。
ブラウザでアクセスすると、Internal Server Error。
apacheのerror_logを見ると、以下の出力がされてる。
AH01144: No protocol handler was valid for the URL /bbb (scheme 'https'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
http サーバへリバースプロキシする場合と比べて SSLProxyEngine を追加する必要がある
![](https://qiita-user-contents.imgix.net/https%3A%2F%2Fcdn.qiita.com%2Fassets%2Fpublic%2Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png?ixlib=rb-4.0.0&w=1200&mark64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9QXBhY2hlJTIwMi40JTIwJUUzJTgxJThCJUUzJTgyJTg5JTIwaHR0cHMlMjAlRTMlODIlQjUlRTMlODMlQkMlRTMlODMlOTAlRTMlODElQjglRTMlODMlQUElRTMlODMlOTAlRTMlODMlQkMlRTMlODIlQjklRTMlODMlOTclRTMlODMlQUQlRTMlODIlQUQlRTMlODIlQjclRTMlODElOTklRTMlODIlOEImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTY4YWE1MjY0NTc1NTkyMGQyMzZkMWI0NmU1YWI1N2M4&mark-x=142&mark-y=112&blend64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbml3YXNhd2EmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTBiYTU4NGE2Y2Y4N2YzYWZjZDQ1MGQ5NzQ2ZmVmY2I2&blend-x=142&blend-y=491&blend-mode=normal&s=2ae2c2afbbb03234584f2764f163ab51)
てことらしい。
httpsで指定したからか。とりあえずhttpで指定し直してみる。
<Location "/bbb">
ProxyPass http://exmple.com/
ProxyPassReverse http://exmple.com/
ProxyPassReverseCookieDomain http://exmple.com/ test.com
ProxyPassReverseCookiePath / /bbb/
</Location>
↓
ブラウザでアクセス。
あれ、Webブラウザのアドレスバーに表示されているURLが、遷移先のドメイン(example.com)に変わってしまった。
example.com 側で、URL正規化(httpsに強制的にリダイレクト)させてたことが原因だった!
考えてみれば当たり前だけど、サブディレクトリ(の先)に当たる側のWebサーバでリダイレクト処理とかしちゃいかんね。
コメント