Compartilhar via

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

  • Artigo

Este artigo mostra a configuração de runtime e implantação mais comum para aplicativos Java no Serviço de Aplicativo. Se você nunca tiver usado o Serviço de Aplicativo do Azure, leia o Início rápido do Java primeiro. Dúvidas gerais sobre como usar o Serviço de Aplicativo que não são específicas do desenvolvimento em Java são respondidas nas Perguntas frequentes sobre o Serviço de Aplicativo.

O Serviço de Aplicativo do Azure executa aplicativos Web Java em um serviço totalmente gerenciado em três variantes:

  • Java SE – pode executar um aplicativo implantado como um pacote JAR que contém um servidor inserido (como Spring Boot, Dropwizard, Quarkus ou um com um servidor Tomcat ou Jetty inserido).
  • Tomcat – O servidor Tomcat interno pode executar um aplicativo implantado como um pacote WAR.
  • JBoss EAP – Com suporte apenas para aplicativos Linux nos tipos de preços Premium v3 e Isolado v2. O servidor JBoss EAP interno pode executar um aplicativo implantado como um pacote WAR ou EAR.

Observação

Para aplicativos Spring, é recomendável usar o Aplicativos Spring do Azure. No entanto, você ainda pode usar o Serviço de Aplicativo do Azure como um destino. Consulte Diretrizes de Destino da Carga de Trabalho Java para obter orientação.

Mostrar versão do Java

Para mostrar a versão atual do Java, execute o seguinte comando no Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Para mostrar todas as versões do Java compatíveis, execute o seguinte comando no Cloud Shell:

az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

Para obter mais informações sobre o suporte à versão, confira Política de suporte de runtime de linguagem do Serviço de Aplicativo.

Implantação do aplicativo

Ferramentas de compilação

Maven

Com o Plug-in do Maven para aplicativos Web do Azure você pode preparar seu projeto Maven Java para o Aplicativo Web do Azure facilmente com um comando na raiz do projeto:

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.13.0:config

Esse comando adiciona um plug-in azure-webapp-maven-plugin e uma configuração relacionada solicitando que você selecione um Aplicativo Web do Azure existente ou crie um. Durante a configuração, ele tenta detectar se o seu aplicativo deve ser implantado no Java SE, no Tomcat ou no JBoss EAP (somente Linux). Em seguida, você poderá implantar seu aplicativo Java no Azure usando o seguinte comando:

mvn package azure-webapp:deploy

Veja uma configuração de exemplo em pom.xml:

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 17</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

  1. Configure o Plug-in Gradle para Aplicativos Web do Azure adicionando o plug-in ao seu build.gradle:

    plugins {
  id "com.microsoft.azure.azurewebapp" version "1.10.0"
}

  2. Configurar os detalhes do aplicativo Web. Os recursos correspondentes do Azure serão criados se eles não existirem. Aqui está um exemplo de configuração. Para obter detalhes, consulte este documento.

    azurewebapp {
    subscription = '<your subscription id>'
    resourceGroup = '<your resource group>'
    appName = '<your app name>'
    pricingTier = '<price tier like 'P1v2'>'
    region = '<region like 'westus'>'
    runtime {
      os = 'Linux'
      webContainer = 'Tomcat 10.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 17'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

  3. Implantar com um comando.

    gradle azureWebAppDeploy

IDEs

O Azure fornece uma experiência perfeita de desenvolvimento do Serviço de Aplicativo Java em Java IDEs populares, incluindo:

Kudu API

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.

Observação

Seu aplicativo .jar deve ser nomeado app.jar para o Serviço de Aplicativo identificar e executar seu aplicativo. O plug-in do Maven faz isso para você automaticamente durante a implantação. Se não desejar renomear o JAR para app.jar, você poderá carregar um script de shell com o comando para executar o JAR. Cole o caminho absoluto desse script na caixa de texto Arquivo de inicialização, na seção Configuração do portal. O script de inicialização não é executado por meio do diretório no qual ele é colocado. Portanto, sempre use caminhos absolutos para fazer referência a arquivos em seu script de inicialização (por exemplo: java -jar /home/myapp/myapp.jar).

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.

Não implante seu .war ou .jar usando FTP. A ferramenta FTP foi projetada para carregar os scripts de inicialização, dependências ou outros arquivos de runtime. Não é a opção ideal para a implantação de aplicativos Web.

Reescrever ou redirecionar URL

Para reescrever ou redirecionar a URL, use um dos reescritores de URL disponíveis, como UrlRewriteFilter.

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

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

Aplicativos de registro em log e depuração

Relatórios de desempenho, visualizações de tráfego e verificações de integridade estão disponíveis para cada aplicativo por meio do portal do Azure. Para obter mais informações, confira Visão geral de diagnóstico do Serviço de Aplicativo do Azure.

Logs de diagnóstico de fluxo

Você pode acessar os logs do console gerados de dentro do contêiner.

Primeiro, ative o log do contêiner executando o seguinte comando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Substitua <app-name> e <resource-group-name> pelos nomes apropriados para seu aplicativo Web.

Depois que o log do contêiner estiver ativado, execute o seguinte comando para ver o fluxo de log:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Se você não vir os logs do console imediatamente, verifique novamente após 30 segundos.

Para interromper o streaming de log a qualquer momento, digite Ctrl+C.

Você também pode inspecionar os arquivos de log em um navegador em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para obter mais informações, confira Logs de fluxo no Cloud Shell.

Acesso ao console do SSH no Linux

Para abrir uma sessão SSH direta com seu contêiner, seu aplicativo deve estar em execução.

Cole a seguinte URL no seu navegador e substitua <app-name> pelo nome do aplicativo:

https://<app-name>.scm.azurewebsites.net/webssh/host

Se você ainda não estiver autenticado, será necessário autenticar com sua assinatura do Azure para se conectar. Uma vez autenticado, consulte um shell no navegador, onde você pode executar comandos dentro de seu contêiner.

Conexão SSH

Observação

Quaisquer alterações feitas fora do diretório /home são armazenadas no próprio contêiner e não persistem além da reinicialização do aplicativo.

Para abrir uma sessão SSH remota no seu computador local, consulte Abrir a sessão SSH no shell remoto.

Ferramentas de solução de problemas do Linux

As imagens Java internas são baseadas no sistema operacional Alpine Linux. Use o gerenciador de pacotes apk para instalar quaisquer ferramentas ou comandos de solução de problemas.

Java Profiler

Todos os runtimes do Java no Serviço de Aplicativo do Azure vêm com o Gravador de Voo do JDK para criação de perfil de cargas de trabalho Java. Você poderá usá-lo para registrar eventos da JVM, do sistema e do aplicativo e solucionar problemas nos aplicativos.

Para saber mais sobre o Java Profiler, visite a documentação do Aplicativo Azure Insights.

Flight Recorder

Todos os runtimes do Java no Serviço de Aplicativo vêm com o Gravador de Voo do Java. Você poderá usá-lo para registrar eventos da JVM, do sistema e do aplicativo e solucionar problemas nos aplicativos do Java.

SSH no Serviço de Aplicativo e execute o comando jcmd para ver uma lista de todos os processos Java em execução. Além do próprio jcmd, você deve ver seu aplicativo Java em execução com um número de pid (ID do processo).

078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

Execute o comando a seguir para iniciar uma gravação de 30 segundos da JVM. Ele cria o perfil da JVM e um arquivo JFR chamado jfr_example.jfr no diretório inicial. (Substitua 116 pelo pid do seu aplicativo Java.)

jcmd 116 JFR.start name=MyRecording settings=profile duration=30s filename="/home/jfr_example.jfr"

Durante o intervalo de 30 segundos, é possível validar a gravação executando jcmd 116 JFR.check. O comando mostra todas as gravações para o processo do Java especificado.

Gravação contínua

Use o Gravador de Voo do Java para criar um perfil contínuo de seu aplicativo do Java com impacto mínimo no desempenho do tempo de execução. Para fazer isso, execute o comando da CLI do Azure a seguir para criar uma Configuração de Aplicativo chamada JAVA_OPTS com a configuração necessária. O conteúdo da Configuração de Aplicativo JAVA_OPTS é passado para o comando java quando o aplicativo é iniciado.

az webapp config appsettings set -g <your_resource_group> -n <your_app_name> --settings JAVA_OPTS=-XX:StartFlightRecording=disk=true,name=continuous_recording,dumponexit=true,maxsize=1024m,maxage=1d

Uma vez que a gravação começa, é possível despejar os dados da gravação atual a qualquer momento usando o comando JFR.dump.

jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.jfr"

Analisar os arquivos .jfr

Use o FTPS para baixar o arquivo JFR no seu computador local. Para analisar o arquivo JFR, faça download e instale o Controle de Missão Java. Para obter instruções sobre o Controle de Missão Java, confira a documentação do JMC e as instruções de instalação.

Registro em log do aplicativo

Habilite o registro em log de aplicativos por meio do portal do Azure ou da CLI do Azure para configurar o Serviço de Aplicativo do Azure para gravar a saída do console padrão do aplicativo e os fluxos de erro do console padrão no sistema de arquivos local ou no Armazenamento de Blobs do Azure. Se você precisar de uma retenção mais longa, configure o aplicativo para gravar a saída em um contêiner do armazenamento de blobs.

Seus logs de aplicativos Java e Tomcat podem ser encontrados no diretório /home/LogFiles/Application/ .

O registro em log do Armazenamento de Blobs do Azure para aplicativos com base no Linux pode ser configurado apenas usando o Azure Monitor.

Se o aplicativo usar Logback ou Log4j para rastreamento, será possível encaminhá-los para revisão no Azure Application Insights usando as instruções de configuração de estrutura de registros em Explorar os logs de rastreamento de Java no Application Insights.

Observação

Devido à vulnerabilidade conhecida CVE-2021-44228, use o Log4j versão 2.16 ou posterior.

Personalização e ajuste

O Serviço de Aplicativo do Azure é compatível com o ajuste e a personalização de caixas por meio do portal e da CLI do Azure. Examine os seguintes artigos para saber mais sobre a configuração de aplicativos Web específica para não Java:

Copiar conteúdo do aplicativo localmente

Defina a configuração JAVA_COPY_ALL do aplicativo como true para copiar o conteúdo do aplicativo para o trabalho local a partir do sistema de arquivos compartilhado. Essa configuração ajuda a resolver problemas de bloqueio de arquivo.

Definir opções de runtime do Java

Para definir a memória alocada ou outras opções de runtime da JVM, crie uma configuração de aplicativo denominada JAVA_OPTS com as opções. O Serviço de Aplicativo passa essa configuração como uma variável de ambiente para o runtime do Java quando ele é iniciado.

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.

Para definir a configuração de aplicativo do plug-in do Maven, adicione marcas de configuração/valor à seção de plug-in do Azure. O seguinte exemplo define um tamanho de heap de Java específico mínimo e máximo:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms1024m -Xmx1024m</value>
    </property>
</appSettings>

Observação

Você não precisa criar um arquivo web.config ao usar o Tomcat no Serviço de Aplicativo do Windows.

Os desenvolvedores que executam um único aplicativo com um slot de implantação no Plano do Serviço de Aplicativo podem usar as seguintes opções:

  • Instâncias B1 e S1: -Xms1024m -Xmx1024m
  • Instâncias B2 e S2: -Xms3072m -Xmx3072m
  • Instâncias B3 e S3: -Xms6144m -Xmx6144m
  • Instâncias P1v2: -Xms3072m -Xmx3072m
  • Instâncias P2v2: -Xms6144m -Xmx6144m
  • Instâncias P3v2: -Xms12800m -Xmx12800m
  • Instâncias P1v3: -Xms6656m -Xmx6656m
  • Instâncias P2v3: -Xms14848m -Xmx14848m
  • Instâncias P3v3: -Xms30720m -Xmx30720m
  • Instâncias I1: -Xms3072m -Xmx3072m
  • Instâncias I2: -Xms6144m -Xmx6144m
  • Instâncias I3: -Xms12800m -Xmx12800m
  • Instâncias I1v2: -Xms6656m -Xmx6656m
  • Instâncias I2v2: -Xms14848m -Xmx14848m
  • Instâncias I3v2: -Xms30720m -Xmx30720m

Ao ajustar as configurações de heap do aplicativo, examine os detalhes do Plano do Serviço de Aplicativo e considere os vários aplicativos e slots de implantação necessários para encontrar a alocação de memória ideal.

Ativar os soquetes da Web

Ative o suporte para soquetes da Web no portal do Azure, nas Configurações de aplicativo. É necessário reiniciar o aplicativo para a configuração entrar em vigor.

Ative o suporte para soquete da Web usando a CLI do Azure com o seguinte comando:

az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true

Depois, reinicie o aplicativo:

az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

Definir a codificação de caractere padrão

No portal do Azure, em Configurações do aplicativo para o aplicativo Web, crie uma configuração de aplicativo denominada JAVA_OPTS com o valor -Dfile.encoding=UTF-8.

Como alternativa, é possível definir a configuração do aplicativo usando o plug-in do Maven do Serviço de Aplicativo. Adicione as marcas de nome e valor de configuração à configuração do plug-in:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Dfile.encoding=UTF-8</value>
    </property>
</appSettings>

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.

Observação

robots933456 em logs

Você poderá ver a seguinte mensagem nos logs de contêiner:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Você pode ignorar essa mensagem com segurança. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicativo usa para verificar se o contêiner é capaz de atender a solicitações. Uma resposta 404 indica apenas que o caminho não existe, mas informa ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder a solicitações.

Como escolher uma versão runtime Java

O Serviço de Aplicativo permite que os usuários escolham a versão principal da JVM, como Java 8 ou Java 11, e a versão do patch, como 1.8.0 _232 ou 11.0.5. Você também pode optar por atualizar a versão do patch automaticamente, à medida que novas versões secundárias se tornarem disponíveis. Na maioria dos casos, os sites de produção devem usar as versões da JVM de patch fixadas. Isso evita interrupções inesperadas durante a atualização automática de uma versão de patch. Todos os aplicativos Web Java usam JVMs de 64 bits e não são configuráveis.

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.

Caso opte por fixar a versão secundária, será necessário atualizar periodicamente a versão secundária da JVM no aplicativo. Para garantir que o aplicativo seja executado na versão secundária mais recente, crie um slot de preparo e aumente a versão secundária no slot de preparo. Após confirmar se o aplicativo foi executado corretamente na nova versão secundária, você pode trocar os slots de preparo e de produção.

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. As instâncias JBoss EAP se comunica pela sub-rede especificada na integração de rede virtual, usando as portas mostradas na variável de ambiente WEBSITES_PRIVATE_PORTS em runtime. Você pode desabilitar o clustering criando uma configuração de aplicativo chamada WEBSITE_DISABLE_CLUSTERING com qualquer valor.

Observação

Caso esteja habilitando a integração de rede virtual com um modelo do ARM, precisará definir manualmente a propriedade vnetPrivatePorts para um valor de 2. Caso habilite a integração de rede virtual da CLI ou do Portal, essa propriedade será definida para você automaticamente.

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.

Observação

Você pode evitar tempos limite de clustering do JBOSS ao limpar arquivos de descoberta obsoletos durante a inicialização do aplicativo

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.

Configuração de linha de base do Tomcat

Observação

Esta seção se aplica somente ao Linux.

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
  • conectionTimeout é 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

Observação

As configurações connectionTimeout, maxThreads e maxConnections podem ser ajustadas com as configurações do aplicativo

A seguir estão exemplos de comandos da CLI que poderá usar para alterar os valores de conectionTimeout, 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 usa 0 como padrão [para sempre]

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>

Próximas etapas

Acesse a central para Desenvolvedores do Azure para Java para conferir inícios rápidos, tutoriais e documentação de referência do Java.