Forum: Ruby on Rails Multple domains, same application, different CSS, some over-rides

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
icke (Guest)
on 2008-11-26 13:56
(Received via mailing list)
I am building a site that will have several different branded
versions of the same site in order to do some SEO coverage.  e.g
www.foo.com,
www.foo.co.uk and www.bar.com

There are many discussions on sub-domains but I would like to come up
with a solution to support the following:
1. multiple domains supported as virtual hosts on Apache acting as a
proxy where I anticipate Rewrites to do maintenance pages, pick up
cached pages etc.
2. Use Mongrels as the app server but they will access the same back-
end Rails app running against the same database.
3. pick up the domain from the http header which will be used to
determine which CSS to use, affiliate-id and where to store cached
files from sort of look-up.
4. User only ever sees parameters in the url without any domain-
specific information included i.e. www.foo.co.uk/quote/read not
www.foo.co.uk/foo/quote/read
5. The session data will be domain specific.
6. Ability to over-ride views and come action controller classes by
domain if necessary.

I am a little confused about routes.rb, apache rewrites and some of
the available plug-ins.  So for example, where should I parse the http
header?

I would be grateful if someone could let me know if I am thinking
about this in completely the wrong way.  If not, are there any good
information sources I should refer to?  Should I post this to the
depolyment list?

Thank you.

O.
blasterpal (Guest)
on 2008-11-26 14:49
(Received via mailing list)
I think this is a very good topic and your question was detailed
enough to kick start a good discussion. There is one question I have
that would help continue:

Do you want to shared the same mongrep resources for all sub-domains?
(or Passenger for that matter) This is a very important distinction
for non-Rails people coming from PHP. Rails is like a JSP/Servlet site
in that a Java/Ruby server instance must be running to work with
Apache to respond to requests. But this means on a shared/VPS server
resource usage, ie memory first and then competing for CPU.

O, please think about above and we'll continue talking. Hopefully some
other folks will chime in as this is something that I ponder as well
as to best scenario.

I can answer a little of your questions:

If sharing mongrel processes is NOT a concern, then i'd recommend SVN
externalizing or making the shared code part of a lib dir. Google "svn
external" and read a little.. And then having the rest of the rails
app be normal for each subdomain. You could also use capistrano to
deploy your app this way too. Have your shared code locally in dev
symlinked to shared rails app code. There are many ways to skin this
car.

#2 I see no issue with each app sharing the same database in the
database.yml from a mysql perspective. This is what multiple mongrels
on single Rails app do anyway. However, you must think about any app
specific issues you may encounter as a result. Do you need a subdomain
column for some records to keep this logic?

#3 ensure application.rb is not shared and thus you get your sessions
for each app?

#4 as far as overriding controllers and actions by subdomain, let's
assume you have included a lib in that has your base shared actions.
and your app includes those controllers in by default. I would think
one could redefine or override those methods.  Or make an
exclude_actions :some_action as part of the lib or something similar
and then you'd create your own action in an actual controller class in
the sub-domain rails app.

I hope this begins a dialogue of some sort.

Hank
icke (Guest)
on 2008-11-26 18:41
(Received via mailing list)
Hank,

Thank you for your response.

I can deploy on a dedicated server so am not short of memory or cores
but I am not expecting very high transactions volumes.  So my
preference would be to have a single (pack?) of mongrels handling the
requests.  Each domain would be handles by an Apache Virtual Host
acting as a Mongrel proxy which would do a few things:

1) Set the document root.
2) redirect to maintenance pages if they are present
3) handle any cache hits
4) manipulate the headers if would like to (somewhere to put some
other information if we want to pass data to the mongrel's).

So effectively each of the Apache virtual servers will point to the
same pack of mongrels defined in  mongrel_cluster.yml which will point
to the same rails app.

#2 - I have designed the application so that it is really only one
application so I would suspect I might be ok on this one, but
certainly it would be a consideration for other applications.

#3 - even if application.rb is shared, cannot I over-ride the :session
path with the domain name in there to effecively partition the
sessions by domain.  I am not sure where I would actually over-ride
this.  environment.rb?  application.rb? routes.rb (in particular   The
same goes for over-riding the page_cache_directory so the pages are
cached to the document root of the apache virtual host.

#4  - if there a way of testing if there is a domain specific version
of a template or view and render that, if there isn't use the shared
version.  I am not sure I am looking at this part correctly.

Thank you again for your help.

Owain.
Frederick C. (Guest)
on 2008-11-26 20:03
(Received via mailing list)
On Nov 26, 4:40 pm, icke <removed_email_address@domain.invalid> wrote:

> #3 - even if application.rb is shared, cannot I over-ride the :session
> path with the domain name in there to effecively partition the
> sessions by domain.  I am not sure where I would actually over-ride
> this.  environment.rb?  application.rb? routes.rb (in particular   The
> same goes for over-riding the page_cache_directory so the pages are
> cached to the document root of the apache virtual host.
>
The session is tracked via a cookie which will be per domain anyway.

Fred
This topic is locked and can not be replied to.