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: Suporte apenas para aplicativos Linux nos níveis de preços Gratuito, 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 ID de processo (pid).

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.

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.

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:

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.

Um diagrama que mostra um aplicativo do Serviço de Aplicativo JBoss integrado à VNet, dimensionado para três instâncias.

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 os tempos limite do clustering do JBoss ao limpar os 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.

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.

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

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.