How do I work on my Rails app in development mode, but push it in production mode? - ruby-on-rails

Simple question, I do all my work on my local at home computer and then I git push to my repo on github, and then on my Ubuntu Server I do a git pull to get the content, but this causes inconsistencies because it pulls in development mode which I always have to go in and change. Is there a way to make it so I can work in development mode but push it to the repo production mode? Thanks.

This isn't a git problem. Rails environments ('production', 'development', 'test') affect how the code runs, but the code isn't changed.
When you run rails server on your development machine, the application starts in development mode because that is the default for that command.
You probably aren't using the same command to host your site on WEBrick on your server, but rather using something like Phusion Passenger, which can (should) be configured to boot your application in Production mode.
If the environment is set correctly, the config/environments/#[RAILS_ENV}.rb file is correctly selected upon loading the app, and the correct database sources are selected from config/database.yml.

Rails apps default to development unless you set the RAILS_ENV variable to production. Git doesn't really factor in to this. On your production machine, you'll want to set RAILS_ENV.
Where to do this depends on your production deployment environment, and how your server is configured. Things like Passenger default to production mode, and configuring that depends on your server (Apache, nginx). If you're manually starting the server from the command line (via rails s thin or something along those lines), then you can configure it in your shell's startup file (.profile or something similar, depending on your shell). thin also optionally takes an environment argument like -e production.
If you provide more details on how your production environment works, you might get a more specific answer for where to set RAILS_ENV.

Related

How to run rails applications on digitalocean using "rails s" (make it a development environment)

My issue is that I created a droplet to develop Rails apps in digitalocean .
I used the one-click rails droplet. And now I want to create more rails apps than the default rails app in this droplet.
The issue here is that it comes installed with nginx/unicorn .. And they're always on with path of default rails project in their config files.
Now let's assume I created another rails app(file) and I want to run it using "rails s" instead of default rails app that is created by the droplet. How can I do it?
Note: I don't want to change the file path in configs each time I decide to try another app
PS: I tried stopping the service of unicorn/nginx one at a time and both of them in the same time to use "rail s" to run the app .. But it didn't work .. Web pages were not loading
I know it might be a question of a rookie. But I'm kinda new to these stuff and I'd appreciate it if anyone could help me.
If you run it with rails s on the server, chances are it will be running with Puma, or if you're on an older version of Rails, Webrick. Unicorn is not involved in that case because Rails is using its own default web server. If you see that 'rails s' is not running in the right environment, it may be because RAILS_ENV is being set in your shell profile. You can override that by doing:
RAILS_ENV=development rails s
To launch your console.
That being said, rails s runs on localhost:3000 by default - and in the case you described it would be running on DigitalOcean's localhost - not yours. In order to get to it from your local machine, you would need to set up some sort of reverse proxy to allow connections to DO to get served from localhost. This is what nginx is doing for you - it's facilitating a reverse proxy.
If you want do use your DO server as a development machine for a second rails app you have, you're going to have to create that new rails app on the server, then create the reverse proxy settings in nginx to direct to it, then finally create the unicorn settings to serve it. This is an uncommon way of developing though. I recommend using your local machine to develop, and setting up Capistrano or some other deploy tool to deploy it to DO instead. You'd still need to add the settings in nginx/unicorn for the second app, but it will save you headache down the road.

Ruby on rails : launch server with code reload

I'm using a server for testing my api. I use this command to launch the server :
rails s -p 3001 -e test -P 42342
I change the port to 3001, to not have a conflict with my dev server (on port 3000).
The thing is that when I change code, the server don't reload the code, I have to kill the server and relaunch.
Is there a parameters that I miss to launch my rails command ?
test is only designed for automated testing, with Rails running for a single test run. Since code should not be changing during a test case, it doesnt have many of the development mode features and is more like production in that regard. Its also intended to reset your database when running tests, which also doesnt seem to be your intention.
If you want (most) classes to auto-reload, always use the development environment.
If for some reason you need a different environment (more than just port, but different configs), you can look at creating a new environment, copying the configs for development (add new entries to config/environments/, config/database.yml, config/secrets.yml, and use as a group in the Gemfile.).

Rails 4 Change port number only for production environment

I found this question before:
How to change Rails 3 server default port in develoment?
However what I really want is to change my port number for the production environment only. I am using RoR 4. It would be very nice if I could type something on production.rbin config/environments. Is there a way to do that?
The answer in brief
The rails stack has your application and then the server that runs your application (aka the "application server"). This server could be webrick (not a good idea in production), thin, gunicorn, passenger etc etc.
You should be telling that server which port to run under. You'll (likely) need to specify this outside Rails - not in config/production.rb because by the time Rails boots it's already running inside some application server.
A deeper dive with an example:
Let's use Heroku for an example, because port numbers there are essentially randomized (at least from the view of us looking in).
Heroku will pick a random port for us, then tell us through the PORT environmental variable. With Heroku you need a Procfile to tell it what services to launch, and your Procfile may look something like this:
web: bundle exec unicorn -p $PORT -c ./config/unicorn.rb
See here, we use -p $PORT to tell unicorn - our application server in this example - to run on some port Heroku gave us.
Back to your question:
However you kick off your application serving process in your production environment, you should tell it to specify the port number to your web server. There's a bunch of ways to kick off your application serving process at a production level: from upstart (built into Ubuntu), to supervisord to god... all these methods run commands and make sure the process stays up (an important part of production level deployment ;) )

should I be using passenger in dev to match prod for a ruby on rails project?

Should I be using passenger in dev to match prod for a ruby on rails project? (as opposed Webrick)
Noting I'll be deploying to dreamhost which uses passenger.
(Also if yes, does it have it's own web-server or do I need to install one?)
Set up a passenger staging server on your production machine. Use same configuration as pro server.
This has just saved my bacon. A recent upgrade we recently pushed broke application and took me a week to get sorted. Fortunately production server continued to function which we found prob.
Use capistrano multistage to manage the same.
You don't have to (mostly). But there might be cases where things can go wrong due to the mismatch between production & dev environment. Using staging environment will catch such issues.
If you want to test things like SSL, then webrick wont work. You need apache/nginx(or other web servers) to use passenger. I also noticed that there is no significant difference in the performance between the two options

Deploying rails application to multiple environments

I am getting ready to deploy to a true production environment. When I say true I mean that my current production environment will now be staging because there is other crap on the server and I am creating a new larger slice for what will actually be my production machine.
The capistrano-ext gem has made separating the deploy recipes quite easy. However, one issue I run into is getting my code from one slice to another. I have a git repo set up on my staging slice that I will be using for production. The flow will be:
Develop locally
Test locally
Push from local to stage
Test on stage
Push from stage to production
...
Therefore I obviously need a way to establish a secure connection between staging and production. When deploying to production, I get a "Permission denied (publickey)." error because this is not set up. How can I establish this connection? Do I need to generate keys on my production server and put the public on my staging? How do I know what user on my production server is trying to connect to my staging server?
Branches and capistrano multistage are your friends.
To solve the production not having access to the git repo issue, try…
set :deploy_via, :copy
…this deploys by checking out locally, and pushing a tar ball.
I find that branching or version tagging works much better for differentiating staging vs. production when using Capistrano.
For example, set up a 'staging' and 'production' branch for your application and use your source control tools to manage migrating changes from one to the next. During deployment simply deploy as you usually would, but with a particular branch instead of the main one.
It's not necessary to promote directly from staging to production, and in fact, this may be considered a bad idea since anyone with access to the staging machine potentially has access to the production server. In most environments a staging server is treated much more casually than the production site, so the security profile is usually quite different.
Do I need to generate keys on my production server and put the public on my staging?
Yes.
How do I know what user on my production server is trying to connect to my staging server?
The productionuser will be whatever user you connect with (see :user). The staginguser will be from the git url (see :repository).
When you use
set :deploy_via, :remote_cache
(which is the default), two ssh connections are actually occurring. The first one is from your local machine to production, and it uses the 'user' as configured in your recipe.
set :user, 'www-data'
The second ssh connection is made by that user, on production, to your git origin. So if git origin is on staging, the production user is trying to connect back to staging to pull code from git.
set :repository, "staginguser#staging.com:project.git"
Try this: ssh to production as the user. Then run the failing command by hand. You'll see the "permission denied" and maybe a prompt for a password. Add the public key of the staging server user to the production box and things should work better.
There's also:
set :gateway, 'staging server ip'
which should allow you to tunnel all the way through to your firewalled production box. But if you're deploying from staging you need to set up keys on the staging box if you're going to go through it that way.
On a side note, it's important to be able to do this whole process from your home box, staging really shouldn't need to have a capistrano gem, the hope is that you can do the whole process without ever having to actually log into a server. That includes logging in to your staging server. :)
If there's an issue of data pushing between the two this could easily be added onto just the production config so that it automatically takes data from staging and rsync's it over.

Resources