Compartilhar via

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

Esse artigo mostra as implantações e configurações de runtime mais comuns para aplicativos Java no Serviço de Aplicativo do Azure. Se for sua primeira vez usando o Serviço de Aplicativo do Azure, primeiro leia o início rápido do Java. Você pode encontrar as respostas para perguntas gerais sobre como usar o Serviço de Aplicativo que não são específicas para o desenvolvimento de Java nas perguntas frequentes do 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 JAR (Arquivo Java) que contém um servidor inserido (como Spring Boot, Quarkus, Dropwizard ou um aplicativo com um servidor Tomcat ou Jetty inserido).
  • Tomcat: o servidor Tomcat interno pode executar um aplicativo implantado como um pacote de arquivo de aplicativo Web (WAR).
  • JBoss Enterprise Application Platform (EAP): o servidor JBoss EAP interno pode executar um aplicativo implantado como um pacote WAR ou EAR (Enterprise Archive). Com suporte para aplicativos Linux em um conjunto de tipos de preços que inclui Gratuito, Premium v3 e Isolado v2.gti

Mostrar a versão do 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 do Java com suporte, execute o seguinte comando no Cloud Shell:

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

Obter a versão do Java no contêiner do Linux

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

Para exibir 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, localize version.sh com:

find / -name "version.sh"

Para exibir 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 a versões, confira a política de suporte ao runtime de linguagem do Serviço de Aplicativo.

O que acontece com ambientes de execução obsoletos no Azure App Service?

Runtimes desatualizados são descontinuados pela entidade mantenedora ou apresentam vulnerabilidades significativas. Assim, eles são removidos da criação e configuração de páginas no portal. Quando um runtime desatualizado está oculto do portal, qualquer aplicativo que ainda esteja usando esse runtime continuará sendo executado.

Se você quiser criar um aplicativo com uma versão de runtime desatualizada que não seja mais mostrada no portal, use a CLI do Azure, o modelo do ARM ou o Bicep. Essas alternativas de implantação permitem que você crie tempos de execução preteridos que foram removidos do portal, mas que ainda têm suporte.

Se um runtime 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.

Implantação do aplicativo

Ferramentas de build

Especialista

Usando o Plug-in do 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

Esse comando adiciona um azure-webapp-maven-plugin plug-in e a configuração relacionada solicitando que você selecione um aplicativo Web existente do Azure ou crie um novo. 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ê pode 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 do 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 da aplicação web. Os recursos correspondentes do Azure são criados, caso não existam. Aqui está uma configuração de exemplo. 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 de desenvolvimento perfeita do Serviço de Aplicativo Java em IDEs (Ambientes de Desenvolvimento Integrado) java populares, incluindo:

APIs Kudu e OneDeploy

Os clientes de implantação, como o plug-in do Maven, o GitHub Actions usando azure/webapps-deploy@v3 e mais recente, ou o comando az webapp deploy usam o OneDeploy, que é invocado chamando o ponto de extremidade /api/publish do site do Kudu nos bastidores. Para obter mais informações sobre essa API, confira essa documentação.

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

Observação

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 o 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 em /home/site/wwwwroot e, por padrão, só dá suporte à implantação de um arquivo WAR em wwwroot. Isso não será colocado no diretório /home/site/wwwroot/webapps, como visto ao usar APIs de implantação, como WarDeploy. Para evitar problemas com conflitos de estrutura de arquivos, é recomendável usar apenas um ou outro tipo de implantação.

Para implantar arquivos WAR no JBoss EAP, consulte esta documentação. Quando OneDeploy for usado, isso renomeará automaticamente o arquivo WAR para app.war e será colocado em /home/site/wwwroot.

Para implantar arquivos EAR, use FTP. Seu aplicativo EAR é implantado na raiz de contexto definida na configuração do aplicativo. 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 uma 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.

Aplicativos de registro 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.

Fazer streaming de logs de diagnóstico

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

Para ativar o log de contêineres, 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 do 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 interromper o streaming de log a qualquer momento, selecione Ctrl+C.

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.

Use o comando az webapp ssh .

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

Todas as alterações feitas fora do /home diretório são armazenadas no próprio contêiner e não persistem além de uma 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 integradas 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.

Criador de perfil Java

Todos os runtimes Java no Serviço de Aplicativo do Azure vêm com o Java Development Kit (JDK) Flight Recorder para criação de perfil de cargas de trabalho Java. Você pode usá-lo para gravar JVM (Máquina Virtual Java), eventos de sistema e aplicativo e para solucionar problemas em seus aplicativos.

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

Gravador de Voo Java

Todos os runtimes Java no Serviço de Aplicativo vêm com o Java Flight Recorder. Você pode usá-lo para gravar eventos JVM, sistema e aplicativo e 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 do próprio jcmd, você deverá 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 cria um arquivo JFR (Java Flight Recorder) nomeado jfr_example.jfr no diretório base. 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

Você pode usar o Java Flight Recorder para criar perfis de seu aplicativo Java continuamente, com impacto mínimo no desempenho do runtime. 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 configuração do JAVA_OPTS 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ê poderá 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"

Analisar arquivos JFR

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

Registro do aplicativo

Para configurar o App Service para gravar a saída padrão do console do 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 registro em log de aplicativos por meio do portal do Azure ou na Azure CLI. Se você precisar de uma retenção mais longa, configure o aplicativo para escrever a saída em um contêiner de armazenamento de blobs.

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

O registro do Armazenamento de Blobs do Azure para aplicativos baseados em Linux pode ser configurado somente pelo Azure Monitor.

Se seu aplicativo usar Logback ou Log4j para rastreamento, você poderá encaminhar esses rastreamentos para análise no Azure Application Insights. Use as instruções de configuração da estrutura de registros em Explorar logs de rastreamento Java no Application Insights.

Observação

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

Personalização e ajuste

O Serviço de Aplicativo do Azure dá suporte a ajuste e personalização padrão por meio do portal do Azure 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 do aplicativo JAVA_COPY_ALL 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 do aplicativo no plugin do Maven, adicione rótulos de configuração/valor na seção de plugins 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 Windows App.

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

Melhorar o desempenho do aplicativo na plataforma pode envolver o ajuste do tamanho do heap para atender melhor às suas necessidades específicas. Ao ajustar as configurações do heap de aplicativos, examine os detalhes do plano do Serviço de Aplicativo e considere os requisitos de vários aplicativos e slots de implantação 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 ao soquete 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, você pode definir a configuração do aplicativo usando o plug-in maven do Serviço de Aplicativo. Adicione rótulos de nome e valor da configuração 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 plug-in do Maven fornecido pelo Apache Sling ou usar esse arquivo de build ant.

Ignore a mensagem robots933456 nos 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 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.

Escolher uma versão de runtime do 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 fazer com que a versão do patch seja atualizada automaticamente à medida que novas versões secundárias estiverem disponíveis. Na maioria dos casos, os aplicativos de produção devem usar versões de patch JVM fixas, que evitam interrupções inesperadas durante uma atualização automática da versão de patch. Todos os aplicativos Web Java usam JVMs de 64 bits e não são configuráveis.

Se estiver usando o Tomcat, você 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 independentemente. No Linux, você pode fixar a versão de patch do Tomcat. A versão de patch da JVM também está fixada, mas não é configurável separadamente.

Se você optar por fixar a versão secundária, será necessário atualizar periodicamente a versão secundária da JVM no aplicativo. Para garantir que seu aplicativo seja executado na nova versão secundária, crie um slot de preparo e incremente a versão secundária no slot de preparo. Depois de confirmar que o aplicativo foi executado corretamente na nova versão secundária, você poderá trocar os slots de preparo 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 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 EAP, use um script de inicialização personalizado ou um comando de inicialização. Para obter um exemplo de ponta a ponta, 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 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 estiver integrado a uma rede virtual, ele será reiniciado e a instalação do JBoss EAP será iniciada automaticamente com uma configuração de cluster. 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 EAP integrado à rede virtual, 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. Se você habilitar a integração de rede virtual da CLI ou portal, essa propriedade será definida automaticamente para você.

Quando o clustering está habilitado, as instâncias 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 de EAP a iniciar obtém permissões de leitura/gravação no arquivo de associação de cluster. Outras instâncias leem o arquivo, encontram o nó primário e coordenam com esse nó para serem incluídas no cluster e adicionadas ao arquivo.

Observação

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

Os tipos de Plano de Serviço de Aplicativo Premium V3, Premium V4 e Isolado V2 podem, opcionalmente, ser distribuídos entre zonas de disponibilidade para melhorar a resiliência e a confiabilidade para suas cargas de trabalho críticas para os negócios. Essa arquitetura também é conhecida como redundância de zona. O recurso de agrupamento do JBoss EAP tem suporte com o recurso de redundância de zona.

Regras de escala automática

Quando você está configurando 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 manipular uma transação de banco de dados) para outro membro do cluster. Ao configurar suas regras de dimensionamento automático no portal para reduzir, use as seguintes opções:

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

Não é necessário adicionar instâncias incrementalmente (escalar horizontalmente). Você pode 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, 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 inicialização do servidor
  3. Fase de configuração do servidor
  4. Fase de implantação do aplicativo
  5. Fase de recarregamento do servidor

Consulte as seções a seguir para obter detalhes e oportunidades para personalizar (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 de 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 /var/ssl/certs diretório e são carregados para $JRE_HOME/lib/security/cacerts.
    • Os certificados privados são fornecidos pela plataforma no /var/ssl/private diretório e são carregados para $JRE_HOME/lib/security/client.jks.
  • Se algum certificado for carregado no repositório de chaves Java nesta etapa, as propriedades javax.net.ssl.keyStorejavax.net.ssl.keyStorePassworde javax.net.ssl.keyStoreType serão adicionados à variável de JAVA_OPTS ambiente.
  • Algumas configurações iniciais de JVM são determinadas, como diretórios de log e parâmetros da memória heap do 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_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 runtime 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 configuração standalone será usada.
    • Para a clustering configuração, o arquivo standalone-azure-full-ha.xml de configuração do servidor é usado.
    • Para a standalone configuração, o arquivo standalone-full.xml de configuração do servidor é usado.

2. Fase de inicialização do servidor

  • Se o JBoss EAP for iniciado na configuração clustering:
    • Cada instância JBoss EAP recebe um identificador interno entre 0 e o número de instâncias para as quais o aplicativo é dimensionado.
    • Se alguns arquivos forem encontrados no caminho do repositório de transações para essa instância de servidor (usando seu identificador interno), isso significa que essa instância de servidor está tomando o lugar de 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 começar na configuração clustering ou standalone, se a versão do servidor for 7.4 ou posterior e o tempo de execução 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 EAP.

3. Fase de configuração do servidor

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

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

    • Adiciona o módulo JBoss EAP azure.appservice, que fornece classes utilitárias para registro em log e integração com o App Service.
    • Atualiza o agente do console para usar um modo sem cores, para que os arquivos de log não fiquem 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 da Linguagem de Descrição dos Serviços Web (WSDL) e das interfaces de gerenciamento.
    • Adiciona o módulo azure.appservice.easyauth JBoss EAP para integração com autenticação do Serviço de Aplicativo e Microsoft Entra ID.
    • Atualiza as configurações de registro dos logs de acesso, bem como 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 autodetiza URLs de Conectividade de Banco de Dados Java (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, ela adicionará os drivers correspondentes ao servidor, adicionará uma fonte de dados para cada uma das URLs JDBC e definirá o nome JNDI (Interface de Diretório e Nomenclatura java) para java:jboss/env/jdbc/<app-setting-name>_DScada fonte de dados, onde <app-setting-name> está o nome da configuração do aplicativo.

  • Se a configuração clustering estiver habilitada, será verificado o agente do console a ser configurado.

  • 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 executará o script de inicialização personalizado, se houver. 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; caso contrário,
    • 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 sudo), permitindo que ele instale pacotes do Linux ou inicie a CLI do JBoss para executar mais comandos de instalação/personalização do JBoss EAP, como criar fontes de dados e instalar adaptadores de recursos. Para obter informações sobre os comandos de gerenciamento de pacotes do Ubuntu, consulte 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 EAP 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.
  • Caso /home/site/wwwroot/app.war exista, implemente-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 existirem páginas JSP autônomas em /home/site/wwwroot, copie-as para a raiz do servidor web e implante-as como um único aplicativo da 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 recarregamento do servidor

  • Depois que as etapas de implantação forem concluídas, o servidor JBoss EAP será recarregado para aplicar quaisquer alterações que exijam um recarregamento do servidor.
  • Após o recarregamento do servidor, os aplicativos implantados no servidor JBoss EAP devem estar prontos para responder às solicitações.
  • O servidor opera até que o aplicativo do App Service 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 EAP for encerrado 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 repositório de transações não inteiro em disco. Nesse caso, um erro é 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:

  • Personalizando a configuração do Tomcat: quando você entende o arquivo server.xml e os detalhes de configuração do Tomcat, você pode 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. Esse processo 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. 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.
  • 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. Você precisa entender esses detalhes 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 no server.xml para a distribuição do Tomcat na inicialização. Essas transformações incluem alterações nas configurações 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.

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 é definido como 16384.
  • URIEncoding é definido como UTF-8.
  • connectionTimeout foi configurado para WEBSITE_TOMCAT_CONNECTION_TIMEOUT, que por padrão é 240000.
  • maxThreads foi configurado para WEBSITE_CATALINA_MAXTHREADS, que por padrão é 200.
  • maxConnections foi configurado para WEBSITE_CATALINA_MAXCONNECTIONS, que por padrão é 10000.

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 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 é definido como AZURE_SITE_APP_BASE, cujo padrão é local WebappsLocalPath.
  • xmlBase foi configurado para AZURE_SITE_HOME, que por padrão é /site/wwwroot.
  • unpackWARs foi configurado para AZURE_UNPACK_WARS, que por padrão é true.
  • workDir é configurado como JAVA_TMP_DIR, o que define 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 foi configurado para AZURE_LOGGING_DIR, que por padrão é home\logFiles.
  • maxDays foi configurado para WEBSITE_HTTPLOGGING_RETENTION_DAYS, que por padrão é 7. Esse valor está alinhado com o padrão da plataforma de logs de aplicativos.

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

Conteúdo relacionado

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