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

Para implantar arquivos .jar em Java SE, use o ponto de extremidade /api/publish do site do Kudu. Para obter mais informações sobre essa API, confira essa documentação.

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

Para implantar arquivos .war para JBoss, use o ponto de extremidade /api/wardeploy/ para executar POST no arquivo morto. Para obter mais informações sobre essa API, confira essa documentação.

Para implantar arquivos .ear, use o FTP. Seu aplicativo .ear é implantado na raiz de contexto definida na configuração do aplicativo. Por exemplo, se a raiz de contexto do aplicativo for <context-root>myapp</context-root>, você poderá procurar o site no caminho /myapp: http://my-app-name.azurewebsites.net/myapp. Se quiser que seu aplicativo Web seja atendido no caminho raiz, verifique se o aplicativo define a raiz de contexto para o caminho raiz: <context-root>/</context-root>. Para obter mais informações, consulte Definir 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 de Aplicativo do aplicativo Web, crie uma configuração de aplicativo chamada JAVA_OPTS que inclua outras configurações, como -Xms512m -Xmx1204m.

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

Pré-compilar 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 do Maven fornecido pelo Apache Sling ou usando este arquivo de compilação Ant.

Se você estiver usando o Tomcat, poderá optar por fixar a versão de patch do Tomcat. No Windows, você pode fixar as versões de patch da JVM e do Tomcat de maneira independente. No Linux, você pode fixar a versão de patch do Tomcat; a versão de patch da JVM também é fixada, mas não pode ser configurada 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 você não consiga se conectar. Aguarde alguns minutos e tente novamente. Essa abordagem é útil para verificações rápidas do estado do servidor atual (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 da 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 de ponta a ponta, confira 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, confira:

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

Clustering

O Serviço de Aplicativo dá suporte ao clustering para JBoss EAP versões 7.4.1 e superior. 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 clusterizado. Ao executar várias instâncias com dimensionamento automático, as instâncias do JBoss EAP se comunicam entre si pela sub-rede especificada na integração da rede virtual. Você pode desabilitar o clustering criando uma configuração de aplicativo chamada WEBSITE_DISABLE_CLUSTERING com qualquer valor.

Quando o clustering está habilitado, as instâncias JBoss EAP usam o protocolo de descoberta JGroups do FILE_PING para descobrir novas instâncias e persistir 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 de EAP a iniciar obtém permissões de leitura/gravação no arquivo de associação de cluster. Outras instâncias fazem a leitura do arquivo, encontram o nó primário e coordenam com esse nó a ser incluído no cluster e adicionados ao arquivo.

Os tipos de Plano de Serviço de Aplicativo Premium V3 e V2 Isolado podem opcionalmente ser distribuídos entre Zonas de Disponibilidade para melhorar a resiliência e a confiabilidade de suas cargas de trabalho críticas para os negócios. Essa arquitetura também é conhecida como redundância de zona. O recurso de agrupamento do JBoss EAP tem suporte 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 transfira sua atividade (como manipular uma transação de banco de dados) a outro membro do cluster. Ao configurar as regras de dimensionamento automático no Portal para redução vertical, use as seguintes opções:

• Operação: "Diminuir contagem em"
• Esfriar: "5 minutos" ou mais
• Contagem de instâncias: 1

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

Planos do Serviço de Aplicativo

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

Ciclo de vida do servidor do 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 inicialização do servidor
• 3. Fase de configuração do servidor
• 4. Fase de implantação do aplicativo
• 5. Fase de recarregamento do servidor

Confira as respectivas seções abaixo para obter detalhes, bem como oportunidades para personalizá-lo (como por meio de configurações de aplicativo).

1. Fase de configuração do ambiente

• O serviço SSH é iniciado para habilitar sessões de SSH seguras com o contêiner.
• O Repositório de Chaves do runtime do Java é atualizado com todos os 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 em $JRE_HOME/lib/security/cacerts.
  • Os certificados privados são fornecidos pela plataforma no diretório /var/ssl/private e são carregados em $JRE_HOME/lib/security/client.jks.
• Se algum certificado for carregado no repositório de chaves Java nessa etapa, as propriedades javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword e javax.net.ssl.keyStoreType serão adicionadas à variável de ambiente JAVA_TOOL_OPTIONS.
• Algumas configurações iniciais da JVM são determinadas, como diretórios de registro e parâmetros de heap de memória Java:
  • Se você fornecer os sinalizadores –Xms ou –Xmx para a memória na configuração JAVA_OPTS do aplicativo, esses valores substituirão os fornecidos pela plataforma.
  • Se você definir a configuração WEBSITES_CONTAINER_STOP_TIME_LIMIT do aplicativo, o valor será passado para a propriedade org.wildfly.sigterm.suspend.timeoutde runtime, 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 runtime do Serviço de Aplicativo passará uma lista de portas a serem usadas para comunicação entre servidores na variável de ambiente WEBSITE_PRIVATE_PORTS e iniciará o JBoss usando a configuração clustering. Caso contrário, a configuração standalone será usada.
  • Para a configuração clustering, será usado o arquivo de configuração do servidor standalone-azure-full-ha.xml.
  • Para a configuração standalone, será usado o arquivo de configuração do servidor standalone-full.xml.

2. Fase de inicialização do servidor

• Se o JBoss for iniciado na configuração clustering:
  • Cada instância do JBoss recebe um identificador interno entre 0 e o número de instâncias para as quais o aplicativo é escalado horizontalmente.
  • 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á tomando o lugar de 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 de o JBoss estar iniciando na configuração clustering ou standalone, se a versão do servidor for 7.4 ou superior e o runtime usar o Java 17, a configuração será atualizada para habilitar o subsistema Elytron para segurança.
• Se você definir a configuração WEBSITE_JBOSS_OPTS do aplicativo, o valor será passado para o script do inicializador do 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 do 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 Servidor do JBoss e a interface de administrador estão prontos, o Serviço de Aplicativo faz o seguinte:
  • Adiciona o módulo azure.appservice do JBoss, que fornece classes de utilitário para registro em log e integração com o Serviço de Aplicativo.
  • Atualiza o agente do console para usar um modo inválida para que os arquivos de log não estejam cheios de sequências de escape de cores.
  • Configura a integração com os logs do Azure Monitor.
  • Atualiza os endereços IP de associação do WSDL e das interfaces de gerenciamento.
  • Adiciona o módulo azure.appservice.easyauth do JBoss para integração com a autenticação do Serviço de Aplicativo e o Microsoft Entra ID.
  • Atualiza a configuração de registro em 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 seja definida, o Serviço de Aplicativo detecta automaticamente URLs JDBC nas configurações do aplicativo do Serviço de Aplicativo. Se houver URLs JDBC válidas para PostgreSQL, MySQL, MariaDB, Oracle, SQL Server ou Banco de Dados SQL do Azure, ele adicionará os drivers correspondentes ao servidor e adicionará uma fonte de dados para cada URL JDBC e definirá o nome JNDI de cada fonte de dados como java:jboss/env/jdbc/<app-setting-name>_DS, em que <app-setting-name> é o nome da configuração do aplicativo.
• Se a configuração clustering estiver habilitada, o agente do 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 executará o script de inicialização personalizado, se houver. 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; caso contrário,
  • Se o caminho /home/startup.sh existir, use-o.

O comando ou script de inicialização personalizado é executado como usuário raiz (não é necessário para sudo), para que 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, confira a documentação do Servidor Ubuntu. Para comandos da CLI do JBoss, confira o Guia da CLI de Gerenciamento do JBoss.

4. Fase de implantação do aplicativo

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

• Se você tiver configurado 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 houver 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 houver 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 recarregamento do servidor

• Depois que as etapas de implantação forem concluídas, o servidor JBoss será recarregado para aplicar as alterações que exijam um recarregamento do servidor.
• Depois que o servidor for recarregado, os aplicativos implantados no servidor JBoss EAP deverão 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 disparar 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 de forma anormal na configuração clustering, uma função final chamada emit_alert_tx_store_not_empty será executada. A função verifica se o processo do JBoss deixou um arquivo de repositório de transações não vazio no disco; em caso afirmativo, um erro será registrado no console: Error: finishing server with non-empty store for node XXXX. Quando uma nova instância de servidor é iniciada, ela procura esses arquivos de armazenamento de transações não vazios para retomar o trabalho (confira 2. Fase de inicialização do servidor).

Configuração de linha de base do Tomcat

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

• Personalizar a configuração do Tomcat: ao entender o arquivo server.xml e os detalhes de configuração do Tomcat, você poderá ajustar as configurações do servidor para corresponder às necessidades de seus aplicativos.
• Depuração: quando um aplicativo é implantado em um servidor Tomcat, os desenvolvedores precisam conhecer a configuração do servidor para depurar os problemas que possam surgir. Isso inclui verificar os logs do servidor, examinar os arquivos de configuração e identificar erros que possam estar ocorrendo.
• Solucionar problemas do Tomcat: inevitavelmente, os desenvolvedores do 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.
• Implantar 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.

Ao criar um aplicativo com o Tomcat integrado para hospedar a carga de trabalho do Java (um arquivo WAR ou um arquivo JAR), há determinadas configurações que você obtém prontas para uso 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 do Servidor Web Tomcat.

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

As últimas versões do Tomcat contê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.

Connector

<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 é definido como WEBSITE_TOMCAT_CONNECTION_TIMEOUT, que usa 240000 como padrão
• maxThreads é definido como WEBSITE_CATALINA_MAXTHREADS, que usa 200 como padrão
• maxConnections é definido como WEBSITE_CATALINA_MAXCONNECTIONS, que usa 10000 como padrão

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 é definido como AZURE_SITE_APP_BASE, que usa WebappsLocalPath local como padrão
• xmlBase é definido como AZURE_SITE_HOME, que usa /site/wwwroot como padrão
• unpackWARs é definido como AZURE_UNPACK_WARS, que usa true como padrão
• workDir é definido como JAVA_TMP_DIR, que usa TMP como padrão
• errorReportValveClass usa nossa válvula de relatório de erros personalizada

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 é definido como AZURE_LOGGING_DIR, que usa home\logFiles como padrão
• maxDays é WEBSITE_HTTPLOGGING_RETENTION_DAYS, que tem como padrão 7. Isso está alinhado com o padrão da plataforma Application Logging

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

• Adiciona algumas páginas de erro e relatório à 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>