关于带有图像上传功能的 Rails 应用程序的 Amazon Cloud Front 问题

发布于 2024-12-04 09:49:30 字数 762 浏览 1 评论 0原文

新的 AWS 问题:我们的 Rails 应用程序目前允许通过 Carrierwave 将图像上传到 S3 存储桶。事情运作良好......但它开始变得有点混乱(和麻烦),因为一些原始文件在一个存储桶中(上传的照片),而其他文件在另一个存储桶中(网站徽标等),而还有其他文件(javascript 和 css) )直接由 Rails 主机提供。

我们正在寻找Cloud Front可能帮助巩固和发展。简化我们的交付......但我们没有人有任何先前的经验。 正确配置后(使用自定义源),我们可以/应该将所有资产带回本地服务器,然后“简单地”依靠 Cloud Front 进行交付吗? 这意味着将所有上传的图像带回(当前在 S3 上)返回到本地 Rails 服务器,而不是使用带有 Fog gem 的 Carrierwave 来上传它们,我们只是处理和处理它们。将文件存储在本地文件系统上。这将有很多优点,其中最主要的是我们可以在本地主机上拥有整个应用程序的完整副本,包括所有资产。

另外,我们是否可以预期新图像在上传后会出现延迟……除了,如果通过 Fog 上传到 S3 处理上传的图像后出现轻微延迟,目前会发生什么情况?

最后,是否有任何理由让我们的 S3 存储桶保持活力?我知道“未使用”的资产已从 CloudFront 中清除,但无论如何,对我来说,尚不清楚什么指标定义了“未使用”。

这是一个常见的用例吗?大多数情况下只是寻求验证或告诉你这样。

谢谢!

Newbish AWS question: Our Rails app currently allows image uploads via Carrierwave to an S3 bucket. Things work well...but it's starting to get a bit confusing (and cumbersome) as some original files are in one bucket (uploaded photos) while others are in another bucket (site logos, etc) while still others (javascript & css) are served directly from the Rails host.

We're looking at Cloud Front to possibly help consolidate & simplify our delivery...but none of us have any prior experience with it. Once properly configured (with a custom origin) can/should we expect to bring all assets back to our local server and then "simply" rely on Cloud Front for delivery? This would mean bringing all the uploaded images (currently on S3) back down to the local Rails server and instead of using Carrierwave with the Fog gem to upload them we just process & store the files on the local filesystem. This would have many advantages, chief of which is we'd have a complete copy of the entire application, including all assets, locally on our hosts.

Also, can we expect delays on a new image being served after it is uploaded...beyond what happens currently where there is a slight delay after processing an uploaded image as it is uploaded to S3 via Fog?

Lastly, is/would there be any reason to keep our S3 buckets alive? I understand "unused" assets are purged from CloudFront but it's not clear, to me anyway, what metric defines "unused".

Is this a common use case? Mostly just looking for validation or a told-you-so.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

小猫一只 2024-12-11 09:49:31

至于使用 cloudfront 的 Carrierwave s3,我写了一篇博客文章详细介绍了如何做到这一点。 (如果您已经有 s3 工作,那么让 cloudfront 部分工作非常容易) ="nofollow">http://jeffdickey.info/using-rierwave-on-heroku-for-image-uploading-w-cloudfront

在 js/css 资产注释上,如果您使用对于 Rails 3.1 资产管道,您所需要做的就是进入 Production.rb 文件并将资产主机设置为指向 Rails 服务器的 Cloudfront CDN。

我喜欢将 content.domain.com 和 assets.domain.com 用于这 2 个 CDN。

无需将 js/css 资源上传到 S3,然后从 CloudFront 提供服务,只需直接提供服务即可。 CloudFront 将为您处理缓存。

As far as the carrierwave s3 using cloudfront, I wrote up a blog article on exactly how to do this. (It's super easy to get the cloudfront part to work if you already have s3 working) http://jeffdickey.info/using-carrierwave-on-heroku-for-image-uploading-w-cloudfront

And on the js/css asset notes, if you're using rails 3.1 asset pipeline, all you need to do is go into your production.rb file and set your asset host to a cloudfront cdn that points to the rails server.

I like to use content.domain.com and assets.domain.com for these 2 cdns.

No need to upload your js/css assets to S3, then serve them from CloudFront, just serve them directly. CloudFront will handle the caching for you.

酒中人 2024-12-11 09:49:31

两个建议:

1)使用 jammitjammit-s3 来管理您的资产并将其传送到云端。在开发过程中,您的资产位于本地文件系统上,但在部署时,您将推送到云端。 s3 gem 足够智能,可以检查哪些文件已更改等。我不确定这将如何受到 Rails 3.1 的影响,但它在 3.0 上对我来说效果很好。

2) 使用cloudflare。这项服务令人难以置信令人兴奋,除了安全优势之外,还可以缓存您的静态资产并使用他们自己的 CDN 提供它们。令人惊讶的是,有一项免费服务几乎可以满足我们大多数人需要的一切,尽管我不知道您的应用程序的要求。强烈建议您检查一下。

Two suggestions:

1) Use jammit and jammit-s3 to manage your assets and deliver them to cloudfront. In development your assets are on your local filesystem but on deploy you push to cloudfront. The s3 gem is smart enough to check which files have changed etc. I'm not sure how this will be affected by rails 3.1 but it has worked well for me on 3.0.

2) Use cloudflare. This service is incredibly exciting and aside from the security benefits also caches your static assets and delivers them using their own cdn. Surprisingly there is a free service which does mostly everything most of us need, though I don't know about your app's requirements. Highly recommended you check it out.

西瓜 2024-12-11 09:49:31

关于将上传的图像传回服务器,需要记住以下几点:

  • 您可能需要为多个云前端边缘位置(目前大约有 20 个)付费,而不是为一个存储桶中的存储付费。另一方面,您只需为实际使用的文件和用户所在的位置付费,因此差异取决于文件的使用方式。
  • 如果文件发生更改,您需要更改其名称,否则您的用户可能看不到更改,也许您已经通过为上传提供唯一名称来解决此问题。

如果egde位置丢失文件,则服务不会出现明显的延迟,Cloudfront将简单地从您的服务器获取文件,转发并存储它以供下次访问。因此,如果文件被清除,那并不重要,因为 Cloudfront 将在需要时再次获取它。

至于其他文件,由于您使用 Rails 3.1 和资产管道,因此非常简单。我在这里记录了我的设置:

http://blog.ertesvag.no/post/10720082458

Regarding bringing the uploaded images back to your server there are a few things to keep in mind:

  • Instead of paying for storage in one bucket you will potentially be paying for several cloudfront edge locations(about 20 of them at the moment). On the other hand you will only be paying for files that are actually used and the location where your users are, so the difference depends on how your files are used.
  • If a file is changed you need to change its name or your user may not see the change, maybe you already solve this by giving uploads unique names.

There is no significant delay in serving, if a file is missing from an egde location Cloudfront will simply fetch the file from your server, forward it and store it for the next time it is accessed. So if a file is purged it does not really matter as Cloudfront will just fetch it again if needed.

As for your other files, since you are using Rails 3.1 with the asset pipeline it is pretty easy. I have documented my set up here:

http://blog.ertesvag.no/post/10720082458

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文