Migrar aplicativos Tomcat para o Tomcat no Serviço de Aplicativo do Azure
Este guia descreve as informações das quais você deve estar ciente quando deseja migrar um aplicativo Tomcat existente para ser executado no Serviço de Aplicativo do Azure usando o Tomcat 9.0.
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 a nenhum desses requisitos de pré-migração, confira os seguintes guias de migração complementares:
- Migrar aplicativos Tomcat para contêineres no Serviço de Kubernetes do Azure
- Migrar aplicativos do Tomcat para Máquinas Virtuais do Azure (diretrizes planejadas)
Alternar para uma plataforma compatível
O Serviço de Aplicativo oferece versões específicas do Tomcat em versões específicas do Java. Para garantir a compatibilidade, migre o aplicativo para uma das versões com suporte do Tomcat e do Java no ambiente atual antes de continuar com qualquer uma das etapas restantes. É necessário testar completamente a configuração resultante. Use a versão estável mais recente da sua distribuição do Linux nesses testes.
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
No Serviço de Aplicativo do Azure, os binários do 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. Esses binários estão disponíveis para download gratuito nos seguintes sites:
Para determinar a sua versão atual do Tomcat, entre no servidor de produção e execute o seguinte comando:
${CATALINA_HOME}/bin/version.sh
Para obter a versão atual usada pelo Serviço de Aplicativo do Azure, baixe o Tomcat 9, dependendo de qual versão você planeja usar no Serviço de Aplicativo do Azure.
Recursos externos de inventário
Recursos externos, como fontes de dados, agentes de mensagem JMS e outros, são injetados por meio de JNDI (Interface de Nomenclatura e Diretório do Java). Alguns desses recursos podem exigir migração ou reconfiguração.
Dentro de seu aplicativo
Inspecione o arquivo META-INF/context.xml. Procure elementos de <Resource> dentro do elemento <Context>.
Nos servidores de aplicativos
Inspecione os arquivos $CATALINA_BASE/conf/context.xml e $CATALINA_BASE/conf/server.xml, bem como os arquivos .xml encontrados nos diretórios $CATALINA_BASE/conf/[nome-do-mecanismo]/[nome-do-host].
Em arquivos context.xml, os recursos de JNDI serão descritos pelos elementos <Resource> dentro do elemento <Context> de nível superior.
Em arquivos server.xml, os recursos de JNDI serão descritos pelos elementos <Resource> dentro do elemento <GlobalNamingResources>.
Fontes de dados
Fontes de dados são recursos de JNDI com o atributo type definido como javax.sql.DataSource. Para cada fonte de dados, documente as seguintes informações:
- 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 Instruções de fonte de dados JNDI na documentação do Tomcat.
Todos os outros recursos externos
Não é possível documentar todas as dependências externas possíveis neste guia. É responsabilidade da sua equipe verificar se você pode atender a todas as dependências externas de seu aplicativo após a migração.
Segredos de inventário
Senhas e cadeias de caracteres seguras
Verifique todas as propriedades e os arquivos de configuração nos servidores de produção para quaisquer senhas e cadeias de caracteres secretas. É necessário verificar server.xml e context.xml em $CATALINA_BASE/conf. Você também pode encontrar arquivos de configuração que contenham senhas ou credenciais dentro de seu aplicativo. Eles podem incluir META-INF/context.xml e, para aplicativos Spring boot, arquivos application.properties ou application.yml.
Inventariar os certificados
Documente todos os certificados usados para pontos de extremidade SSL públicos ou comunicação com bancos de dados de back-end e outros sistemas. Você pode exibir todos os certificados nos servidores de produção executando o seguinte comando:
keytool -list -v -keystore <path to keystore>
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. Você pode identificar alguns ou todos os cenários 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 o aplicativo (como arquivos de dados temporários) ou arquivos estáticos que são visíveis somente para o aplicativo, você pode montar o Armazenamento do Azure no sistema de arquivos do Serviço de Aplicativo. 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 da sessão
Para identificar o gerenciador de persistência de sessão em uso, inspecione os arquivos context.xml em seu aplicativo e a configuração do Tomcat. Procure o elemento <Manager> e observe o valor do atributo className.
As implementações internas de PersistentManager do Tomcat, como StandardManager ou FileStore, não são projetadas para uso com uma plataforma distribuída e dimensionada como o Serviço de Aplicativo. Já que o Serviço de Aplicativo pode balancear a carga entre várias instâncias e reiniciar qualquer instância de maneira transparente a qualquer momento, então a persistência de um estado mutável para um sistema de arquivos não é recomendada.
Se a persistência da sessão for necessária, você precisará usar uma implementação alternativa de PersistentManager que será gravada em um armazenamento de dados externo, como o VMware Tanzu Session Manager com o Cache Redis. Para obter mais informações, confira Usar o Redis como um cache de sessão com o Tomcat.
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.
Casos especiais
Determinados cenários de produção podem exigir alterações adicionais ou impor limitações adicionais. Embora esses cenários sejam raros, é importante verificar se eles não se aplicam ao aplicativo ou estão resolvidos corretamente.
Determinar se o aplicativo depende de trabalhos agendados
Trabalhos agendados, como tarefas do Agendador do Quartz ou trabalhos cron, não podem ser usados com o Serviço de Aplicativo. O Serviço de Aplicativo 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.
Inventarie quaisquer trabalhos agendados, dentro ou fora do servidor de aplicativos.
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 clustering do Tomcat é ou não usado
O clustering do Tomcat não é compatível com o Serviço de Aplicativo do Azure. Em vez disso, você pode configurar e gerenciar o dimensionamento e o balanceamento de carga por meio do Serviço de Aplicativo do Azure sem a funcionalidade específica do Tomcat. Você pode persistir o estado de sessão em um local alternativo para disponibilizá-lo entre réplicas. Para obter mais informações, confira Identificar o mecanismo de persistência da sessão.
Para determinar se seu aplicativo usa clustering, procure o elemento <Cluster> dentro dos elementos <Host> ou <Engine> no arquivo server.xml.
Determinar se conectores não HTTP são ou não usados
O Serviço de Aplicativo dá suporte a apenas um único conector HTTP. Se seu aplicativo exigir conectores adicionais, como o conector AJP, não use o Serviço de Aplicativo.
Para identificar os conectores HTTP usados pelo seu aplicativo, procure elementos <Connector> dentro do arquivo server.xml em sua configuração do Tomcat.
Determinar se MemoryRealm é usado
MemoryRealm requer um arquivo XML persistente. No Serviço de Aplicativo do Azure, você precisará carregar esse arquivo no diretório /home, em um dos subdiretórios dele ou em um armazenamento montado. Em seguida, você precisará modificar o parâmetro pathName de acordo.
Para determinar se MemoryRealm está sendo usado no momento, inspecione os arquivos server.xml e context.xml e pesquise por elementos <Realm> em que o atributo className está definido como org.apache.catalina.realm.MemoryRealm.
Determinar se o acompanhamento de sessão SSL é usado
O Serviço de Aplicativo realiza o descarregamento de sessão fora do runtime do Tomcat. Portanto, não é possível usar o acompanhamento de sessão SSL. Em vez disso, use um modo de acompanhamento de sessão diferente (COOKIE ou URL). Se você precisar de acompanhamento de sessão SSL, não use o Serviço de Aplicativo.
Determine se AccessLogValve é ou não usado
Se você usar AccessLogValve, defina o parâmetro directory como /home/LogFiles ou um dos subdiretórios dele.
Migração
Parametrizar a configuração
Nas etapas de pré-migração, é provável que você tenha identificado alguns segredos e algumas dependências externas, como fontes de dados, nos 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.
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.
Por exemplo, suponha que o arquivo 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="{password}"
/>
Nesse caso, você poderia alterá-lo conforme mostrado no exemplo a seguir:
<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âmetro ocorra para qualquer arquivo context.xml dentro da pasta META-INF dentro de um arquivo .war implantado, defina a variável de ambiente CATALINA_OPTS conforme mostrado no exemplo a seguir:
export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"
Provisionar um plano do Serviço de Aplicativo
Na lista de planos de serviço disponíveis em Preços do Serviço de Aplicativo, selecione o plano cujas especificações correspondem às do hardware de produção atual ou as superam.
Observação
Se você planeja executar implantações de preparo/canário ou usar slots de implantação, o plano do Serviço de Aplicativo precisará incluir essa capacidade adicional. É recomendável usar planos Premium ou superiores para aplicativos Java. Para obter mais informações, consulte Configurar ambientes de preparo no Serviço de Aplicativo do Azure.
Em seguida, crie o plano do Serviço de Aplicativo. Para obter mais informações, confira Gerenciar um plano do Serviço de Aplicativo no Azure.
Criar e implantar aplicativos Web
Você precisará criar um aplicativo Web no plano do Serviço de Aplicativo (escolhendo uma versão do Tomcat como a pilha de runtime) para cada arquivo WAR implantado em seu servidor Tomcat.
Observação
Embora seja possível implantar vários arquivos WAR em um único aplicativo Web, isso é altamente indesejável. Implantar vários arquivos WAR em um único aplicativo Web impede que cada aplicativo seja dimensionado de acordo com suas próprias demandas de uso. Ele também adiciona complexidade a pipelines de implantação subsequentes. Se vários aplicativos precisarem estar disponíveis em uma única URL, considere a possibilidade de usar uma solução de roteamento, como o Gateway de Aplicativo do Azure.
Aplicativos Maven
Se o seu aplicativo for criado com base em um arquivo POM do Maven, use o plug-in do Aplicativo Web para Maven para criar o aplicativo Web e implantar seu aplicativo.
Aplicativos não Maven
Se não for possível usar o plug-in do Maven, você precisará provisionar o aplicativo Web por meio de outros mecanismos, como:
Depois que o aplicativo Web tiver sido criado, use um dos mecanismos de implantação disponíveis para implantar o aplicativo.
Migrar opções de runtime da JVM
Se o aplicativo exigir opções específicas de runtime, use o mecanismo mais apropriado para especificá-las.
Popular segredos
Use as Configurações do Aplicativo para armazenar os segredos específicos no aplicativo. Se você pretende usar os mesmos segredos entre vários aplicativos ou exigir funcionalidades de auditoria e políticas de acesso refinadas, use o Azure Key Vault em vez das Configurações do Aplicativo.
Configurar domínio personalizado e SSL
Se o aplicativo ficar visível em um domínio personalizado, você precisará mapear seu aplicativo Web para ele. Para obter mais informações, confira Tutorial: Mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.
Em seguida, você precisará associar o certificado SSL para esse domínio ao seu aplicativo Web do Serviço de Aplicativo. Para obter mais informações, consulte Proteger um nome DNS personalizado com uma associação SSL no Serviço de Aplicativo do Azure.
Importar certificados de back-end
Todos os certificados para comunicação com sistemas de back-end, como bancos de dados, precisam ser disponibilizados para o Serviço de Aplicativo. Para obter mais informações, consulte Adicionar um certificado SSL no Serviço de Aplicativo.
Migrar fontes de dados, bibliotecas e recursos de JNDI
Para obter as etapas de configuração da fonte de dados, consulte a seção Fontes de dados em Configurar um aplicativo Java do Linux para o Serviço de Aplicativo do Azure.
Para obter instruções adicionais da fonte de dados, consulte as seções a seguir das Instruções de fonte de dados JNDI na documentação do Tomcat:
Migre as dependências de classpath de nível de servidor adicionais seguindo as mesmas etapas para arquivos JAR de fonte de dados.
Migre quaisquer recursos JDNI de nível de servidor compartilhados adicionais.
Observação
Se você estiver seguindo a arquitetura recomendada de um WAR por aplicativo Web, considere migrar bibliotecas de classpath de nível de servidor e recursos de JNDI para o aplicativo. Isso simplificará significativamente a governança de componentes e o gerenciamento de alterações.
Migrar a configuração restante
Ao concluir a seção anterior, você deve ter sua configuração de servidor personalizável em /Home/Tomcat/conf.
Concluir a migração copiando qualquer configuração adicional (como realms e JASPIC)
Migrar os trabalhos agendados
Para realizar trabalhos agendados no Azure, considere a possibilidade de usar um Gatilho de temporizador para Azure Functions. Você não precisa migrar o código do trabalho propriamente dito para uma função. A função pode simplesmente invocar uma URL no aplicativo para disparar o trabalho. Se essas execuções de trabalho precisarem ser invocadas dinamicamente e/ou rastreadas de forma centralizada, considere a possibilidade de usar um lote do Spring.
Como alternativa, você pode criar um aplicativo lógico com um gatilho de recorrência para invocar a URL sem gravar nenhum código fora do aplicativo. Para obter mais informações, consulte Visão geral: O que são os Aplicativos Lógicos do Azure? e Criar, agendar e executar tarefas e fluxos de trabalho recorrentes com o gatilho de recorrência em Aplicativos Lógicos do Azure.
Observação
Para evitar o uso mal-intencionado, você provavelmente precisará garantir que o ponto de extremidade de invocação do trabalho exija credenciais. Nesse caso, a função de gatilho precisará fornecer as credenciais.
Reinicialização e smoke test
Por fim, você precisará reiniciar seu aplicativo Web para aplicar todas as alterações de configuração. Após a conclusão da reinicialização, verifique se o aplicativo está sendo executado corretamente.
Após a migração
Agora que você migrou seu aplicativo para o Serviço de Aplicativo 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 da nuvem.
Recomendações
Se você optou por usar o diretório /home para armazenamento de arquivos, considere substituí-lo pelo Armazenamento do Azure.
Se você tiver uma configuração no diretório /home que contém cadeias de conexão, chaves SSL e outras informações de segredo, considere usar uma combinação do Azure Key Vault e/ou uma injeção de parâmetro com configurações de aplicativo sempre que possível.
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.
Considere usar slots de implantação para implantações confiáveis sem nenhum tempo de inatividade.
Crie e implemente uma estratégia de DevOps. Para manter a confiabilidade, aumentando simultaneamente a velocidade de desenvolvimento, considere automatizar implantações e testar com Azure Pipelines. Ao usar slots de implantação, você pode automatizar a implantação em um slot e depois trocá-lo por outro.
Criar a implementar uma estratégia de continuidade dos negócios e recuperação de desastre. Para aplicativos críticos, considere a possibilidade de usar uma arquitetura de implantação em várias regiões.