5 ms·

That's great! My biggest problem right now in term of deployment time is to sync with amazon for the assets. It literally takes 5 minutes for a small website..

by d0m 13y ago

nthj 13y ago
Yeah, that's frustrating. I might suggest you just serve them from your app [1], and use CloudFront with a custom origin to take over from there. I can deploy a Rails 4 app in ~20 seconds. [1] http://guides.rubyonrails.org/configuring.html#rails-general-configuration http://guides.rubyonrails.org/configuring.html#rails-general...
dataviz 13y ago
Have you tried dedicated CDN service?
friism 13y ago
At Heroku we now [recommend using AWS CloudFront][1] to serve assets, backed by your app running on Heroku instead of with S3. It's a much simpler setup with less state and fewer moving parts - and builds are faster :-). [1]: https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn https://devcenter.heroku.com/articles/using-amazon-cloudfron...
- beambot 13y ago
  Isn't this still problematic with SSL? Last time I checked, you had to pay $600/mo for a custom CloudFront SSL cert if you wanted to pass through the credentials from your own domain. (Using mixed http/https was not an option.)
  - friism 13y ago
    It's true that this is a problem if you insist on serving your CDN assets a custom domain CNAME mapped to CloudFront (i.e. https://assets.mydomain.com/ https://assets.mydomain.com/). It doesn't cost extra if you just use the default CloudFront distribution URL, i.e. https://d3vam04na8c92l.cloudfront.net/stylesheets/application-6502e5a88f02b90aeb32c2dd21ea37ab.css https://d3vam04na8c92l.cloudfront.net/stylesheets/applicatio... This is not entirely clear from the Heroku docs, I'll ping the maintainer for an update.
    - nthj 13y ago
      One cool trick for serving mixed http/https that I somehow went 10 years without finding out: you can just point your Rails asset_host to "//d3vam04na8c92l.cloudfront.net". Browsers understand this to mean "Look up this address via whatever protocol I am currently on, http if http, https if over SSL." This is a huge cache boost in Rails because you don't have to cache your pages twice (once for HTTP once for HTTPs.)
      - girvo 13y ago
        Oh god.. While your post is cool, I reacted violently to the "One cool trick..." part at the beginning. Upworthy, you've broken me.
    - sanderjd 13y ago
      Is there any real downside to this approach, or is it just that it looks "less professional"?
      - neilmiddleton 13y ago
        No, you're still serving the same assets. It's only really an issue if your users like seeing where network requests are going and spot the cloudfront URL.
  - espeed 13y ago
    Does Google have something like CloudFront for Compute Engine? Google gives you edge-cache for free if you use App Engine, but what about GCE?
- ikawe 13y ago
  Thanks, really happy to see this is the officially recommend approach. I've been doing it, but got some uncomfortable knee-jerk reactions from other developers, e.g. "But you should NEVER serve static assets directly!!!". ...but it's only served once!
  - nthj 13y ago
    > e.g. "But you should NEVER serve static assets directly!!!". As with music, painting, and architecture, any development-related NEVERS require that we understand the why, so we can know when to break the rule.
kmtrowbr 13y ago
I have been using this asset_sync gem (with Ruby on Rails), together with S3 & Cloudfront, for 2 years and it works wonderfully: https://github.com/rumblelabs/asset_sync https://github.com/rumblelabs/asset_sync I basically never think about deploying assets. It nearly always just works.
- josephlord 13y ago
  It works but they are a bit slow on merging pull requests. I'm currently using a fork so that CORS can work on Rackspace. I think this sort of issue is why Heroku no longer recommend this approach.
  - neilmiddleton 13y ago
    It's not recommended as asset precompilation usually requires access to the environment (e.g a DB connection), and thus isn't deterministic.
riffraff 13y ago
that seems like a lot of time for a small website. Are you re-uploading the assets all the time?
aantix 13y ago
Something isn't right. Sounds like you're recalculating the cache digests each time.. Make sure you have your cache store set to dalli (production.rb) config.assets.cache_store = :dalli_store
sleepyhead 13y ago
Don't sync. Compile on deploy and let Cloudfront fetch when needed. It should also be possible to cache assets in memcache instead of compiling on each deploy (personally I ran into some issues with it but can't recall why).

That's great! My biggest problem right now in term of deployment time is to sync with amazon for the assets. It literally takes 5 minutes for a small website..

by d0m 13y ago

That's great! My biggest problem right now in term of deployment time is to sync with amazon for the assets. It literally takes 5 minutes for a small website..

nthj 13y ago

Yeah, that's frustrating. I might suggest you just serve them from your app [1], and use CloudFront with a custom origin to take over from there. I can deploy a Rails 4 app in ~20 seconds. [1] http://guides.rubyonrails.org/configuring.html#rails-general-configuration http://guides.rubyonrails.org/configuring.html#rails-general...

dataviz 13y ago

Have you tried dedicated CDN service?

friism 13y ago

At Heroku we now [recommend using AWS CloudFront][1] to serve assets, backed by your app running on Heroku instead of with S3. It's a much simpler setup with less state and fewer moving parts - and builds are faster :-). [1]: https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn https://devcenter.heroku.com/articles/using-amazon-cloudfron...

beambot 13y ago
Isn't this still problematic with SSL? Last time I checked, you had to pay $600/mo for a custom CloudFront SSL cert if you wanted to pass through the credentials from your own domain. (Using mixed http/https was not an option.)
- friism 13y ago
  It's true that this is a problem if you insist on serving your CDN assets a custom domain CNAME mapped to CloudFront (i.e. https://assets.mydomain.com/ https://assets.mydomain.com/). It doesn't cost extra if you just use the default CloudFront distribution URL, i.e. https://d3vam04na8c92l.cloudfront.net/stylesheets/application-6502e5a88f02b90aeb32c2dd21ea37ab.css https://d3vam04na8c92l.cloudfront.net/stylesheets/applicatio... This is not entirely clear from the Heroku docs, I'll ping the maintainer for an update.
  - nthj 13y ago
    One cool trick for serving mixed http/https that I somehow went 10 years without finding out: you can just point your Rails asset_host to "//d3vam04na8c92l.cloudfront.net". Browsers understand this to mean "Look up this address via whatever protocol I am currently on, http if http, https if over SSL." This is a huge cache boost in Rails because you don't have to cache your pages twice (once for HTTP once for HTTPs.)
    - girvo 13y ago
      Oh god.. While your post is cool, I reacted violently to the "One cool trick..." part at the beginning. Upworthy, you've broken me.
  - sanderjd 13y ago
    Is there any real downside to this approach, or is it just that it looks "less professional"?
    - neilmiddleton 13y ago
      No, you're still serving the same assets. It's only really an issue if your users like seeing where network requests are going and spot the cloudfront URL.
- espeed 13y ago
  Does Google have something like CloudFront for Compute Engine? Google gives you edge-cache for free if you use App Engine, but what about GCE?
ikawe 13y ago
Thanks, really happy to see this is the officially recommend approach. I've been doing it, but got some uncomfortable knee-jerk reactions from other developers, e.g. "But you should NEVER serve static assets directly!!!". ...but it's only served once!
- nthj 13y ago
  > e.g. "But you should NEVER serve static assets directly!!!". As with music, painting, and architecture, any development-related NEVERS require that we understand the why, so we can know when to break the rule.

kmtrowbr 13y ago

I have been using this asset_sync gem (with Ruby on Rails), together with S3 & Cloudfront, for 2 years and it works wonderfully: https://github.com/rumblelabs/asset_sync https://github.com/rumblelabs/asset_sync I basically never think about deploying assets. It nearly always just works.

josephlord 13y ago
It works but they are a bit slow on merging pull requests. I'm currently using a fork so that CORS can work on Rackspace. I think this sort of issue is why Heroku no longer recommend this approach.
- neilmiddleton 13y ago
  It's not recommended as asset precompilation usually requires access to the environment (e.g a DB connection), and thus isn't deterministic.

riffraff 13y ago

that seems like a lot of time for a small website. Are you re-uploading the assets all the time?

aantix 13y ago

Something isn't right. Sounds like you're recalculating the cache digests each time.. Make sure you have your cache store set to dalli (production.rb) config.assets.cache_store = :dalli_store

sleepyhead 13y ago

Don't sync. Compile on deploy and let Cloudfront fetch when needed. It should also be possible to cache assets in memcache instead of compiling on each deploy (personally I ran into some issues with it but can't recall why).