简体   繁体   English

Cloudfront 同一存储桶中的多个源

[英]Cloudfront Multiple origins within the same bucket

I have a cloudfront distribution which I'm using with a single S3 bucket as the origin.我有一个 Cloudfront 发行版,我使用一个 S3 存储桶作为源。 The bucket has both private and public data in it, segregated by folders - public_folder_1, public_folder_2, private_folder_1, private_folder_2 .存储桶中有私有和公共数据,按文件夹分隔 - public_folder_1, public_folder_2, private_folder_1, private_folder_2 I want to use cloudfront to serve only the content from the 2 public folders.我想使用 cloudfront 仅提供 2 个公共文件夹中的内容。 I want requests to xxx.cloudfront.net/public_folder_1/file1 to go to public_folder_1 and requests to xxx.cloudfront.net/public_folder_2/file1 to go to public_folder_2 .我希望对xxx.cloudfront.net/public_folder_1/file1请求转到public_folder_1并将对xxx.cloudfront.net/public_folder_2/file1请求转到public_folder_2

I have created 2 origins within the distro with origin name + paths - mybucket/public_folder_1 and mybucket/public_folder_2 for the 2 folders.我在发行版中创建了 2 个源,源名称 + 路径 - mybucket/public_folder_1mybucket/public_folder_2用于 2 个文件夹。 I have also created two behaviours with path patterns - public_folder_1/* and public_folder_2/* (I have tried adding a leading / to the path pattern, it doesn't seem to make a difference) .我还使用路径模式创建了两种行为 - public_folder_1/*public_folder_2/* (我尝试在路径模式中添加前导/ ,它似乎没有什么区别)。 But I can't access files via cloudfront.但是我无法通过 cloudfront 访问文件。

If I change the path pattern for either behaviour to * instead of public_folder_x/* then I can access files using xxx.cloudfront.net/filex .如果我将任一行为的路径模式更改为*而不是public_folder_x/*那么我可以使用xxx.cloudfront.net/filex访问文件。 My concern with this is that if I have 2 files with the same name in both folders how would cloudfront know which folder to use as the origin?我对此的担忧是,如果我在两个文件夹中有 2 个同名文件,cloudfront 如何知道要使用哪个文件夹作为源? I don't want to have to create and manage a seperate distro for each origin path.我不想为每个原始路径创建和管理单独的发行版。

In my case, I wasn't understanding that when CloudFront finds a matching behavior, it forwards the entire URL path to S3 .就我而言,我不明白当 CloudFront 找到匹配行为时,它会将整个 URL 路径转发到 S3 If a matching directory structure isn't represented in your S3 bucket subdirectory, you'll get a 403 response.如果您的 S3 存储桶子目录中未表示匹配的目录结构,您将收到 403 响应。 For example, if you have a behavior matching on /developer/* , and the url is {hostname}/developer/thing.html , the S3 bucket directory which represents your origin must have a root-level subdirectory named "developer" that contains thing.html .例如,如果您在/developer/*上有一个行为匹配,并且 url 是{hostname}/developer/thing.html ,则代表您的来源的 S3 存储桶目录必须具有一个名为“developer”的根级子目录,其中包含thing.html

My concern with this is that if I have 2 files with the same name in both folders how would cloudfront know which folder to use as the origin?我对此的担忧是,如果我在两个文件夹中有 2 个同名文件,cloudfront 如何知道要使用哪个文件夹作为源?

You'd have to find some way to distinguish the files by a matching pattern.您必须找到某种方法通过匹配模式来区分文件。 I would suggest adding uniquely named folders to each origin, then creating behaviors to divert traffic based on the path provided:我建议为每个源添加唯一命名的文件夹,然后根据提供的路径创建行为以转移流量:

  • origin1: mybucket/stuff origin1: mybucket/stuff
  • origin2: mybucket/things origin2: mybucket/things
  • behavior1: /stuff/* --> origin1行为 1: /stuff/* --> origin1
  • behavior2: /things/* --> origin2行为 2: /things/* --> origin2
  • cloudfront-url/stuff/file.html --> returns file.html in the stuff directory, aka origin1. cloudfront-url/stuff/file.html --> 返回 stuff 目录中的file.html ,又名 origin1。
  • cloudfront-url/things/file.html --> returns file.html in the things directory, aka origin2. cloudfront-url/things/file.html --> 返回things目录中的file.html ,也就是origin2。

Edit:编辑:

I just created a single distro with the following two origins...我刚刚创建了一个具有以下两个来源的发行版......

起源

With the following behaviors...有以下行为...

行为

And the following bucket structure...而下面的桶结构...

S3

And here are the results:结果如下:

I'll leave the distro up for a few days so you can click the links.我会将发行版搁置几天,以便您可以单击链接。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM