Compared with PHP, I''d say that frameworks reduce the pain of application development, but they increase the pain of deployment. Part of the problem is choice (a bad thing, in my view) and another part is change (again, a bad thing). Choice is bad because it demands time for the choice. Reading documentation, reading blogs to get real-world comments, and reading comparisons -- these all take time that would be better spent on application development. Change is bad because it may demand continued work on existing applications. (That''s probably fine for developers who can then earn part of their living by maintaining existing sites, but it''s a real pain for academics and others who are making sites to help with other work, not as an end in itself.) I just got the (excellent) new Agile Web Development with Rails book, and it''s a case in point. It says that it''s a bad idea to use fastCGI, in contradiction to the first volume of the same book. I presume these authors know whereof they speak, so that''s a real help to me. I can just ignore any documentation site or blog or entry on this group, talking about fastCGI. But the switch in advice over just a year (or so) worries me a lot. That''s why I''m writing this. I come, finally, to my point. It''s a question. What is the best deployment strategy, for a new application being created in early 2007, using pre-release RoR 1.2? (I am using OS X, in case anyone is interested in helping me directly ... but I''m really asking the question for the benefit of a wider audience.) Thanks for reading this long post. It''s my first on this group. Please be gentle. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Actually, deployment is not a pain. I use my own servers (finding a host, can be difficult), and I can setup a rails production environment in 10 minutes. Steps to deploy an application using gentoo 1) emerge ruby 2) emerge mysql postgres or whatever 3) gem install rails 4) gem install mongrel, mongrel_cluster 5) emerge apache 2.2.2 (needs unmasking first) 6) configure a vhost, start mongrel cluster and that''s it Php maybe a little easier, but you have a lot of other issues to deal with. And, since mongrel serves as an application server, you can distribute your app very easily (all you need is the database replication). It''s not as easy as PHP , but it''s not hard. On 1/11/07, dankelley <Dan.Kelley-PrmmtakczFA@public.gmane.org> wrote:> > > Compared with PHP, I''d say that frameworks reduce the pain of > application development, but they increase the pain of deployment. > Part of the problem is choice (a bad thing, in my view) and another > part is change (again, a bad thing). > > Choice is bad because it demands time for the choice. Reading > documentation, reading blogs to get real-world comments, and reading > comparisons -- these all take time that would be better spent on > application development. > > Change is bad because it may demand continued work on existing > applications. (That''s probably fine for developers who can then earn > part of their living by maintaining existing sites, but it''s a real > pain for academics and others who are making sites to help with other > work, not as an end in itself.) > > I just got the (excellent) new Agile Web Development with Rails book, > and it''s a case in point. It says that it''s a bad idea to use fastCGI, > in contradiction to the first volume of the same book. I presume these > authors know whereof they speak, so that''s a real help to me. I can > just ignore any documentation site or blog or entry on this group, > talking about fastCGI. But the switch in advice over just a year (or > so) worries me a lot. That''s why I''m writing this. > > I come, finally, to my point. It''s a question. > > What is the best deployment strategy, for a new application being > created in early 2007, using pre-release RoR 1.2? (I am using OS X, in > case anyone is interested in helping me directly ... but I''m really > asking the question for the benefit of a wider audience.) > > Thanks for reading this long post. It''s my first on this group. > Please be gentle. > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I haven''t actually deployed a locally developed Rails application to a production environment yet but this "guide" to Capistrano looks promising: http://manuals.rubyonrails.com/read/book/17 HTH - Greg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 11, 2007, at 5:12 AM, bandito wrote:> Steps to deploy an application using gentoo > 1) emerge ruby > 2) emerge mysql postgres or whatever > 3) gem install rails > 4) gem install mongrel, mongrel_cluster > 5) emerge apache 2.2.2 (needs unmasking first)Best make that 2.2.3 or 2.2.4> 6) configure a vhost, start mongrel cluster and that''s it-- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Mongrel now. http://mongrel.rubyforge.org But you''re right, stuff changes pretty fast in the Ruby scene. Mongrel+apache, Mongrel+pen (favorite for a small app), Mongrel+nginx, etc. are good options. Mongrel+pound+lighty is what we use for SlideShare. Vish (too tired to post links right now, google all of these) On 1/12/07, gmacgregor <gmacgregor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I haven''t actually deployed a locally developed Rails application to a > production environment yet but this "guide" to Capistrano looks > promising: > > http://manuals.rubyonrails.com/read/book/17 > > HTH - Greg > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > > > 5) emerge apache 2.2.2 (needs unmasking first) > > Best make that 2.2.3 or 2.2.4 > >True. (Ι was still running 2.2.2, haven't emerged sync for a while). I'm running a production environment, with 10k visits/day on a rather demanding setup for a price aggregator with 0.5M products (3-4M queries per day). Apart from some minor problems with mysql, the whole thing works like a charm. And the best thing is, with mod_proxy_balancer I can setup another server in 10 minutes. B. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 11, 2007, at 5:01 AM, dankelley wrote:> Choice is bad because it demands time for the choice. Reading > documentation, reading blogs to get real-world comments, and reading > comparisons -- these all take time that would be better spent on > application development. > > Change is bad because it may demand continued work on existing > applications. (That''s probably fine for developers who can then earn > part of their living by maintaining existing sites, but it''s a real > pain for academics and others who are making sites to help with other > work, not as an end in itself.)I don''t agree that choice or change are a bad thing, but I do agree that compared to PHP, RoR deployment can be a challenge. At a very high level, and a very low level, the choice and change are a very good thing. It allows a huge amount of architectural tweaking to be done for those that need it done. I would recommend that you deploy on nginx or Apache 2.2.x with mongrel and mongrel_cluster on the back end, for instance, but I could go into details about the pros and cons of that setup. When you say you''re using Mac OS X, do you mean for final deployment? If so, it''s an interesting choice. Mac OS X is ultra-common for development, but perhaps nearly as ultra-uncommon for deployment. I''m *not* suggesting it''s a poor choice. Whatever you''re comfortable with works for me. P.S. <ad>My company insulates you from choice and change in RoR deployment.</ad> -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
dankelley wrote:> What is the best deployment strategy, for a new application being > created in early 2007, using pre-release RoR 1.2? (I am using OS X, in > case anyone is interested in helping me directly ... but I''m really > asking the question for the benefit of a wider audience.)I pretty much follow this to the letter :-) http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/ ...with an additiona capistrano step to link in a production database.yml from a secure location at update_code time. If you don''t need SSL, it scales easily to having multiple apps running on the same box. Alan -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I''ve asked this before, and I''ll ask it again: what advantages, if any, are there to running Apache over Lilghttpd? Everybody seems to be into Apache these days, but I''ve found Lighttpd to be much easier to install and configure than Apache. I suppose the only advantage I can think of for Apache is the ability to use .htaccess files, but that''s a feature I would rarely use anyway. Jason On 1/12/07, Alan Francis <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > dankelley wrote: > > > What is the best deployment strategy, for a new application being > > created in early 2007, using pre-release RoR 1.2? (I am using OS X, in > > case anyone is interested in helping me directly ... but I''m really > > asking the question for the benefit of a wider audience.) > > I pretty much follow this to the letter :-) > > > http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/ > > ...with an additiona capistrano step to link in a production > database.yml from a secure location at update_code time. > > If you don''t need SSL, it scales easily to having multiple apps running > on the same box. > > Alan > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> I''ve asked this before, and I''ll ask it again: what advantages, if any, are > there to running Apache over Lilghttpd? Everybody seems to be into Apache > these days, but I''ve found Lighttpd to be much easier to install and > configure than Apache. I suppose the only advantage I can think of for > Apache is the ability to use .htaccess files, but that''s a feature I would > rarely use anyway.Apache 2.2.2 is mostly used because of its mod_proxy_balancer which proxies rails reguests to mongrel. Of course, having static content served by apache does not hurt either. Regards, Rimantas -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jason Norris wrote:> I''ve asked this before, and I''ll ask it again: what advantages, if any, are > there to running Apache over Lilghttpd? Everybody seems to be into Apache > these days, but I''ve found Lighttpd to be much easier to install and > configure than Apache. I suppose the only advantage I can think of for > Apache is the ability to use .htaccess files, but that''s a feature I would > rarely use anyway.mod_proxy_balancer if you are using Apache 2.2. -- Michael Wang --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---