Hi All,
I have an rails application which is designed to connect to one db and
work at 1 url. Let say i want to host it 10 customers
like
http://customer1.coolapp.com ->customer1 db
http://customer2.coolapp.com ->customer2 db
http://customer3.coolapp.com ->customer3 db
…
http://customer10.coolapp.com ->customer4 db
What is the best way to deploy the application?
Option 1: have multiple code trees for each customer and thus each
customer having his own rails app and use apache/lighttpd to route the
requests much like http://duncandavidson.com/archives/154
Option 2: have a single code tree and depending upon the request url,
connect to the appropriate database, much like
http://wiki.rubyonrails.org/rails/pages … Databases.
I will have some customer specific datafiles.
Which of the approaches is a scalable and maintainable, for lets say
100-1000 customers.
Thanks in Advance.
For me, I would add customer_id in the tables, and make sure that
one “customer” only could see his data. Then you can easily scale.
Also just let the “customer” login. There “record” will tell you who
they are,
and you can go from there.
You can also do the different dns names, but dns’s are a pain, and
also take a while to populate.
Also that means you can have a single mongrel_cluster, and a nginx
proxy to handle the whole mess.
Otherwise you memory usage is going to get interesting.
Did something similar for a network management application I’ve done
before.
On Dec 21, 6:19 am, Giridhar Tatavarty <ruby-forum-incom…@andreas-
Thanks for the reply. The solution seems interesting but
I already have the tables and the application setup without the
customer_id, so it would take a significant effort to go change the
working application. Is there any plug-in / Active record hacks which
will do it easily.
Actually its pretty easy to add the fields using migrations.
Since you probably only have 1 or two customers at this point.
Really promise you your going to regret it other ways.
Also the “customer” id is hiden in most in your “views”.
On Jan 3, 4:15 am, Giridhar Tatavarty <ruby-forum-incom…@andreas-
Hello, I don’t think it would be that hard to add in the customer id
application wide if you changed things at the model or application
level. The concern I would have is performance/privacy issues with
all of the data in the same location.
On the other hand, I would just try to lockdown the application
security wise and use the same db. That way you can take advantage of
mysql clustering http://www.mysql.com/products/database/cluster/ when
your app gets large enough.
It’s a scaling issue that rails will have to deal with more and more,
but I’m confident that it would be mmore manageable for now to setup a
customer_id key in your fields than to deal with the extra database
complexity.
-ht
On Jan 2, 2:15 pm, Giridhar Tatavarty <ruby-forum-incom…@andreas-
Thank you Vitaly, Hugh and glennswest,
for taking time to answer my question. I think both the solutions are
attractive and have their advantages and disadvantages.
It appears that application stability and privacy issues are very
critical so i am leaning towards the solution of Vitaly Kushner and
implement a scheme which serves different db, depending upon url. I
agree with glennswest that dns is pain and testing such setup is also
very complication and i cannot test on my localhost easily such as
customer1.localhost or customer2.localhost etc .
Once, i implement i would post my results. Once again i thank everyone
for their comments.
Giridhar Tatavarty wrote:
Hi All,
I have an rails application which is designed to connect to one db and
work at 1 url. Let say i want to host it 10 customers
like
http://customer1.coolapp.com ->customer1 db
http://customer2.coolapp.com ->customer2 db
http://customer3.coolapp.com ->customer3 db
…
http://customer10.coolapp.com ->customer4 db
What is the best way to deploy the application?
Option 1: have multiple code trees for each customer and thus each
customer having his own rails app and use apache/lighttpd to route the
requests much like http://duncandavidson.com/archives/154
Option 2: have a single code tree and depending upon the request url,
connect to the appropriate database, much like
http://wiki.rubyonrails.org/rails/pages … Databases.
I will have some customer specific datafiles.
Which of the approaches is a scalable and maintainable, for lets say
100-1000 customers.
Thanks in Advance.
The answer depends on the exact circumstances, but in case of an
existing application I think it is much better to go with a single
application tree serving from DIFFERENT databases. i.e. have some filter
choose database per customer. you will have to juggle some active record
connections (and keep them alive etc.) but it will be much easier then
going though the whole application ensuring that the data can not ‘leak’
from one customer to another. In a real-world non trivial application of
a substantial size you usually have custom sql, performance hacks, page
caches etc that might cause the leaks and depending on the problem
domain it might not be an acceptable risk.
BTW, the leak by cached pages is something you will have to deal with
anyway.
You need to define fragment cache path (if you use file store) depending
on the customer.
and if you want page caching, you will need to configure separate web
server root per customer.
i.e. in apache, you will have to define separate virtual host per
customer with a separate cloned ‘public’ directory as a root dir, all
proxying dynamic requests to the same mongrel cluster for example.
Same with per-customer data files. just put them in separate directories
and define current customer directory per request.