Hi all.
Like many of us, I''m currently struggling with Rails deployment. Like
maybe only a few of us, I''m responsible not for one or two webapps but
dozens. Currently, we deploy them as war files using JBoss'' hot
deployment feature, which amounts to copying a war file to a directory
monitored by JBoss. Undeploying the app amounts to removing it from
the directory. So with JBoss I get:
1) Simple deployment
2) Application isolation
We''ve recently discovered that it''s easier (and more fun!) to
write
these apps using RoR instead of J2EE. But it''s not so easy to deploy
them, at least not in a way that makes sense for us. Specifically, we
need, in addition to the above:
3) Consolidated logs
4) Path-based app URI''s.
By path-based URI''s, I mean ''http://host.com/app''
instead of
''http://app.host.com''.
Lately we''ve been toying with the idea of creating a Mongrel plugin
that could provide this app server functionality. In particular, it
could monitor a directory into which multiple RoR apps may be
copied/symlinked, providing hot [un]deployment of them within a single
Mongrel instance. Additionally, it could provide a centralized
interface to log4r (or something compatible) that would route log
messages to a single location.
I ran across this comment for Mongrel::Rails::RailsConfigurator::rails
and got a little worried:
# Because of how Rails is designed you can only have
# one installed per Ruby interpreter (talk to them
# about thread safety). Because of this the first
# time you call this function it does all the config
# needed to get your rails working. After that
# it returns the one handler you''ve configured.
# This lets you attach Rails to any URI (and multiple)
# you want, but still protects you from threads destroying
# your handler.
Zed, would you mind elaborating on this a bit, or at least point me to
more information about this problem?
Does anyone else think this kind of functionality would be useful? If
so, is the approach viable? Would anyone like to help us? :-)
Sorry for the long post,
Jim
On 7/12/06, Jim Crossley <jim.crossley at cptii.com> wrote:> We''ve recently discovered that it''s easier (and more fun!) to write > these apps using RoR instead of J2EE. But it''s not so easy to deploy > them, at least not in a way that makes sense for us. Specifically, we > need, in addition to the above: > > 3) Consolidated logs > 4) Path-based app URI''s.Do you need consolidated access logs or consolidated debugging logs? Using something like Apache with mod_proxy (or mod_proxy_balancer) and then Mongrel with the patch that I sent to Zed a couple days ago would accomplish most of this. You could ignore Mongrel''s access logs and use Apache''s instead. You''d have one (or more) Mongrel back end per app. Then the front-end server (or load balancer, really) proxyies http://host.com/app1 to App1''s Mogrel instance(s), http://host.com/app2 to App2''s Mongrel instances, and so on. You can restart each Mongrel back end independantly for upgrades. To keep things happy, you''d need to write some sort of management front end that takes a list of apps and then builds a config file for your front-end proxy along with a set of scripts for stopping and restarting the Mongrel back ends. It''s probably a couple hours'' work, but it''ll pay for itself almost immediately. Scott
Hi... "Scott Laird" <scott at sigkill.org> writes: [...]> Do you need consolidated access logs or consolidated debugging logs?Yes. :-) Actually, I was referring to the debugging logs. We already use Apache as a reverse proxy to our app server, so its access logs work well for us.> Using something like Apache with mod_proxy (or mod_proxy_balancer) > and then Mongrel with the patch that I sent to Zed a couple days ago > would accomplish most of this. You could ignore Mongrel''s access > logs and use Apache''s instead.I saw that patch, however...> You''d have one (or more) Mongrel back end per app.We *really* want to avoid this, if possible. We have some pretty clever mod_rewrite voodoo in place that compares the incoming URI''s path to our JBoss deployment directory to know whether to proxy the request. We would rather not introduce a path-to-port mapping layer. This is why we''d prefer a single Mongrel instance and path-based URI''s. And wouldn''t the port-per-app make debug log consolidation harder?> Then the front-end server (or load balancer, really) proxyies > http://host.com/app1 to App1''s Mogrel instance(s), > http://host.com/app2 to App2''s Mongrel instances, and so on. You > can restart each Mongrel back end independantly for upgrades.Granted that would give us app isolation, but it would complicate our Apache config by introducing the app-to-port mappings. I don''t want to have to re{start,load} Apache when I add/remove an new application.> To keep things happy, you''d need to write some sort of management > front end that takes a list of apps and then builds a config file > for your front-end proxy along with a set of scripts for stopping > and restarting the Mongrel back ends. It''s probably a couple hours'' > work, but it''ll pay for itself almost immediately.I agree that a management interface would hide some of the complexity, but I''d like to make the transition from JBoss to Rails as transparent as possible to our support staff. I''ll have to give that some thought. Thanks for your quick reply, Jim
On 7/12/06, Jim Crossley <jim.crossley at cptii.com> wrote:> > You''d have one (or more) Mongrel back end per app. > > We *really* want to avoid this, if possible. We have some pretty > clever mod_rewrite voodoo in place that compares the incoming URI''s > path to our JBoss deployment directory to know whether to proxy the > request. We would rather not introduce a path-to-port mapping layer. > This is why we''d prefer a single Mongrel instance and path-based > URI''s.I''d be really amazed if you could get multiple Rails apps running under a single Mongrel process working without causing big problems. You *might* be able to do this by merging all of the apps and treating it like one big app with weird namespace issues. You could probably even automate that. But you''d have to take it down and restart it to make changes, and IMHO that''d be a huge pain in most situations. At the very least, it''d break as soon as one app needs Rails 1.2 while the others require Rails 1.1.> And wouldn''t the port-per-app make debug log consolidation harder?Actually, it might be *easier* if each Mongrel process has its own log directory. Since most Rails log entries are more then one line long, de-interlacing the logs to determine which lines go with which request is a pain. Actually, replacing the Rails logger with something more powerful and using it to consolidate the logs would probably be one of the *first* things that I''d do. I''m not really running any Rails apps in production right now (not counting N Typo installs), so I haven''t had to deal with log-related issues. I should probably add something log-related to the installer that I''m working on. Now where''d I put that to-do list... Anyway, you do realize that Mongrel single-threads Rails requests, right? You''re going to need multiple copies of Mongrel to get any parallelism out of the system, and once you do that you might as well bite the bullet and accept the one-app-per-Mongrel solution. Scott
On 7/12/06, Jim Crossley <jim.crossley at cptii.com> wrote:> > You''d have one (or more) Mongrel back end per app. > > We *really* want to avoid this, if possible. We have some pretty > clever mod_rewrite voodoo in place that compares the incoming URI''s > path to our JBoss deployment directory to know whether to proxy the > request. We would rather not introduce a path-to-port mapping layer. > This is why we''d prefer a single Mongrel instance and path-based > URI''s.You can''t have one mongrel instance power multiple applications, because each mongrel instance loads up the application environment. I think the problem is that you''re trying to compare a mongrel instance with a JBoss instance. They''re not the same kind of application. Mongrel is a much more specific, lightweight, fine-grained app that would be more akin to some kind of component within JBoss. The easiest way to manage deployments with Rails apps is to use Capistrano. I understand that you need a higher level management application. It certainly would be an interesting project. Just realize that such a system should manage mongrel processes, not be built into mongrel itself. Pat
On 7/12/06, Scott Laird <scott at sigkill.org> wrote:> You *might* be able to do this by merging all of the apps and treating > it like one big app with weird namespace issues.I tried this on a single site of mine that had three separate applications - a ticketing system, a billing system, and another specialized application. Managing that was a nightmare. Running separate applications gives another benefit in the form of scalability. As my site grows, I can just add mongrel processes for the specialized application, as it''s the most heavily used part of the site. Also as you said, Mongrel is single-threaded so it''s unrealistic to run any heavily-used application on one instance. As I mentioned in an earlier reply, the real problem at hand is mistaking JBoss and Mongrel to be equivalent systems on different platforms. Pat
"Pat Maddox" <pergesu at gmail.com> writes: [...]> I think the problem is that you''re trying to compare a mongrel > instance with a JBoss instance. They''re not the same kind of > application. Mongrel is a much more specific, lightweight, > fine-grained app that would be more akin to some kind of component > within JBoss.I was worried that my original email might be construed that way. I didn''t mean to start any sort of JBoss vs Mongrel or Java vs RoR flame. I''m just trying to find a way I can combine the development conveniences of one with the deployment conveniences of the other. I certainly don''t want Mongrel or RoR to become the big honking pig that JBoss is. I''m merely looking for a way to achieve app isolation, hot deployment, and log file consolidation.> The easiest way to manage deployments with Rails apps is to use > Capistrano.I don''t doubt that, though the docs are dated and somewhat lacking WRT Mongrel integration, aren''t they? Regardless, I absolutely need to dive into Capistrano.> I understand that you need a higher level management application. > It certainly would be an interesting project. Just realize that > such a system should manage mongrel processes, not be built into > mongrel itself.Understood, thanks. Jim
hi,
that reminds me a bit on
http://mongrel.rubyforge.org/not_mongrel.html
I like the idea of having it simple and small. :)
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
On 7/12/06 3:27 PM, Jim Crossley wrote:> Currently, we deploy them as war files using JBoss'' hot > deployment feature, which amounts to copying a war file to a directory > monitored by JBoss. Undeploying the app amounts to removing it from > the directory.At risk of being banned form the list: I would suggest that you focus your efforts on JRuby. If you have this entrenched java infrastructure maybe you can leverage rails that way. I''m not sure if you could so it today but FWIW JRuby is under very active development. Apologies if this is already known to you.
On 7/12/06, Jim Crossley <jim.crossley at cptii.com> wrote:> "Pat Maddox" <pergesu at gmail.com> writes: > > [...] > > > I think the problem is that you''re trying to compare a mongrel > > instance with a JBoss instance. They''re not the same kind of > > application. Mongrel is a much more specific, lightweight, > > fine-grained app that would be more akin to some kind of component > > within JBoss. > > I was worried that my original email might be construed that way. I > didn''t mean to start any sort of JBoss vs Mongrel or Java vs RoR > flame. I''m just trying to find a way I can combine the development > conveniences of one with the deployment conveniences of the other. > > I certainly don''t want Mongrel or RoR to become the big honking pig > that JBoss is. I''m merely looking for a way to achieve app isolation, > hot deployment, and log file consolidation.Oh I know you weren''t trying to start a Rails vs Java thing. I''m just saying that Mongrel is an application server (well, HTTP server, but application server wrt Rails). JBoss is an application server platform. JBoss is intended to provide a much more comprehensive infrastructure, and you''ll just give yourself a headache if you try to think of Mongrel in the same light. As far as I can tell, the "Rails way" of doing things is the same as the Unix way. Have lots of small applications and utilities that do the job well, and assemble them how you need. For application deployment that means using Capistrano. If you have to manage a number of deployments, find a way to tie it into Capistrano somehow. The Rails Machine guys have done something like that, created a new utility to "machinify" your application. It modifies deploy scripts, sets up stuff on the server, etc. Go to their site and install the gems, then you can take a look at the source and see if you could do something similar.> > The easiest way to manage deployments with Rails apps is to use > > Capistrano. > > I don''t doubt that, though the docs are dated and somewhat lacking WRT > Mongrel integration, aren''t they? Regardless, I absolutely need to > dive into Capistrano.Coda Hale wrote the best guide to using Mongrel that I''ve seen so far. It includes how to use Capistrano and Mongrel. Worked flawlessly for me on dev and production boxes. http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/ hth Pat
On Wed, 2006-07-12 at 19:58 -0500, Tom Brice wrote:> On 7/12/06 3:27 PM, Jim Crossley wrote: > > > Currently, we deploy them as war files using JBoss'' hot > > deployment feature, which amounts to copying a war file to a directory > > monitored by JBoss. Undeploying the app amounts to removing it from > > the directory. > > At risk of being banned form the list: I would suggest that you focus your > efforts on JRuby. If you have this entrenched java infrastructure maybe you > can leverage rails that way. I''m not sure if you could so it today but FWIW > JRuby is under very active development. Apologies if this is already known > to you.NO SOUP FOR YOU! Nah, you''re right. I agree with Jim here. Here''s an analogy. You ever have the girlfriend (or boyfriend) who has enough baggage to choke O''Hare? She''s constantly complaining about how her last boyfriend did this, or her last boyfriend did that. He was a gentlemen, he was nice, he bought her flowers. She obviously left the guy for some reason, so why is she complaining to you? Why doesn''t she just go back to him if he''s so damn great? See, the problem is she wants to have her cake and eat it too. She wants the new nice guy and the piece of crap she used to date all rolled into one Superman. Can''t have it that way. Either she has to start dating again and find that Superman, or just accept that the new guy is different and start admiring his positive qualities (or sleep with both at the same time, but that''s another topic entirely off topic). So, either you have to accept that Mongrel and Rails are just different. Not worse. Different. Instead of saying, "How can I get Mongrel to be like my old JBoss (even though I hate JBoss!)?" You should be saying, "Hey, I need help making my deployment hot and smooth. Can someone help me out?" If you can''t accept it, then you''ve gotta look at something JRuby as the possible Superman in our little analogy (but be prepared to have it not turn out like you like). I''ll answer your original e-mail with a more serious response, but this is the basic philosophy. It''s not better or worse, it''s different. P.S. I *hate* application servers with a passion. Just so you know, I prefer one tool does one job well. If I wanted a thousand kitchen sinks I''d own a Home Hardware. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
First some answers to your questions, then a slight position "paper" at the end... On Wed, 2006-07-12 at 16:27 -0400, Jim Crossley wrote:> Hi all. > > Like many of us, I''m currently struggling with Rails deployment. Like > maybe only a few of us, I''m responsible not for one or two webapps but > dozens. Currently, we deploy them as war files using JBoss'' hot > deployment feature, which amounts to copying a war file to a directory > monitored by JBoss. Undeploying the app amounts to removing it from > the directory. So with JBoss I get: > > 1) Simple deployment > 2) Application isolation >Hmm, but do you really get #2? Be honest. Do you really? C''mon. You sure? I mean *really* isolated applications? No classes mixed from competing jar versions? No ClassLoader1, ClassLoader2, ClassLoader0? No memory hogs crashing all your apps at once? Even with Java the only way to get *true* application isolation is to run them in separate processes. Java''s big pitfall is that it tries to be the OS when the OS is better at being an OS. Now, the reason Java tries to do this is because a base Sun JVM takes up 128M of ram, and even simple apps can easily eat 1G on a bad day. #1 is cake with capistrano. Actually, a billion hundred million times better than any JBoss hackery you''ve got. Capistrano not only hot deploys your apps, but *versions* them, and allows hot undeploy to previous versions while remote managing database migrations, web servers, toasters, and alien space probes. Capistrano is what you want.> We''ve recently discovered that it''s easier (and more fun!) to write > these apps using RoR instead of J2EE. But it''s not so easy to deploy > them, at least not in a way that makes sense for us. Specifically, we > need, in addition to the above: > > 3) Consolidated logs > 4) Path-based app URI''s. >#3 is done by a combination of cleverness, mongrel_cluster, and the power of ln. Basically, if you want to consolidate logs than link your log directory to a directory like /var/log/rails/app1,app2. With that it''s pretty trivial to then harvest these logs as part of your log rotation. Now if you mean "consolidate logs" and actually mean "a mondo log file for all my apps", then how does this jive with your desire for app separation? Seems like counter goals. Still, you can log to a syslog on a separate server if you absolutely need this. For #4 I''ve got a patch I''m applying and then I''ll do a pre-release of 0.3.13.4 to enable it. It''ll give you what you want on this.> By path-based URI''s, I mean ''http://host.com/app'' instead of > ''http://app.host.com''. >Yep, wait for patch.> Lately we''ve been toying with the idea of creating a Mongrel plugin > that could provide this app server functionality. In particular, it > could monitor a directory into which multiple RoR apps may be > copied/symlinked, providing hot [un]deployment of them within a single > Mongrel instance. Additionally, it could provide a centralized > interface to log4r (or something compatible) that would route log > messages to a single location. >I think you''re really over thinking this. Your above desire basically amounts to this single requirements statement: "Change Mongrel and Rails to be like JBoss so I don''t have to change." If you seriously love the JBoss way of deploying, then you should consider JRuby. You''ll be a little limited at first, but it''ll give you what you want. But, I''d say, try the new way. It''s a learning curve initially, but not much of one. And it has huge advantages from its simplicity and the power you get combining Apache+mongrel+capistrano is insane. I literally do "cap -a deploy" and have all my databases updated, checks run, code deployed, servers restarted, the works. And you can customize it to suite your needs. Give it a shot before you go trying to change things to your will.> I ran across this comment for Mongrel::Rails::RailsConfigurator::rails > and got a little worried: > > # Because of how Rails is designed you can only have > # one installed per Ruby interpreter (talk to them > # about thread safety). Because of this the first > # time you call this function it does all the config > # needed to get your rails working. After that > # it returns the one handler you''ve configured. > # This lets you attach Rails to any URI (and multiple) > # you want, but still protects you from threads destroying > # your handler. > > Zed, would you mind elaborating on this a bit, or at least point me to > more information about this problem?Yeah, basically Ruby has a namespace. Rails uses this namespace to put the applications classes in. There''s no mechanism in the Ruby interpreter to have separate namespaces, so you can''t put more than one app inside a Ruby interpreter. But then, you can''t really do this with Java either, and for technical reasons it''s kind of stupid to try. Operating systems are much better than Virtual Machines at separating processes, so in the Rails approach we just let the OS separate the apps and run one process for each app.> > Does anyone else think this kind of functionality would be useful? If > so, is the approach viable? Would anyone like to help us? :-)I wouldn''t want to discourage you, since I''m sure there''s someone who would probably even fund this, but I''d have to say that I''m dead against this in a violently evil way. I was doing Java deployments for years and I *hated* the way it was done. Actually, the fact that you can''t integrate rails into your current setup is a symptom of the java "kitchen-sink-app-server" approach. If you think about it, it''s a very clever ploy by the app server vendors since once you do it their way, you can''t use anything else to manage heterogeneous systems. But let me interject a little bit of perspective on this problem. While I''ve been kind of teasing you, I do think that what you''re expressing is not a problem with how Mongrel/Rails apps are deployed, but more a problem with how the deployments are configured. I''ll explain. Deployment with capistrano is pretty much just as simple as what you''re describing with JBoss. Simpler even since I can have capistrano do a bunch of other nice things, and it even copies the stuff over for you. Like I said, give me a scriptable system any day. But, the way rails does things means that it likes being at a host not a URI. Even with this patch I''m gonna put in, you''ll still have some problems you''ll have to adapt for. I actually don''t like the URI thing, since a DNS change is all you need to setup your vhost. But, this isn''t practical for people who want to cram 100 apps on one box and have to beg operations for a week to get one DNS change. So where I think you should focus your efforts is not on the "hot deployment" (which is a total lie BTW), or the "segmented apps" (another lie), but on making the configuration of a mongrel setup simpler. This is what the RailsMachine guys did and it''s worked great for them. They have a consistent deployment method using capistrano that does all the stuff you''re asking for, but in the rails way. As a matter of fact, if you''re in a time crunch, I''ll pimp them and say you should contact them for some commercial support and they can have you up and running with a sweet setup quick. In conclusion, it''s not the hot deployment you want, that''s just eye-candy. What you want is the simple *configuration* of your deployment, which is possible but it''ll take some work initially. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
I wasn''t making any value judgements about Mongrel, JBoss, Rails, Java, Ruby, or even JRuby or girlfriends or crappy old boyfriends or cake, and I certainly don''t want "Mongrel to be like my old JBoss"! I simply "need help making my deployment hot and smooth. Can someone help me out?" ;-) Jim Zed Shaw <zedshaw at zedshaw.com> writes:> On Wed, 2006-07-12 at 19:58 -0500, Tom Brice wrote: >> On 7/12/06 3:27 PM, Jim Crossley wrote: >> >> > Currently, we deploy them as war files using JBoss'' hot >> > deployment feature, which amounts to copying a war file to a directory >> > monitored by JBoss. Undeploying the app amounts to removing it from >> > the directory. >> >> At risk of being banned form the list: I would suggest that you focus your >> efforts on JRuby. If you have this entrenched java infrastructure maybe you >> can leverage rails that way. I''m not sure if you could so it today but FWIW >> JRuby is under very active development. Apologies if this is already known >> to you. > > NO SOUP FOR YOU! > > Nah, you''re right. I agree with Jim here. Here''s an analogy. > > You ever have the girlfriend (or boyfriend) who has enough baggage to > choke O''Hare? She''s constantly complaining about how her last boyfriend > did this, or her last boyfriend did that. He was a gentlemen, he was > nice, he bought her flowers. She obviously left the guy for some > reason, so why is she complaining to you? Why doesn''t she just go back > to him if he''s so damn great? > > See, the problem is she wants to have her cake and eat it too. She > wants the new nice guy and the piece of crap she used to date all rolled > into one Superman. Can''t have it that way. Either she has to start > dating again and find that Superman, or just accept that the new guy is > different and start admiring his positive qualities (or sleep with both > at the same time, but that''s another topic entirely off topic). > > So, either you have to accept that Mongrel and Rails are just different. > Not worse. Different. Instead of saying, "How can I get Mongrel to be > like my old JBoss (even though I hate JBoss!)?" You should be saying, > "Hey, I need help making my deployment hot and smooth. Can someone help > me out?" If you can''t accept it, then you''ve gotta look at something > JRuby as the possible Superman in our little analogy (but be prepared to > have it not turn out like you like). > > I''ll answer your original e-mail with a more serious response, but this > is the basic philosophy. It''s not better or worse, it''s different. > > > P.S. I *hate* application servers with a passion. Just so you know, I > prefer one tool does one job well. If I wanted a thousand kitchen sinks > I''d own a Home Hardware. > > -- > Zed A. Shaw > http://www.zedshaw.com/http://mongrel.rubyforge.org/ > http://www.railsmachine.com/ -- Need Mongrel support? > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
On Wed, 2006-07-12 at 23:50 -0400, Jim Crossley wrote:> I wasn''t making any value judgements about Mongrel, JBoss, Rails, > Java, Ruby, or even JRuby or girlfriends or crappy old boyfriends or > cake, and I certainly don''t want "Mongrel to be like my old JBoss"! I > simply "need help making my deployment hot and smooth. Can someone > help me out?" ;-)Hehe, nah, I didn''t think you were slagging Mongrel. Just kind of laying out my opinion on the topic. Now, what you need to do is research a few technologies: * capistrano -- does your deployment automation * mongrel_cluster -- does simple cluster configs. * puppet -- more advanced system automation. Also check out the railsmachine gem and talk with Bradley Taylor about he sets things up. He''s got a good setup and the railsmachine stuff is open source, but you have to do a bit of work. Next up, check out the following documents that can you get you up and running with a nice deployment scenario: http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/ Bradley''s setup is an alternative but we don''t have it documented quite as well yet. You could follow Coda''s instructions and get a complete setup working in no time. And that should get you on the right track very well. You''ll have to look at syslog logger and a few other tweaks to get the kind of logging you want, but otherwise it''s the way to go. I hang out as zedas in #rubyonrails, so just private message me if you need help. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?