cloudfrontの設定がうまくいきません

Question

cloudfrontの設定がうまくいきません

解決済

回答 1

投稿 2017/02/20 17:13

評価
クリップ 0
VIEW 3,962

ruuusaamarki

score 442

前提・実現したいこと

route53→ロードバランサ→ec2→RDS（Mysql）
上記のような構成で稼働しているサイトにcloudfrontを導入したいのですがエラーが出てしまいます。
route53→cloudfront→ロードバランサ→ec2→RDS

アプリケーションはwordpressで下記ページを参考にさせていただいています。
http://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13#wp-admin%E3%82%92%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%95%E3%81%9B%E3%81%AA%E3%81%84

サーバはnginx+phpfpm
ドメインはexample.comと仮定させていただきます。

route53の設定は以下のようにしています。
◆example.com ●A-IPv4 address
●Alias Target:dualstack.example-xxxxxxxxx.xxxxxxx.elb.amazonaws.com
(ELBのアドレスを設定）

◆cf.example.com ●A-IPv4 address
●Alias Target:xxxxxxxxxxx.cloudfront.net.
(上記参考サイトにならって設定）

◆www.example.com ●CNAME
●Value:xxxxxxxxxxx.cloudfront.net.
(よくわからずカンで設定）

設定が完了して確認したらロードバランサがOutOfServiceになっていたので
ec2を再起動して再度ロードバランサ側でも定義したのですがOutOfServiceのままです。

発生している問題・エラーメッセージ

キャッシュを削除してoperaのプライベートブラウザでテストしています。

example.comにアクセスした場合
--------------------------------------------------------------------
ページは機能していません
example.com では現在このリクエストを処理できません。

cf.example.comにアクセスするとexample.comにリダイレクトされ
--------------------------------------------------------------------
ページは機能していません
example.com では現在このリクエストを処理できません。

www.example.comにアクセスすると
--------------------------------------------------------------------
ERROR
The request could not be satisfied.
Bad request. 
Generated by cloudfront (CloudFront)

xxxxx.cloudfront.netにアクセスするとwww.example.comにリダイレクトされ
--------------------------------------------------------------------
ERROR
The request could not be satisfied.
Bad request. 
Generated by cloudfront (CloudFront)

ec2のPublic DNS(IPv4)にアクセスすると少し長めにローディングした後
--------------------------------------------------------------------
ec2-xxxx-xxx-xx-xx.compute.amazonaws.com からの応答時間が長すぎます。

次をお試しください:
接続を確認する
プロキシとファイアウォールを確認する
Windows ネットワーク診断ツールを実行する
インターネットの接続を確認してください。
ケーブルの接続を確認し、ご利用のルーター、モデム、その他のネットワークデバイスを再起動してください。

ファイヤウォールあるいはウイルス対策の設定で、Opera にネットワークへのアクセスを許可してください。
ネットワークへのアクセスを許可されたプログラムとして既に表示されている場合は、 いったんリストから削除し、もう一度追加してみてください。

プロキシ サーバーを使用している場合…
プロキシ設定を確認するか、ネットワーク管理者に連絡してプロキシサーバーが機能しているかを確認してください。プロキシサーバーを使用するべきではないと考えられる場合： メインメニュー > 設定 > プロキシ設定の変更… > LAN 設定にアクセスし、「LAN にプロキシサーバーを使用」のチェックを外してください。

ec2のIPv4パブリックIPにアクセスすると少し長めにローディングした後
--------------------------------------------------------------------
xxx.xxx.xxx.xxxx からの応答時間が長すぎます。

次をお試しください:
接続を確認する
プロキシとファイアウォールを確認する
Windows ネットワーク診断ツールを実行する
インターネットの接続を確認してください。
ケーブルの接続を確認し、ご利用のルーター、モデム、その他のネットワークデバイスを再起動してください。

ファイヤウォールあるいはウイルス対策の設定で、Opera にネットワークへのアクセスを許可してください。
ネットワークへのアクセスを許可されたプログラムとして既に表示されている場合は、 いったんリストから削除し、もう一度追加してみてください。

プロキシ サーバーを使用している場合…
プロキシ設定を確認するか、ネットワーク管理者に連絡してプロキシサーバーが機能しているかを確認してください。プロキシサーバーを使用するべきではないと考えられる場合： メインメニュー > 設定 > プロキシ設定の変更… > LAN 設定にアクセスし、「LAN にプロキシサーバーを使用」のチェックを外してください。

xxxx-xxxx.elb.amazonaws.comにアクセスすると
--------------------------------------------------------------------
ページは機能していません

試したこと

route53のAレコード設定を変えてみたりしましたが
上手くいきませんでした。
また色々変えている過程でリダイレクトループが発生した際に
wordpressのwp-config.phpに以下を追記し、現状もそのままです。

$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];

捕捉情報

現在前述の参考サイトを基にwordpressのサイトURL、homeURLをcf.example.comに変更しています。
設定直後はページも表示できていました。

疑問点

route53の設定を変更した際に反映されるまでにタイムラグが5分くらいある気がしました。
cloudfrontもそうですがこれはTTLの秒数で大体反映されるという認識で大丈夫でしょうか。
またCNAME等はTTLの設定欄がないのですがこういった項目の変更は即時反映されるものなのでしょうか。

VPCのACLを設定するという記事も見つけましたがどこから設定するかわかりましたらご教授お願いいたします。
http://www.slideshare.net/hz_ouchi/cloud-front-30133315

気になる質問をクリップする

クリップした質問は、後からいつでもマイページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

クリップを取り消します
良い質問の評価を上げる

以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します

評価を下げられる数の上限に達しました

評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる

teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します

この機能は開放されていません

評価を下げる条件を満たしてません

評価を下げる理由を選択してください
プログラミングに関係のない質問やってほしいことだけを記載した丸投げの質問問題・課題が含まれていない質問意図的に内容が抹消された質問過去に投稿した質問と同じ内容の質問広告と受け取られるような投稿
詳細な説明はこちら

上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。
質問の評価を下げる機能の利用条件

この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
- メールアドレスの認証
  メールアドレスの認証
- 質問評価に関するヘルプページの閲覧
  質問評価に関するヘルプページの閲覧

回答 1 件

評価が高い順
新着順
古い順

同じタグがついた質問を見る

score 1 · Accepted Answer · 2017-02-23T11:23

ベストアンサー

+1

ロードバランサがOutOfServiceになっているというのは、CFと関係なく以下ではないでしょうか？

１．ELBのヘルスチェックが失敗している
⇒セキュリティグループの再確認、ヘルスチェックのURLをローカルから叩いて正常なものが返ってくるかを確認

２．ELBが正常にヘルスチェックを実施できていない
⇒時々発生します。ELBからインスタンスの登録を解除し、再登録で解決します

投稿 2017/02/23 11:23

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2017/02/23 12:06

ご回答ありがとうございます！
セキュリティグループについて再度確認してみました。

EC2に設定しているセキュリティグループ
インバウンド
HTTP | TCP | 80 | sg- xxxxxx(LB)
LBに設定しているセキュリティグループsg- xxxxxx(LB)
HTTP(80) | TCP(6) | 80 | 0.0.0.0/0

またVPCに関してもロードバランサとEC2は同一のVPC内に設置されている状態です。

cloudfrontに関しましてはVPCの外に設置するためVPC,セキュリティグループの設定がないと
認識しておりますがこちらは正しいでしょうか。

cloudfrontを設置する前はロードバランサもInServiceでしたが
いつの間にかOutOfServiceになってしまっておりました。
（route53のaレコードを設定したからでしょうか。。。）

また何かお気づきの点がありましたら
ぜひご教授いただけましたら幸いです。

ご回答ありがとうございます！セキュリティグループについて再度確認してみました。 EC2に設定しているセキュリティグループインバウンド HTTP | TCP | 80 | sg- xxxxxx(LB) LBに設定しているセキュリティグループsg- xxxxxx(LB) HTTP(80) | TCP(6) | 80 | 0.0.0.0/0 またVPCに関してもロードバランサとEC2は同一のVPC内に設置されている状態です。 cloudfrontに関しましてはVPCの外に設置するためVPC,セキュリティグループの設定がないと認識しておりますがこちらは正しいでしょうか。 cloudfrontを設置する前はロードバランサもInServiceでしたがいつの間にかOutOfServiceになってしまっておりました。（route53のaレコードを設定したからでしょうか。。。）また何かお気づきの点がありましたらぜひご教授いただけましたら幸いです。

キャンセル
2017/02/23 12:21

CFはオリジンサーバからコンテンツを取得するだけとなりますので、そもそもオリジンサーバがコンテンツを返せないとどうしようもできません。

サーバ上から
curl -i http://localhost:ポート/path/to/health_check
した結果はどうなっていますか？
これが想定と異なる場合は、インスタンス上のプロセスがダウンしている可能性があります。

Route53のAレコードを設定してもELBとEC2には何の関係もありません。

CFからオリジンELBへのアクセスは、ELBのセキュリティグループが適用されます。
ELBのセキュリティグループは 0.0.0.0/0 80で設定しているのであれば、HTTPのみは制限なくアクセス可能です。

厳密に制限する場合は以下コマンドでCFで利用するIPアドレスの情報がわかります。
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .'

CFはオリジンサーバからコンテンツを取得するだけとなりますので、そもそもオリジンサーバがコンテンツを返せないとどうしようもできません。サーバ上から curl -i http://localhost:ポート/path/to/health_check した結果はどうなっていますか？これが想定と異なる場合は、インスタンス上のプロセスがダウンしている可能性があります。 Route53のAレコードを設定してもELBとEC2には何の関係もありません。 CFからオリジンELBへのアクセスは、ELBのセキュリティグループが適用されます。 ELBのセキュリティグループは 0.0.0.0/0 80で設定しているのであれば、HTTPのみは制限なくアクセス可能です。厳密に制限する場合は以下コマンドでCFで利用するIPアドレスの情報がわかります。 curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .'

キャンセル
2017/02/23 13:06

ありがとうございます！早速以下実行してみた結果になります。
curl -i http://localhost:80/path/to/health_check

HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.3
Date: Thu, 23 Feb 2017 03:36:18 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.6.24
Location: http:///

その後いろいろ試していまして
CnameとAレコードの設定を変えており
現在はroute53にNS,SOAと下記Aレコードが設定されているだけの状態です。
◆cf.example.com ●A-IPv4 address
●Alias Target:xxxxxxxxxxx.cloudfront.net.

リダイレクトされているのはそのせいでしょうか。。。

＞Route53のAレコードを設定してもELBとEC2には何の関係もありません。
＞CFからオリジンELBへのアクセスは、ELBのセキュリティグループが適用されます。
＞ELBのセキュリティグループは 0.0.0.0/0 80で設定しているのであれば、
＞HTTPのみは制限なくアクセス可能です。
＞厳密に制限する場合は以下コマンドでCFで利用するIPアドレスの情報がわかります。
貴重な知識ありがとうございます。このあたりが検索しても見つけられませんでした。

＞curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .'
こちらのコマンドも実行できましたが
これはcroudfrontが設置されているIPという事なのでしょうか。
他に確認するポイントなどありましたら度々で恐縮ですがまたぜひお願いいたします。

ありがとうございます！早速以下実行してみた結果になります。 curl -i http://localhost:80/path/to/health_check HTTP/1.1 301 Moved Permanently Server: nginx/1.6.3 Date: Thu, 23 Feb 2017 03:36:18 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.6.24 Location: http:/// その後いろいろ試していまして CnameとAレコードの設定を変えており現在はroute53にNS,SOAと下記Aレコードが設定されているだけの状態です。 ◆cf.example.com ●A-IPv4 address ●Alias Target:xxxxxxxxxxx.cloudfront.net. リダイレクトされているのはそのせいでしょうか。。。＞Route53のAレコードを設定してもELBとEC2には何の関係もありません。＞CFからオリジンELBへのアクセスは、ELBのセキュリティグループが適用されます。＞ELBのセキュリティグループは 0.0.0.0/0 80で設定しているのであれば、＞HTTPのみは制限なくアクセス可能です。＞厳密に制限する場合は以下コマンドでCFで利用するIPアドレスの情報がわかります。貴重な知識ありがとうございます。このあたりが検索しても見つけられませんでした。＞curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .' こちらのコマンドも実行できましたがこれはcroudfrontが設置されているIPという事なのでしょうか。他に確認するポイントなどありましたら度々で恐縮ですがまたぜひお願いいたします。

キャンセル
2017/02/23 13:25

ELBのヘルスチェックは 200 以外のコードが返ってくると失敗と判定したはずです。
"/path/to/health_check"についてはruuusaamarkiさんの環境に合わせて変更してください。

サーバのローカルから実行して301 RedirectしているのはNginxもしくはAPの設定かと思います。
例えばserverディテクティブで明示的に指定を行うと、リクエストヘッダのHost:に一致しないリクエストが来た場合、そのブロックのサービスにはアクセスできなかったような・・・
nginxの設定ファイルがあるともう少しわかるかもしれません。

AWS IP範囲の情報は以下にあります。
http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html
この内容に従ってCFで利用している情報をjqで抜いただけとなります。
おわかりかと思いますが、IPではなくCIDR IPです。（念のため）

ELBのヘルスチェックは 200 以外のコードが返ってくると失敗と判定したはずです。 "/path/to/health_check"についてはruuusaamarkiさんの環境に合わせて変更してください。サーバのローカルから実行して301 RedirectしているのはNginxもしくはAPの設定かと思います。例えばserverディテクティブで明示的に指定を行うと、リクエストヘッダのHost:に一致しないリクエストが来た場合、そのブロックのサービスにはアクセスできなかったような・・・ nginxの設定ファイルがあるともう少しわかるかもしれません。 AWS IP範囲の情報は以下にあります。 http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html この内容に従ってCFで利用している情報をjqで抜いただけとなります。おわかりかと思いますが、IPではなくCIDR IPです。（念のため）

キャンセル
2017/02/25 11:48

確認が遅くなりまして申し訳ありません。書き込みありがとうございます！
curl -i http://localhost:80/index.phpとしてみましたが結果は前述のものと同じでした。

nginxのconfファイルを２つ確認してみました。
server_nameがexample.comだったのでcf.example.comに変えてみました。
またlistenに関しても80;だったものをlisten *:80;に変えてみました。
その後nginxの再起動、php-fpmの再起動をしました。
がこれでcf.example.comにアクセスしてみてもエラーも表示されず
マウスの横の読み込みが何回転かしてそのまま画面も変わらずという状況です。

現状整理してみます。
route53のAレコードcf.example.comのエイリアスにxxxxxxxxxxx.cloudfront.net. を設定
nginxのconfファイルのserver_nameにcf.example.comを設定、listen *:80;を設定
listen *:80;
server_name cf.example.com
wordpressのサイトURL、homeURLにcf.example.comを設定。

＞サーバのローカルから実行して301 RedirectしているのはNginxもしくはAPの設定かと思います。
すみません、APの設定はapacheの設定ということで大丈夫でしたでしょうか。

＞http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html
＞この内容に従ってCFで利用している情報をjqで抜いただけとなります。
＞おわかりかと思いますが、IPではなくCIDR IPです。（念のため）
すみません、このあたりは全く分かってない状態です。
少し関連記事を読んでみたいと思います。

php-fpmに関しても少し関連がありそうなものがあるか調べてみたのですが
それっぽい情報も見つけられていない状態です。
他に関連がありそうなポイントなどありますでしょうか。

確認が遅くなりまして申し訳ありません。書き込みありがとうございます！ curl -i http://localhost:80/index.phpとしてみましたが結果は前述のものと同じでした。 nginxのconfファイルを２つ確認してみました。 server_nameがexample.comだったのでcf.example.comに変えてみました。またlistenに関しても80;だったものをlisten *:80;に変えてみました。その後nginxの再起動、php-fpmの再起動をしました。がこれでcf.example.comにアクセスしてみてもエラーも表示されずマウスの横の読み込みが何回転かしてそのまま画面も変わらずという状況です。現状整理してみます。 route53のAレコードcf.example.comのエイリアスにxxxxxxxxxxx.cloudfront.net. を設定 nginxのconfファイルのserver_nameにcf.example.comを設定、listen *:80;を設定 listen *:80; server_name cf.example.com wordpressのサイトURL、homeURLにcf.example.comを設定。＞サーバのローカルから実行して301 RedirectしているのはNginxもしくはAPの設定かと思います。すみません、APの設定はapacheの設定ということで大丈夫でしたでしょうか。＞http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html ＞この内容に従ってCFで利用している情報をjqで抜いただけとなります。＞おわかりかと思いますが、IPではなくCIDR IPです。（念のため）すみません、このあたりは全く分かってない状態です。少し関連記事を読んでみたいと思います。 php-fpmに関しても少し関連がありそうなものがあるか調べてみたのですがそれっぽい情報も見つけられていない状態です。他に関連がありそうなポイントなどありますでしょうか。

キャンセル
2017/03/01 00:09

listen 80;
server_name _;

にしてください。
server_nameはApacheでいうところのVirtual Serverの設定になるかと思います。

> すみません、APの設定はapacheの設定ということで大丈夫でしたでしょうか。

APの設定はこの場合Wordpressに相当するのかな？
php-fpm等使っているならそちらの設定も何か影響してるのかな・・・。
Wordpressをお使いならWordpress側がリダイレクトしていそうです。

CIDRは127.0.0.1/32 という感じで、IPアドレスとマスクでIPアドレスを指定する形式です。

listen 80; server_name _; にしてください。 server_nameはApacheでいうところのVirtual Serverの設定になるかと思います。 > すみません、APの設定はapacheの設定ということで大丈夫でしたでしょうか。 APの設定はこの場合Wordpressに相当するのかな？ php-fpm等使っているならそちらの設定も何か影響してるのかな・・・。 Wordpressをお使いならWordpress側がリダイレクトしていそうです。 CIDRは127.0.0.1/32 という感じで、IPアドレスとマスクでIPアドレスを指定する形式です。

キャンセル
2017/03/03 13:06 編集

コメントありがとうございます！

やっと表示されました。
が、自分でも原因がよくわかっておりませんで
実施したことを書かせていただきます。

・nginxのconfigファイルに以下を設定しました。
listen 80;
server_name _;
・結果はまたリダイレクトループになってしまい、おっしゃる通り原因はwordpress,php-fpm関連かと予想してまずwordpressを切り離して、index.phpをecho "hello";のみに設定したところ表示されました。
ヘッダー情報のX-Cache:RefreshHit from cloudfrontも確認できました。
・原因はwordpressの設定と予想してwp-configの設定、データベースでのサイトURL、wordpressURL等を確認、wp-configに設定した下記記述を最下部から最上部に移動しました。
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
・その後数分経ったのちサイトが表示されていました。
ヘッダー情報のX-Cache:RefreshHit from cloudfrontも確認できました。

おそらく最終段階で原因になっていたのはwordpressのwp-config部分で、途中設定を色々変えたりAWS側やnginx等でも間違った設定が残っていたりで複数個所に問題が発生していたんだと予想しています。

長い間お付き合いいただきましてありがとうございました。
今回は本当に色々勉強させていただきました。

コメントありがとうございます！やっと表示されました。が、自分でも原因がよくわかっておりませんで実施したことを書かせていただきます。・nginxのconfigファイルに以下を設定しました。 listen 80; server_name _; ・結果はまたリダイレクトループになってしまい、おっしゃる通り原因はwordpress,php-fpm関連かと予想してまずwordpressを切り離して、index.phpをecho "hello";のみに設定したところ表示されました。ヘッダー情報のX-Cache:RefreshHit from cloudfrontも確認できました。・原因はwordpressの設定と予想してwp-configの設定、データベースでのサイトURL、wordpressURL等を確認、wp-configに設定した下記記述を最下部から最上部に移動しました。 $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST']; $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR']; ・その後数分経ったのちサイトが表示されていました。ヘッダー情報のX-Cache:RefreshHit from cloudfrontも確認できました。おそらく最終段階で原因になっていたのはwordpressのwp-config部分で、途中設定を色々変えたりAWS側やnginx等でも間違った設定が残っていたりで複数個所に問題が発生していたんだと予想しています。長い間お付き合いいただきましてありがとうございました。今回は本当に色々勉強させていただきました。

キャンセル
2017/03/03 13:26

wordpressは本体の設定、プラグインの設定次第ですぐにリダイレクトループになってしまいますよね、私も触っていてよくわからない部分が多いように感じます。
何より解決されてよかったです。

wordpressは本体の設定、プラグインの設定次第ですぐにリダイレクトループになってしまいますよね、私も触っていてよくわからない部分が多いように感じます。何より解決されてよかったです。

キャンセル

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

cloudfrontの設定がうまくいきません

前提・実現したいこと

発生している問題・エラーメッセージ

試したこと

捕捉情報

疑問点

関連した質問

同じタグがついた質問を見る

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

cloudfrontの設定がうまくいきません

前提・実現したいこと

発生している問題・エラーメッセージ

試したこと

捕捉情報

疑問点

15分調べてもわからないことは、teratailで質問しよう！

関連した質問

同じタグがついた質問を見る

SNSアカウントでログイン

teratailアカウントでログイン