Migrar aplicações Tomcat para o Tomcat no Serviço de Aplicações do Azure

  • Artigo

Este guia descreve aquilo de que deve estar ciente quando quer migrar uma aplicação Tomcat já existente para a executar no Serviço de Aplicações do Azure com o Tomcat 9.0.

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.

Se você não puder atender a nenhum desses requisitos de pré-migração, consulte os seguintes guias complementares de migração:

Mudar para uma plataforma suportada

O Serviço de Aplicações oferece versões específicas do Tomcat em versões específicas de Java. Para garantir a compatibilidade, migre seu aplicativo para uma das versões suportadas do Tomcat e Java em seu ambiente atual antes de continuar com qualquer uma das etapas restantes. Certifique-se de que testa a configuração resultante na íntegra. Utilize a versão estável mais recente da sua distribuição Linux nestes testes.

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

No Serviço de Aplicativo do Azure, os binários para Java 8 são fornecidos pelo Eclipse Temurin. Para Java 11, 17 e todas as versões LTS futuras do Java, o Serviço de Aplicativo fornece o Microsoft Build do OpenJDK. Estes binários estão disponíveis para download gratuito nos seguintes sites:

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

${CATALINA_HOME}/bin/version.sh

Para obter a versão atual utilizada pelo Serviço de Aplicações do Azure, transfira o Tomcat 9, dependendo da versão que tencione utilizar no Serviço de Aplicações do Azure.

Inventariar os recursos externos

Os recursos externos, como origens de dados, mediadores de mensagens JMS, entre outros, são injetados através de Java Naming and Directory Interface (JNDI). Alguns desses recursos podem precisar de migração ou reconfiguração.

Na aplicação

Inspecione o ficheiro META-INF/context.xml. Procure elementos <Resource> dentro do elemento <Context>.

No servidor ou servidores da aplicação

Inspecione os ficheiros $CATALINA_BASE/conf/context.xml e $CATALINA_BASE/conf/server.xml, bem como os ficheiros .xml e localizados nos diretórios $CATALINA_BASE/conf/[engine-name]/[host-name].

Nos ficheiros context.xml, os recursos JNDI serão descritos pelos elementos <Resource> dentro do elemento <Context> de nível superior.

Nos ficheiros server.xml, os recursos JNDI serão descritos pelos elementos <Resource> dentro do elemento <GlobalNamingResources>.

Origens de Dados

Origens de dados e recursos JNDI com o atributo type definido como javax.sql.DataSource. Documente a seguinte informação de cada origem de dados:

  • 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 o MANUAL DE INSTRUÇÕES da Origem de Dados do JNDI na documentação do Tomcat.

Todos os outros recursos externos

Não é exequível documentar todas as dependências externas possíveis neste guia. Cabe à sua equipa verificar que pode satisfazer todas as dependências externas da sua aplicação após a migração.

Inventariar segredos

Palavras-passe e cadeias protegidas

Procure cadeias de 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 server.xml e context.xml em $CATALINA_BASE/conf. Também poderá encontrar ficheiros de configuração com palavras-passe ou credenciais dentro da aplicação. Esses ficheiros podem incluir META-INF/context.xml e, para aplicações Spring Boot, application.properties ou application.yml.

Inventariar certificados

Documente todos os certificados utilizados em pontos finais SSL públicos ou em comunicações com bases de dados de back-end e outros sistemas. Pode ver todos os certificados no servidor ou servidores de produção com o comando seguinte:

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

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. Poderá identificar alguns ou todos os cenários 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 apenas estão visíveis para a sua aplicação, pode montar o Armazenamento do Microsoft Azure no sistema de ficheiros do Serviço de Aplicações. Para obter mais informações, consulte Montar o Armazenamento do Azure como um compartilhamento local no Serviço de Aplicativo.

Identificar o mecanismo de persistência de sessão

Para identificar o gestor de persistência de sessão que está a ser utilizado, inspecione os ficheiros context.xml que se encontram na sua aplicação e a configuração do Tomcat. Procure o elemento <Manager> e, em seguida, veja o valor do atributo className.

As implementações PersistentManager integradas do Tomcat, tais como StandardManager ou FileStore, não foram concebidas para serem utilizadas com uma plataforma distribuída e dimensionada como o Serviço de Aplicações. Como o Serviço de Aplicações poderá balancear a carga entre várias instâncias e reiniciar de forma transparente qualquer instância em qualquer momento, não se recomenda que um sistema de ficheiros permaneça num estado mutável.

Se a persistência da sessão for necessária, você precisará usar uma implementação alternativa PersistentManager que gravará em um armazenamento de dados externo, como o VMware Tanzu Session Manager com Cache Redis. Para obter mais informações, veja Utilizar Redis como cache da sessão com o Tomcat.

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.

Casos especiais

Alguns cenários de produção poderão exigir alterações adicionais ou impor mais limitações. Embora esses cenários possam ser pouco frequentes, é importante garantir que eles sejam inaplicáveis ao seu aplicativo ou resolvidos corretamente.

Determinar se a aplicação depende de tarefas agendadas

As tarefas agendadas, tais como tarefas do Quartz Scheduler ou do Cron, não podem ser utilizadas com o Serviço de Aplicações. O Serviço de Aplicativo não impedirá que você implante um aplicativo que contenha tarefas agendadas internamente. 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.

Faça o inventário de todas as tarefas agendadas, dentro ou fora do servidor de aplicações.

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 o clustering do Tomcat está a ser utilizado

O clustering do Tomcat não é suportado no Serviço de Aplicações do Azure. Em vez disso, pode configurar e gerir o dimensionamento e o balanceamento de carga através do Serviço de Aplicações do Azure sem funcionalidade específica do Tomcat. Pode fazer com que o estado de sessão permaneça num local alternativo para o tornar disponível nas réplicas. Para obter mais informações, veja Identificar o mecanismo de persistência de sessão.

Para determinar se a sua aplicação utiliza clustering, procure o elemento <Cluster> dentro dos elementos <Host> ou <Engine> no ficheiro server.xml.

Determinar se há conectores não HTTP a ser utilizados

O Serviço de Aplicações suporta apenas um único conector HTTP. Se a sua aplicação necessitar de conectores adicionais, tais como o conector AJP, não utilize o Serviço de Aplicações.

Para identificar os conectores HTTP utilizados pela sua aplicação, procure elementos <Connector> dentro do ficheiro server.xml na configuração do Tomcat.

Determinar se o MemoryRealm está a ser utilizado

O MemoryRealm necessita de um ficheiro XML persistente. No Azure AppService, você precisará carregar esse arquivo para o diretório /home ou um de seus subdiretórios, ou para o armazenamento montado. Em seguida, você precisará modificar o pathName parâmetro de acordo.

Para determinar se o MemoryRealm está a ser utilizado atualmente, inspecione os seus ficheiros server.xml e context.xml e procure elementos <Realm> nos quais o atributo className está definido como org.apache.catalina.realm.MemoryRealm.

Determinar se o controlo de sessões de SSL está a ser utilizado

O Serviço de Aplicativo executa o descarregamento de sessão fora do tempo de execução do Tomcat, portanto, você não pode usar o rastreamento de sessão SSL. Em vez disso, utilize um modo de controlo de sessões diferente deste (COOKIE ou URL). Se precisar do controlo de sessões de SSL, não utilize o Serviço de Aplicações.

Determinar se o AccessLogValve está a ser utilizado

Se você usar AccessLogValve, você deve definir o directory parâmetro para /home/LogFiles ou um de seus subdiretórios.

Migração

Parametrizar a configuração

Nas etapas de pré-migração, você provavelmente identificou alguns segredos e dependências externas, como fontes de dados, em arquivos server.xml e context.xml . Para cada item identificado, substitua qualquer nome de usuário, senha, cadeia de conexão ou URL por uma variável de ambiente.

Por exemplo, imagine que o ficheiro context.xml contém o seguinte elemento:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

Neste caso, pode mudá-lo conforme mostrado no seguinte exemplo:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Para garantir que a substituição de parâmetros ocorra para qualquer arquivo de context.xml dentro da pasta META-INF dentro de um arquivo .war implantado, certifique-se de definir a CATALINA_OPTS variável de ambiente conforme mostrado no exemplo a seguir:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

Aprovisionar um plano do Serviço de Aplicações

Na lista de planos de serviço disponíveis na tabela de preços do Serviço de Aplicações, selecione o plano cujas especificações correspondem ou excedem as especificações do hardware de produção atual.

Nota

Se planeia executar implementações de teste/proteção ou utilizar blocos de implementação, o plano do Serviço de Aplicações tem de incluir essa capacidade adicional. Recomendamos a utilização de planos Premium ou superiores para aplicações Java. Para obter mais informações, veja Configurar ambientes de teste no Serviço de Aplicações do Azure.

Em seguida, crie o plano do Serviço de Aplicações. Para obter mais informações, veja Gerir um plano do Serviço de Aplicações no Azure.

Criar e implementar aplicações Web

Terá de criar uma aplicação Web no seu Plano do Serviço de Aplicações (escolhendo uma versão do Tomcat como pilha de runtime) para cada ficheiro WAR implementado no seu servidor Tomcat.

Nota

Embora seja possível implementar múltiplos ficheiros WAR numa única aplicação Web, isto é extremamente indesejável. A implementação de múltiplos ficheiros WAR numa única aplicação Web impede que cada aplicação seja dimensionada de acordo com as suas próprias exigências de utilização. Além disso, torna os pipelines de implementação posteriores mais complexos. Se for necessário que múltiplas aplicações estejam disponíveis num único URL, considere utilizar uma solução de encaminhamento, tal como o Gateway de Aplicação do Azure.

Aplicações do Maven

Se a sua aplicação tiver sido criada a partir de um ficheiro POM do Maven, utilize o plug-in de aplicações Web para o Maven para criar a aplicação Web e implementar a sua aplicação.

Aplicações não pertencentes ao Maven

Se não puder utilizar o plug-in do Maven, terá de aprovisionar a aplicação Web através de outros mecanismos, tais como:

Uma vez criada a aplicação Web, utilize um dos mecanismos de implementação disponíveis para implementar a sua aplicação.

Migrar opções de runtime JVM

Se a sua aplicação necessitar de opções específicas de runtime, utilize o mecanismo mais adequado para as especificar.

Preencher segredos

Utilize as Definições da Aplicação para armazenar segredos específicos da sua aplicação. Se pretender partilhar os mesmos segredos entre múltiplas aplicações ou necessitar de capacidades de auditoria e políticas de acesso detalhadas, utilize o Azure Key Vault como alternativa.

Configurar o domínio personalizado e o SSL

Se a sua aplicação estiver visível num domínio personalizado, tem de mapear a aplicação Web para o mesmo. Para obter mais informações, consulte Tutorial: Mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.

Em seguida, tem de vincular o certificado SSL desse domínio à Aplicação Web do Serviço de Aplicações. Para obter mais informações, veja Proteger um nome DNS personalizado com um enlace SSL no Serviço de Aplicações do Azure.

Importar certificados de back-end

Todos os certificados para comunicação com sistemas de back-end, como bases de dados têm de ser disponibilizados para o Serviço de Aplicações. Para obter mais informações, veja Adicionar um certificado SSL no Serviço de Aplicações.

Migrar origens de dados, bibliotecas e recursos JNDI

Para obter os passos de configuração da origem de dados, veja a secção Origens de dados do artigo Configurar uma aplicação Java do Linux para o Serviço de Aplicações do Azure.

Para obter instruções adicionais da origem de dados, veja as seguintes secções do Manual de Instruções da Origem de Dados do JNDI na documentação do Tomcat:

Siga os mesmos passos que seguiu para os ficheiros JAR de origem de dados para migrar outras dependências de classpath ao nível do servidor.

Migre quaisquer recursos JDNI de nível de servidor partilhados adicionais.

Nota

Se estiver a seguir a arquitetura recomendada de um WAR por aplicação Web, considere migrar recursos JNDI e bibliotecas de classpath ao nível do servidor para a sua aplicação. Isto simplificará significativamente a governação dos componentes e a gestão da mudança.

Migrar a configuração restante

Quando concluir a secção anterior, deverá ter a configuração personalizável do servidor em /home/tomcat/conf.

Copie qualquer configuração adicional (tal como realms e JASPIC) para concluir a migração

Migrar trabalhos agendados

Para executar trabalhos agendados no Azure, considere utilizar um acionador Temporizador para as Funções do Azure. Não é preciso migrar o código do trabalho para uma função. Esta pode simplesmente invocar um URL na aplicação para acionar o trabalho. Se essas execuções de trabalhos tiverem de ser invocadas dinamicamente e/ou monitorizadas centralmente, considere utilizar o Spring Batch.

Em alternativa, pode criar uma aplicação lógica com um acionador Recorrência para invocar o URL sem escrever código fora da aplicação. Para obter mais informações, veja Descrição Geral – O que é o Azure Logic Apps? e Criar, agendar e executar tarefas e fluxos de trabalho recorrentes com o acionador Recorrência no Azure Logic Apps.

Nota

Para evitar utilizações maliciosas, é provável que tenha de confirmar que o ponto final de invocação dos trabalhos exige credenciais. Nesse caso, a função de acionador terá de fornecer essas credenciais.

Reiniciar e efetuar teste de fumo

Por fim, terá de reiniciar a sua aplicação Web para aplicar todas as alterações de configuração. Após a conclusão do reinício, verifique se a sua aplicação está a funcionar corretamente.

Pós-migração

Agora que já migrou a sua aplicação para o Serviço de Aplicações do Azure, deve verificar se esta funciona como esperado. Posto isto, temos algumas recomendações que podem tornar a sua aplicação mais nativa da cloud.

Recomendações