Ok, a refinement of the question I asked yesterday (If there were any replies from yesterday I don''t have access to them here .. sorry if I''m duplicating anybody''s words here). How can one host multiple domains with mongrel? Assuming you are mass vhosting and you also want the performance benefits of using mongrel ... As far as I can tell, one could set up a vhost in Apache and a mongrel (cluster) for each host and have that be that. But let''s say you can have an unlimited number of vhosts, this will get seriously tedious and error prone. A great thing about Apache is the ability to interpolate docroots, so you can add infinite vhosts super easy. But, for this to work with Mongrel, it would have to have the same ability, be able to take a request and feed it to the correct app based on some parameters of the request. I haven''t yet looked at Mongrel''s internals, but for those of you with experience there, would it be difficult or is it even a good idea to create a parallel to mongrel_rails, something like mongrel_rails_vhosts or the like? My understanding of plugins is that they can only extend mongrel_rails by adding commands, true? I imagine it would be similar to mongrel_rails but with a dispatcher layer that can be multithreaded and send requests to the correct app based on the request. Or would something like mongrel_cluster, but with the added dispatching layer there be a better approach? Love to hear anyone''s thoughts ... if it seems promising, I''ll take it on. Cheers, John
What are you mass virtual hosting exactly? And what I mean by this is that with one of our apps (the connector), I can have either connector.jasonhoffman.org or jason.joyent.net pull up my webmail, contacts, calendaring, files etc and that''s distinct from anyoneelse.joyent.net and they can have as many other domains map to it as they want. We do this all via stateless (in this context) mongrel processes, anyone can hit any of them and get their stuff. Or are you talking about the mass virtual hosting of many different Rails or Ruby applications? - J On Sep 7, 2006, at 11:40 AM, John Clayton wrote:> Ok, a refinement of the question I asked yesterday (If there were any > replies from yesterday I don''t have access to them here .. sorry if > I''m duplicating anybody''s words here). > > How can one host multiple domains with mongrel? Assuming you are mass > vhosting and you also want the performance benefits of using > mongrel ... > > As far as I can tell, one could set up a vhost in Apache and a > mongrel (cluster) for each host and have that be that. But let''s say > you can have an unlimited number of vhosts, this will get seriously > tedious and error prone. > > A great thing about Apache is the ability to interpolate docroots, so > you can add infinite vhosts super easy. But, for this to work with > Mongrel, it would have to have the same ability, be able to take a > request and feed it to the correct app based on some parameters of > the request. > > I haven''t yet looked at Mongrel''s internals, but for those of you > with experience there, would it be difficult or is it even a good > idea to create a parallel to mongrel_rails, something like > mongrel_rails_vhosts or the like? My understanding of plugins is that > they can only extend mongrel_rails by adding commands, true? I > imagine it would be similar to mongrel_rails but with a dispatcher > layer that can be multithreaded and send requests to the correct app > based on the request. Or would something like mongrel_cluster, but > with the added dispatching layer there be a better approach? > > Love to hear anyone''s thoughts ... if it seems promising, I''ll take > it on. > > Cheers, > > John > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote:> How can one host multiple domains with mongrel? Assuming you are mass > vhosting and you also want the performance benefits of using mongrel ...If I remember right, you are looking at a situtation where you have a single application that will have a different look and feel applied, depending on the domain it is being served to, right? So couldn''t you just set up your app to look at the SERVER_NAME and choose the theme for the content appropriately? Then you just setup your Apache vhosts and feel all the traffic into the same mongrel cluster, and you don''t have to do anything at all at the Mongrel level, right? You leave it to your app to be multidomain aware? What am I missing? Kirk Haines
And if this is the case, we just wrote something up on using this kind of "subdomain" auth as part of a key -- all one app, serving up different "content" / "dashboards" / "features": http://cleanair.highgroove.com/articles/2006/08/14/simplied-subdomain-authentication-in-ruby-on-rails The key is a DNS wildcard record: *.yourdomain.com forwarded to the main web/app server and rules for handling what it does. I hope we didn''t mangle your question too badly, On 9/7/06, Kirk Haines <wyhaines at gmail.com> wrote:> On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote: > > > How can one host multiple domains with mongrel? Assuming you are mass > > vhosting and you also want the performance benefits of using mongrel ... > > If I remember right, you are looking at a situtation where you have a > single application that will have a different look and feel applied, > depending on the domain it is being served to, right? > > So couldn''t you just set up your app to look at the SERVER_NAME and > choose the theme for the content appropriately? > > Then you just setup your Apache vhosts and feel all the traffic into > the same mongrel cluster, and you don''t have to do anything at all at > the Mongrel level, right? You leave it to your app to be multidomain > aware? > > What am I missing? > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com
Hey Guys, Thanks for the quick replies. Some more info: As you mention, Kirk, we are looking to host different instances of the same app, correct. Basically, let''s say we are hosting an online community app, with one instance each for a particular region in a geographical area. So, we''d like a different instance, as opposed to a single instance that switches the underlying context?DB connection, config info, etc.?so that we can keep the data partitioned nicely, not adversely affect performance (these could get a lot of traffic and we''d like to have each one partitioned from the others in case one has issues), have a unique docroot for file storage, etc.. Also, these apps have to be dynamically provisioned?that is, not require a Web server restart or any human intervention to create a new instance. To wit, our plan is to deploy app stubs that link in the shared codebase (haven''t figured that one out), and use Apache''s docroot interpolation to look up an instantiate the correct instance. We use mongrel for other apps now and really like it?it''s made our apps a lot snappier and the reverse proxying stuff just works. The problem (as I see it, and maybe I''m wrong) amounts to being able to not have to create and configure a new mongrel (or cluster) every time we dynamically provision an app. This would involve modifying our Apache conf, restarting, keeping track of used ports, etc., and this we sincerely want to avoid. So, this is when I started to think that it might be possible to add to mongrel functionality similar to what apache does or say what you might do with a J2EE container?host multiple apps in one container and add some sort of dispatching to route requests to the right place. Thanks for your insight. Jason, I''m not sure I totally understand what you''re doing with your connectors, but I''d like to hear more ... On Sep 7, 2006, at 11:50 AM, Jason A. Hoffman wrote:> What are you mass virtual hosting exactly? > > And what I mean by this is that with one of our apps (the connector), > I can have either connector.jasonhoffman.org or jason.joyent.net pull > up my webmail, contacts, calendaring, files etc and that''s distinct > from anyoneelse.joyent.net and they can have as many other domains > map to it as they want. > > We do this all via stateless (in this context) mongrel processes, > anyone can hit any of them and get their stuff. > > Or are you talking about the mass virtual hosting of many different > Rails or Ruby applications? > > - JOn Sep 7, 2006, at 11:51 AM, Kirk Haines wrote:> On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote: > >> How can one host multiple domains with mongrel? Assuming you are mass >> vhosting and you also want the performance benefits of using >> mongrel ... > > If I remember right, you are looking at a situtation where you have a > single application that will have a different look and feel applied, > depending on the domain it is being served to, right? > > So couldn''t you just set up your app to look at the SERVER_NAME and > choose the theme for the content appropriately? > > Then you just setup your Apache vhosts and feel all the traffic into > the same mongrel cluster, and you don''t have to do anything at all at > the Mongrel level, right? You leave it to your app to be multidomain > aware? > > What am I missing? > > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
Thanks, Charles. That''s how we were planning on handling the DNS. What I don''t think your approach doesn''t address for us is partioning the app (db, config, roots, resources) to isolate the impact on performance and data migration. True? J On Sep 7, 2006, at 12:43 PM, Charles Brian Quinn wrote:> And if this is the case, we just wrote something up on using this kind > of "subdomain" auth as part of a key -- all one app, serving up > different "content" / "dashboards" / "features": > > http://cleanair.highgroove.com/articles/2006/08/14/simplied- > subdomain-authentication-in-ruby-on-rails > > The key is a DNS wildcard record: *.yourdomain.com forwarded to the > main web/app server and rules for handling what it does. > > I hope we didn''t mangle your question too badly, > > On 9/7/06, Kirk Haines <wyhaines at gmail.com> wrote: >> On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote: >> >>> How can one host multiple domains with mongrel? Assuming you are >>> mass >>> vhosting and you also want the performance benefits of using >>> mongrel ... >> >> If I remember right, you are looking at a situtation where you have a >> single application that will have a different look and feel applied, >> depending on the domain it is being served to, right? >> >> So couldn''t you just set up your app to look at the SERVER_NAME and >> choose the theme for the content appropriately? >> >> Then you just setup your Apache vhosts and feel all the traffic into >> the same mongrel cluster, and you don''t have to do anything at all at >> the Mongrel level, right? You leave it to your app to be multidomain >> aware? >> >> What am I missing? >> >> >> Kirk Haines >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > -- > Charles Brian Quinn > self-promotion: www.seebq.com > highgroove studios: www.highgroove.com > slingshot hosting: www.slingshothosting.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
I suppose not, but at that point I don''t *think* there''s anything to stop you from determining, say variables like the asset_host to hit for this particular subdomain, or the new ActiveRecord connection to some other database (assuming you''ve already touched one centralized one already), and even where to pull files from (an NFS share maybe). Yeah, this solution really assumes a single application - if you plan on having different versions of your app on different servers, you may want to do some other kind of load balancing to catch it before you hit the rails app and get in as far as our solution takes you. Man, lighttpd has some pretty good regex rules for handling domain, but the mod_proxy_core that you''d ultimately use to pass off to an apache 2.1 -> mongrel is being rewritten. Keep us updated, on what you find out (but I suppose this is a bit off-topic). Have you seen the railsmachine gem [1] or even our slingshot capistrano file [2] that automates vhosts pointing to different mongrel clusters? it might be possible to automate the creation of many vhosts for apache using it - and then farm off your mongrel clusters to different servers. [1] gem install railsmachine [2] http://www.slingshothosting.com/files/apache2_2_mongrel_deploy.rb cheers, On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote:> Thanks, Charles. > > That''s how we were planning on handling the DNS. What I don''t think > your approach doesn''t address for us is partioning the app (db, > config, roots, resources) to isolate the impact on performance and > data migration. True? > > J > > On Sep 7, 2006, at 12:43 PM, Charles Brian Quinn wrote: > > > And if this is the case, we just wrote something up on using this kind > > of "subdomain" auth as part of a key -- all one app, serving up > > different "content" / "dashboards" / "features": > > > > http://cleanair.highgroove.com/articles/2006/08/14/simplied- > > subdomain-authentication-in-ruby-on-rails > > > > The key is a DNS wildcard record: *.yourdomain.com forwarded to the > > main web/app server and rules for handling what it does. > > > > I hope we didn''t mangle your question too badly, > > > > On 9/7/06, Kirk Haines <wyhaines at gmail.com> wrote: > >> On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote: > >> > >>> How can one host multiple domains with mongrel? Assuming you are > >>> mass > >>> vhosting and you also want the performance benefits of using > >>> mongrel ... > >> > >> If I remember right, you are looking at a situtation where you have a > >> single application that will have a different look and feel applied, > >> depending on the domain it is being served to, right? > >> > >> So couldn''t you just set up your app to look at the SERVER_NAME and > >> choose the theme for the content appropriately? > >> > >> Then you just setup your Apache vhosts and feel all the traffic into > >> the same mongrel cluster, and you don''t have to do anything at all at > >> the Mongrel level, right? You leave it to your app to be multidomain > >> aware? > >> > >> What am I missing? > >> > >> > >> Kirk Haines > >> _______________________________________________ > >> Mongrel-users mailing list > >> Mongrel-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/mongrel-users > >> > > > > > > -- > > Charles Brian Quinn > > self-promotion: www.seebq.com > > highgroove studios: www.highgroove.com > > slingshot hosting: www.slingshothosting.com > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com
Ok, I realize this thread should really be called "hosting differently configured instances of the same app in a single mongrel instance", but that doesn''t read as well ;-) I have looked over the source code for Mongrel and the various adaptations and it looks like it''s not too hard to add my own classes that extend mongrel in the same ways as the rails and camping classes do, by writing my own config and handler classes. I think this is the right way to do this but I''d love to hear opinions. On Sep 8, 2006, at 7:57 AM, Charles Brian Quinn wrote:> I suppose not, but at that point I don''t *think* there''s anything to > stop you from determining, say variables like the asset_host to hit > for this particular subdomain, or the new ActiveRecord connection to > some other database (assuming you''ve already touched one centralized > one already), and even where to pull files from (an NFS share maybe). > > Yeah, this solution really assumes a single application - if you plan > on having different versions of your app on different servers, you may > want to do some other kind of load balancing to catch it before you > hit the rails app and get in as far as our solution takes you. > > Man, lighttpd has some pretty good regex rules for handling domain, > but the mod_proxy_core that you''d ultimately use to pass off to an > apache 2.1 -> mongrel is being rewritten. > > Keep us updated, on what you find out (but I suppose this is a bit > off-topic). > > Have you seen the railsmachine gem [1] or even our slingshot > capistrano file [2] that automates vhosts pointing to different > mongrel clusters? it might be possible to automate the creation of > many vhosts for apache using it - and then farm off your mongrel > clusters to different servers.I have indeed, thanks. I''m definitely drawing on these for inspiration. I think our needs for every little performance advantage is what''s driving us here, which is why most stuff, though viable, just isn''t fitting the bill.> > [1] gem install railsmachine > [2] http://www.slingshothosting.com/files/apache2_2_mongrel_deploy.rb > > cheers, > > On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote: >> Thanks, Charles. >> >> That''s how we were planning on handling the DNS. What I don''t think >> your approach doesn''t address for us is partioning the app (db, >> config, roots, resources) to isolate the impact on performance and >> data migration. True? >> >> J >> >> On Sep 7, 2006, at 12:43 PM, Charles Brian Quinn wrote: >> >>> And if this is the case, we just wrote something up on using this >>> kind >>> of "subdomain" auth as part of a key -- all one app, serving up >>> different "content" / "dashboards" / "features": >>> >>> http://cleanair.highgroove.com/articles/2006/08/14/simplied- >>> subdomain-authentication-in-ruby-on-rails >>> >>> The key is a DNS wildcard record: *.yourdomain.com forwarded to the >>> main web/app server and rules for handling what it does. >>> >>> I hope we didn''t mangle your question too badly, >>> >>> On 9/7/06, Kirk Haines <wyhaines at gmail.com> wrote: >>>> On 9/7/06, John Clayton <john at fivesquaresoftware.com> wrote: >>>> >>>>> How can one host multiple domains with mongrel? Assuming you are >>>>> mass >>>>> vhosting and you also want the performance benefits of using >>>>> mongrel ... >>>> >>>> If I remember right, you are looking at a situtation where you >>>> have a >>>> single application that will have a different look and feel >>>> applied, >>>> depending on the domain it is being served to, right? >>>> >>>> So couldn''t you just set up your app to look at the SERVER_NAME and >>>> choose the theme for the content appropriately? >>>> >>>> Then you just setup your Apache vhosts and feel all the traffic >>>> into >>>> the same mongrel cluster, and you don''t have to do anything at >>>> all at >>>> the Mongrel level, right? You leave it to your app to be >>>> multidomain >>>> aware? >>>> >>>> What am I missing? >>>> >>>> >>>> Kirk Haines >>>> _______________________________________________ >>>> Mongrel-users mailing list >>>> Mongrel-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/mongrel-users >>>> >>> >>> >>> -- >>> Charles Brian Quinn >>> self-promotion: www.seebq.com >>> highgroove studios: www.highgroove.com >>> slingshot hosting: www.slingshothosting.com >>> _______________________________________________ >>> Mongrel-users mailing list >>> Mongrel-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > -- > Charles Brian Quinn > self-promotion: www.seebq.com > highgroove studios: www.highgroove.com > slingshot hosting: www.slingshothosting.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
On Fri, 2006-09-08 at 14:49 -0700, John Clayton wrote:> Ok, I realize this thread should really be called "hosting > differently configured instances of the same app in a single mongrel > instance", but that doesn''t read as well ;-) > > I have looked over the source code for Mongrel and the various > adaptations and it looks like it''s not too hard to add my own classes > that extend mongrel in the same ways as the rails and camping classes > do, by writing my own config and handler classes. > > I think this is the right way to do this but I''d love to hear opinions.Yep, Mongrel''s designed to be easily modified and extended, and to make it easy to distribute your extensions using the GemPlugin system. Just pack you stuff in a gem and tell people how to wire it up in a -S mongrel.conf. You''ll want to read through http://mongrel.rubyforge.org/rdoc/ (which closely follows the pre-releases) and to look at the various handlers in lib/mongrel/handlers.rb. You''ll be much more closer to the bare metal, but you''ll have more control and the ability to make things as fast as possible. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
Cool, thanks Zed. On Sep 8, 2006, at 3:24 PM, Zed Shaw wrote:> On Fri, 2006-09-08 at 14:49 -0700, John Clayton wrote: >> Ok, I realize this thread should really be called "hosting >> differently configured instances of the same app in a single mongrel >> instance", but that doesn''t read as well ;-) >> >> I have looked over the source code for Mongrel and the various >> adaptations and it looks like it''s not too hard to add my own classes >> that extend mongrel in the same ways as the rails and camping classes >> do, by writing my own config and handler classes. >> >> I think this is the right way to do this but I''d love to hear >> opinions. > > Yep, Mongrel''s designed to be easily modified and extended, and to > make > it easy to distribute your extensions using the GemPlugin system. > Just > pack you stuff in a gem and tell people how to wire it up in a -S > mongrel.conf. > > You''ll want to read through http://mongrel.rubyforge.org/rdoc/ (which > closely follows the pre-releases) and to look at the various > handlers in > lib/mongrel/handlers.rb. > > You''ll be much more closer to the bare metal, but you''ll have more > control and the ability to make things as fast as possible. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users