Deploy em servidores Wildfly

[adriano.baptistella]

Olá pessoal, tudo bem?

Gostaria de compartilhar com o todos vocês um problema que estou enfrentando na empresa onde trabalho.

Se você tem conhecimento em Deploy automatizados, seja com Wildfly/Jboss Cli ou Ferramentas de DevOps acredito que você possa me ajudar.

Sobre o problema: estamos trabalhando em Java a pelo menos 2 anos. Utilizamos Java 8, Wildfly 8/9, Ferramentas de IC como Jenkins, Sonar, ferramentas de testes unitários, GIT, Hibernate trabalhando com projetos EAR com REST.

Já temos alguns clientes utilizando esse sistema EAR com Jax-rs 2.0 tudo como serviço. Atualmente temos aproximadamente 15 clientes com estes EARs no servidor de aplicação

Obs: cada cliente possui um servidor de aplicação Wildfly pois a base é local do cliente. Porém, estimamos que estes EARs podem estar em poucos meses em 1000 clientes.

Hoje atualizar em 15 clientes esta sendo feito manualmente via Administrador do Wildfly upando os pacotes.

O problema é que temos uma dependência deste EAR em Java com uma aplicação ERP em Delphi. E dependemos de atualizações neste ERP Deplhi para publicar ou não nossos EAR em Java (quem evolui o banco de dados é o ERP Delphi, ou dependemos dele para as novas funcionalidades).

Logo cada cliente poderia estar com versões do serviço diferente.

Gostaríamos de automatizar esse processo de publicação em cliente, onde ao vincularmos a versão X do EAR com a versão X do ERP possamos disparar o deploy em todos os clientes que estejam naquela versão. Talvez com auxílio de alguns serviços existentes podemos verificar qual a versão ideal a ser publicada no Wildfly.

Se não fui claro o suficiente, me perguntem..

A quem entendeu o problema quais seriam as possíveis soluções?

[adrianoschmidt]

Vamos lá... tenho algumas dúvidas:

1) Você vai ter acesso SSH da máquina onde está o seu Jenkins para todas as máquinas onde a aplicação estará hospedada?

2) Caso a resposta acima seja não: todas as máquinas onde a aplicação estará hospedada terão acesso a internet?

3) Como será possível identificar a versão do ERP?

Att,

Adriano Schmidt

[adriano.baptistella]

Grande Adriano Schmitd!

Respondendo suas dúvidas:

1- Sim tem acesso a estes servidores via SSH. Meu Jenkins esta hoje em ambiente interno na empresa mais utilizado para geração de build para equipe de qualidade.

2- Sim, é requisito essencial que estes servidores tenham acesso a internet.

     Obs: temos um produto web e outro mobile, ambos acessam este servidor (não diretamente temos uma facade)

     Web > Acessa uma facade em java que identifica o cliente pelo DNS que retorna onde esta o servidor REST (cliente) > que conecta ao banco de dados do cliente local.

     Precisamos este EAR serviço no cliente pois não acharam seguro expor o banco para portas externas.

3- Atualmente informamos que a versão do serviço 1.00.00.000 trabalha com a versão minima e máxima do ERP Delphi. Então através deste vinculo poderíamos saber quais clientes poderiam receber as atualizações com o EAR Java.

Se ficou alguma dúvida, só perguntar.

Abraço!

[adrianoschmidt]

Certo, eu aconselharia você fazer isso tudo via Jenkins e CLI.

Faça o teste com apenas uma máquina, você acessaria via SSH (O jenkins tem plugin para permitir acesso via ssh) e lá via JBoss CLI faria o deploy.. .poreria até limpar as pastas tmp, work se necessário... e caso precise fazer alguma coisa específica na máquina (como acessar um arquivo em determinado diretório para verificar a versão do ERP) poderia fazer com shell script que seria chamado pelo Jenkins.

mais pra frente... caso você tenha 1000 clientes poderia ver para passar como parâmetro no job do jenkins quais clientes vc quer atualizar... ou no job vc lê um txt com os clientes e faz isso num for...

talvez tenha alguma forma mais elegante de se fazer isso... com outra ferramenta ou até mesmo com o jenkins... mas da forma que falei atenderia....

o que você acha?

Abração!

Adriano Schmidt

[adriano.baptistella]

Legal Adriano!

Atualmente temos a possibilidade de no cliente já baixar o EAR a ser publicado.

Então poderíamos fazer um bkp do EAR atual que esta rodando, tentar subir o EAR novo, seria interessante aqui rodar algumas rotinas de testes, talvez chamar alguns serviços para validar se o sistema esta depé.. se der tudo certo notificaríamos ao portal administrador que o cliente XX atualizou com sucesso para a versão YY do EAR.

Se der falha precisariamos um roolback de pacotes.

Vou buscar mais informações sobre o plugin SSH do Jenkins e criar essa integração com o CLI, talvez um projeto Java pode validar tudo isso pra mim , checar os serviços e invocar o CLI passando o pacote a ser instalado.

Vou dedicar os estudos nessa linha.

Obrigado por enquanto.

[adrianoschmidt]

show! o plugin de SSH é bem fácil de instalar e de usar... já uso há alguns anos...

sobre o bkp e rollback você pode fazer via shell script tmb depois q acessar via SSH..

os testes você pode fazer via java ou se for algo simples só ver se um serviço REST tá de pé por exemplo dá pra fazer com "curl" via linha de comando mesmo...

e fazer deploy/undeploy e parar/subir o wildfly com o CLI é moleza também...

qualquer dúvida só chamar!

abraço!!