Partilhar via

Migrar aplicações WebSphere para o WildFly no Azure Kubernetes Service

  • Artigo

Este guia descreve aquilo de que deve estar ciente quando quer migrar uma aplicação WebSphere já existente para a executar no WildFly num contentor do Azure Kubernetes Service.

Pré-migração

Para garantir uma migração bem-sucedida, antes de começar, conclua as etapas de avaliação e inventário descritas nas seções a seguir.

Fazer o inventário da capacidade do servidor

Documente o hardware (memória, CPU, disco) do(s) servidor(es) de produção atual e as contagens médias e de pico de solicitações e a utilização de recursos. Independentemente do caminho de migração que escolher, vai precisar destas informações. É útil, por exemplo, para ajudar a orientar a seleção do tamanho das VMs em seu pool de nós, a quantidade de memória a ser usada pelo contêiner e quantas CPUs compartilham as necessidades do contêiner.

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

Inventariar todos os segredos

Procure segredos e palavras-passe nas propriedades e nos ficheiros de configuração do servidor ou servidores de produção. Não se esqueça de verificar ibm-web-bnd.xml nos seus WARs. Também poderá encontrar ficheiros de configuração com palavras-passe ou credenciais dentro da aplicação.

Inventariar todos os certificados

Documente todos os certificados utilizados para os pontos finais SSL públicos. Pode ver todos os certificados no servidor ou servidores de produção com o comando seguinte:

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

Verificar se a versão de Java suportada funciona corretamente

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

Nota

Esta validação é particularmente importante se o seu servidor atual estiver a ser executado num JDK não suportado (como Oracle JDK ou IBM OpenJ9).

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

java -version

Veja os Requisitos para obter orientação quanto à versão que deve utilizar para executar o WildFly.

Inventariar recursos do JNDI

Inventariar todos os recursos do JNDI. Alguns, como os mediadores de mensagens do JMS, podem exigir migração ou reconfiguração.

Na aplicação

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

Documentar origens de dados

Se a sua aplicação utilizar bases de dados, terá de recolher as seguintes informações:

  • Qual é o nome da origem de dados?
  • Qual é a configuração do conjunto de ligações?
  • Onde posso obter o ficheiro JAR do controlador JDBC?

Para obter mais informações, veja Configurar a conectividade da base de dados na documentação do WebSphere.

Determinar se e como é que o sistema de ficheiros é utilizado

Qualquer utilização do sistema de ficheiros no servidor de aplicações irá exigir uma reconfiguração ou, em casos raros, alterações da arquitetura. O sistema de ficheiros pode ser utilizado por módulos do WebSphere ou pelo código da aplicação. Poderá identificar alguns ou todos os cenários descritos nas secções seguintes.

Conteúdo estático só de leitura

Se a sua aplicação servir conteúdo estático atualmente, precisa de uma localização alternativa para o mesmo. Pode considerar mover o conteúdo estático para o Armazenamento de Blobs do Azure e adicionar a CDN do Azure para obter transferências super-rápidas a nível global. Para obter mais informações, consulte Hospedagem de site estático no Armazenamento do Azure e Guia de início rápido: integrar uma conta de armazenamento do Azure com a CDN do Azure.

Conteúdo estático publicado dinamicamente

Se a sua aplicação permitir conteúdo estático carregado/produzido pela mesma, mas que é imutável após a criação, pode utilizar o Armazenamento de Blobs do Azure e a CDN do Azure conforme descrito acima, com uma função das Funções do Azure que lide com os carregamentos e as atualizações da CDN. Disponibilizamos uma implementação de exemplo que pode utilizar, em Uploading and CDN-preloading static content with Azure Functions (Carregamento e pré-carregamento da CDN de conteúdo estático com as Funções do Azure).

Conteúdo dinâmico ou interno

Para os ficheiros que são frequentemente escritos e lidos pela sua aplicação (tais como ficheiros de dados temporários) ou os ficheiros estáticos que só estão visíveis para a sua aplicação, pode montar partilhas do Armazenamento do Microsoft Azure sob a forma de volumes persistentes. Para obter mais informações, consulte Criar e usar um volume com Arquivos do Azure no Serviço Kubernetes do Azure (AKS).

Determinar se a aplicação depende de trabalhos agendados

Trabalhos agendados, como tarefas do Agendador de Quartzo ou trabalhos cron do Unix, NÃO devem ser usados com o Serviço Kubernetes do Azure (AKS). O Azure Kubernetes Service não o impedirá de implementar uma aplicação que contenha tarefas agendadas no seu interior. Contudo, se a sua aplicação estiver ampliada, a mesma tarefa agendada pode ser executada mais de uma vez por período agendado. Esta situação pode provocar consequências não intencionais.

Para executar trabalhos agendados no seu cluster do AKS, defina o CronJobs do Kubernetes conforme for necessário. Para obter mais informações, veja Executar Tarefas Automatizadas com um CronJob.

Determinar se é necessária uma ligação ao local

Se a sua aplicação precisar de aceder a um dos seus serviços no local, tem de aprovisionar um dos serviços de conectividade do Azure. Para obter mais informações, veja Ligar uma rede no local ao Azure. Em alternativa, tem de refatorizar a aplicação para utilizar as APIs publicamente disponíveis que os seus recursos no local expõem.

Determinar se os Tópicos ou Filas do Java Message Service (JMS) estão a ser utilizados

Se a sua aplicação utilizar Filas ou Tópicos do JMS, tem de os migrar para um servidor JMS alojado externamente. O Azure Service Bus e o Advanced Message Queuing Protocol (AMQP) podem ser uma excelente estratégia de migração para quem utiliza o JMS. Para obter mais informações, consulte Usar o Java Message Service 1.1 com o Azure Service Bus Standard e AMQP 1.0.

Se tiverem sido configurados arquivos persistentes do JMS, tem de capturar a respetiva configuração e aplicá-la após a migração.

Determinar se a aplicação utiliza APIs específicas do WebSphere

Se a sua aplicação utilizar APIs específicas do WebSphere, terá de refatorizá-la para remover essas dependências. Por exemplo, se tiver utilizado uma classe mencionada na Especificação de API IBM WebSphere Application Server, versão 9.0, utilizou uma API específica do WebSphere na sua aplicação.

Determinar se a aplicação utiliza Entity Beans ou EJB 2.x-style CMP Beans

Se a sua aplicação utilizar Entity Beans ou EJB 2.x-style CMP Beans

Determinar se a funcionalidade Java EE Application Client está a ser utilizada

Se tiver aplicações cliente que se ligam à sua aplicação (servidor) com a funcionalidade Java EE Application Client, terá de as refatorizar a ambas para que utilizem APIs HTTP.

Determinar se a aplicação contem código de SO específico

Se seu aplicativo contiver qualquer código com dependências no sistema operacional 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 por File.Separator ou Paths.get se seu aplicativo estiver sendo executado no Windows.

Determinar se os temporizadores EJB estão a ser utilizados

Se a sua aplicação utilizar temporizadores EJB, tem de confirmar que o código do temporizador EJB pode ser acionado por cada instância do WildFly de forma independente. Esta validação é necessária porque, no cenário de implementação do Azure Kubernetes Service, cada temporizador EJB será acionado na sua própria instância do WildFly.

Determinar se há conectores JCA em utilização

Se a aplicação utilizar conectores JCA, terá de validar se o conector JCA pode ser utilizado no WildFly. Se a implementação JCA estiver associada ao WebSphere, terá de refatorizar a aplicação para remover essa dependência. Se puder ser utilizado, terá de adicionar os JARs ao classpath do servidor e colocar os ficheiros de configuração necessários na localização correta nos diretórios do servidor do WildFly para que estejam disponíveis.

Determinar se o JAAS está a ser utilizado

Se a sua aplicação utilizar o JAAS, tem de capturar a forma como este é configurado. Se estiver a utilizar uma base de dados, pode convertê-la num domínio JAAS no WildFly. Se for uma implementação personalizada, terá de confirmar se pode ser utilizada no WildFly.

Determinar se a aplicação utiliza um Adaptador de Recursos

Se a sua aplicação precisar de um Adaptador de Recursos (RA), tem de ser compatível com o WildFly. Determine se o RA funciona bem numa instância autónoma do WildFly ao implementá-lo no servidor e configurá-lo corretamente. Se o RA funcionar devidamente, terá de adicionar os JARs ao classpath do servidor da imagem do Docker e pôr os ficheiros de configuração necessários na localização correta nos diretórios do servidor do WildFly para que estejam disponíveis.

Determinar se a sua aplicação é composta por vários WARs

Se a sua aplicação for composta por vários WARs, deve tratar cada um desses WARs como aplicações separadas e seguir este guia para cada qual individualmente.

Determinar se a sua aplicação está empacotada como EAR

Se a sua aplicação estiver empacotada como um ficheiro EAR, confirme que examina os ficheiros application.xml e application-bnd.xml e capture as respetivas configurações.

Nota

Se quiser ser capaz de dimensionar cada um dos seus aplicativos Web de forma independente para melhor usar seus recursos do Serviço Kubernetes do Azure (AKS), você deve dividir o EAR em aplicativos Web separados.

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

Se tiver processos em execução fora do servidor de aplicações, como daemons de monitorização, terá de eliminar ou migrá-los para outro local.

Fazer testes no local

Antes de criar as imagens do contentor, migre a aplicação para as versões do JDK e do WildFly que pretende utilizar no AKS. Teste a aplicação de forma minuciosa para garantir a compatibilidade e o desempenho.

Migração

Aprovisionar o Azure Container Service e o Azure Kubernetes Service

Utilize os comandos seguintes para criar um registo de contentores e um cluster do Azure Kubernetes com um Principal de Serviço que tenha a função Leitor no registo. Certifique-se de que escolhe o modelo de rede adequado 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 do Docker para o WildFly

Para criar um Dockerfile, tem de seguir os seguintes pré-requisitos:

  • Um JDK suportado.
  • Uma instalação do WildFly.
  • As opções de runtime do JVM.
  • Uma forma de transmitir variáveis de ambiente (se aplicável).

Depois, pode seguir os passos descritos nas secções abaixo, sempre que aplicável. Pode utilizar o repositório WildFly Container Quickstart como ponto de partida para o Dockerfile e a aplicação Web.

Configurar o FlexVolume do KeyVault

Crie um cofre do Azure KeyVault e preencha todos os segredos necessários. Para obter mais informações, consulte Guia de início rápido: definir e recuperar um segredo do Cofre da Chave do Azure usando a CLI do Azure. Em seguida, configure um KeyVault FlexVolume para tornar esses segredos acessíveis a pods.

Também terá de atualizar o script de arranque utilizado para fazer o bootstrap do WildFly. Esse script tem de importar os certificados para o arquivo de dados que o WildFly utiliza antes de iniciar o servidor.

Configurar origens de dados

Para configurar o WildFly para aceder a uma origem de dados, tem de adicionar o controlador JAR do JDBC à imagem do Docker e, em seguida, executar os comandos da CLI JBoss adequados. Estes comandos têm de configurar a origem de dados ao compilar a imagem do Docker.

Os passos seguintes disponibilizam instruções para PostgreSQL, MySQL e SQL Server.

  1. Transfira o controlador do JDBC para PostgreSQL, MySQL ou SQL Server.

    Descompacte o arquivo transferido para obter o ficheiro .jar do controlador.

  2. Crie um ficheiro com um nome como module.xml e adicione o markup seguinte. Substitua o marcador de posição <module name> (incluindo as chavetas) por org.postgres para PostgreSQL, com.mysql para MySQL ou com.microsoft para SQL Server. Substitua <JDBC .jar file path> pelo nome do ficheiro .jar do passo anterior, incluindo o caminho completo para a localização na qual vai guardar o ficheiro de imagem do Docker; por exemplo, /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 ficheiro com um nome como datasource-commands.cli e adicione o código seguinte. Substitua <JDBC .jar file path> pelo valor que utilizou no passo anterior. Substitua <module file path> pelo nome e o caminho do ficheiro do passo anterior; por exemplo, /opt/database/module.xml.

    Nota

    A Microsoft recomenda o uso do fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento, como para 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 máquina 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. Atualizar a configuração da origem de dados do JTA para a aplicação:

    Abra o ficheiro src/main/resources/META-INF/persistence.xml da aplicação e localize o elemento <jta-data-source>. Substitua os respetivos conteúdos, conforme mostrado aqui:

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

  5. Adicione o seguinte a Dockerfile, para que a origem de dados seja criada quando compilar 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 que DATABASE_CONNECTION_URL vai ser utilizado, pois são diferentes para cada servidor de base de dados e distintos dos valores no portal do Azure. O WildFly é obrigado a utilizar os formatos de URL mostrados aqui:

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

  7. Ao criar o YAML da implementação numa fase posterior, tem de transmitir as seguintes variáveis de ambiente, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME e DATABASE_SERVER_ADMIN_PASSWORD, com os valores adequados.

Nota

A Microsoft recomenda o uso do fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento, como para 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 máquina local, prefira identidades de usuário para conexões sem senha ou sem chave.

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

Configurar recursos do JNDI

Para configurar cada recurso do JNDI que tem de configurar no WildFly, utilizará, geralmente, os passos seguintes:

  1. Transfira os ficheiros JAR necessários e copie-os para a imagem do Docker.
  2. Crie um ficheiro module.xml do WildFly que referencie esses ficheiros JAR.
  3. Crie qualquer configuração de que o recurso específico do JNDI precise.
  4. Crie o script da CLI do JBoss que vai ser utilizado durante a compilação do Docker para registar o recurso do JNDI.
  5. Adicione tudo ao Dockerfile.
  6. Transmita as variáveis de ambiente adequadas no YAML de implementação.

O exemplo abaixo mostra os passos necessários para criar o recurso do JNDI para a conectividade do JMS ao Azure Service Bus.

  1. Transfira o fornecedor Apache Qpid JMS.

    Descompacte o arquivo transferido para obter os ficheiros .jar.

  2. Crie um ficheiro com um nome como module.xml e adicione o markup em /opt/servicebus. Confirme que os números de versão dos ficheiros JAR estão alinhados com os nomes dos ficheiros JAR do passo 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 ficheiro 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 ficheiro com um nome como servicebus-commands.cli e adicione o código seguinte.

    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 a Dockerfile, para que o recurso do JNDI seja criado quando compilar 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 o YAML da implementação numa fase posterior, tem de transmitir 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 adequados.

Rever a configuração do WildFly

Reveja o Guia WildFly Admin para obter eventuais passos adicionais de pré-migração não abrangidos na orientação anterior.

Compilar e enviar a imagem do Docker para o Azure Container Registry

Depois de criar o Dockerfile, tem de compilar a imagem do Docker e publicá-la no Azure Container Registry.

Se tiver utilizado o nosso repositório WildFly Container Quickstart do GitHub, o processo de compilação e envio da imagem para o Azure Container Registry será equivalente a invocar os três comandos seguintes.

Nestes exemplos, a variável de ambiente MY_ACR contém o nome do Azure Container Registry e a variável MY_APP_NAME o nome da aplicação Web que pretende utilizar no Azure Container Registry.

Compilar o ficheiro WAR:

mvn package

Iniciar sessão no Azure Container Registry:

az acr login --name ${MY_ACR}

Criar e enviar a imagem:

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

Em alternativa, pode utilizar a CLI do Docker para primeiro compilar e testar a imagem localmente, conforme mostrado nos comandos seguintes. Esta abordagem pode simplificar os testes e refinar a imagem antes da implementação inicial no ACR. No entanto, requer que instale a CLI do Docker e que confirme que o daemon do Docker está em execução.

Criar 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}

Pode agora aceder à aplicação em http://localhost:8080.

Iniciar sessão no Azure Container Registry:

az acr login --name ${MY_ACR}

Enviar a imagem para o Azure Container Registry:

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

Para obter informações mais aprofundadas sobre como compilar e armazenar imagens de contentores no Azure, veja o módulo do Learn Compilar e armazenar imagens de contentores com o Azure Container Registry.

Aprovisionar um endereço IP público

Se a sua aplicação for acessível a partir das suas redes internas ou virtuais, precisa de um endereço IP estático público. Deverá aprovisionar esse endereço IP dentro do grupo de recursos do nó de cluster, conforme mostrado no exemplo seguinte:

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}."

Implementar no Azure Kubernetes Service (AKS)

Crie e aplique o(s) ficheiro(s) YAML do Kubernetes. Para obter mais informações, consulte Guia de início rápido: implantar um cluster do Serviço Kubernetes do Azure (AKS) usando a CLI do Azure. Se estiver a criar um balanceador de carga externo (seja para a aplicação ou para um controlador de entrada), certifique-se de que fornece o endereço IP aprovisionado na secção anterior como o LoadBalancerIP.

Inclua parâmetros exteriorizados como variáveis de ambiente. Para obter mais informações, veja Definir Variáveis de Ambiente para um Contentor. Não inclua segredos (tais como palavras-passe, chaves de API e cadeias de ligação JDBC). Estes são abrangidos na secção seguinte.

Inclua as definições de memória e CPU quando criar o YAML da implementação, para que os contentores sejam dimensionados corretamente.

Configurar armazenamento persistente

Se a sua aplicação necessitar de armazenamento não volátil, configure um ou mais Volumes Persistentes.

Migrar trabalhos agendados

Para executar trabalhos agendados no seu cluster do AKS, defina o CronJobs do Kubernetes conforme for necessário. Para obter mais informações, veja Executar Tarefas Automatizadas com um CronJob.

Pós-migração

Agora que já migrou a sua aplicação para o Azure Kubernetes Service, deve verificar se esta funciona como o esperado. Depois disso, temos algumas recomendações que podem tornar a sua aplicação mais nativa da cloud.

Recomendações