Trying to test deploy a simple Rails 3.1 app in production mode, using the asset pipeline, after precompiling the assets. Using JRuby and WEBrick 1.3.1 for now; the plan is to deploy next on JBoss.
Everything works fine running in development environment, but in production it raises RoutingError when the client requests any precompiled asset.
The Rails server log looks like:
Started GET "/assets/application-a04f15ca8cb6078896dbdc22266757d9.css"
for 127.0.0.1 at 2012-02-06 18:19:04 -0500
ActionController::RoutingError (No route matches [GET]
"/assets/application-a04f15ca8cb6078896dbdc22266757d9.css)
The precompiled assets are in the applications public/assets directory.
Should I expect WEBrick to be able to handle /public/assets? or can I only test that when deployed on Apache or such?
Any help would be greatly appreciated.
The answer is at No route matches [GET] /assets
It makes sense. Rails in production mode doesn't serve static assets by default, leaving that to the deployment server. You can configure rails to serve static assets by setting config.serve_static_assets to true (though you probably get better performance leaving it as false)
Related
I am developing Rails 5 application and use assets pipeline.
It work well in development mode, but if I try to run it in production mode, it can't load images & styles correctly.
I checked and found that it is because
config.assets.compile = false
in config/environments/production.rb
Unless I set it true, it doesn't work at all.
I know live compilation isn't good for production, what is solution?
There are two options related to serving assets within a Rails server:
Asset compilation
config.assets.compile = true
refers to asset compilation. That is, whether Rails should recompile the assets when it detects that a new version of the source assets is there. In development, you want to have it set to true, so that your styles get compiled when you edit the css files. With the next request, Rails will automatically recompile the assets. On production, you usually want to set it to false and handle asset compilation during deployment. For this, you have to run
RAILS_ENV=production bin/rails assets:precompile
Usually, if you deploy using Capistrano, it takes care of that.
Asset serving
The second option related to assets is
config.public_file_server.enabled
This describes whether it is Rails that should serve the compiled files from the public/assets directory. In development, you want that, so it's true by default. In production, you usually don't want to fire up your web server to serve the logo image or a css file, so you probably compile the assets and then host them separately (for example, on a CDN like cloudfront). If you still want them to be served in production, you can launch Rails with:
RAILS_SERVE_STATIC_FILES=true RAILS_ENV=production bin/rails server
Precompile your assets first.
Run RAILS_ENV=production rake assets:precompile to generate your stylesheets and js files in your public directory.
I'm testing my Rails 4 app in the production environment on my localhost:3000 using the built in Webrick server. When I run RAILS_ENV=production bundle exec rake assets:precompile the assets are rebuilt in public and the manifest is rebuilt, but the pages are still being served with the previous asset names.
Restarting the rails server makes the new assets appear. Is there a less extreme way to achieve this and how will this behave when I port this to my production server running Phusion Passenger. I really don't want to restart Apache to get my assets in gear.
If you did not change the contents of assets, the precompiled version will be as same as the previous one. If you change it even a bit, the fingerprint will change and app will request for the new one only as you have set config.assets.digest = true.
Anyway another work around would be:
Just run:
rake assets:clean
and then,
rake assets:precompile
This makes everything in the asset pipeline to be rebuilt and serve freshly.
Rails automatically clear the cache for every individual file when its contents are edited.
If any of the above did not work, please try as below:
config.serve_static_assets = true in config/environments/production.rb
config.serve_static_assets configures Rails itself to serve static assets. Defaults to true, but in the production environment is turned off as the server software (e.g. Nginx or Apache) used to run the application should serve static assets instead. Unlike the default setting set this to true when running (absolutely not recommended!) or testing your app in production mode using WEBrick. Otherwise you won't be able use page caching and requests for files that exist regularly under the public directory will anyway hit your Rails app.
Ref: http://guides.rubyonrails.org/configuring.html#rails-general-configuration
Hope it helps :)
We faced the same problem where the old assets were being served even after trying rake assets:clean or assets:clobber and eventually server reboot would resolve the issue. The culprit in our case was unicorn. While deploying our rails app using mina and mina-unicorn, we ran rake assets:clobber, then compiled assets and then restarted unicorn in the end. By doing this the unicorn master never gets stopped and continues to show old assets. So, we changed our mina deploy script and instead of restarting unicorn, we stopped unicorn and started it back. This resolved the issue. So, the key steps are
Deploy application
run rake assets:clobber
run rake assets:precompile
stop unicorn
start unicorn
This kills the concept of zero downtime but this is a better solution than restarting the server.
I understand that you use passenger but this information can be helpful for others
You can recompile your rails assets by running the following command:
bin/rails assets:precompile RAILS_ENV=development
en:
activemodel: # or activerecord:
errors:
models:
person:
# Override the format for all Person attributes:
format: "Invalid %{attribute} (%{message})"
attributes:
age:
# Override the format for the age attribute:
format: "%{message}"
blank: "Please fill in your %{attribute}"
Disclaimer: I have looked all over but there are too many solutions to the problem which did not work for me hence this post.
Developed a simple website using Rails 3.2.2 in development mode got all assets working fine. When I switched to use production (ie: rails server -e production), the assets breaks and I get the ActionController::RoutingError (No route matches [GET] "/stylesheets/application.css") error.
I haven't changed the production.rb file.
Thanks for helping this frustrated human being... :)
You should precompile the assets before deploying the project.
bundle exec rake assets:precompile
In production.rb try config.serve_static_assets = true
I just had the same issue. I forgot to add my files to config.assets.precompile...
Rails assets working in development and not production
in my config/environments/production.rb I had to add a list of non default assets (like plugins)...
config.assets.precompile += w%( jquery.plugin.js awesome.css etc )
I'm struggling with setting up a rails-based web site in production mode. An intermediate goal would be to set up a very simple web site. I'm using Rails 3.1.0, rake 0.9.2.2, and
Ruby 1.9.2.
Here is what I tried, with unsuccessful results so far:
initially, make sure RAILS_ENV is not set
rails new test_project
cd test_project
rails generate scaffold User name:string email:string
rake db:migrate
rails s
browse to localhost:3000 or localhost:3000/users
things look OK.
now, attempt to set this up for production:
export RAILS_ENV=production
rake db:migrate
rake assets:precompile
rails s
browse to localhost:3000
PROBLEM: Routing Error; No route matches [GET] "/"
kill rails
in config/routes, add root :to => 'users#index'
rails s
can now browse to localhost:3000 and localhost:3000/users
BUT, rails generates the following errors:
Started GET "/assets/application-00960e5186894b532975562d59176a6a.css" for 127.0.0.1 at 2011-11-26 23:09:44 -0800
ActionController::RoutingError (No route matches [GET] "/assets/application-00960e5186894b532975562d59176a6a.css"):
Started GET "/assets/application-ae30e133eabbb10d9464189d3fb71e25.js" for 127.0.0.1 at 2011-11-26 23:09:44 -0800
ActionController::RoutingError (No route matches [GET] "/assets/application-ae30e133eabbb10d9464189d3fb71e25.js"):
Can anyone shed light on how to fix the above simple attempt to get a Rails 3.1 project working in "production" mode?
The fundamental problem is that the default configuration for running an application in "production" mode makes some assumptions about deployment -- primarily that you're using another webserver (eg. nginx, apache) for serving static assets. You're getting the file not found errors because by default Rails will not serve static assets in production mode
If you're trying to use WEBrick to duplicate a "production" environment, it needs to be configured to serve static assets. You can simply flip the boolean in your production.rb
environments/production.rb
# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = false
Once you make that change and restart the server, you'll be serving the assets you precompiled using WEBrick which while inefficient, will certainly give you an idea about what it's like in production.
Routing error, go to your routes.rb file and add
resources :users
Now when you run 'rake routes' from terminal you will see the relevant routes you require to navigate this model.
It is running Rails 3.0.0 or Rails 3.0.5 (using Ruby 1.9.2)
When in development mode
rails server
then http://localhost:3000 works all fine, and http://localhost:3000/foos will load up a stylesheet.css
but when it is
rails server -e production
then now all of a sudden, http://localhost:3000 gives:
No route matches "/"
and http://localhost:3000/foos can run, but the stylesheet.css is not loaded and opening it in the browser shows:
No route matches "/stylesheets/scaffold.css"
Is special route needed for production vs development? (or is it for some other reason?)
You need to set
config.serve_static_assets = true
in config/environments/production.rb. It's likely commented out in there already.
By default Rails does not serve static files by itself in production, since full-on web servers like Nginx or Apache, will serve them automatically anyway.