JBoss 5 com várias (múltiplas) instâncias

JBoss 5 com várias (múltiplas) instâncias

Recentemente precisei configurar o JBoss para funcionar com várias instâncias em uma mesma máquina.

Antes de inciarmos precisamos verificar os seguintes requisitos:

– Não podemos carregar múltiplas instâncias usando os mesmos arquivos de configuração;
– Devemos ter a certeza que todos os serviços de todas as instâncias estão usando portas diferentes entre si;
– Determinar como iremos parar cada um dos serviços.

Para realização desta tarefa, vamos seguir a seguinte estrutura:

1) Configuração das múltiplas instâncias
2) Uso de portas diferentes para serviços distintos entre as instâncias
3) Como parar as instâncias individualmente
4) Testando a aplicação

Vamos começar do início, claramente.

1) Configuração das múltiplas instâncias

Para a configuração dos arquivos em múltiplas instâncias é algo de cópia de arquivos.
Vá até o diretório /jboss/server, lá encontrará vários diretórios e entre eles o default.
Copie este diretório várias vezes quantas forem as instâncias que vc precisar.
Escolhi o diretório default pois este é o mais completo e que normalmente funciona com todas as aplicações. Se vc tem que fazer a configuração que estou explicando aqui, deve entender a diferença entre o minimal, default, web…

Pois bem, altere o nome do diretório para o nome da instância que vc quer, por exemplo, producao, treinamento, homologacao…

2) Uso de portas diferentes para serviços distintos entre as instâncias

O JBoss 5 e até versões anteriores possuem arquivos para a configuração das portas de acesso aos serviços. Geralmente o arquivo a ser configurado está no diretório /jboss/server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml e melhor, normalmente já vem configurado com uma configuração padrão e mais 4 configurações.

Quando se carrega o JBoss normalmente ele utiliza a configuração padrão e assim não é necessário fazer nenhum tipo de configuração a mais. No nosso caso será necessário uma chamada diferente quando na execução do JBoss.

No arquivo referido, o bindings-jboss-beans.xml, possuímos no total 5 configurações, a padrão e mais outras quatro que podemos usar. Neste exemplo não iramos utilizar todas, mas se for necessário apenas acrescente novas configurações conforme explico neste exemplo.

No arquivo bindings-jboss-beans.xml existe:

 <!– Provides management tools with a ProfileService ManagementView 
        interface to the SBM and its components –>
   <bean name=”ServiceBindingManagementObject” 
         class=”org.jboss.services.binding.managed.ServiceBindingManagementObject”>
         
      <constructor>
         <!– The name of the set of bindings to use for this server –>
         <parameter>${jboss.service.binding.set:ports-default}</parameter>
          
         <!–  The binding sets –>
         <parameter>
            <set>
               <inject bean=”PortsDefaultBindings”/>
               <inject bean=”Ports01Bindings”/>
               <inject bean=”Ports02Bindings”/>
               <inject bean=”Ports03Bindings”/>
               <inject bean=”Ports04Bindings”/>
            </set>
         </parameter>
         
         <!– Base binding metadata that is used to create bindings for each set –>
         <parameter><inject bean=”StandardBindings”/></parameter>
         
      </constructor>
   </bean>

que é onde os binds são criados.

Logo abaixo temos

<!– The ports-default bindings are obtained by taking the base bindings and adding 0 to each port value  –>
   <bean name=”PortsDefaultBindings”  class=”org.jboss.services.binding.impl.ServiceBindingSet”>
      <constructor>
         <!–  The name of the set –>
         <parameter>ports-default</parameter>
         <!– Default host name –>
         <parameter>${jboss.bind.address}</parameter>
         <!– The port offset –>
         <parameter>0</parameter>
         <!– Set of bindings to which the “offset by X” approach can’t be applied –>
         <parameter><null/></parameter>
      </constructor>
   </bean>

para a configuração da porta padrão, a configuração padrão conforme vimos anteriormente.

Depois existe a configuração da primeira configuração das portas:

 <!– The ports-01 bindings are obtained by taking the base bindings and adding 100 to each port value –>
   <bean name=”Ports01Bindings”>
      <constructor>
         <!–  The name of the set –>
         <parameter>ports-01</parameter>
         <!– Default host name –>
         <parameter>${jboss.bind.address}</parameter>
         <!– The port offset –>
         <parameter>100</parameter>
         <!– Set of bindings to which the “offset by X” approach can’t be applied –>
         <parameter><null/></parameter>
      </constructor>
   </bean>

Esta configuração diz que o nome dela é ports-01 e que deve usar o endereço padrão e acrescentar 100 à esta porta para a sua inicialização. O que quer dizer isso?

Simples, o JBoss já vem configurado para que você use-o com várias instâncias e essa configuração diz que você pode usá-la e o JBoss irá acrescentar 100 ao endereço padrão das portas dos serviços que a instância requisitar. Portanto, quando você carregar usando esta configuração o JBoss carrega e as portas entre as instâncias não irão ter conflitos.

Bom, para usar a configuração, carregue o JBoss usando o comando:

run -c intância -Djboss.service.binding.set=ports-01

Onde instância é o nome da instância que criou no passo1 e port-01 é o nome que vc pode escolher dentro do arquivo bindings-jboss-beans.xml. Importante salientar que é possível usar duas vezes em  uma mesma máquina o mesmo nome nem da instância, nem do ports-01.

3) Como parar as instâncias individualmente

Após tudo isso feitos, agora como iremos para o serviço?
Usando o comando:

shutdown -s localhost:1099 -S

onde localhost é o nome da máquina que precisamos parar o serviço, 1099 é o número da porta onde foi carregado o JMX da instância. A porta 1099 é para a configuração padrão, para a configuração ports-01 é só adicionar 100, portanto 1199 e assim por diante.

4) Testando a aplicação

Agora é a parte boa, testar e ter certeza que tudo está certo. Como tudo funciona de primeira, essa é a melhor parte 😀
Vamos lá.

Para saber a porta da aplicação é só fazer o mesmo esquema de acrescentar 100 a porta padrão da sessões anteriores, portanto, use o seguinte link para acessar a sua aplicação:

http://localhost:8180/aplicacao

Onde, localhost é o nome da sua máquina, 8180 é a porta para acessar o serviço. Neste exemplo, 8180 é para a configuração ports-01, se estiver usando a configuração padrão, vc já sabe: 8080. E aplicacao  nome da sua aplicação.

Feito.

Tudo é simples quando se sabe fazer 😉

Até a próxima.

Transferência de Arquivos: SSH, SCP, authorized_keys…

Transferência de Arquivos: SSH, SCP, authorized_keys…

Recentemente comecei a configuração de uma novo servidor e precisei usar o SCP.
Utilizo o Jenkins, antigo Hudson, para execução dos meus scripts.
Quando tentei fazer o SCP, que usa o SSH, não funcionou.
Então para que isso funcionasse é necessário a configuração do Sistema Operacional (SO) para funcionar sem ser necessário o uso de senhas, já que eu preciso usar via comando script.

Para que isso seja possível é necessário verificar:
1) O usuário do servidor de origem possui direito no diretório onde está o arquivo de origem;
2) O usuário que será usado para autenticar no servidor destino deve possuir direito no diretório do servidor destino;
3) Possuir o SCP e SSH instalados em ambos os servidores.

Com isto pronto, e normalmente, todos os servidores vem com isso funcionando, vamos começar a configuração.

Serão necessários os seguintes passos para a execução:

a) Acessar o servidor de origem via SSH;
b) Criar o par de chaves assimétricas (chave pública e privada);
c) Colocar a chave pública no servidor de destino;
d) Realizar a cópia do arquivo.

Isto posto, vamos aos seguintes passos:

a) Acessar o servidor de origem via SSH

Acesse o servidor de origem, por exemplo, usando o seguinte comando:

ssh expert@10.1.1.2

onde SSH é o comando para acessar o servidor através de um canal seguro, expert é o nome do usuário e 10.1.1.2 é o endereço do servidor onde está o arquivo que preciso passar ao outro servidor.

b) Criar o par de chaves assimétricas (chave pública e privada)

Vamos criar o par de chaves que irá capacitar aos servidores transitar arquivos entre eles, mas apenas em um sentido. Se for necessário o contrário, também será necessário configurar o outro servidor para isto.

No servidor de origem, vamos executar o comando:

ssh-keygen -t rsa

Irá ser pedido, uma palavra senha, mas como queremos que não seja necessário senha, pressione ENTER para todas as perguntas. Assim serão criadas as chaves públicas e privadas.

c) Colocar a chave pública no servidor de destino

Vamos agora copiar o arquivo de chave pública para o servidor de destino.
Logue o servidor de origem, por exemplo:

ssh expert@10.1.1.2

Vá até o home do usuário:

cd ~

entre no diretório .ssh

copie o arquivo id_rsa.pub para a sua máquina.

Agora vá até o servidor de destino, por exemplo:

ssh expert@10.1.1.3

Vá ao diretório home:

cd ~

entre no diretório .ssh

copie o arquivo id_rsa.pub para este diretório.

Renomeie o arquivo id_rsa.pub para authorized_keys* Este ponto é muito importante para o funcionamento.
Caso já exista este arquivo será necessário fazer o append neste arquivo.

d) Realizar a cópia do arquivo

Se tudo correu bem agora é só realizar a copia do arquivo usando um canal seguro sem o uso de senha.

Para tanto, logue no servidor de origem:

ssh expert@10.1.1.2

e execute o comando para a cópia do arquivo desejado, por exemplo:

scp log.txt expert@10.1.1.3:/proj1

onde SCP é o programa que realiza a cópia do arquivo usando SSH, log.txt é o arquivo que preciso cópia, expert é o nome do usuário que eu configurei o home no servidor de destino, 10.1.1.3 é o servidor de destino e proj1 é o diretório que eu quero o arquivo fique armazenado.

Tomara que com você tenha dado certo na primeira tentativa 😀

Pronto, agora você tem os servidores configurados para a transferência segura entre os dois servidores sem a necessidade colocar senha em nenhum lugar.

Isto é bastante útil para a automatização de tarefas. Você poderá criar tarefas agendadas de cópia entre os dois servidores sem a necessidade de escrever a senha nos arquivos de scripts o que poderia causar problemas na segurança do seu serviço.

Aquele abraço.

Experts Programming

Image

Após muito tempo fazendo códigos e procurando soluções entre os amigos, os conhecidos e também na internet, hoje tenho uma boa ideia sobre como é difícil achar uma solução real para problemas não triviais.

Este é objetivo do blog, colocar bons códigos, soluções de problemas que atrapalham os mais experientes no ramo e principalmente, ter tudo isso on-line e para fácil e rápido acesso.

Não trabalho na área de design nem fotografia, então aquela besteirada de câmera isso ou fonte aquilo, você não encontrará aqui. Só pra constar.

Zx Spectrum