[ANN] Introducing SwitchTower: Distributed deployment for Rails
David Heinemeier Hansson
multiple machines. It lets you (among many other things) deploy
distributed applications with a single command.
When your application is young you may be deploying it to a single
machine, which runs the web server, app server, and database all
together. In this situation, deploying manually is not unbearably
painful. But as your application grows you may find yourself needing
to deploy your application to two web servers, four app servers, and
two database servers, atomically. This is where SwitchTower steps in
as a pain-killer.
*Getting Started*
Suppose you have an existing Rails application that you want to deploy
to a cluster of machines. SwitchTower attempts to make the entire
process as painless as possible:
* Install SwitchTower. This is as simple as @gem install switchtower@.
* Decorate your application with the necessary SwitchTower files. Just
do @switchtower --apply-to /path/to/your/app@.
* Tell SwitchTower where your application code sits and what machines
it should deploy to. Just edit @config/deploy.rb@ and fill in the
blanks.
* Set up your machines so they are ready to receive your application.
It's as easy as @rake remote_exec ACTION=setup@.
* Lastly, deploy your application! Just type @rake deploy@ and let the
good times roll.
*Other Capabilities*
In addition to simply moving your application to the various boxes,
SwitchTower attempts to make the task of maintaining your deployment
simpler. Suppose something goes wrong while checking out your
code--SwitchTower will detect that and roll back the change, _on all
deployed machines_. This means it is much harder to wind up with your
application out of sync on the various boxes.
Other things SwitchTower can do, out of the box:
* Database migrations on your production database
* Enable/disable the web interface (only works with Apache currently)
* Restart your application on the application servers
SwitchTower also makes it very simple to override and extend the
standard tasks, and to write your own. The tasks use a simple language
similar to Rake that allows you to automate many different tasks.
*More Information*
Want to know more about SwitchTower? There's an entire user manual
full of useful tidbits at http://manuals.rubyonrails.com/read/book/17.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework
Peña, Botp
#SwitchTower is a utility for executing commands in parallel on
#multiple machines. It lets you (among many other things) deploy
#distributed applications with a single command.
#
#When your application is young you may be deploying it to a single
#machine, which runs the web server, app server, and database all
#together. In this situation, deploying manually is not unbearably
#painful. But as your application grows you may find yourself needing
#to deploy your application to two web servers, four app servers, and
#two database servers, atomically. This is where SwitchTower steps in
#as a pain-killer.
..
i'm a nuby on rails/ruby/web and i've played w your magical rails framework. It is really amazing. My q is: Assumming i just have the sample rails running on one host, and i want it to raise to 3 tiers on 3 hosts (web, app, db), would switchtower take care of the division by just pointing what host to put the web to, the app to, and the db to? The reason i am asking is that i do _not_ know anything about the application layer part (since i just see the rails app as just one coherent stand alone application) and i want to see what is the application layer side, the web side, and the db side.
sorry for the dumb newbie question.
thanks for rails and kind regards -botp
Jamis Buck
> David Heinemeier Hansson [mailto:david.he...@gmail.com] :
>
> #SwitchTower is a utility for executing commands in parallel on
> #multiple machines. It lets you (among many other things) deploy
> #distributed applications with a single command.
> #
> #When your application is young you may be deploying it to a single
> #machine, which runs the web server, app server, and database all
> #together. In this situation, deploying manually is not unbearably
> #painful. But as your application grows you may find yourself needing
> #to deploy your application to two web servers, four app servers, and
> #two database servers, atomically. This is where SwitchTower steps in
> #as a pain-killer.
> ...
>
>
> i'm a nuby on rails/ruby/web and i've played w your magical rails
> framework. It is really amazing. My q is: Assumming i just have the
> sample rails running on one host, and i want it to raise to 3 tiers
> on 3 hosts (web, app, db), would switchtower take care of the
> division by just pointing what host to put the web to, the app to,
> and the db to? The reason i am asking is that i do _not_ know
> anything about the application layer part (since i just see the
> rails app as just one coherent stand alone application) and i want
> to see what is the application layer side, the web side, and the db
> side.
The difference between the "web" and "application" layers are this:
the "web" layer is simply the web server (without anything rails-
specific) and the "application" layer is (for instance) the set of
FCGI listeners. Using lighttpd (or getting clever with apache/
haproxy) you can have multiple stand-alone FCGI listeners running on
one machine, with the web server running on another machine and
sending the requests to the listeners.
You can use the spawn-fcgi utility (it comes with lighttpd, but it
isn't lighttpd-specific) to launch new FastCGI listeners. To make
things simple, you can use the spinner and spawner utilities that
come with Rails (and which wrap the spawn-fcgi utility). Check out
the SwitchTower manual for info on how to use these.
As for configuring lighttpd and apache to communicate with
independently spawned fastcgi listeners, you'll need to check out the
docs for those.
It definitely isn't as simple configuring a setup like this as it is
to just let the web server manage the listeners, but it scales much
further. That said--don't try scaling before you need it. Keep things
as simple as possible, for as long as possible, and you'll save
yourself a lot of grief in the long run.
- Jamis
Peña, Botp
#The difference between the "web" and "application" layers are this:
#the "web" layer is simply the web server (without anything rails-
#specific) and the "application" layer is (for instance) the set of
#FCGI listeners. Using lighttpd (or getting clever with apache/
#haproxy) you can have multiple stand-alone FCGI listeners running on
#one machine, with the web server running on another machine and
#sending the requests to the listeners.
thanks Jamis. That gives me a clearer/more specific view.
i used to (naively) view it like this:
web [top]- web server stuff
app [mid]- stuff not of the above and not of below but controls them
db [bot]- db stuff
:-)
#You can use the spawn-fcgi utility (it comes with lighttpd, but it
#isn't lighttpd-specific) to launch new FastCGI listeners. To make
#things simple, you can use the spinner and spawner utilities that
#come with Rails (and which wrap the spawn-fcgi utility). Check out
#the SwitchTower manual for info on how to use these.
great you mention lighttpd. I'm having difficulty getting it thru debian's apt. Seems like debian people are not interested in lighttpd :-(
#As for configuring lighttpd and apache to communicate with
#independently spawned fastcgi listeners, you'll need to check out the
#docs for those.
#
#It definitely isn't as simple configuring a setup like this as it is
#to just let the web server manage the listeners, but it scales much
#further. That said--don't try scaling before you need it. Keep things
#as simple as possible, for as long as possible, and you'll save
#yourself a lot of grief in the long run.
#
great advice.
Thanks much and kind regards -botp
#- Jamis
#