Arquivo da tag: Apache

Apache2 e Tomcat com mod_jk

Nesses últimos dias trabalhei bastante na administração e configuração de servidores *nix na Giran, revivendo algumas experiências antigas e aprendendo muitas outras novas e estou aproveitando para escrever um pouco sobre elas.

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>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.

Integração contínua é com TeamCity

Recentemente fui convidado a montar o ambiente de integração contínua de uma empresa. O trabalho inicial de verificação dos projetos, testes e builds existente foi feito como manda o figurino. Todos os projetos usavam maven2 e, felizmente, todos eles (inclusive os sub-projetos) possuíam pom’s bem configurados e completamente funcionais.

Os builds e processos internos (manuais) para builds da empresa estavam ok, verificados e funcionando. Feito isso fomos aos testes. Testes!? Ok, vamos ao próximo passo e esqueça os testes por enquanto. O controle de versão era feito com Subversion e os clientes usando Tortoise. A IDE utilizada por toda a organização era o IntelliJ IDEA, mesmo assim o cliente para o SVN era o Tortoise, ainda tento compreender isso até hoje.

wheresthebuild-smallA empresa estava em um momento de criação e manutenção de testes funcionais, então, algumas pessoas estavam trabalhando exclusivamente com Selenium. Era uma boa oportunidade, pois estes testes seriam todos automatizados no ambiente de integração contínua a ser preparado. Uma série de procedimentos foram realizados até chegarmos no ambiente de facto, mas vou pular isso para o post não ficar grande e chato de mais.

Comecei então com a preparação de alguns protótipos. Já trabalhei algumas vezes em ambientes de integração contínua com o CruiseControl e também com o CruiseControl.rb, logo pensei em utilizar um desses. Pesquisando e perguntando a conhecidos cheguei às indicações de: Hudson com muitas indicações, Continuum da Apache, TeamCity da JetBrains e Bamboo da Atlassian, sendo estes dois últimos privados e com custo para licença. Ainda assim estava considerando as duas alternativas pagas logo depois de alguma alternativa da família CC, isto porque a empresa possuía licenças do Jira e Confluence, logo o Bamboo poderia ser uma boa pedida devido a recursos de integração. E também possuíam licenças do IntelliJ IDEA, logo a integração com a IDE poderia ser um ponto positivo para o TeamCity.

Alguma coisa aconteceu comigo e na manhã seguinte eu resolvi começar pelas ferramentas que eu não conhecia. Comecei pelo Hudson, TeamCity e por último Continuum, resolvi parar por aqui pra não perder mais tempo, nesse momento já havia uma escolha muito clara e três dias já haviam se passado.

Continue lendo Integração contínua é com TeamCity