Configurando um servidor de desenvolvimento da Giran as novidades não foram grandes, a maioria das aplicações, serviços e preocupações foram as mesmas de um ambiente de desenvolvimento local. Já as experiências com a configuração do servidor de produção foram bem mais legais e algumas inéditas. Oracle, MySQL, SVN, Gitorious, Ruby Enterprise Edition + Passenger e claro, Apache 2 HTPP Server e Apache Tomcat.

Por hora vou escrever apenas sobre o mod_jk, que é a integração entre o Apache 2 HTPP Server e o Apache Tomcat. Eu já tive experiências anteriores com o mod_jk em ambientes de produção, em ambientes com redudância, com tomcat, com jboss e alguns mais, mas ainda não havia passado por uma situação onde eu iniciasse do zero e todas as responsabilidades estivessem comigo, e isso foi ótimo.

Um resumo do ambiente:

• Ubuntu Server 8.04
• Apache 2 HTTP Server 2.2.8
• Apache Tomcat 6.0.18
• JDK 1.6.0_13

O Apache

O Apache e o mod_jk foram instalados usando o próprio apt-get, então esta tarefa foi realmente muito fácil:

jeveaux@baium ~ $ sudo apt-get install apache2 libapache2-mod-jk

Uma série de pacotes e dependências virão junto com os dois pacotes acima, pode confirmar que tudo vai dar certo.

Esta instalação deixará o Apache em /etc/apache2, onde nós teremos (os principais arquivos):

• httpd.conf – Configuração geral do apache.
• conf.d – Configurações diversas, todos arquivos que estiverem nesse diretório serão carregados como configuração.
• mods-available – Arquivos de configuração e ativação dos módulos.
• mods-enabled – Módulos que estão ativados no apache, são links simbólicos para os arquivos do diretório mods-available.
• sites-available – Arquivos de configuração dos sites (VirtualHost).
• sites-enabled – Sites que estão ativados, são links simbólicos para os arquivos do diretório sites-available.

No httpd.conf poucas coisas precisam de intervenção, pessoalmente eu gosto muito deste esquema de organização e divisão de configurações utilizada pelo apache. Por exemplo, tudo que estiver no diretório APACHE2_HOME/mods-enabled será carregado automaticamente, primeiro todos os arquivo .load, que geralmente contém o LoadModule, e depois todos os arquivos .conf, que contém as configurações específicas do módulo, desta forma temos vários pares load+conf, um para cada módulo.

O JDK e o Tomcat

Apesar do servidor ser Ubuntu, desta vez eu não usei o apt-get. Eu sempre preferi instalar o JDK e algumas outras ferramentas de forma manual, não sei exatamente porque tenho essa mania, mas não consigo fugir.

O que importa é que o JAVA_HOME e o PATH estejam ajustados, se isso estiver correto tanto faz se você instalar usando o apt-get ou não. De qualquer forma, se você optar por usar o apt-get, basta seguir o comando abaixo:

jeveaux@baium ~ $ sudo apt-get install sun-java6-jdk tomcat5.5

Se não, se você for paranóico como eu, certifique-se de ter configurado o JAVA_HOME e o PATH manualmente no seu .bashrc:

export JAVA_HOME=/development/jdk1.6.0_13
export PATH=$JAVA_HOME/bin:$PATH

O mod_jk

O mod_jk já foi instalado anteriormente, então só precisamos certificar de que ele esteja ativado.

Caso você queira ativar ou desativar um módulo, existem duas maneiras: 1) usar os comandos a2enmod <mod> e a2dismod <mod> ou simplesmente criar ou remover os links simbólicos em APACHE2_HOME/mods-enabled.

1) Configurar os workers

A instalação foi tão simples que somente um arquivo nos interessa por enquanto: /etc/libapache2-mod-jk/workers.properties. Abaixo apenas as configurações mais importantes e algumas que precisaremos alterar:

workers.tomcat_home=/development/apache-tomcat-6.0.18
workers.java_home=/development/jdk1.6.0_13
worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=1

No workers.properties temos o mapeamento do tomcat (workers.tomcat_home) e do JDK (workers.java_home). Há outra propriedade muito importante que é a worker.list, nela definimos todos “workers” que teremos. Para um único servidor teremos apenas um worker, mas em ambientes de cluster teremos vários. E temos para cada worker as suas configurações particulares: port, host e type, além de uma em particular, muito importante em ambiente de cluster e load balancer, a lbfactor, que indica a quantidade de trabalho do worker no conjunto, quanto menor o valor, menor o esforço do worker, ou seja, menos requisições serão despachadas para este worker.

2) Iniciar (ou montar) o JK

Mais uma vez temos dois caminhos a seguir aqui. Iniciar o JK no site principal ou em algum VirtualHost (sub-domínio) específico. O que vai mudar é onde você vai inserir o código a seguir.

Caso queira colocar o JK no seu site principal, você poderá inserir o código abaixo no seu httpd.conf – o que eu não recomendo – ou criar um arquivo jk.conf em APACHE2_HOME/mods-available, depois criar o link simbólico para este arquivo em APACHE2_HOME/mods-enabled.

Mas se você quiser ou precisar usar o JK somente em algum site e/ou sub-domínio específico, insira o código abaixo direto no arquivo do site em APACHE2_HOME/sites-enabled.

JkWorkersFile   /etc/libapache2-mod-jk/workers.properties
JkLogFile       /var/log/apache2/mod_jk.log
JkLogLevel      info
JkMount /*.jsp ajp13_worker
JkMount /teste/* ajp13_worker

Com essas configurações estamos escolhendo qual arquivo de workers vamos usar (JkWorkerFile), ou seja, qual o tomcat e JDK. Também definimos o arquivo de log e qual o tipo de log será gravado e, o ponto chave, quando o JK será usado. O JkMount pode ser repetido quantas vezes for preciso e é nele que definiremos todos os padrões de URL quanto forem precisos para que o JK seja usado.

É neste momento, configurando o JkMount, que podemos dividir o processamento de recursos dinâmicos (jsp, servlet) para o Tomcat e recursos estáticos para o Apache. Não vou entrar nesse ponto neste artigo, mas fica a dica.

Com o trecho acima estamos encaminhando para o tomcat – através do JK – tudo que terminar com .jsp ou tudo que estiver após /teste.

O Deployment

Aqui tudo correrá como qualquer aplicação Java, sem nenhuma diferença. Chamaremos nossa aplicação Java de “teste”. Após o deploy podemos acessa-la como de costume em http://localhost:8080/teste, mas agora com o JK podemos acessar também através da porta 80 (apache) em http://localhost/teste.

Depois de uma passada habitual pelo Blog do Luca, fiquei sabendo em primeira mão do lançamento do Event Server da BEA, junto veio de tabela uma nova versão do Real Time Server.

Estou rodando esse brinquedinho aqui em casa mas ainda não consegui ver diferenças significativas entre o WLS8.1 e WLS9.2 que tenho aqui, como ainda não simulei uma grande quantidade de eventos para testa-lo, ficarei com a dúvida se esta é mais uma técnica milagrosa da BEA para vender mais algumas centenas de licenças ou se o novo servidor realmente suportará os 50.000 eventos complexos e simultâneos, como se propõe a fazer. Pelo que pude ver no site do Event Server, ele tem um novo Dashboard que me pareceu muito interessante e útil, só que ainda não consegui usa-lo, se alguém souber como por favor me avise ou se alguém já estiver usando-o, deixe um comentário :D