RVM com Passenger e múltiplas instâncias HTTPD

No artigo anterior, falei sobre sobre RVM (Ruby Version Manager), explicando sobre instalação, configuração e seu funcionamento interno. Porém, não mencionei nada sobre seu uso com o Phusion Passenger (A.K.A mod_rails, mod_rack), e algumas pessoas me perguntaram sobre isso. Eu não abordei essa parte no artigo anterior por duas razões: A primeira é porque já era madrugada e o sono já me dominava :) e a segunda porque o artigo iria ficar muito grande e o conteúdo inicial já era suficiente para montar um ambiente local na máquina do desenvolvedor.

Esse artigo basea-se no uso do Apache 2.x e no Sistema Operacional OSX. Porém, as configurações em SOs POSIX se assemelham, portanto usuários do Ubuntu e afins não deverão ter nenhum problema.

Instalando o Passenger em uma Rubie/Gemset

Se você já usa RVM ou seguiu os passos do artigo anterior, já deve ter tudo instalado e configurado e já possui uma Rubie com ou sem Gemsets (não faz diferença ter Gemsets para esse artigo). Caso contrário, leia novamente.

Abra o terminal e entre na sua Rubie/Gemset, instale a gem do passenger e o módulo do apache (ou nginx):

$ rvm use rubie@gemset #ex: rvm use 1.8.7@minhaapp
$ gem install passenger
$ rvmsudo passenger-install-apache2-module

Muita atenção nesse momento. A instalação do módulo do apache (ou nginx) deve ser feita usando rvmsudo. Sem isso não funcionou comigo e acho que com ninguém vai funcionar :)

Feito isso, no fim da instalação do módulo ele vai mandar você colocar aquelas 3 linhas de configuração do Passenger nas suas configs do apache. Eu sugiro criar um arquivo passenger.conf ou similar e colar esse código dentro desse arquivo, pra não misturar com as configs básicas do Servidor Http. Se você estiver usando Mac, as configurações do apache provavelmente estarão em /etc/apache2 e existe um diretório other, onde colocamos as configurações adicionais, como esta que acabamos de criar para o passenger.

Agora precisamos ajustar um detalhe nessas configurações do Passenger. Quando instalamos o Passenger e módulo do apache em uma RVM, a terceira linha da configuração (PassengerRuby) que a instalação sugere, não aponta para o diretório correto, e não funciona. É necessário fazer uma modificação e vou explicar.

Quando instalamos a RMV, ele cria um diretório chamado ~/.rvm/bin, onde ficam todos os executáveis das rubies (ruby, irb, gem, ri, rdoc). A instalação do Passenger não entende isso e aponta para uma estrutura diferente, formada da seguinte maneira: ~/.rvm/rubies/{Rubie}/bin/ruby, e isso não funciona. Portanto, precisamos alterar essa linha para que fique da segunte forma:

$ PassengerRuby ~/.rvm/bin/{Rubie}@{Gemset}

A documentação sugere uma forma diferente dessa, nos indicando executar rvm {Rubie@Gemset} –passenger e substituir essa terceira linha da segunte forma:

$ PassengerRuby ~/.rvm/bin/passenger_ruby

O que isso faz é criar um link symbólico de passenger_ruby apontando para o {Rubie}@{Gemset} que você quer. Eu acho isso desnecessário, principalmente porque você pode querer usar o passenger com várias Rubies diferentes, que é o que vou abordar mais adiante. Portanto, eu prefiro ficar com a primeira opção.

Agora basta configurar o VirtualHost (presumo que você já sabiba fazer isso) e reiniciar o Apache. Nesse momento tudo já deve estar funcionando corretamente e você deve estar conseguindo ver sua aplicação funcionando. Não se esqueça de configurar o /etc/hosts (é bastante comum ver gente capotando porque esqueceu essa parte, rs).

Múltiplas apps em Rubies diferentes

Segundo a documentação do Passenger, a diretiva PassengerRuby deve ser usada apenas uma vez, nos limitando a ter nossas aplicações em uma Rubie/Gemset única. Uma maneira comum de trabalhar com essa limitação é instalar o Ruby Enterprise Edition (i.e. Ruby EE) ou qualquer versão de Ruby e instalar todas as gems de todos os projetos nessa Rubie. A partir daí, basta criar um VirtualHost para cada Aplicação. Essa era a forma que trabalhavamos sem RVM. Com RVM a idéia e sair dessa limitação, podendo por exemplo rodar uma app usando Ruby 1.8.7 com Rails 2.3 e outra com Ruby 1.9.2 e Rails3. Isso inclusive num ambiente de produção, isolando bem as apps e evitando conflitos. Vamos portanto resolver o problema de outra maneira.

Criando uma nova configuração para o Apache

Talvez você não saiba, mas o diretório /etc/apache2 não é o servidor Apache HTTPD propriamente dito, mas as configurações que esse servidor usa quando você sobe a instância. Por padrão, o apachectl procura as configurações nesse diretório, mas é perfeitamente possível indicar o path do arquivo de configuração que você quer usar, e é baseado nisto que vamos usar uma alternativa melhor.

Antes de qualquer coisa, vamos trocar alguns parâmetros na configuração default do Apache, para podermos rodar mais de uma instância sem nenhum tipo de problema acidental. Por padrão, nas configurações em /etc/apache2/httpd.conf tem um Listen definito para *:80. Vamos mudar isso:

Listen 127.0.0.1:80

Mudemos também quaisquer configurações de VirtualHost existentes que estejam usando *:80:

VirtualHost 127.0.0.1:80

Agora chegou a hora de clonar essas configurações para uma nova. Esse trabalho é um pouco chato, portanto resolvi criar um Shell Script para isso chamado osx-clone-apache.sh que pode ser baixado aqui e está no meu gist. Já testei no Snow Leopard e Leopard. Se alguém quiser fazer um para ubuntu e outros SOs é bem vindo e eu coloco como update no artigo.

Baixe o Script e execute a seguinte linha no terminal:

$ sudo ./osx-clone-apache.sh http-clone 127.0.0.1:80 127.0.0.2:80

Onde http-clone é o nome da nova configuração que será criada dentro de /etc, 127.0.0.1:80 é o Listen que está configurado em /etc/apache2 e 127.0.0.2:80 é o novo Listen. Essa nova configuração não leva nada do diretório other nem do passenger_pane_vhosts se você estiver usando o Passenger Preference Pane.

Agora que temos uma nova config do apache apontando para 127.0.0.2:80 precisamos configurar nossa interface de rede para passar a responder a esse ip:

$ ifconfig lo0 alias 127.0.0.2/32

Se não me engano, no Ubuntu isso não é necessário, mas no Mac eu não conheço outra forma de fazer isso. Se alguém souber é bem vindo.

Nesse ponto basta repetir os mesmos procedimentos de configuração de Passenger para novas Rubies e Gemsets para essa nova configuração do apache que acabamos de criar. Mais uma vez não esqueça de ajustar suas configurações no /etc/hosts.

O último passo é subir uma instância do apache usando as novas configurações criadas.

$ sudo apachectl -f /etc/{novaconfig}/httpd.conf -k start

Pronto, você já tem 2 instâncias do Apache rodando versões de Ruby/Rails diferentes na mesma máquina.

Conclusão

O RVM (Ruby Version Manager) trouxe uma nova perspectiva no gerênciamento de ambientes Ruby/Rails. O Deploy de Aplicações com versões de Ruby e Rails usando Phusion Passenger numa mesma máquina se torna trivial, desde que se saiba o que está fazendo. As configurações apresentadas neste artigo podem (e acho que devem) ser usadas também em ambiente de produção, pois a SANDBOX criada é muito mais simples de ser gerênciada do que aquela mistura habitual de VirtualHosts, Gems e afins.

Mãos a obra !!!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Esta entrada foi publicada em infra, rails, ruby, tools e marcada com a tag , , , , , . Adicione o link permanente aos seus favoritos.
  • http://twitter.com/reginaldosousa Reginaldo Sousa

    Quando tento clonar a configuração dá o seguinte erro:
    $sudo ./Documents/osx-clone-apache.sh http-clone 127.0.0.1:80 127.0.0.2:80
    sudo: ./Documents/osx-clone-apache.sh: command not found

  • http://codificando.com Emerson Macedo

    Acho que você esqueceu de dar permissão de execução para o script. Tente chmod a+x Documents/osx-clone-apache.sh e depois rode o comando.

    []s

  • http://twitter.com/rodvlopes Rodrigo V. Lopes

    Fiz até o passo de instalação do passenger e deu tudo certo. Já estou com meu VirtualHost rodando. Valeu.

  • Germano Ricardi

    Para Nginx precisa alterar muita coisa como está sendo alterado no apache?

  • http://codificando.com Emerson Macedo

    Basta criar um arquivo conf do nginx. É muito mais simples.