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 <bassnode@gmail.com> wrote:> > 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060721/4e6c2059/attachment.html
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 Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/> <tel:+1-415-233-1000>
On Jul 21, 2006, at 9:02 AM, Pratik wrote:
> 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 <bassnode@gmail.com> wrote:
> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060721/796747d8/attachment.html
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. On 7/21/06, Pratik <pratiknaik@gmail.com> wrote:> 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 <bassnode@gmail.com> wrote: > > > 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > 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
On Jul 21, 2006, at 10:09 AM, Dan Kohn 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 Mornini
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 -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Tom Mornini Sent: Friday, July 21, 2006 12:13 PM To: rails@lists.rubyonrails.org Subject: Re: [Rails] multi-server rails deployment On Jul 21, 2006, at 10:09 AM, Dan Kohn 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 Mornini _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
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 Kohn wrote: >Also, why bother with fancy DNS-based authentication? Won''t ausername 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.
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 <bassnode@gmail.com> wrote:> 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 Kohn 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. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > 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
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 7/21/06, Pratik <pratiknaik@gmail.com> wrote:> 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 <bassnode@gmail.com> wrote: > > 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 Kohn 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. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > 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 >
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 Mornini