Implantar e configurar um aplicativo Tomcat, JBoss ou Java SE no Serviço de Aplicativo do Azure

Para implementar arquivos .jar no Java SE, use o /api/publish endpoint do site Kudu. Para obter mais informações sobre essa API, consulte esta documentação.

Para implantar arquivos .war no Tomcat, use o /api/wardeploy/ ponto de extremidade para POSTAR seu arquivo morto. Para obter mais informações sobre essa API, consulte esta documentação.

Para implantar arquivos .war no JBoss, use o /api/wardeploy/ endpoint para POSTAR seu arquivo morto. Para obter mais informações sobre essa API, consulte esta documentação.

Para implantar arquivos .ear, use FTP. Seu aplicativo .ear é implantado na raiz de contexto definida na configuração do aplicativo. Por exemplo, se a raiz de contexto do seu aplicativo for <context-root>myapp</context-root>, você poderá navegar no site no /myapp caminho: http://my-app-name.azurewebsites.net/myapp. Se você quiser que seu aplicativo Web seja servido no caminho raiz, certifique-se de que seu aplicativo defina a raiz de contexto para o caminho raiz: <context-root>/</context-root>. Para obter mais informações, consulte Definindo a raiz de contexto de um aplicativo Web.

O Tomcat também fornece uma válvula de reescrita.

O JBoss também fornece uma válvula de reescrita.

No portal do Azure, em Configurações do Aplicativo para o aplicativo Web, crie uma nova configuração de aplicativo chamada JAVA_OPTS que inclua outras configurações, como -Xms512m -Xmx1204m.

No portal do Azure, em Configurações do Aplicativo para o aplicativo Web, crie uma nova configuração de aplicativo chamada CATALINA_OPTS que inclua outras configurações, como -Xms512m -Xmx1204m.

Pré-compilação de arquivos JSP

Para melhorar o desempenho dos aplicativos Tomcat, você pode compilar seus arquivos JSP antes de implantar no Serviço de Aplicativo. Você pode usar o plug-in Maven fornecido pelo Apache Sling ou usar este arquivo de compilação Ant.

Se estiver a utilizar o Tomcat, pode optar por fixar a versão do patch do Tomcat. No Windows, você pode fixar as versões de patch da JVM e do Tomcat de forma independente. No Linux, você pode fixar a versão patch do Tomcat; a versão de patch da JVM também é fixada, mas não é configurável separadamente.

Executar a CLI do JBoss

Na sessão SSH do aplicativo JBoss, você pode executar a CLI do JBoss com o seguinte comando:

$JBOSS_HOME/bin/jboss-cli.sh --connect

Dependendo de onde o JBoss está no ciclo de vida do servidor, talvez não seja possível se conectar. Aguarde alguns minutos e tente novamente. Essa abordagem é útil para verificações rápidas do estado atual do servidor (por exemplo, para ver se uma fonte de dados está configurada corretamente).

Além disso, as alterações feitas no servidor com a CLI do JBoss na sessão SSH não persistem após a reinicialização do aplicativo. Sempre que o aplicativo é iniciado, o servidor JBoss EAP começa com uma instalação limpa. Durante o ciclo de vida de inicialização, o Serviço de Aplicativo faz as configurações de servidor necessárias e implanta o aplicativo. Para fazer alterações persistentes no servidor JBoss, use um script de inicialização personalizado ou um comando de inicialização. Para obter um exemplo completo, consulte Configurar fontes de dados para um aplicativo Tomcat, JBoss ou Java SE no Serviço de Aplicativo do Azure.

Como alternativa, você pode configurar manualmente o Serviço de Aplicativo para executar qualquer arquivo na inicialização. Por exemplo:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Para obter mais informações sobre os comandos da CLI que você pode executar, consulte:

• Documentação do Red Hat JBoss EAP
• WildFly CLI Receitas

Clustering

O Serviço de Aplicativo oferece suporte a clustering para JBoss EAP versões 7.4.1 e superiores. Para habilitar o clustering, seu aplicativo Web deve ser integrado a uma rede virtual. Quando o aplicativo Web é integrado a uma rede virtual, ele é reiniciado e a instalação do JBoss EAP é iniciada automaticamente com uma configuração clusterizada. Quando você executa várias instâncias com dimensionamento automático, as instâncias EAP do JBoss se comunicam entre si pela sub-rede especificada na integração de rede virtual. Você pode desabilitar o clustering criando uma configuração de aplicativo nomeada WEBSITE_DISABLE_CLUSTERING com qualquer valor.

Quando o clustering está habilitado, as instâncias do JBoss EAP usam o protocolo de descoberta JGroups FILE_PING para descobrir novas instâncias e manter as informações do cluster, como os membros do cluster, seus identificadores e seus endereços IP. No Serviço de Aplicativo, esses arquivos estão em /home/clusterinfo/. A primeira instância EAP a iniciar obtém permissões de leitura/gravação no arquivo de associação do cluster. Outras instâncias leem o arquivo, localizam o nó primário e coordenam-se com esse nó a ser incluído no cluster e adicionado ao arquivo.

Os tipos Premium V3 e Isolated V2 App Service Plan podem, opcionalmente, ser distribuídos entre zonas de disponibilidade para melhorar a resiliência e a confiabilidade para suas cargas de trabalho críticas para os negócios. Essa arquitetura também é conhecida como redundância de zona. O recurso de clustering JBoss EAP é compatível com o recurso de redundância de zona.

Regras de dimensionamento automático

Ao configurar regras de dimensionamento automático para dimensionamento horizontal, é importante remover instâncias incrementalmente (uma de cada vez) para garantir que cada instância removida possa transferir sua atividade (como lidar com uma transação de banco de dados) para outro membro do cluster. Ao configurar suas regras de dimensionamento automático no Portal para reduzir a escala, use as seguintes opções:

• Operação: "Diminuir contagem por"
• Arrefecimento: "5 minutos" ou superior
• Contagem de instâncias: 1

Você não precisa adicionar instâncias incrementalmente (dimensionamento), você pode adicionar várias instâncias ao cluster de cada vez.

Planos do Serviço de Aplicações

O JBoss EAP está disponível nos seguintes níveis de preços: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 e P5mv3.

Ciclo de vida do servidor JBoss

Um aplicativo JBoss EAP no Serviço de Aplicativo passa por cinco fases distintas antes de realmente iniciar o servidor.

• 1. Fase de configuração do ambiente
• 2. Fase de lançamento do servidor
• 3. Fase de configuração do servidor
• 4. Fase de implementação da aplicação
• 5. Fase de recarga do servidor

Consulte as respetivas seções abaixo para obter detalhes, bem como oportunidades para personalizá-lo (como por meio das configurações do aplicativo).

1. Fase de configuração do ambiente

• O serviço SSH é iniciado para habilitar sessões SSH seguras com o contêiner.
• O Keystore do tempo de execução Java é atualizado com quaisquer certificados públicos e privados definidos no portal do Azure.
  • Os certificados públicos são fornecidos pela plataforma no diretório /var/ssl/certs e são carregados no $JRE_HOME/lib/security/cacerts.
  • Os certificados privados são fornecidos pela plataforma no diretório /var/ssl/private e são carregados no $JRE_HOME/lib/security/client.jks.
• Se algum certificado for carregado no keystore Java nesta etapa, as propriedades javax.net.ssl.keyStoree javax.net.ssl.keyStorePassword javax.net.ssl.keyStoreType serão adicionadas à JAVA_TOOL_OPTIONS variável de ambiente.
• Algumas configurações iniciais da JVM são determinadas, como diretórios de log e parâmetros de heap de memória Java:
  • Se você fornecer os –Xms sinalizadores ou –Xmx para memória na configuração JAVA_OPTSdo aplicativo, esses valores substituem os fornecidos pela plataforma.
  • Se você definir a configuração WEBSITES_CONTAINER_STOP_TIME_LIMITdo aplicativo, o valor será passado para a propriedade org.wildfly.sigterm.suspend.timeoutruntime , que controla o tempo máximo de espera de desligamento (em segundos) quando o JBoss está sendo interrompido.
• Se o aplicativo estiver integrado a uma rede virtual, o tempo de execução do Serviço de Aplicativo passará uma lista de portas a serem usadas para comunicação entre servidores na variável WEBSITE_PRIVATE_PORTS de ambiente e iniciará o JBoss usando a clustering configuração. Caso contrário, a standalone configuração será usada.
  • Para a clustering configuração, o arquivo de configuração do servidor standalone-azure-full-ha.xml é usado.
  • Para a standalone configuração, o arquivo de configuração do servidor standalone-full.xml é usado.

2. Fase de lançamento do servidor

• Se o clustering JBoss for iniciado na configuração:
  • Cada instância do JBoss recebe um identificador interno entre 0 e o número de instâncias para as quais o aplicativo é expandido.
  • Se alguns arquivos forem encontrados no caminho do repositório de transações para essa instância do servidor (usando seu identificador interno), isso significa que essa instância do servidor está substituindo uma instância de serviço idêntica que falhou anteriormente e deixou transações não confirmadas para trás. O servidor está configurado para retomar o trabalho nessas transações.
• Independentemente se o JBoss estiver começando na clustering configuração ou standalone , se a versão do servidor for 7.4 ou superior e o tempo de execução usar Java 17, a configuração será atualizada para habilitar o subsistema Elytron para segurança.
• Se você definir a configuração WEBSITE_JBOSS_OPTSdo aplicativo, o valor será passado para o script do iniciador JBoss. Essa configuração pode ser usada para fornecer caminhos para arquivos de propriedade e mais sinalizadores que influenciam a inicialização do JBoss.

3. Fase de configuração do servidor

• No início dessa fase, o Serviço de Aplicativo aguarda primeiro que o servidor JBoss e a interface de administração estejam prontos para receber solicitações antes de continuar. Isso pode levar mais alguns segundos se o Application Insights estiver habilitado.
• Quando o JBoss Server e a interface de administração estiverem prontos, o Serviço de Aplicativo fará o seguinte:
  • Adiciona o módulo azure.appserviceJBoss , que fornece classes de utilitário para registro em log e integração com o Serviço de Aplicativo.
  • Atualiza o registrador de console para usar um modo incolor para que os arquivos de log não estejam cheios de sequências de fuga de cores.
  • Configura a integração com os logs do Azure Monitor.
  • Atualiza os endereços IP de ligação das interfaces WSDL e de gerenciamento.
  • Adiciona o módulo azure.appservice.easyauth JBoss para integração com autenticação do Serviço de Aplicativo e ID do Microsoft Entra.
  • Atualiza a configuração de log dos logs de acesso e o nome e a rotação do arquivo de log do servidor principal.
• A menos que a configuração WEBSITE_SKIP_AUTOCONFIGURE_DATABASE do aplicativo esteja definida, o Serviço de Aplicativo deteta automaticamente URLs JDBC nas configurações do aplicativo do Serviço de Aplicativo. Se existirem URLs JDBC válidas para PostgreSQL, MySQL, MariaDB, Oracle, SQL Server ou Banco de Dados SQL do Azure, ele adicionará o(s) driver(es) correspondente(s) ao servidor e adicionará uma fonte de dados para cada URL JDBC e definirá o nome JNDI para cada fonte de dados como java:jboss/env/jdbc/<app-setting-name>_DS, onde <app-setting-name> é o nome da configuração do aplicativo.
• Se a clustering configuração estiver habilitada, o registrador de console a ser configurado será verificado.
• Se houver arquivos JAR implantados no diretório /home/site/libs , um novo módulo global será criado com todos esses arquivos JAR.
• No final da fase, o Serviço de Aplicativo executa o script de inicialização personalizado, se existir. A lógica de pesquisa para o script de inicialização personalizado da seguinte maneira:
  • Se você configurou um comando de inicialização (no portal do Azure, com a CLI do Azure, etc.), execute-o; caso contrário,
  • Se o caminho /home/site/scripts/startup.sh existir, use-o;
  • Se o caminho /home/startup.sh existir, use-o.

O comando ou script de inicialização personalizado é executado como o usuário root (sem necessidade de ), para sudoque eles possam instalar pacotes Linux ou iniciar a CLI do JBoss para executar mais comandos de instalação/personalização do JBoss (criação de fontes de dados, instalação de adaptadores de recursos), etc. Para obter informações sobre os comandos de gerenciamento de pacotes do Ubuntu, consulte a documentação do Ubuntu Server. Para obter os comandos da CLI do JBoss, consulte o Guia da CLI do JBoss Management.

4. Fase de implementação da aplicação

O script de inicialização implanta aplicativos no JBoss procurando nos seguintes locais, em ordem de precedência:

• Se você definiu a configuração WEBSITE_JAVA_WAR_FILE_NAMEdo aplicativo , implante o arquivo designado por ele.
• Se /home/site/wwwroot/app.war existir, implante-o.
• Se existirem outros arquivos EAR e WAR em /home/site/wwwroot, implante-os.
• Se /home/site/wwwroot/webapps existir, implante os arquivos e diretórios nele. Os arquivos WAR são implantados como aplicativos em si, e os diretórios são implantados como aplicativos Web "explodidos" (descompactados).
• Se existirem páginas JSP autônomas em /home/site/wwwroot, copie-as para a raiz do servidor Web e implante-as como um aplicativo Web.
• Se nenhum arquivo implantável for encontrado ainda, implante a página de boas-vindas padrão (página de estacionamento) no contexto raiz.

5. Fase de recarga do servidor

• Quando as etapas de implantação estiverem concluídas, o servidor JBoss será recarregado para aplicar quaisquer alterações que exijam uma recarga do servidor.
• Após o recarregamento do servidor, o(s) aplicativo(s) implantado(s) no servidor JBoss EAP devem estar prontos para responder às solicitações.
• O servidor é executado até que o aplicativo do Serviço de Aplicativo seja interrompido ou reiniciado. Você pode parar ou reiniciar manualmente o aplicativo do Serviço de Aplicativo ou acionar uma reinicialização ao implantar arquivos ou fazer alterações de configuração no aplicativo do Serviço de Aplicativo.
• Se o servidor JBoss sair anormalmente na clustering configuração, uma função final chamada emit_alert_tx_store_not_empty será executada. A função verifica se o processo JBoss deixou um arquivo de armazenamento de transações não vazio no disco; Em caso afirmativo, é registado um erro na consola: Error: finishing server with non-empty store for node XXXX. Quando uma nova instância do servidor é iniciada, ela procura esses arquivos de armazenamento de transações não vazios para retomar o trabalho (consulte 2. Fase de lançamento do servidor).

Configuração de linha de base do Tomcat

Os desenvolvedores Java podem personalizar as configurações do servidor, solucionar problemas e implantar aplicativos no Tomcat com confiança se souberem sobre o arquivo de server.xml e os detalhes de configuração do Tomcat. As personalizações possíveis incluem:

• Personalizando a configuração do Tomcat: Entendendo o arquivo server.xml e os detalhes de configuração do Tomcat, você pode ajustar as configurações do servidor para atender às necessidades de seus aplicativos.
• Depuração: Quando um aplicativo é implantado em um servidor Tomcat, os desenvolvedores precisam saber a configuração do servidor para depurar quaisquer problemas que possam surgir. Isso inclui verificar os logs do servidor, examinar os arquivos de configuração e identificar quaisquer erros que possam estar ocorrendo.
• Solução de problemas do Tomcat: Inevitavelmente, os desenvolvedores Java encontram problemas com seu servidor Tomcat, como problemas de desempenho ou erros de configuração. Ao entender o arquivo server.xml e os detalhes de configuração do Tomcat, os desenvolvedores podem diagnosticar e solucionar esses problemas rapidamente, o que pode economizar tempo e esforço.
• Implantando aplicativos no Tomcat: para implantar um aplicativo Web Java no Tomcat, os desenvolvedores precisam saber como configurar o arquivo server.xml e outras configurações do Tomcat. Entender esses detalhes é essencial para implantar aplicativos com êxito e garantir que eles sejam executados sem problemas no servidor.

Quando você cria um aplicativo com o Tomcat integrado para hospedar sua carga de trabalho Java (um arquivo WAR ou um arquivo JAR), há certas configurações que você obtém para a configuração do Tomcat. Você pode consultar a documentação oficial do Apache Tomcat para obter informações detalhadas, incluindo a configuração padrão para o servidor Web Tomcat.

Além disso, há certas transformações que são aplicadas em cima do server.xml para a distribuição do Tomcat no início. Estas são transformações para as configurações de conector, host e válvula.

As últimas versões do Tomcat têm server.xml (8.5.58 e 9.0.38 em diante). As versões mais antigas do Tomcat não usam transformações e podem ter um comportamento diferente como resultado.

Conector

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>

• maxHttpHeaderSize está definido como 16384
• URIEncoding está definido como UTF-8
• connectionTimeout está definido como WEBSITE_TOMCAT_CONNECTION_TIMEOUT, cujo padrão é 240000
• maxThreads está definido como WEBSITE_CATALINA_MAXTHREADS, cujo padrão é 200
• maxConnections está definido como WEBSITE_CATALINA_MAXCONNECTIONS, cujo padrão é 10000

A seguir estão exemplos de comandos da CLI que você pode usar para alterar os valores de connectionTimeout, maxThreads ou maxConnections:

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000

• O conector usa o endereço do contêiner em vez de 127.0.0.1

Host

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">

• appBase está definido como AZURE_SITE_APP_BASE, cujo padrão é local WebappsLocalPath
• xmlBase está definido como AZURE_SITE_HOME, cujo padrão é /site/wwwroot
• unpackWARs está definido como AZURE_UNPACK_WARS, cujo padrão é true
• workDir está definido como JAVA_TMP_DIR, que assume como predefinição TMP
• errorReportValveClass Usa nossa válvula de relatório de erro personalizado

Válvula

<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>

• directory está definido como AZURE_LOGGING_DIR, cujo padrão é home\logFiles
• maxDays é para WEBSITE_HTTPLOGGING_RETENTION_DAYS, que é padrão para 7. Isso se alinha com o padrão da plataforma de log de aplicativos

No Linux, ele tem a mesma personalização, além de:

• Adiciona algumas páginas de erros e relatórios à válvula:

  <xsl:attribute name="appServiceErrorPage">
      <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
  </xsl:attribute>
  
  <xsl:attribute name="showReport">
      <xsl:value-of select="'${catalina.valves.showReport}'"/>
  </xsl:attribute>
  
  <xsl:attribute name="showServerInfo">
      <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
  </xsl:attribute>