Partilhar via

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

Este artigo mostra a configuração de implantação e tempo de execução mais comum para aplicativos Java no Serviço de Aplicativo do Azure. Se for a primeira vez que você usa o Serviço de Aplicativo do Azure, você deve primeiro ler o início rápido do Java. Você pode encontrar as respostas para perguntas gerais sobre o uso do Serviço de Aplicativo que não são específicas do desenvolvimento Java 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 Standard Edition (SE): Pode executar um aplicativo implantado como um pacote Java Archive (JAR) que contém um servidor incorporado (como Spring Boot, Quarkus, Dropwizard ou um aplicativo com um servidor Tomcat ou Jetty incorporado).
  • Tomcat: O servidor Tomcat integrado pode executar um aplicativo implantado como um pacote WAR (Web Application Archive).
  • JBoss Enterprise Application Platform (EAP): O servidor JBoss EAP integrado pode executar um aplicativo implantado como um pacote WAR ou Enterprise Archive (EAR). Suportado para aplicativos Linux em um conjunto de níveis de preços que inclui Free, Premium v3 e Isolated v2.gti

Mostrar a versão Java

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

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

Para mostrar todas as versões Java suportadas, execute o seguinte comando no Cloud Shell:

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

Obtenha a versão Java no contêiner Linux

Para obter informações de versão mais detalhadas no contêiner Linux, abra uma sessão SSH com o contêiner. Aqui estão alguns exemplos do que você pode executar.

Para visualizar a versão do Java na sessão SSH:

java -version

Para exibir a versão do servidor Tomcat na sessão SSH:

sh /usr/local/tomcat/version.sh

Ou, se o servidor Tomcat estiver em um local personalizado, encontre version.sh com:

find / -name "version.sh"

Para visualizar a versão do servidor JBoss EAP na sessão SSH:

$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

Para obter mais informações sobre o suporte à versão, consulte a Política de suporte ao tempo de execução de linguagem do Serviço de Aplicações.

O que acontece com tempos de execução desatualizados no Serviço de Aplicativo?

Tempos de execução desatualizados são descontinuados pela organização responsável pela manutenção ou descobertos com vulnerabilidades significativas. Assim, eles são removidos das páginas de criação e configuração no portal. Quando um tempo de execução desatualizado é oculto do portal, qualquer aplicativo que ainda esteja usando esse tempo de execução continua a ser executado.

Se você quiser criar um aplicativo com uma versão de tempo de execução desatualizada que não é mais mostrada no portal, use a CLI do Azure, o modelo ARM ou o Bicep. Essas alternativas de implantação permitem criar tempos de execução obsoletos que foram removidos no portal, mas ainda estão a ser suportados.

Se um tempo de execução for totalmente removido da plataforma do Serviço de Aplicativo, o proprietário da assinatura do Azure receberá um aviso por email antes da remoção.

Implantando seu aplicativo

Ferramentas de construção

Maven

Usando o plug-in Maven para Aplicativos Web do Azure, você pode preparar facilmente seu projeto com um comando na raiz do projeto:

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

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

mvn package azure-webapp:deploy

Aqui está um exemplo de configuração 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 a build.gradle:

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

  2. Configure os detalhes do seu aplicativo Web. Os recursos correspondentes do Azure são criados se 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. Lance com um único comando.

    gradle azureWebAppDeploy

IDEs

O Azure fornece uma experiência de desenvolvimento perfeita do Java App Service em IDEs (Ambientes de Desenvolvimento Integrado) Java populares, incluindo:

APIs Kudu e OneDeploy

Clientes de implantação, como o plug-in Maven, o GitHub Actions usando azure/webapps-deploy@v3 e mais recentes, ou o comando az webapp deploy usam o OneDeploy, que é invocado chamando o /api/publish ponto de extremidade do site Kudu por trás. Para obter mais informações sobre essa API, consulte esta documentação.

Quando esses métodos de implantação são usados, eles renomeiam automaticamente o arquivo JAR fornecido para app.jar durante o processo de implantação. Este será colocado sob /home/site/wwwwroot. Para implementar arquivos JAR no Java SE, consulte esta documentação.

Nota

Se você usar métodos alternativos como FTP ou APIs ZipDeploy mais antigas, esse método de renomear o arquivo JAR fornecido não será invocado. Anote isso se estiver usando a caixa de texto Arquivo de inicialização na seção Configuração do portal para chamar explicitamente seu arquivo JAR.

Você pode implantar arquivos WAR em seu aplicativo Tomcat seguindo esta documentação. Quando esses métodos de implantação acima forem usados, eles renomearão automaticamente o arquivo War fornecido para app.war durante o processo de implantação. Isso será colocado sob /home/site/wwwwroot e, por padrão, suporta apenas a implantação de um arquivo WAR em wwwroot. Isso não será colocado sob o /home/site/wwwroot/webapps diretório como visto ao usar APIs de implantação, como o WarDeploy. Para evitar problemas com conflitos de estrutura de arquivos, é aconselhável usar apenas um ou outro tipo de implantação.

Para implantar arquivos WAR no JBoss EAP, consulte esta documentação. Quando o OneDeploy é usado, ele renomeia automaticamente o arquivo WAR para app.war e é colocado em /home/site/wwwroot.

Para implantar arquivos EAR, use FTP. A sua aplicação EAR é implantada na raiz de contexto definida na configuração da sua aplicação. 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.

Não implante seu WAR ou JAR usando FTP. A ferramenta FTP foi projetada para carregar scripts de inicialização, dependências ou outros arquivos de tempo de execução. Não é a escolha ideal para implantar aplicativos Web.

Reescrever ou redirecionar um URL

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

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

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

Registo e depuração de aplicações

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, consulte Visão geral do diagnóstico do Serviço de Aplicativo do Azure.

Transmitir registos de diagnóstico em tempo real

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

Para ativar o log de contêiner, execute 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> por nomes apropriados para seu aplicativo Web.

Depois de ativar o log de contêiner, execute o seguinte comando para ver o fluxo de log:

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

Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.

Para parar a transmissão de logs a qualquer momento, selecione Ctrl+C.

Para obter mais informações, consulte Transmitir logs no Cloud Shell.

Acesso ao console SSH no Linux

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

Use o comando az webapp ssh .

Se ainda não estiver autenticado, é necessário fazê-lo com a sua subscrição do Azure para se ligar. Uma vez autenticado, pode ver uma shell no browser, na qual pode executar comandos dentro do seu contentor.

Ligação SSH

Nota

Todas as alterações feitas fora do /home diretório são armazenadas no próprio contêiner e não persistem após uma reinicialização do aplicativo.

Para abrir uma sessão SSH remota a partir do computador local, veja Abrir sessão SSH a partir da shell remota.

Ferramentas de solução de problemas do Linux

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

Ferramenta de perfilagem Java

Todas as runtimes Java no Azure App Service vêm com o Java Development Kit (JDK) Flight Recorder para realizar o profiling de cargas de trabalho Java. Você pode usá-lo para registrar eventos Java Virtual Machine (JVM), sistema e aplicativo e para solucionar problemas em seus aplicativos.

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

Gravador de vôo Java

Todos os runtimes Java no Azure App Service vêm com Java Flight Recorder. Você pode usá-lo para registrar eventos da JVM, do sistema e do aplicativo e para solucionar problemas em seus aplicativos Java.

SSH no Serviço de Aplicativo e execute o jcmd comando para ver uma lista de todos os processos Java em execução. Além de jcmd em si, deverá ver a sua aplicação 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 seguinte comando para iniciar uma gravação de 30 segundos da JVM. Ele cria o perfil da JVM e cria um arquivo Java Flight Recorder (JFR) nomeado jfr_example.jfr no diretório home. 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, você pode validar que a gravação está ocorrendo executando jcmd 116 JFR.check. O comando mostra todas as gravações para o processo Java dado.

Gravação contínua

Você pode usar o Java Flight Recorder para criar continuamente o perfil de seu aplicativo Java com impacto mínimo no desempenho do tempo de execução. Para fazer isso, execute o seguinte comando da CLI do Azure para criar uma configuração de aplicativo nomeada JAVA_OPTS com a configuração necessária. O conteúdo da JAVA_OPTS configuração do aplicativo é passado para o java comando 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

Depois que a gravação for iniciada, você pode despejar os dados de gravação atuais a qualquer momento usando o JFR.dump comando.

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

Analise arquivos JFR

Use FTPS para baixar seu arquivo JFR para sua máquina local. Para analisar o arquivo JFR, baixe e instale o Java Mission Control (JMC). Para obter instruções sobre como usar o Java Mission Control, consulte a documentação do JMC e as instruções de instalação.

Registo de aplicações

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

Os logs da aplicação Java e Tomcat podem ser encontrados no diretório /home/LogFiles/Application/.

O registo de Armazenamento Blob do Azure para aplicações baseadas em Linux só pode ser configurado usando o Azure Monitor.

Se seu aplicativo usa Logback ou Log4j para rastreamento, você pode encaminhar esses rastreamentos para revisão no Azure Application Insights. Utilize as instruções de configuração do framework de logging em Explorar logs de rastreamento Java no Application Insights.

Nota

Devido à vulnerabilidade CVE-2021-44228conhecida , certifique-se de usar o Log4j versão 2.16 ou posterior.

Personalização e ajuste

O Azure App Service suporta ajuste pré-configurado e customização através do portal do Azure e da CLI do Azure. Analise os seguintes artigos para obter informações sobre a configuração de aplicativos Web não específicos do Java:

Copiar conteúdo do aplicativo localmente

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

Definir opções de tempo de execução Java

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

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.

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

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

Nota

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

Por padrão, o Serviço de Aplicativo define o tamanho do Heap máximo da JVM como 70% da memória total disponível para o Plano do Serviço de Aplicativo. Para desativar a configuração padrão, você pode usar a configuração do aplicativo WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

Melhorar o desempenho do seu aplicativo na plataforma pode envolver ajustar o tamanho da pilha para melhor atender às suas necessidades específicas. Ao ajustar as configurações de heap de aplicações, revise os detalhes do plano do App Service e considere os requisitos de múltiplas aplicações e de slots de implantação para encontrar a alocação de memória ideal.

Ativar soquetes da Web

Ative o suporte para web sockets no portal do Azure nas definições de aplicação para a aplicação. Você precisa reiniciar o aplicativo para que a configuração entre em vigor.

Ative o suporte a 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

Em seguida, 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 codificação de caracteres padrão

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

Como alternativa, você pode definir a configuração do aplicativo usando o plug-in do App Service Maven. Adicione o nome da configuração e as tags de valor na configuração do plugin:

<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 plugin Maven fornecido pelo Apache Sling ou usar este arquivo de compilação Ant.

Ignorar a mensagem robots933456 nos logs

Poderá ver a seguinte mensagem nos registos de contentores:

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

Pode ignorar esta mensagem. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicações utiliza para verificar se o contentor consegue satisfazer pedidos. Uma resposta 404 indica que o caminho não existe e sinaliza ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder às solicitações.

Escolha uma versão de tempo de execução 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 ter a versão do patch atualizada automaticamente à medida que novas versões secundárias ficam disponíveis. Na maioria das situações, os aplicativos de produção devem usar versões de patch JVM fixadas, que evitam interrupções imprevistas durante uma autoatualização de patch. Todos os aplicativos Web Java usam JVMs de 64 bits e não são configuráveis.

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

Se você optar por fixar a versão secundária, precisará atualizar periodicamente a versão secundária da JVM no aplicativo. Para garantir que a sua aplicação seja executada na versão secundária mais recente, crie um ambiente de preparação e incremente a versão secundária nesse ambiente. Depois de confirmar que o aplicativo é executado corretamente na nova versão secundária, você pode trocar os slots de preparação e produção.

Executar a CLI do JBoss

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

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

Dependendo de onde o JBoss EAP 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 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 EAP, 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 Java SE, Tomcat ou JBoss EAP 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:

Agrupamento

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.

Um diagrama que mostra um aplicativo JBoss EAP App Service integrado à rede virtual, dimensionado para três instâncias.

Nota

Se você estiver habilitando sua integração de rede virtual com um modelo ARM, precisará definir manualmente a propriedade vnetPrivatePorts como um valor de 2. Se você habilitar a integração de rede virtual a partir da CLI ou do portal, essa propriedade será definida para você automaticamente.

Quando o clustering está habilitado, as instâncias do JBoss EAP usam o FILE_PING protocolo de descoberta JGroups para descobrir novas instâncias e persistir informações de cluster (por exemplo: 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 lêem o ficheiro, identificam o nó primário e coordenam-se com esse nó para serem incluídas no cluster e adicionadas ao ficheiro.

Nota

Você pode evitar tempos limite de clustering do JBoss EAP limpando arquivos de descoberta obsoletos durante a inicialização do aplicativo.

Os tipos Premium V3, Premium V4 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 zonas. 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: "Reduzir a contagem em"
  • Arrefecimento: "5 minutos" ou mais
  • Contagem de instâncias: 1

Não é necessário adicionar instâncias incrementalmente (dimensionamento). Você pode adicionar várias instâncias ao cluster ao mesmo tempo.

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, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 e P5mv4.

Ciclo de vida do servidor JBoss EAP

Um aplicativo JBoss EAP no Serviço de Aplicativo passa por cinco fases distintas antes de 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 implantação do aplicativo
  5. Fase de recarga do servidor

Consulte as seções a seguir para obter detalhes e oportunidades para personalizar (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 de 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 /var/ssl/certs diretório e são carregados no $JRE_HOME/lib/security/cacerts.
    • Os certificados privados são fornecidos pela plataforma no /var/ssl/private diretório 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.keyStore, javax.net.ssl.keyStorePassworde javax.net.ssl.keyStoreType serão adicionadas à JAVA_OPTS 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 EAP 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 EAP usando a clustering configuração. Caso contrário, a standalone configuração será usada.
    • Para a clustering configuração, o arquivo de standalone-azure-full-ha.xml configuração do servidor é usado.
    • Para a standalone configuração, o arquivo de standalone-full.xml configuração do servidor é usado.

2. Fase de lançamento do servidor

  • Se o clustering JBoss EAP for iniciado na configuração:
    • Cada instância do JBoss EAP 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. A outra instância de serviço 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 EAP ser iniciado na clustering configuração ou standalone , se a versão do servidor for 7.4 ou posterior 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 EAP.

3. Fase de configuração do servidor

  • No início dessa fase, o Serviço de Aplicativo espera primeiro que o servidor JBoss EAP e a interface de administração estejam prontos para receber solicitações antes de continuar. Esse processo pode levar mais alguns segundos se o Application Insights estiver habilitado.

  • Quando o JBoss EAP Server e a interface de administração estiverem prontos, o Serviço de Aplicativo executará as seguintes ações:

    • Adiciona o módulo azure.appserviceJBoss EAP , que fornece classes de utilitário para registro em log e integração com o Serviço de Aplicativo.
    • Atualiza o registrador do console para usar um modo incolor para que os arquivos de log não estejam cheios de sequências que escapam de cores.
    • Configura a integração com os logs do Azure Monitor.
    • Atualiza os endereços IP de ligação do WSDL (Web Services Description Language) e das interfaces de gerenciamento.
    • Adiciona o módulo azure.appservice.easyauth JBoss EAP para integração com a autenticação do Serviço de Aplicativo e o Microsoft Entra ID.
    • Atualiza a configuração dos logs de acesso, bem como o nome e a rotação do arquivo principal de log do servidor.

  • A menos que a configuração WEBSITE_SKIP_AUTOCONFIGURE_DATABASE do aplicativo esteja definida, o Serviço de Aplicativo deteta automaticamente URLs JDBC (Java Database Connectivity) 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á os drivers correspondentes ao servidor, adicionará uma fonte de dados para cada uma das URLs JDBC e definirá o nome JNDI (Java Naming and Directory Interface) 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 /home/site/libs diretório, 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 é definida da seguinte maneira:

    • Se você configurou um comando de inicialização (por exemplo, por meio do portal do Azure ou da CLI do Azure), 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 raiz (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 EAP, como a criação de fontes de dados e a instalação de adaptadores de recursos. Para obter informações sobre os comandos de gerenciamento de pacotes do Ubuntu, consulte a documentação do Ubuntu Server. Para os comandos JBoss CLI, consulte o Guia CLI do JBoss Management.

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

O script de inicialização implanta aplicativos no JBoss EAP 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 no /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 no /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, implante a página de boas-vindas padrão (página de estacionamento) no contexto raiz.

5. Fase de recarga do servidor

  • Após a conclusão das etapas de implantação, o servidor JBoss EAP é recarregado para aplicar quaisquer alterações que exijam uma recarga do servidor.
  • Depois que o servidor for recarregado, os aplicativos implantados no servidor JBoss EAP devem estar prontos para responder às solicitações.
  • O servidor é executado até que a aplicação do App Service seja interrompida ou reiniciada. 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 EAP sair anormalmente na configuração clustering, uma função final chamada emit_alert_tx_store_not_empty será executada. A função verifica se o processo JBoss EAP 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

Nota

Esta secção aplica-se apenas ao Linux.

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: Ao entender 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. Esse processo 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. Quando você entende 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. Você precisa entender esses detalhes 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 Tomcat Web Server.

Além disso, há certas transformações que são aplicadas sobre o server.xml para a distribuição do Tomcat no início. Essas transformações incluem alterações nas 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.

Nota

As configurações connectionTimeout, maxThreads e maxConnections podem ser ajustadas com as definições da aplicação.

A seguir estão exemplos de comandos da CLI que você pode usar para alterar os valores de connectionTimeout, maxThreadsou 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.

Anfitrião

<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 por padrão é TMP.
  • errorReportValveClass utiliza a nossa válvula personalizada para relatórios de erro.

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 está definido como WEBSITE_HTTPLOGGING_RETENTION_DAYS, cujo padrão é 7. Esse valor se alinha com o padrão da plataforma de log de aplicativos.

No Linux, ele tem a mesma personalização e 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>

Conteúdo relacionado

Visite o Centro do Azure para Desenvolvedores Java para encontrar guias de início rápido, tutoriais e documentação de referência do Azure para Java.