Skip to content
This repository has been archived by the owner on Apr 23, 2019. It is now read-only.

Staging Environment Setup For Chef and Rails? #144

Open
conradwt opened this issue Nov 15, 2014 · 5 comments
Open

Staging Environment Setup For Chef and Rails? #144

conradwt opened this issue Nov 15, 2014 · 5 comments

Comments

@conradwt
Copy link

I noticed that a staging.rb was created within the following location:

/path/to/rails/app/config/deploy/staging.rb

Thus, I'm guessing that it's necessary to add a staging entry to the host.json by doing the following:

"active_applications": {
    "example_production": {
        "rails_env": "production"
        ...
    },
   "example_staging": {
      "rails_env": "staging"
      ...
    }
}

Next, should environment specific deployment configuration be moved from config/deploy.rb to their respective locations:

/path/to/rails/app/config/deploy/staging.rb
/path/to/rails/app/config/deploy/production.rb

For example, deploy_to which will be different for each environment because I would prefer using the following for staging:

set :deploy_to, '/u/apps/example_staging'

Lastly, I'm guessing that it's necessary to add a staging.rb to the rails config/environments directory. Then one can deploy and access the staging environment by doing the following:

$ bundle exec cap staging deploy
$ open http://www.example.com:2222
@michiels
Copy link
Member

Hey @conradwt. You are completely correct.

Did you try this and did it work out for you?

Michiel

@ghost ghost self-assigned this Nov 25, 2014
@ghost
Copy link

ghost commented Nov 26, 2014

Hello @conradwt

That staging.rb is initially created by Capistrano install script, and it should be nearly identical to production.rb. The main reason of why you might need a staging or pre-production server is because there are too many differences between the development and production environments like SSL, assets, or how HTTP and Rails servers are different too. Or perhaps you want to test newest migrations, tasks or scripts right before they go to production.

So if you use staging for this purpose you'll probably need it to be started with production environment settings (just to make sure your staging is as close as possible to the production instance) and there is no need to create another environment config.

Finally, deploy/staging.rb and deploy/production.rb are not used on production or staging. These are just some config files needed to run Capistrano tasks locally.

@conradwt
Copy link
Author

@oiuzikov deploy/staging.rb and deploy/production.rb are being used to configure the settings for the particular environment on deploy. For example, I moved the deploy_to setting to the particular environments (i.e. deploy/production.rb and deploy/staging.rb). Otherwise, if deploy_to setting is defined within the deploy.rb which is the current default, a deploy to staging will override your production environment by creating another directory and symbolic linking to the current directory. In short, I need to staging server to both test new code and allow the client to preview updates.

@conradwt
Copy link
Author

@michiels I'm seeing the following issue when I try deploy to the production server:

[173bfdec]  rake aborted!
DEBUG[173bfdec]     
DEBUG[173bfdec]     PG::ConnectionBad: FATAL:  password authentication failed for user "deploy"
DEBUG[173bfdec]     
DEBUG[173bfdec]     FATAL:  password authentication failed for user "deploy"

Next, I have the following within my runlist:

 "run_list":["role[postgresql]","role[rails_passenger]"],

Do I need to update to the new sample_host.json structure because it has changed from the time that I had created my version of it?

@conradwt
Copy link
Author

conradwt commented Dec 9, 2014

OK, I was able to resolve the issue, "PG::ConnectionBad: FATAL: password authentication failed for user "deploy" that I'm was seeing when using "bundle exec cap production deploy" by doing the following after provisioning the server:

In the file, /etc/postgresql/9.3/main/pg_hba.conf, on the provisioned server:

from:

host    all             all             127.0.0.1/32            md5

to:

host    all             all             127.0.0.1/32            trust

Next, I updated the runlist to look like the following:

"run_list": [ "recipe[postgresql::server]", "role[rails_passenger]", "role[sysadmins]" ],

Furthermore, I made sure that deploy user and the database owner were using the same username and password. I'm not sure if this correct way of doing things but it's working now. Finally, after deploying to staging and navigating to the site at www.example.com:2222 or example.com:2222 doesn't bring up the site.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants