De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
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.
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:
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.
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.
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.
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:
sun-java6-*;
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.
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):
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:
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:
$LOG), que será gerado no diretório /tmp com o nome do arquivo sendo o número do processo em execução;
$INSTALADOR_DIR
$FERRAMENTAS_DIR
$JBOSS_ZIP
$JBOSS_URL
$JBOSS_DIR
ok_ou_falha que verificará se houve erro na execução do comando anterior e, em caso positivo, abortará a execução do mesmo;
$INSTALADOR_DIR e efetua a mudança para ele (mkdir -p ...);
$JBOSS_ZIP.md5) redirecionando a saída do comando para $LOG;
$JBOSS_ZIP;
$FERRAMENTAS_DIR e efetua a mudança para ele (mkdir -p ...);
unzip ...);
jboss apontando para o diretório no qual foi extraído o JBoss (ln -s ...);
$JBOSS_HOME tornando mais fácil a substituição do JBoss por outra versão, caso precisemos realizar esta tarefa no futuro;
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;
~/.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);
sed para alterar o conteúdo do arquivo ~/.bashrc e substituir a string FERRAMENTAS_DIR pelo valor correspondente a variável $FERRAMENTAS_DIR;
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.
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
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:
run.sh). Como vimos, ele ficará atrelado a execução da console corrente;
Ctrl+Z). Isto fará com que o processo em execução do JBoss seja parado;
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!
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.
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".
É 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.
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:
$JBOSS_HOME/server/, com o nome que desejarmos. Por exemplo: "instancia2";
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
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
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
This policy contains information about your privacy. By posting, you are declaring that you understand this policy:
This policy is subject to change at any time and without notice.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
Comentários