Is it possible (or normal) to have Ruby on Rails development and production on the same server? And is it OK to have sqlite for development and postgresql for production?
It is not normal, but it is possible - and occasionally needed - to debug problems that are only showing up in production. A couple of examples are assets (javascripts, images, etc) that are served up differently in development as opposed to production due to the asset pipeline. Another area is caching which tends to be different in production and is frequently disabled in development.
In ruby on rails there are usually (at least) three modes that the server can run in.
These are referred to as 'environments'.
development. This is your local machine and is what you normally use locally during development
tests. This is used when you run tests and test suites.
production. This is the mode used for actual production servers which are usually on a remote server.
Sometimes you do want/need to run a local development server in 'production mode' and in these cases you do this inline with
RAILS_ENV=production rails server
or
rails server -e production
or
rails server -e production -p 3001
# Specify the port (e.g. **-p 3001**) if you want to run on a different port (the default port is 3000),
# e.g. to run in development mode in one window and production mode in another.
When you run your local server in another mode, such as production, you'll need to be aware that this also affects your database connection. config/database.yml has your database connection and also uses the RAILS_ENV settings.
You may want/need to run your server in production mode - but use your local database. You can do this by temporarily using the actual setting from the development block in the production block of config/database.yml. Just be sure to save the original settings / restore afterwards (before you do your next push).
It's also totally ok and indeed common to have sqlite locally and mysql/postgres/oracle in production.
I wouldn't say it is "normal" or not to have both environments on a single server. A lot of small structures already do it, so to my mind it won't cause any problems.
Anyway, as long as both environments are clearly isolated (i.e. two separate folders at least, and two rvm gemsets or rbenv environments for the ruby and gem versions), it won't cause any problems. Just remember to launch both servers with different ports or sockets and you're done.
That is the way I've done for five projects and it ran without trouble.
You can run same app on same machine on different mode like production or development using different port
rails s # which will run on development mode like localhost:3000
rails s -e production 3002 # for production mode like localhost:3002
second answer regarding database.. Yes you can use different database in different mode like for development sqlite3 and for production postgress by modifying your database.yml file
development:
adapter: sqlite3
database: yourapp_development
username: root
password: root
host: localhost
production:
adapter: postgresql
host: localhost
username: postgres
password: password
pool: 5
timeout: 5000
database: yourapp_production
and in your gemfile
group :development do
gem "sqlite3"
end
group :production do
gem 'pg'
end
You generally run RoR in development mode on development machines - i.e., on your local system where application development takes place. The point is to run RoR in development-friendly manner - exposing error messages, avoiding the need to precompile assets, etc - it's slower but much easier to actively work with.
Having different database systems for development and production is possible, but inadvisable. Ideally the application development environment is closely matched with the production environment - allowing for your code to work in an identical, and predictable manner. SQLite3 can behave quite differently from PostgreSQL - the two have different feature-sets. There are a lot of things that PostgreSQL can do that SQLite can't (I'm not sure about the reverse). See http://edgeguides.rubyonrails.org/active_record_postgresql.html for PostgreSQL-specific features.
Related
I deploy my Rails 6 app (with stimulus-relflex) on Heroku. Everything work find including my jQuery and JS but anything related to stimulus-relfex dont work? Everything work fine on my local dev machine. Any ideas?
You give very little information, but my first guess would be to check the config/cable.yml. It is misleading, but ActionCable "just works" in development, while in production mode one has to configure a pubsub queueing system. The default is set to "redis", which is a (payable?) add-on on heroku, and if you already use redis, it has to be configured/linked correctly in the cable.yml.
A very simple solution is to use postgresql as the pubsub queue, which you are probably already using (on heroku), and is as simple as writing
production:
adapter: postgresql
Add the redis addon on heroku to your application maybe that works..
My goal is to have 2 databases and 2 deployments of rails on the same server. I want to have the regular production server using the production database. Then I want to be able to deploy to a different web address that will use a different database. My goal is to be able to push the backup first and make sure all the migrations etc. work in the full environment. I would then push it to the main server.
The issue I seem to run into is that the database.ml file only lists the 3 database types. The passenger environment will also assume that its running in production and would migrate the main MySQL database even if I deploy the code to a different directory. Whats the best way around this? Was wondering if it is simple or if it involves setting lots of variables in lots of places? Any suggestions would be great!
You can add other database types to database.yml as you see fit.
staging:
adapter: postgresql
host: mydb_host
database: mydb_staging
etc...
You can copy config/environments/production.rb to config/environments/staging.rb and leave it as is so the two environments are exactly the same, or tweak staging.rb as you see fit.
Now you have a staging environment! Use it where appropriate, e.g.:
rake RAILS_ENV=staging db:migrate
I am not a passenger expert, but know that my shop has both staging and production instances of apps running on the same server under passenger, so it can be done. Google can probably instruct you better on configuring that than I can.
I have been developing ruby on rails application since some couple of months. I use the default WEBrick server to run the applications. And I found that when I start the WEBrick server in the development and production modes, the server works more speed for production mode than for the development mode.
Is there any specific reason behind that? Can anybody explain me?
In production mode, a server loads code into the cache, which makes things quick. However, that's not the case in development mode (since you don't want to restart your webrick every time you made a change). Every request loads the according code again, which takes a bit of time.
And the most of all time-eaters is the asset pipeline. In production, you get a compiled version of your assets (javascripts and css) in maybe one or two requests. In development, you get them split, for debugging purpose (based on your environment settings, of course). And because a browser does not handle all requests simultaneously, some assets are loaded after other ones are finished loading. You can watch this behaviour with e.g. firebug's network console. That means: the more assets you have, the longer your page takes to load in development mode.
In dev mode classes are not cached, so Rails reloads all the classes each time you refresh. Also, asset compilation is not done in development (by default), so Rails reloads all the assets (CSS, Javascript etc) each time you refresh.
The difference is between 2 environments. In Rails, there are several environment. Each has his own database configuration and Rails options.
You can use the Rails.env variable to made some different change with particular environment.
By default, the development environment is without all cache and activate the auto-reloading. The production environment is with all cache.
But if you want you can make a production environment like development or development environment like production.
You can add some new specific environment too.
Creating new Environment:
Assuming you want create the hudson environment.
Create a new environment file in config/environments/hudson.rb.
You can start by cloning an existing one, for instance config/environments/test.rb.
Add a new configuration block in config/database.yml for your environment.
That's all.
Now you can start the server
ruby script/server -e hudson
Run the console
ruby script/server hudson
And so on.
I'm trying to run this web aplication of Ruby on Rails with Apache using Phusion Passenger. I already configured the httpd.conf file.
I also have another aplication which runs with 'rails server' commmand, and it's connecting to the development database. However, i don't understand why the aplication which runs with apache it's trying to connect to a production database that i didn't create yet instead development as it should be.
What i have to configure to make my Ruby on Rails application run as development?
Apache with Phusion provide a production level web server environment, rails server (WEBrick) is a simple web server that lets you test locally. You typically use one or the other on a given machine. But not always :-)
But to answer your question, which database is used by Rails is determined by the RAILS_ENV variable, which is by default, one of production, development or test.
When you create a new rails application, a default database configuration is created in the file app/config/database.yml -- there are separate sections that provide necessary parameters for connecting to your database(s). Other environment-specific configurations may be specified either in the environment.rb or in app/config/environments/<name>.rb.
In your Passenger config, you can set the RAILS_ENV variable as documented here http://www.modrails.com/documentation/Users%20guide%20Apache.html#rails_env.
I just realized also that it seems like Passenger is looking for production (expecting the db name to be someweb_production) -- chances are you have to run a bundle exec rake db:migrate in the production environment in order to (create and) initialize the database. You may need to pass the environment parameter in this case also.
For your local config (rails server) the server will look for a shell environment variable named RAILS_ENV, and you can also pass a specific environment on the command line e.g. rails server --environment=development. I think if neither is specified, rails server defaults to development.
The problem was that i didn't include the following lines in the Apache conf file:
RailsEnv development
RackEnv development
I'm learning Ruby on Rails. At the moment I'm just running my site locally with rails server in the OS X Terminal. What changes when a Rails site is run on a production box?
Is the site still started with rails server?
Any differences with how the db is setup?
Note: I'm running Rails 3.
A rails app can be run in production calling rails server -e production, although 99% of the time you'll be serving on something like passenger or thin instead of WEBrick, which means there's a different command to start the server. (thin start -e production for instance)
This is a complicated question, but the best place to start learning about the differences would be to look at the specific environment.rb files. When rails boots up it starts with the environment file that matches the called environment, ie if you start it in development it begins by loading your development.rb file, or if you're in production it will load the production.rb file. The differences in environments are mostly the result of these differences in the various environment config files.
Basically if a Rails 3.1 app is in production mode, then by default it is not going to be compiling assets on the fly, and a lot of caching will be going on that isn't happening in development. Also, when you get error messages they will be logged but not rendered to the user, instead the static error page from your public directory will be used.
To get more insight into this, I would suggest reading the relevant rails guides:
Rails Initialization Guide: http://guides.rubyonrails.org/initialization.html
Rails Configuration Guide: http://guides.rubyonrails.org/configuring.html
There are two contexts you can use the word "production" here. One of them is running the server in production mode. You can do this locally by,
RAILS_ENV=production ./script/server
The configuration for this is picked up from config/environments/production.rb. Try comparing this file with config/environments/development.rb. There are only subtle differences like caching classes. Development mode makes it easier so that it will respond to any changes you make instantly. Plus there are two different databases (by default) will be used namely yourproject_development and yourproject_production if you choose to run your server in either of these modes.
On the other hand, rails deployment to a production box is something different. You will need to pick your server carefully. You may have to deal with a deployment script may be capistrano. You may also need a load balancer such as netgear. The database also may require a deep consideration like size expectation, master/slave clustering etc.,
Note: I have never used Rails 3. This answer is biased towards 2.3.x.