você está aqui: Home  → Arquivo de Mensagens

Instalando, iniciando, testando e parando o JBoss AS 6 no Linux Ubuntu 10.04

Colaboração: Paulo Jerônimo

Data de Publicação: 07 de julho de 2010

Neste tutorial, parte integrante do treinamento "JBoss AS - Instalação, configuração e monitoração básica (32h) (JBAS-1)", toda vez que citarmos de maneira simplificada a palavra JBoss estaremos nos referindo ao JBoss AS 6.

Esporadicamente, este tutorial sofre atualizações. Para acompanhá-las, siga @ladoservidor.

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_18"
  OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
  OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
  $ javac -version
  javac 1.6.0_18

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_18"
  OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
  OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
  $ which java
  /usr/bin/java
  $ ls -la /usr/bin/java
  lrwxrwxrwx 1 root root 22 2010-06-30 11:17 /usr/bin/java -> /etc/alternatives/java
  $ ls -la /etc/alternatives/java
  lrwxrwxrwx 1 root root 40 2010-06-30 11:17 /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 38548 2010-04-15 00:43 /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:

  1. Adicionar o repositório de pacotes para o qual foram movidos os pacotes sun-java6-*;
  2. Atualizar a lista de pacotes do Ubuntu;
  3. 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"
  Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
  Java HotSpot(TM) Client VM (build 16.3-b01, 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

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 pela execução do seguinte comando:

  $ cat > instalar-jboss <<'FIM'
  #!/bin/bash
  LOG=/tmp/$$.log
  INSTALADORES_DIR=~/instaladores
  FERRAMENTAS_DIR=~/ferramentas
  JBOSS_ZIP=jboss-as-distribution-6.0.0.20100429-M3.zip
  JBOSS_DIR=jboss-6.0.0.20100429-M3
  JBOSS_DOWNLOADS_URL="http://downloads.sourceforge.net/project/jboss/JBoss/JBoss-6.0.0.M3/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_ZIP" -a -f "$JBOSS_ZIP.md5" ] || {
    for f in $JBOSS_ZIP $JBOSS_ZIP.md5; do
      [ -f "$f" ] && continue
      echo -n "Baixando $f... "
      wget "`echo $JBOSS_DOWNLOADS_URL | sed s,ARQUIVO,$f,g`" &> $LOG
      ok_ou_falha
    done
  }
  echo -n "Verificando o checksum do arquivo $JBOSS_ZIP... "
  test `md5sum $JBOSS_ZIP | cut -d ' ' -f 1` = `cat $JBOSS_ZIP.md5`
  ok_ou_falha
  mkdir -p $FERRAMENTAS_DIR && cd $FERRAMENTAS_DIR
  echo -n "Extraindo $JBOSS_ZIP... "
  rm -rf $JBOSS_DIR; unzip $INSTALADORES_DIR/$JBOSS_ZIP &> $LOG
  ok_ou_falha
  echo -n "Criando o link jboss para $JBOSS_DIR... "
  rm -f jboss; ln -s $JBOSS_DIR jboss
  ok_ou_falha
  grep '^# Ajusta.*JBoss$' ~/.bashrc &> /dev/null && exit 0
  echo -n "Ajustando as variáveis de ambiente para o funcionando do JBoss... "
  cat >> ~/.bashrc <<'EOF'
  # Ajusta as variáveis de ambiente para o funcionamento do JBoss
  export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
  export JBOSS_HOME=FERRAMENTAS_DIR/jboss
  export PATH=$JBOSS_HOME/bin:$PATH
  EOF
  sed -i s,FERRAMENTAS_DIR,$FERRAMENTAS_DIR,g ~/.bashrc
  ok_ou_falha
  FIM

Após a execução do comando acima, será criado o script instalar-jboss, que 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 zip do JBoss: $JBOSS_ZIP
    • A URL base que será utilizada para o download do zip do JBoss: $JBOSS_URL
    • O diretório que será construído pela extração do JBoss: $JBOSS_DIR
  • Cria a função ok_ou_falha que 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_DIR e 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_ZIP.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_ZIP;
  • 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_DIR e 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 apontando 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_HOME tornando mais fácil a substituição do JBoss por outra versão, caso precisemos realizar esta tarefa no futuro;
  • Utiliza o grep para verificar se o conteúdo do arquivo $HOME/.bashrc já 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 ~/.bashrc ajustando o valor para algumas variáveis de ambiente utilizadas pelo JBoss na sua execução. As seguintes variáveis de ambiente são adicionadas:
    • $JAVA_HOME, que guarda a localização do diretório de instalação do JDK;
    • $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 sed para alterar o conteúdo do arquivo ~/.bashrc e substituir a string FERRAMENTAS_DIR pelo valor correspondente a variável $FERRAMENTAS_DIR;
  • 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):

  $ chmod +x instalar-jboss && ./instalar-jboss
  Baixando jboss-as-distribution-6.0.0.20100429-M3.zip... Ok
  Extraindo jboss-as-distribution-6.0.0.20100429-M3.zip... Ok
  Criando o link jboss para jboss-6.0.0.20100429-M3... Ok
  Ajustando as 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 4 ~/.bashrc
  # Ajusta as variáveis de ambiente para o funcionamento do JBoss
  export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
  export JBOSS_HOME=/home/aluno/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:

  $ 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:

  07:59:50,725 INFO  [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.20100429-M3 "Neo"] Started in 38s:311ms

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:

  08:09:59,379 INFO  [AbstractServer] Stopped: JBossAS [6.0.0.20100429-M3 "Neo"] in 7s:999ms

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 (sudo netstat -tulpn | grep `ps -ef | grep org.jboss.Main | awk '{print $2}'`), 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/aluno/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/aluno/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 "`JBAS-1-T". 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 "`JBAS-1-T".

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.sh de "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 jnp://localhost:1199

Nos parâmetros passados ao shutdown.sh, além do -S que já conhecíamos, desta vez também informamos -s jnp://localhost:1199. Isto significa que queremos parar o JBoss que está sendo executado localmente, enviando um comando que será transmitido a porta 1199 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 jnp://localhost:1099. O parâmetro -s ou --server= especifica uma URL para o endereço de um servidor de nomes JNDI (Java Naming and Directory Interface).

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):

  $ sudo netstat -tulpn | grep $(ps -ef | grep org.jboss.Main$ | awk '{print $2}') | sort | head -n3
  tcp        0      0 127.0.0.1:1090          0.0.0.0:*               LISTEN      19352/java      
  tcp        0      0 127.0.0.1:1091          0.0.0.0:*               LISTEN      19352/java      
  tcp        0      0 127.0.0.1:1098          0.0.0.0:*               LISTEN      19352/java      
  tcp        0      0 127.0.0.1:1099          0.0.0.0:*               LISTEN      19352/java      
  tcp        0      0 127.0.0.1:3873          0.0.0.0:*               LISTEN      19352/java      
  tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      19352/java 

Obtendo as portas utilizadas pela segunda instância (ordenando e mostrando apenas as seis primeiras linhas da saída gerada):

  $ sudo netstat -tulpn | grep $(ps -ef | grep org.jboss.Main.*ports-01$ | awk '{print $2}') | sort | head -n6
  tcp        0      0 127.0.0.1:1190          0.0.0.0:*               LISTEN      19357/java      
  tcp        0      0 127.0.0.1:1191          0.0.0.0:*               LISTEN      19357/java      
  tcp        0      0 127.0.0.1:1198          0.0.0.0:*               LISTEN      19357/java      
  tcp        0      0 127.0.0.1:1199          0.0.0.0:*               LISTEN      19357/java      
  tcp        0      0 127.0.0.1:3973          0.0.0.0:*               LISTEN      19357/java      
  tcp        0      0 127.0.0.1:4544          0.0.0.0:*               LISTEN      19357/java

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:

  $ sudo netstat -tulpn | grep `ps -ef | grep org.jboss.Main | awk '{print $2}'`

A linha acima merece algumas explicações! Nela, o netstat está sendo executado com o comando sudo logo, é como se ele estivesse sendo rodado pelo superusuário (root) e, portanto, imprime a informação de todos os processos em execução na máquina. Mas, nós só queremos as informações do processo que executa a JVM do JBoss (ps -ef | 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 segundo campo (na saída do ps). Logo, utilizamos o canivete suiço awk para obter apenas este campo. O número obtido é 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).

A saída do comando executado obviamente varia entre máquinas diferentes mas, deverá ser algo próximo ao apresentado abaixo:

  tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:5500          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:5501          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:4446          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:3873          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:1090          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:1091          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:5445          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:4712          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:8009          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:4713          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:4714          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:1098          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:1099          0.0.0.0:*               LISTEN      11068/java      
  tcp        0      0 127.0.0.1:5455          0.0.0.0:*               LISTEN      11068/java      
  udp        0      0 0.0.0.0:37770           0.0.0.0:*                           11068/java      
  udp        0      0 0.0.0.0:9876            0.0.0.0:*                           11068/java      

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. 11068 e está escutando todas as portas listadas acima.

Fonte: http://a.ladoservidor.com/tutoriais/jbossas6-instala/index.html

Paulo Jerônimo é consultor, instrutor e palestrante. Trabalha com linguagens de programação e ferramentas executadas sob plataformas abertas, baseadas em software livre. Presente no mercado corporativo desde 1993, atualmente produzindo soluções com o uso de frameworks e de práticas ágeis em Java, Python, Scala, Clojure ou Groovy. Vasta experiência em arquitetura, desenvolvimento e infraestrutura para o atendimento a requisitos não funcionais em softwares de missão crítica, escaláveis e tolerantes a falhas, executados por clusters de servidores de aplicações. Currículo completo: http://j.mp/curriculopj


 

 

Veja a relação completa dos artigos de Paulo Jerônimo

Opinião dos Leitores

Flávio Felipe
06 Nov 2014, 11:57
Excelente passo a passo!
felipe
15 Abr 2011, 09:36
Muito obrigado, ajudou bastante
Hermogenes
11 Jul 2010, 02:03
Parabéns pelo artigo. Muito bem elaborado o passo a passo das instalações e configurações. Uma dúvida, no tópico "Instalando JDK da Sun" a última linha do script não seria:
update-java-alternatives -s java-6-sun?
[]s
Hermogenes
*Nome:
Email:
Me notifique sobre novos comentários nessa página
Oculte meu email
*Texto:
 
  Para publicar seu comentário, digite o código contido na imagem acima
 


Powered by Scriptsmill Comments Script