We finally have everything up and running... at least the basics. However, we needed something more, such as starting/stopping/restarting our other servers. This was easily achieved using our own custom tasks in deploy.rb.
However, there was one odd one, which was backgrounDRb. To start the server, you must use:
./script/backgroundrb start -e production
The first problem we encountered was that after Capistrano had finished executing, the backgrounDRb daemon would disappear. After some research, an easy fix was found, which was to run the script through the nohup function:
nohup ./script/backgroundrb start -e production
This enabled backgroundrb to exist after Capistrano was complete. There was also another oddity that I found through research which I also implemented, which was to cd to the root directory before executing the script:
cd path/to/root && nohup ./script/backgroundrb start -e production
I never tested whether or not I could run the script without cd-ing... but the above command works for me without a problem, so why fix something that's not broken?
Next came environment problems. Backgroundrb was, for some odd reason, accessing the database in the development environment. However, I was clearly running the script in production!
Looking through the code, I realized that in bdrb_config.rb, it was setting the ENV["RAIL_ENV"] using the -e flag (which I stated production). However, when the master and meta workers were initialized, they were loading the rails environment without checking the ENV["RAILS_ENV"]. They were using the config file instead!
To fix this problem, simply change line 262 of master_worker.rb and line 350 of meta_worker.rb from:
run_env = CONFIG_FILE[:backgroundrb][:environment] || 'development'
to:
run_env = ENV["RAILS_ENV"] || CONFIG_FILE[:backgroundrb][:environment] || 'development'
This should check all the possible places that the environment could have been set and now everything should be running in the production environment!
Hope this helps anyone that was just as stumped as I was!
W
Showing posts with label Deployment. Show all posts
Showing posts with label Deployment. Show all posts
Saturday, May 3, 2008
Monday, April 28, 2008
Deployment: Part 2
As I mentioned in the last post, we got past SVN.
We finally came to Mongrel Cluster. This was a major headache. Apparently, Capistrano is broken when it comes to handling Mongrel Cluster. Simply following the Capistrano's site tutorial will not work.
The first step around this was to get the Palm Tree gem on the local machine:
>sudo gem install palmtree
This will include some recipes that we can use with our deploy.rb that you need to run Capistrano.
Next, add this to the top:
require 'palmtree/recipes/mongrel_cluster'
This will include the recipe needed to fix the deployment scripts. Basically, it rewrites the deploy script that comes with Capistrano. All you really need to know is that it works ;)
Next, generate a mongrel_cluster.yml by following the "Mongrel Cluster Setup" in this wiki. Check this into your repository as we'll need it.
Add this line to your deploy.rb:
set :mongrel_conf, "root_of_the_app/config/mongrel_cluster.yml"
Last thing we need to add is to tell Capistrano not to use sudo:
set :use_sudo, false
When all this is finally done, make sure that everything is in your repository. We can now attemtp a deploy:
cap deploy:cold
Make sure you use cold, as this should be the first time you're deploying. A deploy:cold is different than a simple deploy because it assumes that your servers are not running yet. Hopefully everything went right here. This should get you past Mongrel Cluster.
The next would be take a look at how to customize your deploy, such as starting other servers that you would potentially need.
We found the "after_stop", "after_start", and "after_restart" helpful for handling our other servers. Make sure that you put them in the deploy namespace ;)
Good luck!
W
We finally came to Mongrel Cluster. This was a major headache. Apparently, Capistrano is broken when it comes to handling Mongrel Cluster. Simply following the Capistrano's site tutorial will not work.
The first step around this was to get the Palm Tree gem on the local machine:
>sudo gem install palmtree
This will include some recipes that we can use with our deploy.rb that you need to run Capistrano.
Next, add this to the top:
require 'palmtree/recipes/mongrel_cluster'
This will include the recipe needed to fix the deployment scripts. Basically, it rewrites the deploy script that comes with Capistrano. All you really need to know is that it works ;)
Next, generate a mongrel_cluster.yml by following the "Mongrel Cluster Setup" in this wiki. Check this into your repository as we'll need it.
Add this line to your deploy.rb:
set :mongrel_conf, "root_of_the_app/config/mongrel_cluster.yml"
Last thing we need to add is to tell Capistrano not to use sudo:
set :use_sudo, false
When all this is finally done, make sure that everything is in your repository. We can now attemtp a deploy:
cap deploy:cold
Make sure you use cold, as this should be the first time you're deploying. A deploy:cold is different than a simple deploy because it assumes that your servers are not running yet. Hopefully everything went right here. This should get you past Mongrel Cluster.
The next would be take a look at how to customize your deploy, such as starting other servers that you would potentially need.
We found the "after_stop", "after_start", and "after_restart" helpful for handling our other servers. Make sure that you put them in the deploy namespace ;)
Good luck!
W
Saturday, April 26, 2008
Deployment: Part 1
So we're nearing the stage of our deployment and decided to perform a dry run on J's spare computer. We installed the Ubuntu server on his machine, along with all the stuff we needed (SSH, Ruby, Rails, gems, etc.)
We then decided to go with Ubuntu server + Apache + Mongrel Cluster + Capistrano for an action-packed deployment. We decided on Ubuntu since we have had such a good impression with them and have had experience with troubleshooting on an Ubuntu machine. Apache + Mongrel Cluster seems to be a fast-growing standard, although there are many configurations to choose from. We had been doing research and found that this configuration would be the most painless. As well, this configuration is supposed to handle very well. We used Capistrano to help with our deployment and to make maintenance much easier when deploying on a remote server.
Basically, the whole setup revolved around Capistrano. So... off we went to figure out how to use it. This took us a very long time as we had to troubleshoot some problems.
The first problem that was not even mentioned on the Capistrano site was logging into the remote server with a particular username. In the examples, they simply say to just use:
role :app, my.server.com
However, this will log you into the remote server with the username you have with the local machine. This is not what we wanted, so we ended up having to attach the username in front:
role :app, username@my.server.com
Next, when the server was trying to checkout our repository from SVN, it crapped out. We added this to our deploy.rb to get around this:
default_run_options[:pty] => true
Now, our deploy ran fine, until we got to Mongrel Cluster T.T
Hopefully this will get you out of the rough, unless you're using Mongrel Cluster, which I'll cover in the next post.
W
We then decided to go with Ubuntu server + Apache + Mongrel Cluster + Capistrano for an action-packed deployment. We decided on Ubuntu since we have had such a good impression with them and have had experience with troubleshooting on an Ubuntu machine. Apache + Mongrel Cluster seems to be a fast-growing standard, although there are many configurations to choose from. We had been doing research and found that this configuration would be the most painless. As well, this configuration is supposed to handle very well. We used Capistrano to help with our deployment and to make maintenance much easier when deploying on a remote server.
Basically, the whole setup revolved around Capistrano. So... off we went to figure out how to use it. This took us a very long time as we had to troubleshoot some problems.
The first problem that was not even mentioned on the Capistrano site was logging into the remote server with a particular username. In the examples, they simply say to just use:
role :app, my.server.com
However, this will log you into the remote server with the username you have with the local machine. This is not what we wanted, so we ended up having to attach the username in front:
role :app, username@my.server.com
Next, when the server was trying to checkout our repository from SVN, it crapped out. We added this to our deploy.rb to get around this:
default_run_options[:pty] => true
Now, our deploy ran fine, until we got to Mongrel Cluster T.T
Hopefully this will get you out of the rough, unless you're using Mongrel Cluster, which I'll cover in the next post.
W
Subscribe to:
Posts (Atom)