2017-05-03 7 views
0

私は古いウェブサイトを新しいウェブサイトに段階的に置き換えています。ユーザーの観点からは、既存のURLはすべて同じである必要がありますが、特定のパスは新しいページを提供する必要があります。CloudFrontを使用してオリジンサーバ間のトラフィックを分割する - この設定は正しいですか?

私は2つのオリジンサーバーを持っています:レガシーサーバー(www.mysite.com)と新しいEC2(www.ec2-loadbalancer.com) - プライバシ上の理由から明らかです。

CNAME設定がwww.mysite.comのAWS CloudFrontディストリビューションを作成しました。 、

  • www.mysite.com
  • www.ec2-loadbalancer.com
  • /fooのようなパスが私のEC2ロードバランサの原点に送信されるように、私はいくつかの動作を設定したCloudFrontの内

:この分布の中で私は2つの起源ドメインを作成しました他のすべてのパス(デフォルトなど)はwww.mysite.comに送信されます。

DNSの観点から、私はCNAMEというwww.mysite.comというレコードを追加しました。これは私のCloudfrontホストドメイン(例:foo.cloudfront.net.)を指しています。このドメインのAレコードは、従来のサーバーのIPを指しています。

私は今日このすべてを立ち上げたが、うまくいったようだが、サイト上で断続的に403エラーが発生していて、変更して2時間後に表示されている( "www" CNAMEがなかったので、違いを生む)、一部のブラウザは元のIP(CloudFrontではなく)からサイトを提供しています。

これを正しく設定しましたか?レガシーサーバのIPアドレスを指し示すAレコードを使ってこれを行う方法を考え出すことができず、CloudFrontはIPアドレスを起点として入力することを許可していません。 IPアドレスでwww CNAMEを指摘して、代わりにAレコードポイントをCloudFrontに設定しましたか?私はここで少し失われています。

一方、すべてのことが伝播する可能性がありますが、変更後に40倍のエラーが発生していることには気をつけています。

答えて

1

それは、あなたがデバッグを助けるために私達とドメインを共有するが、非常に少なくともすることはできません残念ですdigはあなたの友人です。例えば:

$ dig membership.theguardian.com 
... 
;; ANSWER SECTION: 
membership.theguardian.com. 367 IN CNAME i.global-ssl.fastly.net. 
i.global-ssl.fastly.net. 12 IN A 151.101.128.67 
i.global-ssl.fastly.net. 12 IN A 151.101.64.67 
i.global-ssl.fastly.net. 12 IN A 151.101.0.67 
i.global-ssl.fastly.net. 12 IN A 151.101.192.67 

... membership.theguardian.comはCNAMEによってしっかりと指していることを示しています。

$ dig @8.8.8.8 membership.theguardian.com 

を...ので、他の人があなたのドメインを解決しているあなたはどのように見ることができます:あなたはこれを行うことにより、8.8.8.8にGoogle's DNSのように、代替DNSサーバに確認することができます。

DNSの観点から、私は私のCloudFrontのホストドメインを指すwww.mysite.com のCNAMEレコードを追加しました(例えば。foo.cloudfront.netを。)。 このドメインのAレコードは、レガシーサーバーのIPを指します。

Iよない DNSの専門家、それは私がここであなたを理解していないんだけど、それのようなこの音は、あいまいさを紹介することが可能ですので、?私には、同じwww.mysite.comドメインの2つの異なるレコードがあり、そのうちの1つがCloudFrontを指しており、もう1つはレガシーサーバーのIPです。それがどのように解決されるかに応じて、ブラウザをどちらか一方に送ることができますか?

  • www.mysite.comのみ CloudFrontのにを指している必要があります。私は個人的にこれにCNAMEを使用します。
  • あなたのレガシーサーバとEC2 Elastic Load Balancerの両方に明確なアドレスが必要です。混乱を避けるために、自分自身で明確なドメイン名を付けてください(例:legacy.mysite.com & beta.mysite.com)。CloudFrontでは、トラフィックを誘導しているときに名前を明確にしてください(例:従来のサーバに行く方法として、トラフィックをwww.mysite.comに渡すと混乱する)。

enter image description here

幸運!

+1

これが解決策でした。私は 'A'レコードを削除し、' www' CNAMEをCloudfrontで指摘しました。これらの2つのレコード間のあいまいさは、ここでは40倍/ 50倍のエラーがなくなったためです。ありがとうRoberto! –

1

クラウドフロントディストリビューションを指す別名でAレコード(名前付きドメイン名用)を作成する必要があると思います。それは問題を解決するはずです。

すなわち使用エイリアス名の代わりにIPアドレスとCloudFrontをにあなたのドメインを指す:

enter image description here

+0

あなたはAレコードが指摘すべき点はどこですか?この設定のどこかで、レガシーサーバのIPアドレスを参照する必要があります... –

+0

私はスクリーンショットを追加しました。エイリアス名を使用すると、サーバーのIPアドレスを参照する必要はありません –

+0

ありがとうございます - 私はまだ明確ではないと私はこれが正しいとは確信していません。私のドメイン名はRoute 53でホストされていませんが、それでも、これはうまくいかないでしょうか? CloudFrontディストリビューションのエイリアスレコードを作成すると、はい、私のドメインにアクセスすることになりますが、私のオリジンサーバーはもはや元のIPを指しません(現在のドメインのAレコードがそこにポイントしているので) ? –

関連する問題