web-dev-qa-db-ja.com

Amazon Route 53 + Cloudfront + s3-> ec2のangularjsアプリを使用

私はangularjs2アプリに必要なセットアップについて本当に混乱しています。

これは、html5モードのURLを使用したSPAアプリケーションであり、必要なのは次のとおりです。

  • www.mydomain.com/blabla...へのリクエストは、同じmydomainにリダイレクトされますが、wwwはありません
  • mydomain.com/anything/including/path/like/thisへのリクエストは、s3（/ cloudfront）index.htmlを提供します
  • mydomain.com/path/or/not/path/file_that_ends_with_any_extesnion_like.jsへのリクエストはs3（/ cloudfront）からそのファイルを提供します難しすぎる場合は、すべてのアセットがアセットフォルダーにあるようにウェブサイトを設定することもできますしたがって、mydomain.com/assets/path/blabla.blaへのリクエストは静的なものを提供しますs3からのファイル（/ cloudfront）
  • 最後になりましたが、mydomain.com/api/...へのリクエストは、私のREST APInode.jsサーバーを保持するec2インスタンスにリダイレクトされます。

通常、nginx try_filesの間にnginxとnode.jsで1つのec2インスタンスを使用し、失敗した場合はindex.htmlファイルを提供し、URLが/api/..の場合は、同じec2にあるAPIにリクエストをリダイレクトします。

このセットアップの問題は、複数のec2インスタンスがある場合、拡張性が低く、維持が難しいことです。

Googleでよく調べましたが、AWSクラウドで説明したような設定方法に関するガイドやブログ投稿が見つかりません。

前もって感謝します ：）

amazon-ec2amazon-web-servicesamazon-s3amazon-route53amazon-cloudfront
1
kfir124

www.mydomain.com/blabla ...へのリクエストは、同じmydomainにリダイレクトされますが、wwwはありません。

これは、S3でwww.example.comという名前の空のバケットを作成し、すべてのリクエストを別のホスト名（example.com）にリダイレクトするように構成し、DNSをそのバケットに向けることによって行われます。

Www側でhttpsリクエストのリダイレクトをサポートする場合は、バケットのWebサイトエンドポイントを指すwwwホスト名の2番目のCloudFrontディストリビューションを作成し、DNSがCloudFrontを指すようにします。

mydomain.com/anything/include/path/like/thisへのリクエストにより、s3（/ cloudfront）index.htmlが提供されます

静的Webサイトホスティング用にexample.comバケット（上記の空のバケットではなく、コンテンツを含むバケット）を構成し、バケットの静的Webサイトホスティング構成オプションで インデックスドキュメント名をindex.htmlに設定します。 S3のドキュメントで説明されているように、バケットに対してS3 Webサイトホスティング機能が有効になっている場合、バケット内の適切な場所からの名前付きインデックスページは、次のルールに従って、可能な限りS3によって自動的に返されます。

  • リクエストされたパスが/foo/bar/（末尾にスラッシュが付いている）の場合、S3はキーfoo/bar/index.htmlを持つオブジェクトを探して返し、ブラウザのアドレスバーは変更されません。

  • リクエストされたパスが/foo/bar（末尾のスラッシュなし）で、foo/bar/index.htmlが存在する場合、S3は/foo/bar/へのリダイレクトを返します。これにより、末尾の/がブラウザのアドレスバーに表示された後、上記の動作が発生します。 （これは、末尾のスラッシュを追加するためのリダイレクトであり、標準のWebサーバーの動作です。そうしないと、インデックスページの相対リンクが間違ったディレクトリを指します）。

CloudFront Originをセットアップするときに、CloudFrontのドロップダウンリストからバケットを選択する代わりに、バケットのWebサイトエンドポイントホスト名を入力する必要があります。そうしないと、インデックスドキュメントなどのWebサイト機能が有効になりません。

重要

Example.com.s3.amazonaws.comなど、リストからバケットの名前を選択しないでください

http://docs.aws.Amazon.com/gettingstarted/latest/swh/getting-started-create-cfdist.html

次号：

mydomain.com/path/or/not/path/file_that_ends_with_any_extesnion_like.jsへのリクエストは、難しすぎる場合はs3（/ cloudfront）からそのファイルを提供します。すべてのアセットがアセットフォルダーにあるようにウェブサイトを設定することもできます。 mydomain.com/assets/path/blabla.blaへのリクエストは、s3（/ cloudfront）から静的ファイルを提供します

それぞれがパスパターンに一致するキャッシュ動作を使用して、リクエストの送信先の「オリジン」（バックエンドシステム）を選択するようにCloudFrontを設定できます。この場合、デフォルトのキャッシュ動作がバケットを指すようにしたいようです。バケットは、別のキャッシュ動作と一致しない場合、そこにすべてのリクエストを送信します。

最後になりましたが、mydomain.com/api/...へのリクエストは、my REST APInode.jsサーバーを保持するec2インスタンスにリダイレクトされます。

おそらく、実際には「リダイレクト」を意味するのではなく、EC2インスタンスへの「転送」または「プロキシ」（同じこと）リクエストを意味します。

EC2インスタンスをサイトのCloudFrontディストリビューションの別のオリジンとして宣言します。このオリジンを使用するパスパターン/api/*に一致する新しいキャッシュ動作を作成すると、CloudFrontはこれらのリクエストをEC2インスタンスに送信します。

EC2のコードがAPIレスポンスで適切なCache-Control:ヘッダーを返すようにして、CloudFrontが適切な時間キャッシュするか、Cache-Control: no-cacheを返す場合はまったくキャッシュしないようにします。

キャッシュ動作パスパターンでは、先頭のスラッシュが欠落していることは暗黙的であるため、api/*は/api/*と同等であることに注意してください。

CloudFrontには、オリジンの属性である「オリジンパス」と呼ばれる設定があることにも注意してください。これは、キャッシュ動作の属性である「パスパターン」と混同されることがあります。 「オリジンパス」は、特定のオリジンに送信するパスとは関係がないため、空白のままにします。

5
Michael - sqlbot