I’m building an app in rails that will be deployed on 3 different
servers but am not sure the best way to deploy it. The app is
something like Google Adwords (an online advertising program,
essentially).
ServerA is the Administration server
ServerB is the Ad server (feeds ad requests to affiliates)
ServerC is the Click server (handles incoming clicks from our affiliate
sites)
All 3 servers will use the same database cluster.
I have been building the app under one rails app directory because the
different parts depend on each other. For instance, the Admin code
depends on classes in the Click code which depends on the Ads code…
These dependencies have left me confused about the best way to deploy.
My initial thought was to just deploy the complete app to all 3
servers and whatever code gets used, gets used. Since they are all on
the same database cluster, you ostensively could use any part of the
code on any of the servers; it’s all controlled by how we drive the
specific traffic to the servers (via DNS/domainnames).
Anyone see problems with this? Is there a better way? Maybe
something fancy with Capistrano, et al?
Thanks,
Ed
What you can probably do is, have a different routing file for different
servers.
For example, administrator server can have a file that reads something
like
:
map.connect ‘:action/:id’, :controller => ‘admin’
-Pratik
On 7/21/06, Ed Hickey [email protected] wrote:
specific traffic to the servers (via DNS/domainnames).
–
rm -rf / 2>/dev/null - http://null.in
“Things do not happen. Things are made to happen.” - JFK
I suspect you’ll be much better off deploying the identical app to
all 3 servers. More homogeneity means less moving parts and less
things breaking. You also get redundancy so that things keep working
normally if one (or even two) of your servers go down.
Also, why bother with fancy DNS-based authentication? Won’t a
username and password to login to the admin portion of the site be
enough (with SSL if necessary)? That said, you will certainly want
to use a different server process to serve out static ad images from
the one running your rails apps. But that is standard anyway.
- dan
–
Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000
thanks, that would definitely help for restricting certain areas, but
all the code would still be deployed to all 3 servers. that part just
seemed a little sketchy to me…safer, but seemingly uneccessary.
I agree as well
You may want to look at fossilize plugin
It generates a gem off your rails app…
Then you can redploy it again and again
On Jul 21, 2006, at 10:09 AM, Dan K. wrote:
I suspect you’ll be much better off deploying the identical app to
all 3 servers. More homogeneity means less moving parts and less
things breaking. You also get redundancy so that things keep
working normally if one (or even two) of your servers go down.
+1
–
– Tom M.
I didn’t mean to insinuate we were using DNS-based auth. I just meant
that the click servers will be available at click.domain.com, the
admin server at admin.domain.com, etc. So, essentially, we have
control over which servers people visit for which task.
As far as the images, we plan on using Apache for images (and other
statics) and Mongrel for the rails apps.
thanks for all the feedback. deploying the same code to all 3 servers
does seem like the best way. less work, less chance of problems.
ed
Dan K. wrote:
Also, why bother with fancy DNS-based authentication? Won’t a
username and password >to login to the admin portion of the site be
enough (with SSL if necessary)? That said, you >will certainly want
to use a different server process to serve out static ad images from
the >one running your rails apps. But that is standard anyway.
well, the servers aren’t really tied together in a sense that i’d need
to load balance them. they won’t share the same traffic. they won’t
even know about each other. the only thing they will share is the
database.
i will probably just deploy the complete rails app to all 3 servers
though.
thanks for all the input.
ed
On Jul 21, 2006, at 2:44 PM, Ed Hickey wrote:
well, the servers aren’t really tied together in a sense that i’d need
to load balance them. they won’t share the same traffic. they won’t
even know about each other. the only thing they will share is the
database.
i will probably just deploy the complete rails app to all 3 servers
though.
Why would you take this route?
Deploy the entire app to all three servers, and distribute all hits
to all
three servers via load balancing.
Doing this makes maximum use of your hardware and gives you the most
reliable
environment as well.
To have the luxury of three servers, and then segregate specific traffic
types for (what appears to be) arbitrary reasons would be a really
unfortunate
decision.
–
– Tom M.
Why can’t you just deploy entire application on all 3 servers and do
load balancing ? That’d be good for long run I feel.
-Pratik
On 7/22/06, Ed Hickey [email protected] wrote:
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
rm -rf / 2>/dev/null - http://null.in
“Things do not happen. Things are made to happen.” - JFK