Implantar manualmente um aplicativo Java com JBoss EAP em um cluster do Azure Red Hat OpenShift

Este artigo mostra como implantar um aplicativo Red Hat JBoss Enterprise Application Platform (EAP) em um cluster do Azure Red Hat OpenShift. O exemplo é um aplicativo Java apoiado por um banco de dados SQL. O aplicativo é implantado usando gráficos do Helm do JBoss EAP.

Neste guia, você aprenderá a:

O aplicativo de exemplo é um aplicativo com monitoração de estado que armazena informações em uma sessão HTTP. Ele faz uso dos recursos de cluster JBoss EAP e usa as seguintes tecnologias Jakarta EE e MicroProfile:

• Jakarta Server Faces
• Jakarta Enterprise Beans
• Persistência do Jakarta
• MicroProfile Health

Este artigo é uma orientação manual passo a passo para executar o aplicativo JBoss EAP em um cluster do Azure Red Hat OpenShift. Para obter uma solução mais automatizada que acelera sua jornada para o cluster do Azure Red Hat OpenShift, consulte Guia de início rápido: implantar o JBoss EAP no Azure Red Hat OpenShift usando o portal do Azure.

Se você estiver interessado em fornecer comentários ou trabalhar em estreita colaboração em seu cenário de migração com a equipe de engenharia que desenvolve o JBoss EAP em soluções do Azure, preencha esta breve pesquisa sobre a migração do JBoss EAP e inclua suas informações de contato. A equipe de gerentes de programas, arquitetos e engenheiros entrará em contato prontamente com você para dar início a uma estreita colaboração.

Pré-requisitos

1. Prepare uma máquina local com um sistema operacional do tipo Unix suportado pelos vários produtos instalados - como Ubuntu, macOS ou Windows Subsystem for Linux.

2. Instale uma implementação do Java Standard Edition (SE). As etapas de desenvolvimento local neste artigo foram testadas com o Java Development Kit (JDK) 17 da compilação Microsoft do OpenJDK.

3. Instale o Maven 3.8.6 ou posterior.

4. Instale a CLI do Azure 2.40 ou posterior.

5. Clone o código deste aplicativo de demonstração (lista de pendências) para o sistema local. O aplicativo de demonstração está no GitHub.

6. Siga as instruções em Criar um cluster do Red Hat OpenShift 4 no Azure.

   Embora a etapa "Obter um segredo de pull do Red Hat" seja rotulada como opcional, ela é necessária para este artigo. O segredo pull permite que o cluster do Azure Red Hat OpenShift localize as imagens do aplicativo JBoss EAP.

   Se você planeja executar aplicativos com uso intensivo de memória no cluster, especifique o tamanho adequado da máquina virtual para os nós de trabalho usando o parâmetro --worker-vm-size. Para saber mais, veja:

   • CLI do Azure para criar um cluster
   • Tamanhos de máquina virtual compatíveis com a otimização para memória

7. Conecte-se ao cluster seguindo as etapas em Conectar-se a um cluster do Red Hat OpenShift 4 no Azure.

   • Siga as etapas em "Instalar a CLI do OpenShift"
   • Conectar-se a um cluster do Red Hat OpenShift no Azure usando a CLI do OpenShift com o usuário kubeadmin

8. Execute o seguinte comando para criar o projeto OpenShift para este aplicativo de demonstração:

   oc new-project eap-demo
   

9. Execute o comando a seguir para adicionar a função de exibição à conta de serviço padrão. Essa função é necessária para que o aplicativo possa descobrir outros pods e configurar um cluster com eles:

   oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)
   

Preparar o aplicativo

Clone o aplicativo de exemplo usando o seguinte comando:

git clone https://github.com/Azure-Samples/jboss-on-aro-jakartaee

Você clonou o aplicativo de Todo-list demonstração e seu repositório local está na main ramificação. O aplicativo de demonstração é um aplicativo Java simples que cria, lê, atualiza e exclui registros no SQL do Azure. Você pode implantar esse aplicativo como ele está em um servidor JBoss EAP instalado em sua máquina local. Você só precisa configurar o servidor com o driver de banco de dados e a fonte de dados necessários. Você também precisa de um servidor de banco de dados acessível em seu ambiente local.

No entanto, quando você estiver visando o OpenShift, convém cortar os recursos do seu servidor JBoss EAP. Por exemplo, talvez você queira reduzir a exposição de segurança do servidor provisionado e reduzir o espaço ocupado em geral. Talvez você também queira incluir algumas especificações do MicroProfile para tornar seu aplicativo mais adequado para execução em um ambiente do OpenShift. Quando você usa o JBoss EAP, uma maneira de realizar essa tarefa é empacotando seu aplicativo e seu servidor em uma única unidade de implantação conhecida como JAR inicializável. Vamos fazer isso adicionando as alterações necessárias ao nosso aplicativo de demonstração.

Navegue até o repositório local do aplicativo de demonstração e altere o branch para bootable-jar:

## cd jboss-on-aro-jakartaee
git checkout bootable-jar

Vamos rever rapidamente o que alteramos nesse branch:

• Adicionamos o wildfly-jar-maven plugin para provisionar o servidor e o aplicativo em um único arquivo JAR executável. A unidade de implantação do OpenShift é o nosso servidor com o nosso aplicativo.
• No plugin Maven, especificamos um conjunto de camadas do Galeão. Essa configuração nos permite cortar os recursos do servidor apenas para o que precisamos. Para ver a documentação completa no Galleon, confira a documentação do WildFly.
• Nosso aplicativo usa Jakarta Faces com solicitações Ajax, o que significa que há informações armazenadas na sessão HTTP. Não queremos perder essas informações caso um pod seja removido. Poderíamos salvar essas informações no cliente e enviá-las de volta em cada solicitação. No entanto, há casos em que você pode decidir não distribuir determinadas informações para os clientes. Para esta demonstração, optamos por replicar a sessão em todas as réplicas de pod. Para fazer isso, adicionamos <distributable /> ao web.xml. Isso, juntamente com os recursos de cluster de servidor, torna a sessão HTTP distribuível em todos os pods.
• Adicionamos duas verificações de integridade do MicroProfile que permitem identificar quando o aplicativo está ativo e pronto para receber solicitações.

Executar o aplicativo localmente

Antes de implantar o aplicativo no OpenShift, vamos executá-lo localmente para verificar como ele funciona. As etapas a seguir pressupõem que você tenha o SQL do Azure em execução e disponível em seu ambiente local.

Para criar o banco de dados, siga as etapas no Início Rápido: criar um banco de dados individual do Banco de Dados SQL do Azure, mas use as seguintes substituições.

• Para Grupo de recursos, use o grupo de recursos criado anteriormente.
• Para Nome do banco de dados, use todos_db.
• Em Logon do administrador do servidor, use azureuser.
• Para Senha, use Passw0rd!.
• Na seção Regras de firewall, alterne Permitir que serviços e recursos do Azure acessem este servidor para Sim.

Todas as outras configurações podem ser usadas com segurança no artigo vinculado.

Na página Configurações adicionais, você não precisa escolher a opção de preencher previamente o banco de dados com dados de exemplo, mas não há nenhum dano em fazer isso.

Depois de criar o banco de dados, obtenha o valor do nome do servidor na página de visão geral. Passe o mouse sobre o valor do campo Nome do servidor e selecione o ícone de cópia que aparece ao lado do valor. Salve esse valor de lado para uso posterior (definimos uma variável nomeada MSSQLSERVER_HOST para esse valor).

Siga as etapas abaixo para criar e executar o aplicativo localmente.

1. Crie o JAR inicializável. Como estamos usando o banco de dados com o eap-datasources-galleon-pack MS SQL Server, devemos especificar a versão do driver de banco de dados que queremos usar com essa variável de ambiente específica. Para obter mais informações sobre o eap-datasources-galleon-pack MS SQL Server, consulte a documentação da Red Hat

   export MSSQLSERVER_DRIVER_VERSION=7.4.1.jre11
   mvn clean package
   

2. Inicie o JAR inicializável usando os comandos a seguir.

   Você deve garantir que o banco de dados SQL do Azure permita o tráfego de rede do host no qual esse servidor está sendo executado. Como você selecionou Adicionar endereço IP do cliente atual ao executar as etapas no Início Rápido: criar um banco de dados único do Banco de Dados SQL do Azure, se o host no qual o servidor está em execução for o mesmo host do qual seu navegador está se conectando ao portal do Azure, o tráfego de rede deverá ser permitido. Se o host no qual o servidor está sendo executado for algum outro host, você precisará consultar Usar o portal do Azure para gerenciar regras de firewall IP no nível do servidor.

   Quando estamos iniciando o aplicativo, precisamos passar as variáveis de ambiente necessárias para configurar a fonte de dados:

   export MSSQLSERVER_USER=azureuser
   export MSSQLSERVER_PASSWORD='Passw0rd!'
   export MSSQLSERVER_JNDI=java:/comp/env/jdbc/mssqlds
   export MSSQLSERVER_DATABASE=todos_db
   export MSSQLSERVER_HOST=<server name saved aside earlier>
   export MSSQLSERVER_PORT=1433
   mvn wildfly-jar:run
   

   Se você quiser saber mais sobre o runtime subjacente usado por essa demonstração, a documentação Pack de Recursos do Galleon para integrar fontes de dados tem uma lista completa de variáveis de ambiente disponíveis. Para obter detalhes sobre o conceito de feature-pack, confira a documentação do WildFly.

   Se você receber um erro com texto semelhante ao exemplo a seguir:

   Cannot open server '<your prefix>mysqlserver' requested by the login. Client with IP address 'XXX.XXX.XXX.XXX' is not allowed to access the server.
   

   Essa mensagem indica que suas etapas para garantir que o tráfego de rede seja permitido não funcionaram. Verifique se o endereço IP da mensagem de erro está incluído nas regras de firewall.

   Se você receber uma mensagem com texto semelhante ao exemplo a seguir:

   Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: There is already an object named 'TODOS' in the database.
   

   Essa mensagem indica que os dados de exemplo já estão no banco de dados. Você pode ignorar esta mensagem.

3. (Opcional) Se você quiser verificar os recursos de clustering, também poderá iniciar mais instâncias do mesmo aplicativo passando o argumento jboss.node.name para o JAR inicializável e, para evitar conflitos com os números de porta, deslocando os números de porta usando jboss.socket.binding.port-offset. Por exemplo, para iniciar uma segunda instância que representa um novo pod no OpenShift, você pode executar o seguinte comando em uma nova janela de terminal:

   export MSSQLSERVER_USER=azureuser
   export MSSQLSERVER_PASSWORD='Passw0rd!'
   export MSSQLSERVER_JNDI=java:/comp/env/jdbc/mssqlds
   export MSSQLSERVER_DATABASE=todos_db
   export MSSQLSERVER_HOST=<server name saved aside earlier>
   export MSSQLSERVER_PORT=1433
   mvn wildfly-jar:run -Dwildfly.bootable.arguments="-Djboss.node.name=node2 -Djboss.socket.binding.port-offset=1000"
   

   Se o cluster estiver funcionando, você poderá ver no log do console do servidor um rastreamento semelhante ao seguinte:

   INFO  [org.infinispan.CLUSTER] (thread-6,ejb,node) ISPN000094: Received new cluster view for channel ejb
   

   Observação

   Por padrão, o JAR inicializável configura o subsistema JGroups para usar o protocolo UDP e envia mensagens para descobrir outros membros do cluster para o endereço multicast 230.0.0.4. Para verificar corretamente os recursos de clustering em seu computador local, seu sistema operacional deve ser capaz de enviar e receber datagramas multicast e encaminhá-los para o IP 230.0.0.4 por meio de sua interface ethernet. Se você vir avisos relacionados ao cluster nos logs do servidor, verifique sua configuração de rede e verifique se ela dá suporte a multicast nesse endereço.

4. Abra http://localhost:8080/ no navegador para visitar a home page do aplicativo. Se você criou mais instâncias, poderá acessá-las alterando o número da porta, por exemplo http://localhost:9080/. O aplicativo deve ser semelhante à imagem a seguir:

   

5. Verifique as investigações de disponibilidade e preparação para o aplicativo. O OpenShift usa esses pontos de extremidade para verificar quando seu pod está ativo e pronto para receber solicitações do usuário.

   Para verificar o status de disponibilidade, execute:

   curl http://localhost:9990/health/live
   

   Você deverá ver este resultado:

   {"status":"UP","checks":[{"name":"SuccessfulCheck","status":"UP"}]}
   

   Para verificar o status de prontidão, execute:

   curl http://localhost:9990/health/ready
   

   Você deverá ver este resultado:

    {"status":"UP","checks":[{"name":"deployments-status","status":"UP","data":{"todo-list.war":"OK"}},{"name":"server-state","status":"UP","data":{"value":"running"}},{"name":"boot-errors","status":"UP"},{"name":"DBConnectionHealthCheck","status":"UP"}]}
   

6. Pressione CTRL + C para interromper o aplicativo.

Implantar no OpenShift

Para implantar o aplicativo, usaremos os gráficos JBoss EAP Helm já disponíveis no Azure Red Hat OpenShift. Também precisamos fornecer a configuração desejada, por exemplo, o usuário do banco de dados, a senha do banco de dados, a versão do driver que desejamos usar e as informações de conexão usadas pela fonte de dados. As etapas a seguir pressupõem que você tenha o SQL do Azure em execução e acessível a partir do cluster OpenShift e tenha armazenado o nome de usuário, a senha, o nome do host, a porta e o nome do banco de dados do banco de dados em um objeto OpenShift OpenShift Secret chamado mssqlserver-secret.

Navegue até o repositório local do aplicativo de demonstração e altere o branch atual para bootable-jar-openshift:

git checkout bootable-jar-openshift

Vamos fazer uma rápida revisão sobre o que mudamos neste ramo:

• Adicionamos um novo perfil Maven chamado bootable-jar-openshift que prepara o JAR inicializável com uma configuração específica para executar o servidor na nuvem. Por exemplo, ele permite que o subsistema JGroups use solicitações de rede para descobrir outros pods usando o protocolo KUBE_PING.
• Adicionamos um conjunto de arquivos de configuração no diretório jboss-on-aro-jakartaee/deployment . Neste diretório, você pode encontrar os arquivos de configuração para implantar o aplicativo.

Implantar o aplicativo no OpenShift

As próximas etapas explicam como você pode implantar o aplicativo com um gráfico do Helm usando o console Web OpenShift. Evite codificar valores confidenciais em seu gráfico Helm usando um recurso chamado 'segredos'. Um segredo é simplesmente uma coleção de pares nome=valor, onde os valores são especificados em algum lugar conhecido antes de serem necessários. Em nosso caso, o gráfico do Helm usa dois segredos, com os pares name=value a seguir de cada um.

• mssqlserver-secret

  • db-host transmite o valor de MSSQLSERVER_HOST.
  • db-name transmite o valor de MSSQLSERVER_DATABASE
  • db-password transmite o valor de MSSQLSERVER_PASSWORD
  • db-port transmite o valor de MSSQLSERVER_PORT.
  • db-user transmite o valor de MSSQLSERVER_USER.

• todo-list-secret

  • app-cluster-password transmite uma senha arbitrária especificada pelo usuário para que os nós de cluster possam se formar com mais segurança.
  • app-driver-version transmite o valor de MSSQLSERVER_DRIVER_VERSION.
  • app-ds-jndi transmite o valor de MSSQLSERVER_JNDI.

1. Crie mssqlserver-secret.

   oc create secret generic mssqlserver-secret \
       --from-literal db-host=${MSSQLSERVER_HOST} \
       --from-literal db-name=${MSSQLSERVER_DATABASE} \
       --from-literal db-password=${MSSQLSERVER_PASSWORD} \
       --from-literal db-port=${MSSQLSERVER_PORT} \
       --from-literal db-user=${MSSQLSERVER_USER}
   

2. Crie todo-list-secret.

   export MSSQLSERVER_DRIVER_VERSION=7.4.1.jre11
   oc create secret generic todo-list-secret \
       --from-literal app-cluster-password=mut2UTG6gDwNDcVW \
       --from-literal app-driver-version=${MSSQLSERVER_DRIVER_VERSION} \
       --from-literal app-ds-jndi=${MSSQLSERVER_JNDI}
   

3. Abra o console do OpenShift e navegue até a exibição de desenvolvedor. Você pode descobrir a URL do console do cluster OpenShift executando este comando. Faça login com o ID de usuário e senha que você obteve de kubeadmin uma etapa anterior.

   az aro show \
       --name $CLUSTER \
       --resource-group $RESOURCEGROUP \
       --query "consoleProfile.url" \
       --output tsv
   

   Selecione a <perspectiva /> Desenvolvedor no menu suspenso na parte superior do painel de navegação.

   

4. <Na perspectiva /> Desenvolvedor, selecione o projeto eap-demo no menu suspenso Projeto.

   

5. Selecione +Adicionar. Na seção Catálogo de Desenvolvedores, selecione Gráfico do Helm. Você chega ao catálogo do Helm Chart disponível no cluster do Azure Red Hat OpenShift. Na caixa Filtrar por palavra-chave, digite eap. Você deve ver várias opções, como mostrado aqui:

   

   Como nosso aplicativo usa recursos MicroProfile, selecionamos o Helm Chart para EAP Xp. O Xp significa Pacote de Expansão. Com o pacote de expansão do JBoss Enterprise Application Platform, os desenvolvedores podem usar APIs (interfaces de programação de aplicativo) do Eclipse MicroProfile para criar e implantar aplicativos baseados em microsserviços.

6. Selecione o JBoss EAP XP 4 Helm Chart e, em seguida, selecione Install Helm Chart.

Neste ponto, precisamos configurar o pacote para criar e implantar o aplicativo:

1. Altere o nome da versão para eap-todo-list-demo.

2. Podemos configurar o Pacote do Helm usando uma Exibição de Formulário ou uma Exibição YAML. Na seção rotulada Configurar por meio de, selecione Exibição YAML.

3. Altere o conteúdo YAML para configurar o Pacote do Helm copiando e colando o conteúdo do arquivo do Pacote do Helm disponível em deployment/application/todo-list-helm-chart.yaml em vez do conteúdo existente:

   

   Este conteúdo faz referências aos segredos que você definiu anteriormente.

4. Por fim, selecione Instalar para iniciar a implantação do aplicativo. Essa ação abre o modo de exibição Topologia com uma representação gráfica da versão do Helm (chamada eap-todo-list-demo) e seus recursos associados.

   

   A Versão do Helm (abreviada como HR) é denominada eap-todo-list-demo. Ela inclui um recurso de implantação (abreviado como D) também chamado eap-todo-list-demo.

   Se você selecionar o ícone com duas setas em um círculo no canto inferior esquerdo da caixa D , será levado para o painel Logs . Aqui você pode observar o progresso do build. Para retornar ao modo de exibição de topologia, selecione Topologia no painel de navegação esquerdo.

5. Quando a compilação for concluída, o ícone no canto inferior esquerdo exibirá uma verificação verde

6. Quando a implantação for concluída, o contorno do círculo será azul escuro. Se você passar o mouse sobre o azul escuro, você verá uma mensagem aparecendo informando algo semelhante ao 3 Running. Quando você vir essa mensagem, poderá acessar a URL do aplicativo (usando o ícone superior direito) da rota associada à implantação.

   

7. O aplicativo é aberto no navegador, pronto para ser usado, com aparência semelhante à seguinte imagem:

   

8. O aplicativo mostra o nome do pod que serve as informações. Para verificar as funcionalidades de clustering, você pode adicionar algumas tarefas pendentes. Em seguida, exclua o pod com o nome indicado no campo Nome do Host do Servidor que aparece no aplicativo usando oc delete pod <pod-name>. Depois de excluir o pod, crie um novo Todo na mesma janela do aplicativo. Você pode ver que o novo Todo é adicionado por meio de uma solicitação Ajax e o campo Nome do Host do Servidor agora mostra um nome diferente. Nos bastidores, o balanceador de carga do OpenShift despachou a nova solicitação e a entregou em um pod disponível. A visualização Jakarta Faces é restaurada a partir da cópia da sessão HTTP armazenada no pod que está processando a solicitação. Na verdade, você pode ver que o campo ID da Sessão não foi alterado. Se a sessão não for replicada em seus pods, você receberá um Jakarta Faces ViewExpiredExceptione seu aplicativo não funcionará conforme o esperado.

Limpar os recursos

Excluir o aplicativo

Se você quiser apenas excluir seu aplicativo, poderá abrir o console do OpenShift e, na exibição do desenvolvedor, navegar até a opção de menu Helm. Neste menu, você pode ver todas as versões do Helm Chart instaladas no cluster.

Localize o Pacote do Helm eap-todo-list-demo e, no final da linha, selecione os pontos verticais da árvore para abrir a entrada do menu contextual de ação.

Selecione Desinstalar a Versão do Helm para remover o aplicativo. Observe que o objeto secreto usado para fornecer a configuração do aplicativo não faz parte do gráfico. Você precisará removê-lo separadamente se não precisar mais dele.

Execute o seguinte comando se você quiser excluir o segredo que contém a configuração do aplicativo:

$ oc delete secrets/todo-list-secret
# secret "todo-list-secret" deleted

Excluir o projeto OpenShift

Você também pode excluir toda a configuração criada para esta demonstração excluindo o projeto eap-demo. Para fazer isso, execute o seguinte comando:

$ oc delete project eap-demo
# project.project.openshift.io "eap-demo" deleted

Excluir o cluster do Azure Red Hat OpenShift

Exclua o cluster do Azure Red Hat OpenShift seguindo as etapas em Tutorial: Excluir um cluster do Azure Red Hat OpenShift 4.

Exclua o grupo de recursos

Se você quiser excluir todos os recursos criados pelas etapas anteriores, exclua o grupo de recursos criado para o cluster do Azure Red Hat OpenShift.

Próximas etapas

Você pode saber mais sobre as referências usadas neste guia:

• Red Hat JBoss Enterprise Application Platform
• Red Hat OpenShift no Azure
• Pacotes do Helm do JBoss EAP
• JAR inicializável do JBoss EAP

Continue a explorar as opções para executar o JBoss EAP no Azure.