Deployment
We first tried to deploy using capistrano, a tool for deploying web applications from a source code management to one or multiple servers.
We set up our deployment following those three guides :
- Deploying Rails 3 Apps with Git, Capistrano and Passenger
- Setup tutorial for a Rails with Git, Github, Capistrano, Ruby Enterprise, and Passenger
- Deploying Rails with Github, SSH keys, Capistrano, Apache, Passenger
After installing the capistrano gem, use :
capify .
within the repository, this will create the deploy.rb file that we configured as follows :
require 'bundler/capistrano'
default_run_options[:pty] = true # Must be set for the password prompt from git to work
# name of the application
set :application, "MyFM"
set :deploy_to, "/opt/rails/#{application}"
set :user, "appweb"
set :scm, :git
set :repository, "http://github.com/HE-Arc/MyFM.git"
set :branch, 'master'
role :web, "myfm.appweb.labinfo.eiaj.ch" # Your HTTP server, Apache/etc
role :app, "myfm.appweb.labinfo.eiaj.ch" # This may be the same as your `Web` server
role :db, "myfm.appweb.labinfo.eiaj.ch", :primary => true # This is where Rails migrations will run
# if you're still using the script/reaper helper you will need
# these http://github.com/rails/irs_process_scripts
# Passenger mod_rails
namespace :deploy do
task :start do ; end
task :stop do ; end
task :restart, :roles => :app, :except => { :no_release => true } do
run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
end
end
Sadly, our deployement with capistrano wasn't as smooth as in the first guide. We encountered lots of problems, mainly because of the school's proxy.
First, we put the ssh link address of our github repository in our deploy.rb file but this didn't work because the production server couldn't access through the ssh port. So instead, we decided to use the http link but we had to set a http_proxy environment variable and tell git to use that variable.
==>See the server configuration section below to solve proxies problems.
In order to test if Capistrano has enough rights to write files/folders onto the server, use the following command :
cap deploy:check
If not, change the appFolder to world-write persmissions
sudo chmod -R 777 appFolder
Then use :
cap deploy
And finally, set it back to normal persmissions with :
sudo chmod -R 755 appFolder
Since we were using the "appweb" user within our deploy.rb, there was no problem with that command. Off course, for later purposes, it would be more secure to add a deployment user on the production server and allow him to modify stuff only on the web application folder.
As we first encountered a lot of problems with the proxy server in our deployment with Capistrano, we decided to clone our git repo directly on the production server using the git's http protocol:
git clone http://github.com/HE-Arc/MyFM.git
This worked well but it just reported our proxy problem a bit further. Actually, the scrobbler API used to gather informations from LastFM was still not working.
http_proxy = http://proxy.he-arc.ch:8080
export http_proxy
https_proxy = http://proxy.he-arc.ch:8080
export https_proxy
git config --global http.proxy $http_proxy
Create a .gemrc file in home directory and add the proxy :
http_proxy: http://proxy_ip:proxy_port
If it is still not working, use :
gem install -p http://proxy_ip:proxy_port gemname
As we were having problems with the school's proxy not allowing our LastFM scrobbler gem to gather informations, we tried to solve the problem using Tsocks .
tsocks' role is to allow non SOCKS aware applications (e.g telnet, ssh, ftp etc) to use SOCKS without any modification. It does this by intercepting the calls that applications make to establish network connections and negotating them through a SOCKS server as necessary.
We installed Tsocks on the production server using:
sudo apt-get install tsocks
We then configured the "tsocks.conf" file as following:
We tested that our configuration was correct using the following command (which wasn't working previously):
tsocks git ls-remote [email protected]:HE-Arc/MyFM.git
and it worked.
As Phusion Passenger is an Apache module we had to find a way to start either the Passenger module and/or Apache using Tsocks.
We first tried to run tsocks passenger start but this just recompiled passenger and introduced errors. When we tried to access our application, we've had the following error :
To solve this, Mr. Mallaby did the following :
- Removed old logs files linked to innodb
- Added "skip-innodb" in the mysql configuration
- Rebooted mysql lots of time....
- Dropped and recreated the database
We then tried to run apache on tsocks but this didn't work neither.
In a desperate move to bypass the school's proxy for our scrobbler gem to work, we asked Mr. Schaefer for some help.
He first tried to set the preloads variables manually on the Apache server (this is what tsocks was supposed to do) but it appeared that the server clears those "variables" everytime.
Those variables were set in the /etc/apache2/sites-availables/default :
SetEnv LD_PRELOAD /usr/lib/libtsocks.so
SetEnv http_proxy http://proxy.he-arc.ch:8080/
His solution was to use a transparent proxy. This squid of his own intercept the requests from the production server before passing them to the school proxy.
In order to tell the server where the request as to route, he made a script (see more /root/tproxy.sh) which has to be run each time the production server boots.
Although this does not work with everything not on the port 80, it works pretty well for our scrobbler gem.
When we first deployed without Capistrano, we encountered problems with the mysql database. Apparently, downgrading the ruby version from 1.9.3 to 1.9.2p290 fixed the problem.