Following on from part 3 you should now have your Rails application nicely hosted and deployed using Capistrano from your SVN repository. All good – but what happens when you want to serve another public web folder into the mix e.g. in public/myfolder, but you DON’T want it under version control ? Why you ask ?
Well lets take this example further, what if this folder contained a copy of the Mint stats package in public/mint – i.e. PHP code, that you wanted to execute and run. Since new versions of Mint are released fequently, and i’m often adding and removing ‘Peppers’ (read Mint Plugins), I see no need to put Mint under version control. Purists might argue differently, but I dont collect stats on my local dev box either so it makes no sense to have it there after a checkout.
Assuming your convinced I’ll start off getting Mint up and running on the server, with PHP through Lighttpd and stats being recorded. Then i’ll add some extra functions to the Capistrano deployment, allowing us to deploy ‘around’ this folder on the public server.
Configuring Lighttpd with PHP and FastCGI
First ensure your server already has PHP installed and is configured with the FastCGI module;
$> php -v
PHP 5.1.4 (cgi-fcgi) (built: Aug 2 2006 23:53:20)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
If you dont see the (cgi-fcgi) part, then you’ll need to re-configure PHP with the FastCGI module. There are instructions for installing PHP and configuring modules at PHP.net – and elsewhere on the web – Google is your friend.
Now configure your config/lighttpd.conf file (do this locally on your dev machine, checkin to SVN and redeploy – or just edit on the server to get things working then apply the same changes locally, checkin & deploy), in config/lighttpd.conf;
server.modules = ( "mod_rewrite", "mod_accesslog", "mod_fastcgi", "mod_compress", "mod_expire", "mod_proxy" )
fastcgi.server = (".php" => ("127.0.0.1" =>
("socket" => CWD + "/tmp/sockets/php.socket",
"bin-path" => "/usr/local/bin/php",
"bin-environment" => ("PHP_FCGI_CHILDREN" => "1", "PHP_FCGI_MAX_REQUESTS" => "5000")
))
)
# lighttpd proxy server (pound) - no proxy for mint please
$HTTP["url"] !~ "^/mint/" {
proxy.balance = "fair"
proxy.server = ( "/" => ( ( "host" => "127.0.0.1", "port" => 6000 ) ) )
}
Things to note here are;
- Add mod_fastcgi to your server.modules if its not there already.
- fastcgi.server is configured with your server’s PHP bin path, and a tmp socket (which can be anywhere).
- We DON’T want to proxy requests for Mint through Pound to Mongrel – since this is a PHP app, we just want Lighttpd to deal with it using FastCGI – hence the need for the if statement on the pound proxy configuration.
Setting up Mint (e.g. in Typo)
First grab your licensed copy of Mint for your domain – and drop the mint/ folder into current/public/mint to the main Rails directory on your server. Next add the following url.rewrite to your lighttpd configuration;
# configure for mint access
url.rewrite = ("^/mint/$" => "/mint/index.php", "^/mint/\?(.*)" => "/mint/index.php?$1")
This url.rewrite is nessecary to ensure that Lighttpd doesnt treat files or folders under /mint/ as Rails specific. Again this should also be added in your local copy, and checked in to SVN. DON’T deploy with Capistrano just yet – because doing so will check out a new release and archive the existing current/ folder (and hence remove our /current/public/mint) – You’ll also want to add the following javascript in the header of any page where stats should be reported;
<script src="/mint/?js" type="text/javascript"></script>
Setting up Capistrano
In order to keep using Capistrano to deploy to your server with mint in the current/public/mint folder – we need to deploy around it. There are probably better ways to do this – in the Capistrano deployment recipe file (config/deploy.rb) – I added two action functions; one occurs before deployment starts, the other after. The functions basically move the mint/ folder out of the way (to the top level shared folder) while Capistrano does its stuff. So in config/deploy.rb;
# executed before deployment
task :before_deploy, :roles => [:web, :app] do
# copy the mint/ and files/ folders to holding area in shared/
puts "before deploy ---> copy mint and files to shared from current"
run "sudo mv #{deploy_to}/#{current_dir}/public/mint #{shared_dir}/mint"
run "sudo mv #{deploy_to}/#{current_dir}/public/files #{shared_dir}/files"
end
# executed after deployment
task :after_deploy, :roles => [:web, :app] do
# copy the mint/ and files/ folders back from holding area in shared/
puts "after deploy ---> copy mint and files from shared to current"
run "sudo mv #{shared_dir}/mint #{deploy_to}/#{current_dir}/public/mint"
run "sudo mv #{shared_dir}/files #{deploy_to}/#{current_dir}/public/files"
end
You’ll also see i’m doing the same thing for a current/public/files folder – This folder is used by Typo for uploaded files for blog entries. Without these actions in place, each Capistrano deploy would clear out the files/ folder on your server.
Trying it out
Check the changes in, make sure the mint folder is on your server (and correctly configured) and run a new Capistrano deploy. During this you should see the before and after tasks running (you may will be asked for a password to sudo). You should then see your copy of mint up and running, like so; /mint/
Thus ends the mini-guide; Any suggestions, comments or questions are appreciated. Normal useless entries will resume here as of today.
References
8 comments so far
David Rice Aug 18, 2006
Matt,
Why not keep mint in the shared directory and in your after deploy, create a symbolic link from the public folder in your rails app to the mint directory in shared.
I’m doing this with a couple of sites at the minute (not with mint though, but i’ll probably be updating my blog to do this soon)
run "ln -nfs #{deploy_to}shared/mint #{release_path}/public/mint" </code
Matt Aug 18, 2006
Thanks, I’ll try that, but I think I’d still have to deploy around the Typo public/files directory in this way.
I’ll give the symbolic link a try and see how it goes.
Jonathan Aug 20, 2006
I did it with symlinks for various projects and found it was a more convenient solution than move, especially when those directories, you want to keep out of svn, weight a few gigabyte.
Jon Maddox Aug 20, 2006
Yeah, I’d go with the symlink method, and add it to your after_symlink task. I do this all the time for deployed sites for file_column asset folders, and anything else i need to keep between deploys. I love this little trick.
For what its worth, I used a subdomain on my site to host mint. That way I could just use a seperate vhost to define how it was served. Its working out nice, but i like the idea of dumping it under the shared/ directory.
Matt Aug 21, 2006
Ive now switched to symlinking both the files/ and mint/ folders in the after_deploy task, which works much better;
So you can ignore my convoluted instructions in the tutorial for moving the folders in and out of the public/ and shared/ directories; Hope this article is still of some use to people trying to get PHP working under Lighttpd.
Aníbal Rojas Aug 22, 2006
I tried to leave this commen in a previous post, but it look like it is closed for comments:
Wow! This is a great tutorial, a friend is trying to get me to experiment with Cherokee, instead of Lighty (he’s a Cherokee devl ;-) Take a look at this nice and small web server at: www.0×50.org
Off Topic: This is just a quick note to invite you to register at RubyCorner.com, a meeting place for people interested in the Ruby Programming Language or any of the related technologies.
Meekish Aug 25, 2006
Thank you for all the help!
Init scripts for Lighttpd, Mongrel, and Pound are definitely essential. I would venture to say that a post covering those is a needed addition to make this guide complete.
Also, seeing as how I will have my own VPS, I will probably want to have a bunch of VHOSTS, each with their own mongrel cluster. What would the POUND config look like for this?
Would there be multiple ListenHTTP tags like so?
Now I just need to combine your guide with this guide and I should be all set :)
Thanks again!
Matt Aug 25, 2006
I had been thinking of a Part 5 to this series, covering how to setup your server for multiple VHOSTS under the same hosting stack. The reason I havent done it is because I simply havent had time to set it up myself yet. When I do – I write up the process here. And your right showing the init.d scripts would help so i’ll include that in the next part too.