2016-08-01 11 views
1

S3にホストされているCloudFrontとOVHサーバーでホストされているオンラインショップ(Prestashop)とブログ(Wordpress)を使用する静的なショーケースWebサイトがあります。 >ノーマル -Cloudfrontを使用してS3サブフォルダを別のドメインにリダイレクト

  • mysite.com/:私の3つのサイトが同じホスト上にあるように、それは次のパターンを使用して、機能して

    は、私は私の静的なウェブサイトの2つのサブフォルダに隠されたリダイレクトを作りたいです行動

  • mysite.com/blog/ - > myblog.com/
  • mysite.com/store/ - もちろん> mystore.com/

、私はそれを処理されるすべての要求を必要とします方法、最終的に何かを持っている時:

mysite.com/store /fr/1-myproduct.html

戻って何

mystore.com /fr/1-myproduct.html

だろう戻ってきた。

これは本当に難しいようですが、私の問題には本当の解決策が見つからなかったため、この時点ではこのようなことをすることさえ可能かもしれません。 私はプロキシの使用を検討しましたが、それは飛行機を取り除くためにスレッジハンマーを使用するようなものではありませんか?

だから私の質問は、だろう...

を私はすべての可能なリダイレクトで検索しましたし、私は唯一のサブドメイン/ドメインのリダイレクトを見つけることができた「どのように私はそれを行うことができますか?」 しかし、今私は疑問に思っています"それを行うことはできますか?"


P.S:それは今まで、私は投稿する前に長い時間を検索するために使用しています私の最初のポストだと私は常に今を除いて、解決策を見つけてしまいます。どんな提案も大歓迎です。

+0

私はリバースプロキシなしであなたが望むものと正確には思えません。あなたは適切なサーバーに転送するAレコードを管理することができますが、store.mysite.comとblog.mysite.comをovhサーバーに転送することができます –

+0

@FrédéricHenriはい、これは私がやりたいことです。ステークホルダーはSEOの目的のためにサブフォルダに絶対にそれを必要とします。あなたの答えをありがとう、それは私の最後の希望(どのように劇的)なので、私はプロキシについて確認します。 –

答えて

5

それが私の最後の希望

待ちだので、私はプロキシについて確認します。

私はS3でホストされている静的なショーケースのウェブサイトを持っているとCloudFrontを

CloudFrontのを使用して、リバースプロキシです。

CloudFrontは、他の2つのサイトの柔軟性に応じて、複数の独立したサイトを1つのホスト名で組み合わせて、行きたい場所に行くことができます。

これは、ディストリビューション用に追加のオリジンサーバーを作成し、追加のキャッシュビヘイビアを作成し、追加のパスに一致するパスパターン(/blogおよび/blog/*など)を作成することによって行われます。

しかし、キャッチがあります。 CloudFrontは一致するパターンを削除できないため、パターン/blog/*に一致するmainsite.example.com/blog/hello-worldはblog.example.com/blog/hello-worldに転送され、blog.example.comには転送されません/こんにちは世界。 ¹これにより、これらのサイトをこのように統合するためには、他のサイトを変更する必要があります。 ...

ない限り

ここで、あなたはすでに、何の問題を独自のパスパターンを持っていないが、余分なサイトのコンテンツは、個々のサイトのルートにある場合、あなたは問題が表示された場合。疑う余地はありませんが、それでも問題です。

の後ろにある逆プロキシ の代わりに、これらのパスを書き換えて要求を代替サーバーに送信することができます。 HAProxy、Nginx、およびVarnishはすべてこのような機能を提供し、驚くほど小さなハードウェアで多数のプロキシリクエストを処理できるので、大きな問題ではありません。 サービスは、リクエストが処理されるとすぐにパスを書き換えることができます。

しかし、結論としては、プロキシ以外の本当の解決策が見つからない理由は、代替手段がないということです。特定のホスト名のすべてのパスは、1つの論理的な場所またはそれ以上の同一構成のエンドポイント。 CloudFrontの場合、論理的な場所は物理的にグローバルに分散されます。


¹ CloudFrontは、mainsite.example.com/bar/fizzに対する要求がfoosite.example.com/foo/bar/fizzに転送できるようにネイティブに、実際に、要求を転送する前に経路に先頭に追加することができ原点を設定するときに起点パスを/fooに設定します。しかし、Lambda @ Edgeを使用しなくても、パス部分を削除したり、パスを修正することはできません。上で説明したシナリオでは、追加のオリジンサーバーを構成するときに、オリジンパスを空白のままにします。

+1

かなり面白いですが、これはクラウドフロントの良いユースケースを提供します –

+0

申し訳ありませんが、私はそれをどうやって行うことができるのかを文書化しています。実際に私はウェブサイトを展開した後に作業を始めました。 (私はそれが唯一の "ウェブサイトのキャッシャー"だと思った)。 しかし、元のドメイン(myblog.com)と動作(/ blog/*はすべてカスタムの起源myblog.comにリダイレクトされます)を設定した後でも404エラーが発生し、JavaScriptを使用してリダイレクトされます。 リダイレクトがエラーによって上書きされる可能性はありますか? –

+0

私の前の解説に答える: はい! Cloudwardディストリビューションの404エラーがリダイレクトされるように設定した場合、それが離れた起点かベース起源かにかかわらず、404エラーは設定した同じリンクにリダイレクトされます。 私はインデックスを試しました。myblog.com/blogのhtmlファイルとそれなし。 これで、正しくコンテンツが表示され、元の基点に設定した404ページに戻らずに、wordpress '404ページを上書きします。 –

関連する問題