Olá a Todos!
Saudações.
Buscando ampliar os debates em relação ao RoR (RubyOnRails), está aqui um
post do blog do Akita (www.akitaonrails.com, com seus dévidos créditos, é um
blog que recomendo sua leitura diária, muita coisa interessante!), onde ele
fala do momento de colocar uma aplicação RoR em produção, o que achei muito
interessante.
---------------------------
Posted by AkitaOnRails on quinta-feira, 18 de maio de 2006
Estou no capítulo sobre Deployment de Rails em ambiente de produção.
Afinal, qual a vantagem de se desenvolver um grande aplicativo, totalmente Ajax
se não sabemos como colocá-lo para o uso de nossos usuários?
The Usual Suspects são Apache2 + FastCGI, LightTPD + FastCGI. Não há muitas
outras opções. WEBRick é um servidor competente para nossos testes durante o
desenvolvimento mas dificilmente serve para produção.
Temos dispatch.cgi, o que significa CGI. Acredito que este suporte exista
apenas para o último caso, talvez para algo próximo ao Dia do Apocalipse. Nah,
CGI não é opção, esqueçam.
Mas Apache tem o mod_ruby. Também não, é um projeto pouco atualizado,
instável e jamais serviria para produção.
Também temos ouvido falar de SCGI, uma simplificação do FastCGI, mas ainda é
muito novo. Falta amadurecer para receber a responsabilidade de nossa produção.
Bom, então só pode ser Apache2 + FCGI. Também não. Infelizmente o projeto
mod_fastcgi estava quase abandonado, tem vários problemas de deixar processos
zumbis sobrando, defuntos. Não desejo esse tipo de problema para ninguém.
Chegamos ao LightTPD + FCGI, que é a opção recomendada pelo próprio David
Hansson e é usado por todos os seus produtos na 37signals. De fato, Lighty vem
sendo muito bem desenvolvido, tem performance e robustez quase comparáveis ao
Apache e o melhor: tem um excelente suporte a FCGI. Para ambiente nix talvez
seja mesmo o ideal. \u003c/p\>\n\u003cp\>Mas e ambientes Windows? Lighty é
compilado usando Cygwin e ainda é um estágio muito experimental. Não tem
suporte para se instalar como um Windows Service, dependendo de produtos de
terceiros. Há pouca maturidade nisso. \n\u003c/p\>\n\u003cp\>Mas felizmente,
Zed Shaw, o criador de um suporte ao \u003cspan\>SCGI\u003c/span\> para Rails
trouxe uma alternativa muito mais atraente: *Mongrel. Ele é uma biblioteca e um
servidor \u003cspan\>HTTP\u003c/span\> totalmente feito em Ruby. Para aqueles
que não fugiram das aulas de compiladores no curso de Ciências da Computação,
seu processador de \n\u003cspan\>HTTP\u003c/span\> foi feito
com Ragel.\u003c/p\>\n\u003cp\>\u003cem\>"Mas WEBRick também é feito em
Ruby"\u003c/em\>. Acreditem, não analisei ainda para saber a mágica, mas Zed
Shaw fez um milagre. Sim, o interpretador Ruby talvez seja um dos mais lentos,
mesmo assim Mongrel é muito bom, e com as capacidades de cache do Rails, ele é
a melhor solução hoje. Funciona muito bem em ambiente unix e também tem suporte
muito bom para Windows. Pode ser instalado via RubyGems e ainda se instala como
Windows Service. \n\u003c/p\>\n\u003cp\>Com suporte para cluster com
\u003cstrong\>Mongrel_Cluster\u003c/strong\>, é ainda mais simples de escalar.
Tanto Apache quanto Lighty tem bons suportes a proxy reverso e load balancing,
o que facilita mais ainda colocar os velhos conhecidos na linha de frente e
Mongrel no backend, servindo Rails. Acredito que este seja o melhor denominador
comum de todas as soluções de produção. \n\u003c/p\>\n\u003cp\>Prestem atenção
ao trabalho de Zed Shaw, ainda vem novidades por aí.
Sabendo que muitos brasileiros se vêem obrigados a lidar com ambientes Windows
em seus clientes, esta é uma excelente notícia a
todos.\u003c/p\>\u003c/div\>\n\u003cdiv\> \u003c/div\>\n\u003cdiv\> \u003c/div\>\n\u003cdiv\>disponível
em: \u003ca
href\u003d\"http://www.akitaonrails.com/articles/find_by_date?month\u003d5&year\u003d2006\";
target\u003d\"_blank\" onclick\u003d\"return
top.js.OpenExtLink(window,event,this)\"\>http://www.akitaonrails.com\u003cWBR\>/articles/find_by_date?month\u003d5\u003cWBR\>&year\u003d2006\n\u003c/a\>\u003c/div\>\n\u003cdiv\> \u003c/div\>\n\u003cdiv\> \u003c/div\>\n\u003cdiv\> \u003c/div\>\n\u003cdiv\>p.s:
testei um pequeno exemplo de cadastro de usuários, em uma máquina Intel
Pentium III 750 Mhz com 256 MB RAM, GNU/Debian ",1] ); //-->
Mas e ambientes Windows? Lighty é compilado usando Cygwin e ainda é um
estágio muito experimental. Não tem suporte para se instalar como um Windows
Service, dependendo de produtos de terceiros. Há pouca maturidade nisso.
Mas felizmente, Zed Shaw, o criador de um suporte ao SCGI para Rails trouxe
uma alternativa muito mais atraente: *Mongrel. Ele é uma biblioteca e um
servidor HTTP totalmente feito em Ruby. Para aqueles que não fugiram das aulas
de compiladores no curso de Ciências da Computação, seu processador de HTTP foi
feito com Ragel.
"Mas WEBRick também é feito em Ruby". Acreditem, não analisei ainda para
saber a mágica, mas Zed Shaw fez um milagre. Sim, o interpretador Ruby talvez
seja um dos mais lentos, mesmo assim Mongrel é muito bom, e com as capacidades
de cache do Rails, ele é a melhor solução hoje. Funciona muito bem em ambiente
unix e também tem suporte muito bom para Windows. Pode ser instalado via
RubyGems e ainda se instala como Windows Service.
Com suporte para cluster com Mongrel_Cluster, é ainda mais simples de
escalar. Tanto Apache quanto Lighty tem bons suportes a proxy reverso e load
balancing, o que facilita mais ainda colocar os velhos conhecidos na linha de
frente e Mongrel no backend, servindo Rails. Acredito que este seja o melhor
denominador comum de todas as soluções de produção.
Prestem atenção ao trabalho de Zed Shaw, ainda vem novidades por aí. Sabendo
que muitos brasileiros se vêem obrigados a lidar com ambientes Windows em seus
clientes, esta é uma excelente notícia a todos.
disponível em:
http://www.akitaonrails.com/articles/find_by_date?month=5&year=2006
---------------------------
Bom, tenho realmente essa dúvida, como colocar o RoR em produção. Como já foi
dito nesta lista, não é um trabalho fácil fazer o RoR rodar junto com o apache.
Depois de algumas muitas horas, consegui, fazendo ele rodar usando CGI, o que
não demonstrou uma performance muito atraente. Segui o how to disponível em:
http://www.howtoforge.com/ruby_on_rails_debian_etch
Sem querer duvidar do Akita, mas como já disse antes, ampliando os debates
sobre o assunto, a melhor solução seria o uso do Mongrel? Mongrel Cluster com
Apache?
abraços a todos,
Luiz (lufeos)
p.s: desculpem pelo e-mail longo.
---------------------------------
Novo Yahoo! Cadê? - Experimente uma nova busca. _______________________________________________
Ruby-l mailing list
[email protected]
http://www.listas.unicamp.br/mailman/listinfo/ruby-l
