Compartilhar via

Migrar aplicativos WebLogic Server para o WildFly no Serviço de Kubernetes do Azure

  • Artigo

Este guia descreve as informações das quais você deve estar ciente quando deseja migrar um aplicativo WebLogic Server existente para ser executado no WildFly em um contêiner do Serviço de Kubernetes do Azure.

Pré-migração

Antes de tudo, para garantir uma migração bem-sucedida, conclua as etapas de avaliação e de inventário descritas nas seções a seguir.

Se você não puder atender aos requisitos de pré-migração, confira o guia de migração complementar:

Inventariar a capacidade do servidor

Documente o hardware (memória, CPU, disco) dos servidores de produção atuais, assim como as contagens de solicitações média e de pico e a utilização de recursos. Você precisará dessas informações independentemente do caminho de migração que escolher. Elas são úteis, por exemplo, para ajudar a orientar a seleção do tamanho das VMs no pool de nós, da quantidade de memória a ser usada pelo contêiner e de quantos compartilhamentos de CPU o contêiner precisa.

É possível redimensionar pools de nós no AKS. Para saber como, consulte Redimensionar pools de nós no AKS (Serviço de Kubernetes do Azure).

Inventariar todos os segredos

Antes do advento das tecnologias de "configuração como serviço", como o Azure Key Vault, não havia um conceito bem definido de "segredos". Em vez disso, você tinha um conjunto distinto de definições de configuração que funcionavam efetivamente como aquilo que agora chamamos de "segredos". Com servidores de aplicativos como o WebLogic Server, esses segredos estão em muitos arquivos de configuração e repositórios de configuração diferentes. Verifique todas as propriedades e os arquivos de configuração nos servidores de produção em busca de segredos e senhas. Não se esqueça de verificar o weblogic.xml em seus WARs. Arquivos de configuração que contenham senhas ou credenciais também podem ser encontrados dentro de seu aplicativo. Para saber mais, consulte Conceitos básicos do Azure Key Vault.

Inventariar todos os certificados

Documente todos os certificados usados para pontos de extremidade SSL públicos. Você pode exibir todos os certificados nos servidores de produção executando o seguinte comando:

keytool -list -v -keystore <path to keystore>

Inventariar recursos de JNDI

Faça um inventário de todos os recursos de JNDI. Por exemplo, fontes de dados como bancos de dados podem ter um nome JNDI associado que permite que o JPA associe corretamente instâncias de EntityManager a um banco de dados específico. Para obter mais informações sobre os recursos e bancos de dados de JNDI, consulte Fontes de dados do WebLogic Server na documentação da Oracle. Outros recursos relacionados a JNDI, como agentes de mensagens JMS, podem exigir migração ou reconfiguração. Para obter mais informações sobre a configuração do JMS, confira Oracle WebLogic Server 12.2.1.4.0.

Determinar se a replicação de sessão é usada

Se seu aplicativo depender da replicação de sessão, com ou sem o Oracle Coherence*Web, você terá duas opções:

  • Refatore seu aplicativo para usar um banco de dados para gerenciamento de sessão.
  • Refatore seu aplicativo para externalizar a sessão para o serviço Redis do Azure. Para obter mais informações, consulte Azure Cache for Redis.

Documentar fontes de dados

Se seu aplicativo usar algum banco de dados, você precisará capturar as informações a seguir:

  • Qual é o nome da fonte de dados?
  • Qual é a configuração do pool de conexões?
  • Onde posso encontrar o arquivo JAR do driver JDBC?

Para saber mais sobre drivers JDBC no WebLogic, consulte Usando drivers JDBC com o WebLogic Server.

Determinar se o WebLogic foi personalizado

Determine quais das personalizações a seguir foram feitas e capture o que foi feito.

  • Os scripts de inicialização foram alterados? Esses scripts incluem setDomainEnv, commEnv, startWebLogic e stopWebLogic.
  • Parâmetros específicos foram passados para a JVM?
  • JARs foram adicionados ao classpath do servidor?

Determinar se uma conexão com o local é necessária

Se seu aplicativo precisar acessar qualquer um dos seus serviços locais, você precisará provisionar um dos serviços de conectividade do Azure. Para obter mais informações, consulte Conectar uma rede local ao Azure. Como alternativa, você precisará refatorar seu aplicativo para usar APIs disponíveis publicamente que seus recursos locais expõem.

Determinar se as Filas ou os Tópicos do JMS (Java Message Service) estão em uso

Se seu aplicativo estiver usando Filas ou Tópicos do JMS, você precisará migrá-los para um servidor do JMS hospedado externamente. O Barramento de Serviço do Azure e o AMQP (Advanced Message Queuing Protocol) podem ser uma excelente estratégia de migração para pessoas que usam o JMS. Para obter mais informações, confira Usar o Java Message Service 1.1 com o padrão de Barramento de Serviço do Azure e o AMQP 1.0.

Se os armazenamentos persistentes JMS tiverem sido configurados, você deverá capturar a configuração deles e aplicá-la após a migração.

Determinar se você está usando suas próprias bibliotecas Java EE compartilhadas personalizadas criadas

Se você estiver usando o recurso de biblioteca Java EE compartilhada, terá duas opções:

  • Refatore o código do aplicativo para remover todas as dependências em suas bibliotecas e incorporar a funcionalidade diretamente ao seu aplicativo.
  • Adicione as bibliotecas ao classpath do servidor.

Determinar se pacotes OSGi são usados

Se você usou pacotes OSGi adicionados ao WebLogic Server, precisará adicionar os arquivos JAR equivalentes diretamente ao seu aplicativo Web.

Determinar se o aplicativo contém código específico do sistema operacional

Se seu aplicativo contiver qualquer código com dependências do sistema operacional do host, você precisará refatorá-lo para remover essas dependências. Por exemplo, talvez seja necessário substituir qualquer uso de / ou \ em caminhos do sistema de arquivos com File.Separator ou Paths.get se o aplicativo estiver em execução no Windows.

Determinar se o Barramento de Serviço da Oracle está em uso

Se seu aplicativo estiver usando o OSB (Barramento de Serviço do Oracle), você precisará capturar como o OSB está configurado. Para saber mais, consulte Sobre a instalação do Barramento de Serviço da Oracle.

Determinar se seu aplicativo é composto por vários WARs

Se seu aplicativo for composto por vários WARs, você deverá tratar cada um desses WARs como aplicativos separados e consultar este guia para cada um deles.

Determinar se seu aplicativo está empacotado como um EAR

Se seu aplicativo estiver empacotado como um arquivo EAR, examine os arquivos application.xml e weblogic-application.xml e capture as configurações deles.

Observação

Se você deseja conseguir escalar cada um dos seus aplicativos Web independentemente para um melhor uso dos recursos do Serviço de Kubernetes do Azure, divida o EAR em aplicativos Web separados.

Identificar todos os processos e daemons externos em execução nos servidores de produção

Se você tiver processos em execução fora do servidor de aplicativos, como daemons de monitoramento, precisará eliminá-los ou migrá-los para outro lugar.

Validar se a versão Java com suporte funciona corretamente

Usar o WildFly no Serviço de Kubernetes do Azure requer uma versão específica do Java. Portanto, você precisará confirmar se o aplicativo é executado corretamente usando essa versão com suporte.

Observação

Essa validação é especialmente importante se o servidor atual estiver sendo executado em um JDK não compatível (como Oracle JDK ou IBM OpenJ9).

Para determinar a sua versão atual do Java, entre no servidor de produção e execute o seguinte comando:

java -version

Consulte Requisitos para obter diretrizes sobre qual versão usar para executar o WildFly.

Determinar se o aplicativo depende de trabalhos agendados

Trabalhos agendados, como tarefas do Agendador do Quartz ou trabalhos cron do Unix, NÃO podem ser usados com o AKS (Serviço de Kubernetes do Azure). O Serviço de Kubernetes do Azure não impedirá que você implante um aplicativo que contém tarefas agendadas internamente. No entanto, se o aplicativo for escalado horizontalmente, um mesmo trabalho agendado poderá ser executado mais de uma vez por período agendado. Essa situação pode levar a consequências indesejadas.

Para executar trabalhos agendados em seu cluster do AKS, defina CronJobs do Kubernetes conforme necessário. Para obter mais informações, confira Execução de tarefas automatizadas com um CronJob.

Determinar se a ferramenta de script do WebLogic é usada

Se você usar a WLST (Ferramenta de script do WebLogic) para realizar a implantação atualmente, precisará avaliar o que ela está fazendo. Se a WLST estiver alterando parâmetros (runtime) do seu aplicativo como parte da implantação, verifique se esses parâmetros estão em conformidade com uma das seguintes opções:

  • Os parâmetros são externalizados como configurações do aplicativo.
  • Os parâmetros são incorporados em seu aplicativo.
  • Os parâmetros estão usando a CLI do JBoss durante a implantação.

Se a WLST estiver fazendo mais do que o mencionado acima, você terá que realizar um trabalho extra durante a migração.

Determinar se seu aplicativo usa APIs específicas do WebLogic

Se seu aplicativo usar APIs específicas do WebLogic, você precisará refatorá-lo para remover essas dependências. Por exemplo, se você usou uma classe mencionada na Referência de API Java para o Oracle WebLogic Server, você usou uma API específica do WebLogic em seu aplicativo. Você precisaria refatorar para remover a referência.

Determinar se o aplicativo usa Beans de Entidade ou Beans CMP com estilo EJB 2.x

Se o aplicativo usar Beans de Entidade ou Beans CMP com estilo EJB 2.x, você precisará refatorá-lo para remover essas dependências.

Determinar se o recurso Cliente do Aplicativo Java EE está sendo usado

Se tiver aplicativos cliente que se conectam ao seu aplicativo (servidor) usando o recurso Cliente do Aplicativo Java EE, você precisará refatorar os aplicativos cliente e seu aplicativo (servidor) para usar APIs HTTP.

Determinar se um plano de implantação foi usado

Se seu aplicativo tiver sido implantado usando um plano de implantação, avalie o que o plano de implantação está fazendo. Se o plano de implantação for uma implantação direta, então você poderá implantar seu aplicativo Web sem nenhuma alteração. Se o plano de implantação for mais elaborado, determine se pode usar a CLI do JBoss para configurar adequadamente seu aplicativo como parte da implantação. Se não for possível usar a CLI do JBoss, refatore seu aplicativo de modo que um plano de implantação não seja mais necessário.

Determinar se temporizadores EJB estão sendo usados

Se seu aplicativo usar temporizadores EJB, você precisará validar que o código do temporizador EJB pode ser disparado pela instância do WildFly de maneira independente. Essa validação é necessária porque, no cenário de implantação do Serviço de Kubernetes do Azure, cada temporizador EJB será disparado em sua própria instância do WildFly.

Determinar se e como o sistema de arquivos é usado

Qualquer uso do sistema de arquivos no servidor de aplicativos exigem reconfiguração ou, em casos raros, alterações de arquitetura. O sistema de arquivos pode ser usado por módulos compartilhados do WebLogic ou pelo seu código do aplicativo. Você poderá identificar alguns ou todos os cenários descritos nas seções a seguir.

Conteúdo estático somente leitura

Se seu aplicativo estiver servindo conteúdo estático no momento, você precisará de um local alternativo para ele. Talvez você queira considerar a migração de conteúdo estático para o Armazenamento de Blobs do Azure e a adição da CDN do Azure para downloads extremamente rápidos, globalmente. Para obter mais informações, confira Hospedagem de site estático no Armazenamento do Microsoft Azure e Início rápido: Integrar uma conta de armazenamento do Azure à CDN do Azure.

Conteúdo estático publicado dinamicamente

Se o aplicativo permitir conteúdo estático que é carregado/produzido pelo aplicativo, mas não puder ser alterado após sua criação, você poderá usar o Armazenamento de Blobs do Azure e a CDN do Azure, conforme descrito acima, com uma Função do Azure para lidar com uploads e atualização de CDN. Fornecemos uma implementação de exemplo para seu uso em Carregar conteúdo estático e fazer o pré-carregamento desse conteúdo pela CDN com o Azure Functions.

Conteúdo dinâmico ou interno

Para arquivos que são frequentemente escritos e lidos pelo aplicativo (como arquivos de dados temporários) ou arquivos estáticos que são visíveis somente para o aplicativo, você pode montar compartilhamentos do Armazenamento do Azure como volumes persistentes. Para obter mais informações, confira Criar e usar um volume com os Arquivos do Azure no AKS (Serviço de Kubernetes do Azure).

Determinar se conectores JCA são usados

Se seu aplicativo usar conectores JCA, você precisará validar se o conector JCA pode ser usado no WildFly. Se a implementação do JCA estiver vinculada ao WebLogic, você precisará refatorar seu aplicativo para remover essa dependência. Se puder ser usado, você precisará adicionar os JARs ao classpath do servidor e colocar os arquivos de configuração necessários no local correto nos diretórios do servidor do WildFly para que ele esteja disponível.

Determinar se seu aplicativo usa um Adaptador de Recurso

Se o aplicativo precisar de um RA (Adaptador de Recurso), ele precisará ser compatível com o WildFly. Determine se o RA funciona bem em uma instância autônoma do WildFly implantando-o no servidor e configurando-o corretamente. Se o RA funcionar corretamente, você precisará adicionar os JARs ao classpath do servidor da imagem do Docker e colocar os arquivos de configuração necessários no local correto nos diretórios do servidor do WildFly para que ele fique disponível.

Determinar se o JAAS está sendo usado

Se seu aplicativo estiver usando o JAAS, você precisará capturar como o JAAS está configurado. Se estiver usando um banco de dados, você poderá convertê-lo em um domínio JAAS no WildFly. Caso se trate de uma implementação personalizada, você precisará validar que ela pode ser usada no WildFly.

Determinar se o clustering do WebLogic é usado

É provável que você tenha implantado seu aplicativo em vários WebLogic Servers para conseguir alta disponibilidade. O Serviço de Kubernetes do Azure é capaz de dimensionar, mas se a API de Cluster do WebLogic tiver sido usada, precisará refatorar seu código para eliminar o uso dessa API.

Realizar testes in-loco

Antes de criar suas imagens de contêiner, migre o aplicativo para as versões do JDK e do WildFly que pretende usar no AKS. Teste o aplicativo cuidadosamente para garantir a compatibilidade e o desempenho.

Migração

Provisionar o Registro de Contêiner do Azure e o Serviço de Kubernetes do Azure

Use os seguintes comandos para criar um registro de contêiner e um cluster do Kubernetes do Azure cuja entidade de serviço tenha a função de Leitor no registro. Verifique se você escolheu o modelo de rede apropriado para os requisitos de rede do seu cluster.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

Criar uma imagem de Docker para o WildFly

Para criar um Dockerfile, você precisará dos seguintes pré-requisitos:

  • Um JDK com suporte.
  • Uma instalação do WildFly.
  • Suas opções de runtime do JVM.
  • Uma maneira de passar variáveis de ambiente (se aplicável).

Em seguida, você pode executar as etapas descritas nas seções a seguir, quando aplicável. Você pode usar o Repositório de Início Rápido do Contêiner WildFly como um ponto de partida para seu Dockerfile e aplicativo Web.

Configurar FlexVolume do KeyVault

Crie um Azure KeyVault e preencha todos os segredos necessários. Para saber mais, confira Início Rápido: Definir e recuperar um segredo do Azure Key Vault usando a CLI do Azure. Em seguida, configure um FlexVolume do KeyVault para tornar esses segredos acessíveis para pods.

Também será necessário atualizar o script de inicialização usado para inicializar o WildFly. Esse script deve importar os certificados para o keystore usado pelo WildFly antes de iniciar o servidor.

Configurar as fontes de dados

Para configurar o WildFly para acessar uma fonte de dados, você precisará adicionar o JAR do driver JDBC à imagem do Docker e, em seguida, executar os comandos apropriados da CLI do JBoss. Esses comandos devem configurar a fonte de dados ao criar a imagem do Docker.

As etapas a seguir fornecem instruções para PostgreSQL, MySQL e SQL Server.

  1. Baixe o driver JDBC para PostgreSQL, MySQL ou SQL Server.

    Descompacte o arquivo baixado para obter o arquivo .jar do driver.

  2. Crie um arquivo com um nome como module.xml e adicione a marcação a seguir. Substitua o espaço reservado <module name> (incluindo os colchetes angulares) por org.postgres para PostgreSQL, com.mysql para MySQL ou com.microsoft para SQL Server. Substitua <JDBC .jar file path> pelo nome do arquivo .jar da etapa anterior, incluindo o caminho completo para o local em que você colocará o arquivo na imagem do Docker, por exemplo, em /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Crie um arquivo com um nome como datasource-commands.cli e adicione o código a seguir. Substitua <JDBC .jar file path> pelo valor usado na etapa anterior. Substitua <module file path> pelo nome do arquivo e pelo caminho da etapa anterior, por exemplo, /opt/database/module.xml.

    Observação

    A Microsoft recomenda usar o fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento, como bancos de dados, caches, mensagens ou serviços de IA, requer um grau muito alto de confiança no aplicativo e traz riscos não presentes em outros fluxos. Use esse fluxo somente quando opções mais seguras, como identidades gerenciadas para conexões sem senha ou sem chave, não forem viáveis. Para operações de computador local, prefira identidades de usuário para conexões sem senha ou sem chave.

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

  4. Atualize a configuração da fonte de dados de JTA para seu aplicativo:

    Abra o arquivo src/main/resources/META-INF/persistence.xml para o aplicativo e localize o elemento <jta-data-source>. Substitua o conteúdo como mostrado aqui:

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

  5. Adicione o seguinte ao seu Dockerfile para que a fonte de dados seja criada quando você criar a imagem do Docker

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Determine o DATABASE_CONNECTION_URL a ser usado, pois eles são diferentes para cada servidor de banco de dados e diferentes dos valores no portal do Azure. Os formatos de URL mostrados aqui são necessários para o uso do WildFly:

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. Ao criar seu YAML de implantação em um estágio posterior, você precisará passar as seguintes variáveis de ambiente, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME e DATABASE_SERVER_ADMIN_PASSWORD, com os valores apropriados.

Observação

A Microsoft recomenda usar o fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento, como bancos de dados, caches, mensagens ou serviços de IA, requer um grau muito alto de confiança no aplicativo e traz riscos não presentes em outros fluxos. Use esse fluxo somente quando opções mais seguras, como identidades gerenciadas para conexões sem senha ou sem chave, não forem viáveis. Para operações de computador local, prefira identidades de usuário para conexões sem senha ou sem chave.

Para obter mais informações sobre como configurar a conectividade do banco de dados com o WildFly, confira PostgreSQL, MySQL ou SQL Server.

Configurar os recursos de JNDI

Para configurar cada recurso de JNDI que é necessário configurar no WildFly, você geralmente usará as seguintes etapas:

  1. Baixe os arquivos JAR necessários e copie-os para a imagem do Docker.
  2. Crie um arquivo module.xml do WildFly que faz referência a esses arquivos JAR.
  3. Crie qualquer configuração necessária para o recurso JNDI específico.
  4. Crie um script da CLI do JBoss a ser usado durante a compilação do Docker para registrar o recurso de JNDI.
  5. Adicione tudo ao Dockerfile.
  6. Passe as variáveis de ambiente apropriadas em seu YAML de implantação.

O exemplo a seguir mostra as etapas necessárias para criar o recurso de JNDI para conectividade do JMS com o Barramento de Serviço do Azure.

  1. Baixe o provedor de JMS Apache Qpid

    Descompacte o arquivo baixado para obter os arquivos .jar.

  2. Crie um arquivo com um nome como module.xml e adicione a marcação a seguir em /opt/servicebus. Verifique se os números de versão dos arquivos JAR estão alinhados com os nomes dos arquivos JAR da etapa anterior.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Crie um arquivo jndi.properties em /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Crie um arquivo com um nome como servicebus-commands.cli e adicione o código a seguir.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Adicione o seguinte ao seu Dockerfile para que o recurso de JNDI seja criado quando você criar a imagem do Docker

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. Ao criar seu YAML de implantação em um estágio posterior, você precisará passar as seguintes variáveis de ambiente, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE e SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC e SB_TOPIC com os valores apropriados.

Examinar a configuração do WildFly

Examine o Guia do Administrador do WildFly para consultar etapas pré-migração adicionais não abordadas pelas orientações anteriores.

Compilar e efetuar push da imagem do Docker para o Registro de Contêiner do Azure

Depois de criar o Dockerfile, você precisará compilar a imagem do Docker e publicá-la no seu registro de contêiner do Azure.

Se você usou nosso Início Rápido do Contêiner do WildFly no repositório do GitHub, o processo de compilação e push de sua imagem para o registro de contêiner do Azure seria equivalente a invocar os três comandos a seguir.

Nesses exemplos, a variável de ambiente MY_ACR contém o nome do registro de contêiner do Azure e a variável MY_APP_NAME contém o nome do aplicativo Web que você deseja usar em seu registro de contêiner do Azure.

Compilar o arquivo WAR:

mvn package

Fazer logon no em seu registro de contêiner do Azure:

az acr login --name ${MY_ACR}

Compilar e efetuar push da imagem:

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

Como alternativa, você pode usar a CLI do Docker para compilar e testar a imagem localmente, conforme mostrado nos comandos a seguir. Essa abordagem pode simplificar o teste e refinar a imagem antes da implantação inicial no ACR. No entanto, ela requer que você instale a CLI do Docker e verifique se o daemon do Docker está em execução.

Compilar a imagem:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Executar a imagem localmente:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Agora, você pode acessar seu aplicativo em http://localhost:8080.

Fazer logon no em seu registro de contêiner do Azure:

az acr login --name ${MY_ACR}

Efetuar push da imagem ao registro de contêiner do Azure:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Para obter informações mais detalhadas sobre como compilar e armazenar imagens de contêiner no Azure, confira o módulo do Learn Compilar e armazenar imagens de contêiner com o Registro de Contêiner do Azure.

Provisionar um endereço IP público

Se quiser que o aplicativo esteja acessível de fora de suas redes internas ou virtuais, você precisará de um endereço IP estático público. Provisione esse endereço IP dentro do grupo de recursos do nó do cluster, conforme mostrado no exemplo a seguir:

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Implantar no AKS (Serviço de Kubernetes do Azure)

Criar e aplicar seus arquivos YAML do Kubernetes. Para obter mais informações, consulte Início Rápido: Implantar um cluster do AKS (Serviço de Kubernetes do Azure) usando a CLI do Azure. Se você estiver criando um balanceador de carga externo (seja para seu aplicativo ou para um controlador de entrada), será necessário fornecer o endereço IP provisionado na seção anterior como o LoadBalancerIP.

Inclua parâmetros externos como variáveis de ambiente. Para saber mais, confira Definir variáveis de ambiente para um contêiner. Não inclua segredos (como senhas, chaves de API e cadeias de conexão JDBC). Eles são abordados na seção a seguir.

Inclua as configurações de memória e CPU ao criar seu YAML de implantação para que os contêineres sejam dimensionados corretamente.

Configurar um armazenamento persistente

Se seu aplicativo exigir armazenamento não volátil, configure um ou mais Volumes Persistentes.

Migrar os trabalhos agendados

Para executar trabalhos agendados em seu cluster do AKS, defina CronJobs do Kubernetes conforme necessário. Para obter mais informações, confira Execução de tarefas automatizadas com um CronJob.

Após a migração

Agora que você migrou seu aplicativo para o Serviço de Kubernetes do Azure, você deve verificar se ele funciona conforme o esperado. Após fazer isso, confira as recomendações a seguir para tornar seu aplicativo mais nativo da nuvem.

Recomendações