Compartilhar via

Migrar aplicativos WebSphere 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 WebSphere 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.

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

Verifique todas as propriedades e os arquivos de configuração nos servidores de produção em busca de segredos e senhas. Verifique o ibm-web-bnd.xml em seus WARs. Arquivos de configuração que contenham senhas ou credenciais também podem ser encontrados dentro de seu aplicativo.

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>

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.

Inventariar recursos de JNDI

Faça um inventário de todos os recursos de JNDI. Alguns, como agentes de mensagens JMS, podem exigir migração ou reconfiguração.

Dentro de seu aplicativo

Inspecione o arquivo WEB-INF/ibm-web-bnd.xml e/ou WEB-INF/web.xml.

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 obter mais informações, consulte Configuração de conectividade de banco de dados na documentação do WebSphere.

Determinar se e como o sistema de arquivos é usado

Qualquer uso do sistema de arquivos no servidor de aplicativos exigirá reconfiguração ou, em casos raros, alterações de arquitetura. O sistema de arquivos pode ser usado por módulos do WebSphere ou pelo código do aplicativo. Você pode 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 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 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 seu aplicativo usa APIs específicas do WebSphere

Se seu aplicativo usar APIs específicas do WebSphere, você precisará refatorá-lo para remover essas dependências. Por exemplo, se você usou uma classe mencionada no Servidor de Aplicativos do IBM WebSphere, Especificação da API Versão 9.0, você usou uma API específica do WebSphere em seu aplicativo.

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 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 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 conectores JCA estão em uso

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 WebSphere, 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 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 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 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 application-bnd.xml e capture as configurações deles.

Observação

Se você quiser ser capaz de dimensionar cada um de seus aplicativos Web de forma independente para melhor uso dos recursos do AKS (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.

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. Depois de fazer isso, temos algumas recomendações para você que podem tornar seu aplicativo mais nativo de nuvem.

Recomendações