When ever you deploy a new rails app with an Apache/Mongrel_Cluster setup, you have to setup a bunch of configuration files, symlink those to the right places so apache and mongrel cluster pick them up, restart those, figure out why it didn't work the first time, and on and on. What you can't do is just drop some files into a directory and expect your site to start working... Maybe Litespeed lets you do this, who knows.. :) --- Here's an idea for an automatic rails deployment system, lets hypothetically call it dog_walker (get it? mongrel?! har har...): It would consist daemon process that monitors a rails "apps" directory. If a new sub-directory comes into existance and has the appropriate config file, say app_name/config/dog_walker.yml, it picks it up, assigns it one or more ports to run mongrels, and starts them up. It also modifies and reloads Apache (or lighttpd/nginx, whatever the front-end proxy is) with a new virtual host, and bam, your site is up! Each site's dog_walker.yml could look something like: --- environment: production nbr_mongrels: 3 server_name: www.mysweetrailsapp.com dog_walker itself would probably also need one main config file, something like: --- apps_dir: /home/username/rails_apps proxy_server: apache apache_conf_dir: /etc/httpd/conf.d port_range_start: 3500 port_range_end: 4000 dog_walker could manage for you which ports get assigned to which apps and all that junk, and create the appropriate .conf files for apache, and then restart/reload it so it starts serving your app. just an idea at the moment... -- Scott B. Electro Interactive, Inc. Office: 813-333-5508 Web - http://www.ElectroInteractive.com Blog - http://synthesis.sbecker.net
on 2007-01-25 00:02
on 2007-01-25 00:58
Scott B. wrote: > > > --- > just an idea at the moment... I have some thoughts on this. I think there should be an API to talk to the hosting environment. So say you have a account that you want to deploy a rails app to that has no setup done for it other than username/password/homedirectory. I think it should be possible to create a system so that all you need to do is configure the address of where you connect to your hosting provider, and the username/password. The API takes care of asking the hosting environment to setup things like DNS, virtual hosts, ports, IP addresses, email accounts, etc. On the hosting environment side they can have various different setups but the person deploying the app doesn't need to know the specifics of those for most simple setups, and may not care so long as it works. I've experimented in the last week with building pound config files from templates with simple search/replace, and doing this for other types of config files should be similarly easy though I would prefer a more dynamic setup. With apache it should be possible to update a live system with libapache rather than writing out a config file, and reloading. I know there is a patch to bind to make it dynamically load new zones, and it should be possible to patch any open source server to give it similar functionality if someone hasn't already. With an API like this it would be possible to not just easily deploy apps to many different providers with ease, but have the user interface for things like adding domains, subdomains, and email addresses be part of the app you deploy rather than some disconnected system. This way you can have a consistent user interface no matter who you choose for your hosting provider. -- Daniel J. Systems Administrator PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting www.planetargon.com daniel.planetargon.us +1 503 445 2457 +1 877 55 ARGON [toll free] +1 815 642 4968 [fax]
on 2007-01-25 01:32
> When ever you deploy a new rails app with an Apache/Mongrel_Cluster > setup, you have to setup a bunch of configuration files, symlink those > to the right places so apache and mongrel cluster pick them up, restart > those, figure out why it didn't work the first time, and on and on. > > What you can't do is just drop some files into a directory and expect > your site to start working... Maybe Litespeed lets you do this, who > knows.. :) Sort of... using their virtual templates you can come pretty close. Upload your app and tell lightspeed to associate it (file system path, domain name) with the rails virtual template. graceful restart.
on 2007-01-25 01:55
On Jan 24, 5:01 pm, "Scott B." <email@example.com> wrote: > When ever you deploy a new rails app with an Apache/Mongrel_Cluster > setup, you have to setup a bunch of configuration files, symlink those > to the right places so apache and mongrel cluster pick them up, restart > those, figure out why it didn't work the first time, and on and on. The railsmachine gem provides a good base for configuring a new rails site for deployment. I employ everyone to take a look at the gem. Maybe you could bake something up that would work better for your site using the gem as a base.  https://support.railsmachine.com/index.php?pg=kb.p...
on 2007-01-25 02:05
On Jan 24, 6:53 pm, "bryanl" <firstname.lastname@example.org> wrote: > https://support.railsmachine.com/index.php?pg=kb.p... I actually do use a derivative of that railsmachine stuff. It's based on the slingshot rails apache2.2/mongrel cluster deployment script, which you can get here: http://www.slingshothosting.com/files/apache2_2_mo... That'll go and create the apache conf files, the mongrel cluster files, etc, when you run "cap remote:deploy". Which is kinda cool, but I still like the idea of a daemon process watching a rails apps folder and handling all that for you so you don't even need to think about it. You wouldn't have to care what ports mongrel are running on, etc. - Scott
on 2007-01-25 14:34
On 1/24/07, Daniel J. <email@example.com> wrote: > I have some thoughts on this. I think there should be an API to talk to > the hosting environment. Our control panel that Ezra is writing (temporarily stalled so he can complete his book!) is fully accessible via ActiveResource. All tasks will eventually have a programmatic interface, including user managment, email setup, DNS configuration, environment setup, and even deployment of specific application packages (Subversion URL + revision, gems and versions, etc) into those environments. We believe this will be a big hit, once it's available(!), with application developers who resell our hosting service.
on 2007-01-25 23:36
Well I can't quite offer you that, but I've got a tenant depoyment down to cap -s user=tenant1 make_tenant That creates a separate user context and user database, handles all the security nonsense and makes the application available, as if by magic, on 'http://tenant1.yourdomain/ It also automatically handles SSL. If you have the apache module loaded it forces HTTPS and if you don't it uses HTTP. The form of SSL used means that you only need a certificate for 'yourdomain' not a wildcard one. No releases at the moment, but you are welcome to look at the GPL'ed Capistrano code at http://rubyforge.org/projects/multi-tenant Any feedback or encouragement appreciated. Questions on the associated forum if you like, or here if you prefer. NeilW
on 2007-01-26 19:39
Hey Neil, I don't see any files at http://rubyforge.org/projects/multi-tenant ? - Scott
on 2007-01-26 20:06
Since he said there were no releases, I checked the subversion repository and noticed they were there. Regards, Sean