Tutorial: Instalando, iniciando, testando e parando o JBoss AS 6
Autor: Paulo Jerônimo
Última atualização: 14/10/2010 às 10:39 - Comentários: http://blog.ladoservidor.com/2010/07/tutorial-nstalando-iniciando-testando-e.html- Checando os pré-requisitos para a instalação
- Instalando um Java Development Kit (JDK)
- Baixando e instalando o JBoss
- Iniciando e parando o JBoss
- Verificando as portas utilizadas pelo JBoss
Checando os pré-requisitos para a instalação
O JBoss é uma aplicação 100% Java, que pode ser executado em qualquer sistema operacional que tenha um Java Development Kit (JDK) instalado na versão 1.5 ou superior.
Como requisitos de hardware, Peter Johnson, um dos autores do livro JBossInAction, recomenda que seja utilizado no mínimo um processador single-core (como o Pentium IV), 1 GB de RAM e 500 MB de espaço livre em disco. É claro que estes requisitos são afetados pela quantidade de usuários que irão utilizar a aplicação e o correto, em qualquer situação, é a ocorrência de testes de carga e de desempenho para avaliar se o hardware que executará o JBoss aguentará a demanda.
Devido ao melhor desempenho do JDK 1.6 em relação as versões anteriores, seu uso é recomendado. Dependendo do hardware, a versão do JDK pode ser a de 32 ou a 64 bits. Entretanto é importante estar atento as características da execução de uma versão JVM 64 bits num hardware compatível:
- Em máquinas de 64 bits:
- Canais duplicados de comunicação entre RAM e CPU melhoram o desempenho para aplicações com grande consumo de memória;
- O endereçamento de memória é virtualmente ilimitado (até 1 hexabyte). Entretanto, grandes heaps afetam o desempenho do coletor de lixo;
- Aplicações que precisam executar com mais de 1,5 GB de RAM (incluindo o espaço livre para otimizações do coletor de lixo) deveriam utilizar JVMs de 64 bits;
- Aplicações que executam numa JVM de 32 bits e não exigem mais que os tamanhos mínimos de heap não irão se aproveitar dos recursos oferecidos por uma JVM de 64 bits;
Nosso próximo passo então será a instalação de um JDK.
Este tutorial, poderá ter seus passos seguidos através do uso da vm-curso-ladoservidor. Isto é recomendável e facilitará as atividades a seguir que, mesmo assim, podem ser executadas em qualquer Ubuntu na versão 10.04.
Instalando um Java Development Kit (JDK)
Versões anteriores a 10.04 do Ubuntu costumavam instalar um JDK através dos pacotes sun-java*. Entretanto nesta versão, o pacote sun-java6-jdk foi movido para outro repositório. Isto tornou sua instalação um pouco mais complexa. Contudo, o objetivo desta mudança foi dar maior visibilidade a versão open source equivalente (o OpenJDK) que pode ser facilmente instalado através dos repositórios de pacotes já configurados.
Instalando o OpenJDK
A instalação do OpenJDK (e o teste das versões de seus binários) é realizada pela execução dos comandos a seguir:
$ sudo apt-get install openjdk-6-jdk $ java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1) OpenJDK Client VM (build 17.0-b16, mixed mode, sharing) $ javac -version javac 1.6.0_20
Na vm-curso-ladoservidor o pacote openjdk-6-jdk já está instalado. Logo, o comando acima não efetua nenhum download/instalação nesta VM. Entretanto, se o removessemos e mandássemos reinstalá-lo, o download deste pacote iria exigir que alguns outros também fossem baixados. É fácil saber quais são eles através da execução do comando abaixo:
$ apt-cache depends openjdk-6-jdk
Se solicitarmos a remoção completa do pacote openjdk-6-jdk podemos notar que, mesmo assim, o comando java continuará a funcionar. Por que? Vamos descobrir, seguindo a execução (e visualizando o resultado) dos comandos abaixo:
$ sudo apt-get purge openjdk-6-jdk $ java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1) OpenJDK Client VM (build 17.0-b16, mixed mode, sharing) $ which java /usr/bin/java $ ls -la /usr/bin/java lrwxrwxrwx 1 root root 22 2010-10-11 11:18 /usr/bin/java -> /etc/alternatives/java $ ls -la /etc/alternatives/java lrwxrwxrwx 1 root root 40 2010-10-11 11:18 /etc/alternatives/java -> /usr/lib/jvm/java-6-openjdk/jre/bin/java $ ls -la /usr/lib/jvm/java-6-openjdk/jre/bin/java -rwxr-xr-x 1 root root 38508 2010-09-07 14:35 /usr/lib/jvm/java-6-openjdk/jre/bin/java $ dpkg -S /usr/lib/jvm/java-6-openjdk/jre/bin/java openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/jre/bin/java
Pela saída apresentada acima, notamos que o comando java é um link simbólico em /usr/bin/java. Este link aponta para outro (/etc/alternatives/java) que por sua vez, aponta para o binário disponibilizado em /usr/lib/jvm/java-6-openjdk/jre/bin/java. Com base na localização real deste binário, o utilitário dpkg-query pode ser utilizado para então determinar qual o pacote que o contém. Por fim, sua saída nos indica que este pacote é o openjdk-6-jre-headless. Ou seja, se apenas desejássemos ter instalado a JRE (e não o JDK), este seria o pacote que deveriamos utilizar.
Para que todo este uso de links simbólicos? Este mecanismo é utilizado no Linux para possibilitar que diferentes alternativas de JDK/JRE possam ser instaladas. O link /etc/alternatives/java é atualizado quando se instala uma versão diferente de JRE, mas o /usr/bin/java não. Para testar isto, vamos executar a instalação do pacote sun-java6-jdk através dos comandos do tópico a seguir.
Instalando o JDK da Sun
Talvez, por qualquer motivo que seja, desejemos não utilizar a versão open source do JDK. Se isto ocorrer, o JDK da falecida Sun (comprada pela Oracle) pode ser instalado no Ubuntu de acordo com os comandos a seguir:
$ sudo bash -c ' add-apt-repository "deb http://archive.canonical.com/ lucid partner" apt-get update apt-get install sun-java6-jdk sun-java6-plugin update-java-alternatives -s java6-sun '
Os comandos acima irão:
- Adicionar o repositório de pacotes para o qual foram movidos os pacotes
sun-java6-*; - Atualizar a lista de pacotes do Ubuntu;
- Implantar a JDK da Sun e o plugin para browsers Mozilla (incluindo o Firefox);
Após ter realizado a instalação, note que o link /etc/alternatives/java agora estará apontando para outro binário, conforme apresentado pela saída do comando a seguir:
$ readlink /etc/alternatives/java /usr/lib/jvm/java-6-sun/jre/bin/java
Note também que as versões apresentadas na execução dos binários do JDK/JRE também mudam:
$ java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1) OpenJDK Client VM (build 17.0-b16, mixed mode, sharing) $ javac -version javac 1.6.0_20
Para vermos que outras alternativas teríamos para os binários do JDK, o comando a seguir poderia ser utilizado:
$ update-java-alternatives -l java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk java-6-sun 63 /usr/lib/jvm/java-6-sun
Sendo assim, podemos novamente apontar os links para os binários do OpenJDK (reinstalando-o) através dos comando a seguir:
$ sudo bash -c ' apt-get install openjdk-6-jdk icedtea6-plugin update-java-alternatives -s java-6-openjdk '
O pacote icdetea6-plugin é similar em funcionalidades ao sun-java6-plugin mas, é open source.
Na opinião do Lado Servidor, o OpenJDK é o futuro que já se tornou presente em termos de Java livre! E, sendo assim, ele merece nossa total chance de uso. Neste tutorial, a versão de JDK de nossa escolha para a execução do JBoss é o OpenJDK.
Baixando e instalando o JBoss
Vamos executar todo o processo de instalação e testes do JBoss através de um novo usuário no sistema. Faremos isto no intuito de organizar melhor nosso ambiente de laboratório e também de não poluir os arquivos do usuário corrente (na vm-curso-ladoservidor, usuário aluno). Sendo assim, nossa primeira tarefa será criar este usuário e, em seguida, nos logaremos como ele, através dos seguintes comandos:
$ sudo useradd -m -s /bin/bash lab_jbossas6 $ sudo su - lab_jbossas6
As tarefas relativas ao download e a instalação do JBoss são muito simples e podem ser realizados de maneira manual através de quatro passos (sendo um opcional):
- Baixar um arquivo compactado da Internet;
- Verificar se o download foi efetuado corretamente, utilizando o utilitário md5sum; (passo opcional)
- Descompactar este arquivo no sistema de arquivos local;
- Ajustar algumas variáveis de ambiente;
Para automatizar este trabalho, deixando-o ainda mais simples, iremos criar e executar um shell-script que poderá ser utilizado várias vezes para refazer as tarefas acima. Além de torná-las automáticas e padronizadas, o script também verificará possíveis erros, como:
- Download incompleto ou errado;
- Impossibilidade de baixar ou extrair o arquivo de instalação do JBoss por qualquer motivo; (Ex.: falta de espaço em disco)
Vamos gerar o script, no diretório bin do usuário, através da execução do seguinte comando:
$ bash -c ' mkdir -p ~/bin && cd ~/bin wget http://a.ladoservidor.com/tutoriais/jbossas6-instala/bin/instalar-jboss chmod +x instalar-jboss '
Após a execução do comando acima, será criado o script instalar-jboss. Você pode visualizar seu conteúdo através do seguinte comando:
$ cat instalar-jboss
#!/bin/bash
LOG=/tmp/$$.log
INSTALADORES_DIR=~/instaladores
FERRAMENTAS_DIR=~/ferramentas
JBOSS_INSTALADOR=jboss-as-distribution-6.0.0.20100911-M5.zip
JBOSS_DIR=jboss-6.0.0.20100911-M5
JBOSS_LINK=jboss
JBOSS_URL_INSTALADOR="http://downloads.sourceforge.net/project/jboss/JBoss/JBoss-6.0.0.M5/ARQUIVO?use_mirror=ufpr"
ok_ou_falha() { [ $? = 0 ] && echo Ok || { echo "Falhou! Veja $LOG"; exit 1; }; }
mkdir -p $INSTALADORES_DIR && cd $INSTALADORES_DIR
[ -f "$JBOSS_INSTALADOR" -a -f "$JBOSS_INSTALADOR.md5" ] || {
for f in $JBOSS_INSTALADOR $JBOSS_INSTALADOR.md5; do
[ -f "$f" ] && continue
echo -n "Baixando $f... "
wget "`echo $JBOSS_URL_INSTALADOR | sed s,ARQUIVO,$f,g`" -O $f &> $LOG
ok_ou_falha
done
}
echo -n "Verificando o checksum do arquivo $JBOSS_INSTALADOR... "
test `md5sum $JBOSS_INSTALADOR | cut -d ' ' -f 1` = `cat $JBOSS_INSTALADOR.md5`
ok_ou_falha
mkdir -p $FERRAMENTAS_DIR && cd $FERRAMENTAS_DIR
echo -n "Extraindo $JBOSS_INSTALADOR... "
rm -rf $JBOSS_DIR; unzip $INSTALADORES_DIR/$JBOSS_INSTALADOR &> $LOG
ok_ou_falha
echo -n "Criando o link $JBOSS_LINK para $JBOSS_DIR... "
rm -f $JBOSS_LINK; ln -s $JBOSS_DIR $JBOSS_LINK
ok_ou_falha
grep '^export JAVA_HOME' ~/.bashrc &> /dev/null || {
echo -n 'Ajustando JAVA_HOME... '
echo 'export JAVA_HOME=/usr/lib/jvm/java-6-openjdk' >> ~/.bashrc
ok_ou_falha
}
grep '^export JBOSS_HOME' ~/.bashrc &> /dev/null && exit 0
echo -n "Ajustando variáveis de ambiente para o funcionando do JBoss... "
cat >> ~/.bashrc <<'EOF'
export JBOSS_HOME=FERRAMENTAS_DIR/JBOSS_LINK
export PATH=$JBOSS_HOME/bin:$PATH
EOF
sed -i "
s,FERRAMENTAS_DIR,$FERRAMENTAS_DIR,g
s,JBOSS_LINK,$JBOSS_LINK,g
" ~/.bashrc
ok_ou_falha
Este script realiza as seguintes tarefas:
- Ajusta algumas variáveis que representam:
- O log de execução para algumas tarefas (
$LOG), que será gerado no diretório /tmp com o nome do arquivo sendo o número do processo em execução; - O diretório que conterá o instalador do JBoss:
$INSTALADOR_DIR - O diretório que conterá o JBoss após sua instalação:
$FERRAMENTAS_DIR - O instalador do JBoss:
$JBOSS_INSTALADOR - A URL base que será utilizada para o download do zip do JBoss:
$JBOSS_URL_INSTALADOR - O diretório que será construído pela extração do JBoss:
$JBOSS_DIR - O link simbólico para o diretório de instalação:
$JBOSS_LINK
- O log de execução para algumas tarefas (
- Cria a função
ok_ou_falhaque verificará se houve erro na execução do comando anterior e, em caso positivo, abortará a execução do mesmo; - Cria o diretório
$INSTALADOR_DIRe efetua a mudança para ele (mkdir -p ...); - Baixa, caso não existam, o zip de instalação do JBoss e o arquivo que contém seu checksum (
$JBOSS_INSTALADOR.md5) redirecionando a saída do comando para$LOG; - Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
- Testa o md5sum do
$JBOSS_INSTALADOR; - Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
- Cria o diretório
$FERRAMENTAS_DIRe efetua a mudança para ele (mkdir -p ...); - Remove o diretório de instalação do JBoss (caso exista) e extrai o conteúdo o zip do JBoss (
unzip ...); - Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
- Remove (caso exista) e cria o link simbólico
$JBOSS_LINKapontando para o diretório no qual foi extraído o JBoss (ln -s ...);- A criação deste link simbólico simplificará o valor da variável
$JBOSS_HOMEtornando mais fácil a substituição do JBoss por outra versão, caso precisemos realizar esta tarefa no futuro;
- A criação deste link simbólico simplificará o valor da variável
- Utiliza o
greppara verificar se o conteúdo do arquivo$HOME/.bashrcjá contém a localização do$JAVA_HOMEe, em caso negativo, adiciona esta localização;- Cria a variável
$JAVA_HOMEno caso dela já não estar configurada;
- Cria a variável
- Utiliza o
greppara verificar se o conteúdo do arquivo$HOME/.bashrcjá foi atualizado com as configurações das variáveis de ambiente e, em caso positivo, encerra a execução do script; - Adiciona conteúdo ao arquivo
~/.bashrcajustando o valor para algumas variáveis de ambiente utilizadas pelo JBoss na sua execução. As seguintes variáveis de ambiente são adicionadas:$JBOSS_HOME, que guarda a localização do diretório de instalação do JBoss;$PATH, que agora agregará a localização para os binários do JBoss ($JBOSS_HOME/bin);
- Utiliza o
sedpara alterar o conteúdo do arquivo~/.bashrce substituir as stringsFERRAMENTAS_DIReJBOSS_LINKpelos valores correspondentes das variáveis$FERRAMENTAS_DIRe$JBOSS_LINK; - Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
A execução do script instalar-jboss, e o carregamento das variáveis de ambientes necessárias para a execução do JBoss AS, podem ser realizadas através da execução dos comandos a seguir (observe a saída de execução do instalar-jboss):
$ ./instalar-jboss Baixando jboss-as-distribution-6.0.0.20100911-M5.zip... Ok Baixando jboss-as-distribution-6.0.0.20100911-M5.zip.md5... Ok Verificando o checksum do arquivo jboss-as-distribution-6.0.0.20100911-M5.zip... Ok Extraindo jboss-as-distribution-6.0.0.20100911-M5.zip... Ok Criando o link jboss para jboss-6.0.0.20100911-M5... Ok Ajustando JAVA_HOME... Ok Ajustando variáveis de ambiente para o funcionando do JBoss... Ok $ source ~/.bashrc
O script instalar-jboss poderá ser executado quantas vezes for necessário. Ele sempre apagará a instalação anterior do JBoss e refazê-la. Só baixará o instalador do JBoss caso ele não seja encontrado. Verificará se o checksum MD5 do instalador está correto e, só reajustará o conteúdo de ~/.bashrc caso isto já não tenha sido realizado.
Você pode verificar se o ajuste do arquivo ~/.bashrc foi realizado com sucesso através da execução do comando tail, com o parâmetro -n 4 para solicitar apenas a impressão das quatro últimas linhas deste arquivo:
$ tail -n 3 ~/.bashrc export JAVA_HOME=/usr/lib/jvm/java-6-openjdk export JBOSS_HOME=/home/lab_jbossas6/ferramentas/jboss export PATH=$JBOSS_HOME/bin:$PATH
Quando o comando source ~/.bashrc é executado, o shell corrente refaz a leitura deste arquivo. Com isto, as variáveis de ambiente ficam disponíveis. Como este arquivo é lido a cada vez que se abre um shell no Linux, estas variáveis estarão disponíveis toda vez que isto ocorrer.
A partir deste ponto, estamos preparados para executar o JBoss. Isto é o que faremos nos próximos passos.
Iniciando e parando o JBoss
Da forma mais básica e simples possível
A execução do JBoss pode ser realizada através do comando a seguir (encontrado em $JBOSS_HOME/bin e que deverá já estar no PATH em função da execução dos comandos anteriores):
$ run.sh
Quando o comando acima é invocado, o JBoss inicia sua execução. Vários serviços serão levantados por ele e o log de execução aparece na tela aberta.
Após o JBoss subir todos os serviços da configuração corrente e estar pronto para ser executado, uma mensagem como a apresentada a seguir, deverá estar presente na console de sua execução:
19:07:46,198 INFO [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.20100911-M5 "Neo"] Started in 30s:137ms
Este é o sinal visível pelo log, de que o JBoss foi iniciado.
Para finalizar a execução do JBoss existem várias alternativas. A mais simples delas, caso tenhamos acesso a console de sua execução, é pressionar, simultaneamente, as teclas Ctrl e C (Ctrl+C). Desta forma, um sinal de shutdown será enviado ao JBoss para que ele possa encerrar sua execução, educadamente. Isto significa que ele solicitará, para cada um dos serviços em execução, o seu encerramento. Quando tudo estiver consumado ;-), no log da console aberta deveremos notar uma frase como a apresentada a seguir:
19:08:53,226 INFO [AbstractServer] Stopped: JBossAS [6.0.0.20100911-M5 "Neo"] in 3s:50ms
Colocando o JBoss em background
Talvez não queiramos que a execução do JBoss esteja atrelada a uma console. Sendo assim, a forma correta de iniciarmos o JBoss seria através do comando a seguir:
$ JBOSS_CONSOLE=/tmp/jboss.log; nohup run.sh &> $JBOSS_CONSOLE &
Com isto, o log de execução do JBoss (tanto para a saída padrão quanto de erros) será direcionado ao arquivo /tmp/jboss.log. O comando nohup desatrela a execução do comando run.sh do shell corrente e o &, ao final do comando, coloca a execução do JBoss em background, liberando o shell corrente para a digitação de novos comandos.
Uma característica desta forma de inicialização do JBoss é que não veremos mais o seu log na tela aberta. Para podermos então acessá-lo, faremos uso do comando tail, conforme demonstrado a seguir:
$ tail -f $JBOSS_CONSOLE
Outra característica importante é que, mesmo fechando o shell corrente, o JBoss continuará em execução. Experimente isto! Feche a console corrente, e abra uma nova. Após fazer isto, verifique que o processo de execução do JBoss ainda está ativo, através da chamada ao seguinte comando:
$ ps -ef | grep org\.jboss\.Main
A classe org.jboss.Main é classe que inicializa o JBoss, e que é executada na execução do comando java através script run.sh.
Outra forma de verificar a execução de uma aplicação Java, de uma forma mais portável, é utilizar o comando jps. Ele é um utilitário do JDK e, sendo assim, pode ser utilizado nos diferentes sistemas operacionais que suportam o Java. O uso do jps, para saber se o JBoss está em execução, é exemplificado a seguir:
$ jps -l | grep org\.jboss\.Main
Agora que não temos mais acesso a console de execução do JBoss, como encerrá-lo? Alguns brutos diriam: kill -9 no process id (PID) do JBoss ;-). Mas, nós somos educados! A menos que o JBoss não o seja conosco, nós não iremos utilizar o comando kill e, em seu lugar, invocaremos o comando a seguir:
$ shutdown.sh -S
Isto fará com que o JBoss entenda que queremos tirá-lo de campo ;-).
No Linux, mesmo que o JBoss já esteja em execução, podemos colocá-lo em background. Para isto, os procedimentos são:
- Iniciar o JBoss da forma mais básica e simples possível (
run.sh). Como vimos, ele ficará atrelado a execução da console corrente; - Digitar, simultaneamente, as teclas Ctrl e Z (
Ctrl+Z). Isto fará com que o processo em execução do JBoss seja parado; - Executar o comando
bg. Isto colocará a execução do JBoss em background. Mas, trará o inconveniente de que qualquer log de sua execução ainda aparecerá na tela da console aberta.
Execute os procedimentos acima antes de prosseguir!
Permitindo o acesso para além de localhost
Por medida de segurança o JBoss não permite, nas formas de inicialização que foram apresentadas anteriormente, que ocorra o acesso aos serviços levantados por ele, fora de localhost. Isto significa, por exemplo, que não conseguiriamos acessar as interfaces administrativas do JBoss a partir de outra máquina. Como testar isto? Existem algumas formas. Uma delas é observar que portas estão sendo utilizadas pelo processo do JBoss, como apresentado no tópico "Verificando as portas utilizadas pelo JBoss". Execute os comandos daquele tópico e depois retorne a este.
Pelo que podemos observar, por padrão todas as portas TCP abertas pelo JBoss são acessíveis apenas pelo endereço IP 127.0.0.1 (localhost). Logo, tirando a própria máquina que executa o JBoss, nenhuma outra poderá acessar seus serviços.
Liberar o acesso ao JBoss para outras máquinas, implica em reinicializá-lo com um parâmetro que informe que ele deverá se ligar a uma interface de rede que tenha um IP acessível por outras máquinas, ou, que ele deverá se ligar a todas as interfaces de rede. Estas tarefas podem ser realizadas através do parâmetro de inicialização "-b <IP_OU_NOME>". Vamos então parar o JBoss em execução e levantá-lo novamente, com este parâmetro:
$ shutdown.sh -S; tail -f $JBOSS_CONSOLE
Ao perceber que o JBoss foi finalizado com sucesso através da observação do log, damos um Ctrl+C na execução do tail e reinicializamos o JBoss:
$ JBOSS_CONSOLE=/tmp/jboss.log; nohup run.sh -b 0.0.0.0 &> $JBOSS_CONSOLE &
Agora, pelo uso do parâmetro "-b 0.0.0.0" passado ao run.sh, estamos solicitando ao JBoss que ele entre em execução aguardando conexões oriundas de qualquer uma de suas interfaces de rede.
Após reexecutar o comando que nos possibita averiguar as portas utilizadas pelo JBoss (netstat -tulpn | grep $(jps -l | grep org\.jboss\.Main | cut -d " " -f 1)), poderemos observar um resultado semelhante ao apresentado a seguir (são mostradas apenas algumas linhas):
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 13415/java tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 13415/java tcp 0 0 0.0.0.0:5500 0.0.0.0:* LISTEN 13415/java tcp 0 0 0.0.0.0:4444 0.0.0.0:* LISTEN 13415/java
Vendo a saída apresentada, notamos que conexões as portas 8080, 8083, etc, podem ser realizadas a partir de qualquer uma das interfaces de rede. Isto é identificado na saída pelo número do IP apresentado antes do número da porta: "0.0.0.0".
Podemos testar o acesso a uma porta servida pelo JBoss, através do comando telnet, como exemplificado a seguir: (Substitua o IP apresentado por um IP válido em tua máquina, diferente do IP 127.0.0.1.)
$ telnet 187.25.148.177 8080 Trying 187.25.148.177... Connected to 187.25.148.177. Escape character is '^]'. ^]Connection closed by foreign host.
Se desejássemos que o JBoss se ligasse apenas a uma interface de rede específica informaríamos, no lugar de "-b 0.0.0.0", o IP ou o nome da máquina associada a ele (pelo arquivo /etc/hosts ou pelo DNS). Por exemplo, -b 192.168.2.101.
Colocando uma instância diferente em execução
Uma instância de JBoss, é uma configuração em execução. O JBoss, ao ser instalado, vem com diferentes configurações e cada uma delas é localizada no diretório $JBOSS_HOME/server, conforme apresentado na saída do comando a seguir:
$ tree -L 1 -d $JBOSS_HOME/server /home/lab_jbossas6/ferramentas/jboss/server ├── all ├── default ├── jbossweb-standalone ├── minimal ├── osgi └── standard
A saída acima apresenta 6 configurações distintas. Por padrão, quando não é especificado que configuração será executada, o jboss levantará a "default".
Cada configuração, possui um conjunto próprio de diretórios e arquivos. Por exemplo, na configuração "default", temos os seguintes diretórios no primeiro nível:
$ tree -L 1 -d $JBOSS_HOME/server/default /home/lab_jbossas6/ferramentas/jboss/server/default ├── conf ├── data ├── deploy ├── deployers ├── lib ├── log ├── tmp └── work
O escopo deste tópico não abrange a explicação de cada um destes diretórios. Isto é abordado em outra parte do treinamento "JBoss AS - Instalação, configuração e monitoração básica (32h) (JBAS-1)". Entretanto, é aqui que informamos que, para levantar uma instância diferente de JBoss, o parâmetro "-c <configuracao>" deve ser passado ao script run.sh. Devemos também notar que "run.sh" ou "run.sh -c default" significam a mesma coisa. Para testar o uso deste parâmetro, vamos finalizar a instância corrente:
$ shutdown.sh -S; tail -f $JBOSS_CONSOLE
Agora, vamos iniciar uma instância diferente do JBoss, a "minimal":
$ run.sh -c minimal
Podemos observar que esta instância sobe em bem menos tempo que a "default". Dê um Ctrl+C em sua console para finalizá-la.
Também foge do escopo deste tópico as explicacões para as configurações de JBoss. Mais informações sobre isto podem ser obtidas no treinamento "JBoss AS - Instalação, configuração e monitoração básica (32h) (JBAS-1)".
Colocando mais de uma instância em execução
É possível subir várias instâncias do JBoss ao mesmo tempo. Basicamente, existem duas alternativas para isto: utilizar um IP diferente para cada instância ou, utilizar um conjunto de portas diferente para cada uma delas.
A alternativa mais comum para administradores de servidores Linux, após terem conhecido o uso do parâmetro "-b <IP_OU_NOME>", discutido no tópico anterior, é realizar a criação de uma interface de rede (virtual ou não) e levantar cada instância de JBoss num IP específico. Esta alternativa entretanto, exige o domínio de comandos do Linux. A outra solução, utilizar portas diferentes para o JBoss, não exige conhecimentos específicos de Linux e pode ser aplicada em diferentes sistemas operacionais.
Através de portas diferentes
A execução de mais de uma instância de JBoss através do uso de um conjunto diferente de portas, para cada uma delas, é realizada na versão 6 pelo uso de uma propriedade de sistema, passado para a JVM que executará a instância.
O procedimento é bem simples. Uma segunda instância baseada em "default" poderá subir da seguinte forma:
- Copiamos o conteúdo de "default" para outro diretório, também abaixo de
$JBOSS_HOME/server/, com o nome que desejarmos. Por exemplo: "instancia2"; - Executamos o
run.shde "instancia2" informando a propriedade de sistema com o parâmetro "-Dpropriedade=valor";
Estes são os comandos que irão criar "intancia2" e colocá-la em execução, ao mesmo tempo em que será realizada a inicialização da instância "default":
$ bash -c ' cp -r $JBOSS_HOME/server/default $JBOSS_HOME/server/instancia2 nohup run.sh &> /tmp/jboss.default.log & nohup run.sh -c instancia2 -Djboss.service.binding.set=ports-01 &> /tmp/jboss.instancia2.log & '
Para parar a segunda instância, podemos executar o seguinte comando:
$ shutdown.sh -S -s service:jmx:rmi:///jndi/rmi://localhost:1190/jmxrmi
Nos parâmetros passados ao shutdown.sh, além do -S que já conhecíamos, desta vez também informamos -s service:jmx:rmi:///jndi/rmi://localhost:1190/jmxrmi. Isto significa que queremos parar o JBoss que está sendo executado localmente, enviando um comando que será transmitido a porta 1190 do JBoss em execução. Por padrão, quando não informamos estes parâmetros/valores, é como se estivéssemos escrito shutdown.sh -S -s -s service:jmx:rmi:///jndi/rmi://localhost:1090/jmxrmi (1090 é a porta utilizada na configuração default).
Quando utilizamos o valor ports-01 para a propriedade jboss.service.bind.set cada uma das portas utilizadas pela configuração default (sem o uso desta propriedade) tem o seu valor incrementado de 100. Se utilizarmos o valor ports-02, ao valor padrão é somado 200, e assim por diante... Podemos observar isto pelo uso do netstat:
Obtendo as portas utilizadas pela primeira instância (ordenando e mostrando apenas as seis primeiras linhas da saída gerada):
netstat -tulpn | grep $(jps -l | grep org\.jboss\.Main | cut -d " " -f 1) | sort | head -n6 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 127.0.0.1:1090 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:1091 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:1098 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:1099 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:3873 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:4446 0.0.0.0:* LISTEN 2430/java
Obtendo as portas utilizadas pela segunda instância (ordenando e mostrando apenas as seis primeiras linhas da saída gerada):
$ netstat -tulpn | grep $(jps -lm | grep org\.jboss\.Main.*ports-01 | cut -d " " -f 1) | sort | head -n6 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 127.0.0.1:1190 0.0.0.0:* LISTEN 2822/java tcp 0 0 127.0.0.1:1191 0.0.0.0:* LISTEN 2822/java tcp 0 0 127.0.0.1:1198 0.0.0.0:* LISTEN 2822/java tcp 0 0 127.0.0.1:1199 0.0.0.0:* LISTEN 2822/java tcp 0 0 127.0.0.1:3973 0.0.0.0:* LISTEN 2822/java tcp 0 0 127.0.0.1:4546 0.0.0.0:* LISTEN 2822/java
O comando acima utiliza o -lm como argumento passado ao jps. O parâmetro -m diz ao jps que ele deverá também imprimir os argumentos passados para o método main da classe Java que está sendo executada (org.jboss.Main). Sendo assim, podemos então utilizar o grep para saber que estamos lidando com o conjunto de portas ports-01, ao invés do default e então, descobrirmos que portas são utilizados por este conjunto. Observe que, nesta instância, todas as portas apresentadas tem seu valor incrementado de 100 (em relação a primeira).
Através de IPs diferentes
Executar outra instância do JBoss através de IPs diferentes já foi explicado. Não é mais novidade que o parâmetro "-b <IP_OU_NOME>", passado ao run.sh, possibilita a execução de uma outra instância do JBoss num IP diferente mas, escutando o mesmo conjunto de portas. A questão é: e se tivermos apenas uma interface de rede, por exemplo, a eth0? Bem, neste caso, se não quisermos mesmo utilizar um conjunto diferente de portas, a solução é criar uma interface de rede virtual.
Uma interface de rede virtual pode ser criada no linux com o comando ifconfig. Supondo que estamos na rede 192.168.1.0 e que o IP 192.168.1.2 esteja disponível, o comando a seguir criaria a interface virtual eth0:0:
$ ifconfig eth0 add 192.168.1.2 netmask 255.255.255.0
Agora, teríamos uma interface de rede virtual, associada a mesma placa de rede mas com um IP diferente e, com isto, poderíamos iniciar o JBoss neste novo IP através de run.sh -b 192.168.1.2. Não haveria nenhum problema nesta abordagem e nem conflitos no uso de portas.
Para remover a interface virtual o mesmo ifconfig poderia ser utilizado, informando-se os parâmetros abaixo:
$ ifconfig eth0 del 192.168.1.2
Verificando as portas utilizadas pelo JBoss
O comando netstat possibilita-nos averiguar que portas são utilizadas por um processo em execução. Para testá-lo, caso o JBoss não esteja no ar, vamos iniciá-lo:
$ JBOSS_CONSOLE=/tmp/jboss.log; nohup run.sh &> $JBOSS_CONSOLE &
Agora, a partir da execução do comando a seguir, solicitaremos ao netstat que nos informe que portas estão sendo utilizadas pelo PID do JBoss:
$ netstat -tulpn | grep $(jps -l | grep org\.jboss\.Main | cut -d " " -f 1) | sort
A linha acima merece algumas explicações! Nela, o netstat está sendo executado para imprimir a informação de todos os processos em execução do usuário corrente. Mas, nós só queremos as informações do processo que executa a JVM do JBoss (jps -l | grep org\.jboss\.Main). A partir do resultado obtido com este comando, queremos pegar o PID do processo. Em sua saída já temos isto, mas queremos apenas um número, que é representado pelo primeiro campo da saída do jps. Logo, utilizamos o comando cut para obtê-lo. Este número é passado ao grep que, por sua vez, recebe como entrada, a saída do netstat filtrando assim, apenas as portas utilizadas pelo JBoss (colhemos da saída do netstat apenas os processo com o PID do mesmo). Para ter uma saída ordenada, utilizamos o comando sort.
A saída do comando executado obviamente varia entre máquinas diferentes mas, deverá ser algo próximo ao apresentado abaixo:
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 127.0.0.1:1090 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:1091 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:1098 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:1099 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:3873 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:4446 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:4712 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:4713 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:4714 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:5445 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:5455 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:5500 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:5501 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:8009 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 2430/java tcp 0 0 127.0.0.1:8083 0.0.0.0:* LISTEN 2430/java
Podemos observar que, como não estamos executando o comando netstat como root, recebemos uma notificação deste comando informando que não veremos informações de outros processos que não sejam do usuário corrente (lab_jbossas6). Na quarta coluna, temos um par de valores IP:porta. A sexta coluna, onde para as conexões do tipo tcp está escrito LISTEM, indica que tais IPs/portas estão aguardando conexões. A sétima coluna nos informa o PID do processo que está escutando tal porta. Logo, neste exemplo, o PID do JBoss é de nr. 2340 e está escutando todas as portas listadas acima.