Configurar um aplicativo Java para o Serviço de Aplicativo do Azure

Artigo
04/12/2024

Nota

Para aplicativos Spring, recomendamos o uso do Azure Spring Apps. No entanto, você ainda pode usar o Serviço de Aplicativo do Azure como destino. Consulte Java Workload Destination Guidance para obter conselhos.

O Serviço de Aplicativo do Azure permite que os desenvolvedores Java criem, implantem e dimensionem rapidamente seus aplicativos Web Java SE, Tomcat e JBoss EAP em um serviço totalmente gerenciado. Implante aplicativos com plug-ins Maven, a partir da linha de comando ou em editores como IntelliJ, Eclipse ou Visual Studio Code.

Este guia fornece conceitos-chave e instruções para desenvolvedores Java que usam o Serviço de Aplicativo. Se você nunca usou o Serviço de Aplicativo do Azure, leia primeiro o início rápido do Java. Perguntas gerais sobre o uso do Serviço de Aplicativo que não são específicas do desenvolvimento Java são respondidas nas Perguntas frequentes do Serviço de Aplicativo.

Mostrar versão do Java

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

az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

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

az webapp list-runtimes --os windows | grep 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 Java suportadas, 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, consulte Política de suporte ao tempo de execução do idioma do Serviço de Aplicativo.

Implantando seu aplicativo

Build Tools

Maven

Com o plug-in 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.11.0:config

Este comando adiciona um plug-in e uma azure-webapp-maven-plugin configuração relacionada, solicitando que você selecione um Aplicativo Web do Azure existente ou crie um novo. 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 11</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

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.7.1"
}
```

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 9.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 8'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

Implante com um comando.
```
gradle azureWebAppDeploy
```

IDEs

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

VS Code: Java Web Apps com Visual Studio Code
IntelliJ IDEA:Criar um aplicativo Web Hello World para o Serviço de Aplicativo do Azure usando o IntelliJ
Eclipse:Criar um aplicativo Web Hello World para o Serviço de Aplicativo do Azure usando o Eclipse

Kudu API

Java SE

Para implementar arquivos .jar no Java SE, use o /api/publish/ endpoint do site Kudu. Para obter mais informações sobre essa API, consulte esta documentação.

Nota

Seu aplicativo .jar deve ser nomeado app.jar para o Serviço de Aplicativo para identificar e executar seu aplicativo. O plug-in Maven faz isso automaticamente durante a implantação. Se você não quiser renomear seu JAR para app.jar, você pode carregar um shell script com o comando para executar seu aplicativo .jar. Cole o caminho absoluto para esse script na caixa de texto Arquivo de inicialização na seção Configuração do portal. O script de inicialização não é executado a partir do diretório no qual foi colocado. Por isso, utilize sempre caminhos absolutos para referenciar ficheiros no script de arranque (por exemplo: java -jar /home/myapp/myapp.jar).

Tomcat

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

JBoss EAP

Para implantar arquivos .war no JBoss, use o /api/wardeploy/ endpoint para POSTAR seu arquivo morto. Para obter mais informações sobre essa API, consulte esta documentação.

Para implantar arquivos .ear, use FTP. Seu aplicativo .ear é implantado na raiz de contexto definida na configuração do aplicativo. Por exemplo, se a raiz de contexto do seu aplicativo for <context-root>myapp</context-root>, você poderá navegar no site no /myapp caminho: http://my-app-name.azurewebsites.net/myapp. 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.

Registro em log e depuração de aplicativos

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 fluxo

Para aceder aos registos da consola gerados a partir do código da sua aplicação no Serviço de Aplicações, ative o registo de diagnósticos ao executar o seguinte comando no Cloud Shell:

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

Os valores possíveis para --level são: Error, Warning, Info e Verbose. Cada nível subsequente inclui o nível anterior. Por exemplo: Error inclui apenas mensagens de erro e Verbose inclui todas as mensagens.

Depois de ativar o registo de diagnósticos, execute o seguinte comando para ver o fluxo de registos:

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

Se não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

Nota

Também pode inspecionar os ficheiros de registo no browser em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para parar a transmissão de registos em qualquer altura, escreva Ctrl+C.

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

Primeiro, ative o log de 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.

Quando o log de 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 não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

Para interromper o streaming de logs 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, consulte Transmitir logs no Cloud Shell.

Acesso ao console SSH

Para abrir uma sessão SSH direta com o seu contentor, a sua aplicação deve estar em execução.

Cole o seguinte URL no browser e substitua <app-name> pelo nome da aplicação:

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

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 realizadas fora do diretório /home são armazenadas no próprio contentor e não persistem para além do reinício da aplicação.

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

Ferramentas de resolução de problemas

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.

Criador de perfis Java

Todos os tempos de execução Java no Serviço de Aplicativo do Azure vêm com o JDK Flight Recorder para criar o perfil de cargas de trabalho Java. Você pode usá-lo para registrar eventos da JVM, do sistema e do aplicativo e solucionar problemas em seus aplicativos.

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

Gravador de voo

Todos os tempos de execução Java no Serviço de Aplicativo vêm com o Java Flight Recorder. Você pode usá-lo para registrar eventos da JVM, do sistema e do aplicativo e solucionar problemas em seus aplicativos Java.

Gravação Cronometrada

Para fazer uma gravação cronometrada, você precisa do PID (Process ID) da aplicação Java. Para encontrar o PID, abra um navegador no site do SCM do seu aplicativo Web em https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/. Esta página mostra os processos em execução no seu aplicativo Web. Encontre o processo chamado "java" na tabela e copie o PID (Process ID) correspondente.

Em seguida, abra o Debug Console na barra de ferramentas superior do site do SCM e execute o seguinte comando. Substitua <pid> pelo ID do processo copiado anteriormente. Este comando inicia uma gravação de perfil de 30 segundos do seu aplicativo Java e gera um arquivo nomeado timed_recording_example.jfr no C:\home diretório.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.JFR"

SSH em seu Serviço de Aplicativo e execute o jcmd comando para ver uma lista de todos os processos Java em execução. Além do jcmd em si, 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 seguinte comando para iniciar uma gravação de 30 segundos da JVM. Ele cria o perfil da JVM e cria um arquivo JFR chamado jfr_example.jfr no diretório base. (Substitua o 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 chamada JAVA_OPTS com a configuração necessária. O conteúdo da Configuração do Aplicativo JAVA_OPTS é passado para o java comando quando seu 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 é 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 `.jfr` arquivos

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

Registo de aplicações

Habilite o log do aplicativo por meio do portal do Azure ou da CLI do Azure 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. O registro em log na instância local do sistema de arquivos do Serviço de Aplicativo é desabilitado 12 horas após sua configuração. Se você precisar de retenção mais longa, configure o aplicativo para gravar a saída em um contêiner de armazenamento de Blob. Seus logs de aplicativos Java e Tomcat podem ser encontrados no diretório /home/LogFiles/Application/ .

Habilite o log do aplicativo por meio do portal do Azure ou da CLI do Azure 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. Se você precisar de retenção mais longa, configure o aplicativo para gravar a saída em um contêiner de armazenamento de Blob. Seus logs de aplicativos Java e Tomcat podem ser encontrados no diretório /home/LogFiles/Application/ .

O log do Armazenamento de Blobs do Azure para aplicativos baseados 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 usando as instruções de configuração da estrutura de log em Explore Java trace logs in Application Insights.

Nota

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

Personalização e ajuste

O Serviço de Aplicativo do Azure dá suporte ao ajuste e à personalização prontos para uso por meio do portal do Azure e da CLI. 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 JAVA_COPY_ALL do aplicativo para true copiar o conteúdo do aplicativo para o trabalhador local 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 nomeada JAVA_OPTS para Java SE ou CATALINA_OPTS para Tomcat 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.

Os desenvolvedores que executam um único aplicativo com um slot de implantação em seu 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 de aplicativos, revise os detalhes do plano do Serviço de Aplicativo e leve em consideração as necessidades de vários aplicativos e slots de implantação para encontrar a alocação ideal de memória.

Ativar soquetes da Web

Ative o suporte para soquetes da Web no portal do Azure nas configurações do aplicativo para o aplicativo. 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 Serviço de Aplicativo 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é-compilação de 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 Maven fornecido pelo Apache Sling ou usar este arquivo de compilação Ant.

Aplicações seguras

Os aplicativos Java executados no Serviço de Aplicativo têm o mesmo conjunto de práticas recomendadas de segurança que outros aplicativos.

Autenticar usuários (autenticação fácil)

Configure a autenticação de aplicativo no portal do Azure com a opção Autenticação e Autorização . A partir daí, você pode habilitar a autenticação usando o Microsoft Entra ID ou logins sociais como Facebook, Google ou GitHub. A configuração do portal do Azure só funciona ao configurar um único provedor de autenticação. Para obter mais informações, consulte Configurar seu aplicativo do Serviço de Aplicativo para usar a entrada do Microsoft Entra e os artigos relacionados para outros provedores de identidade. Se você precisar habilitar vários provedores de entrada, siga as instruções em Personalizar entradas e saídas.

Java SE

Os desenvolvedores do Spring Boot podem usar o Microsoft Entra Spring Boot starter para proteger aplicativos usando anotações e APIs familiares do Spring Security. Certifique-se de aumentar o tamanho máximo do cabeçalho no arquivo application.properties . Sugerimos um valor de 16384.

Tomcat

Seu aplicativo Tomcat pode acessar as declarações do usuário diretamente do servlet convertendo o objeto Principal em um objeto Map. O Map objeto mapeia cada tipo de declaração para uma coleção de declarações para esse tipo. No exemplo de código a seguir, request é uma instância de HttpServletRequest.

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

Agora você pode inspecionar o Map objeto em busca de qualquer reivindicação específica. Por exemplo, o trecho de código a seguir itera por todos os tipos de declaração e imprime o conteúdo de cada coleção.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

Para sair dos usuários, use o /.auth/ext/logout caminho. Para executar outras ações, consulte a documentação em Personalizar entradas e saídas. Há também documentação oficial sobre a interface Tomcat HttpServletRequest e seus métodos. Os seguintes métodos de servlet também são hidratados com base na configuração do Serviço de Aplicativo:

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

Para desativar esse recurso, crie uma Configuração do Aplicativo nomeada WEBSITE_AUTH_SKIP_PRINCIPAL com um valor de 1. Para desativar todos os filtros de servlet adicionados pelo Serviço de Aplicativo, crie uma configuração nomeada WEBSITE_SKIP_FILTERS com o valor de 1.

Configurar TLS/SSL

Para carregar um certificado TLS/SSL existente e associá-lo ao nome de domínio do seu aplicativo, siga as instruções em Proteger um nome DNS personalizado com uma associação TLS/SSL no Serviço de Aplicativo do Azure. Você também pode configurar o aplicativo para impor TLS/SSL.

Usar referências do KeyVault

O Azure KeyVault fornece gerenciamento secreto centralizado com políticas de acesso e histórico de auditoria. Você pode armazenar segredos (como senhas ou cadeias de conexão) no KeyVault e acessar esses segredos em seu aplicativo por meio de variáveis de ambiente.

Primeiro, siga as instruções para conceder ao seu aplicativo acesso a um cofre de chaves e fazer uma referência do KeyVault ao seu segredo em uma Configuração do aplicativo. Você pode validar que a referência resolve para o segredo imprimindo a variável de ambiente enquanto acessa remotamente o terminal do Serviço de Aplicativo.

Para injetar esses segredos no arquivo de configuração do Spring ou do Tomcat, use a sintaxe de injeção de variável de ambiente (${MY_ENV_VAR}). Para arquivos de configuração do Spring, consulte esta documentação sobre configurações externalizadas.

Usar o Java Key Store

Por padrão, todos os certificados públicos ou privados carregados no App Service Linux são carregados nos respetivos Armazenamentos de Chaves Java quando o contêiner é iniciado. Depois de carregar seu certificado, você precisará reiniciar o Serviço de Aplicativo para que ele seja carregado no Java Key Store. Os certificados públicos são carregados no armazenamento de chaves em $JRE_HOME/lib/security/cacerts, e os certificados privados são armazenados em $JRE_HOME/lib/security/client.jks.

Mais configuração pode ser necessária para criptografar sua conexão JDBC com certificados no Java Key Store. Consulte a documentação do driver JDBC escolhido.

Inicializar o armazenamento de chaves Java

Para inicializar o import java.security.KeyStore objeto, carregue o arquivo keystore com a senha. A senha padrão para ambos os armazenamentos de chaves é changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Carregue manualmente o armazenamento de chaves

Você pode carregar certificados manualmente no armazenamento de chaves. Crie uma configuração de aplicativo, SKIP_JAVA_KEYSTORE_LOAD, com um valor de para desabilitar o Serviço de 1 Aplicativo de carregar os certificados no armazenamento de chaves automaticamente. Todos os certificados públicos carregados no Serviço de Aplicativo por meio do portal do Azure são armazenados em /var/ssl/certs/. Os certificados privados são armazenados em /var/ssl/private/.

Você pode interagir ou depurar a Java Key Tool abrindo uma conexão SSH com o Serviço de Aplicativo e executando o comando keytool. Consulte a documentação da Key Tool para obter uma lista de comandos. Para obter mais informações sobre a API KeyStore, consulte a documentação oficial.

Configurar plataformas APM

Esta seção mostra como conectar aplicativos Java implantados no Serviço de Aplicativo do Azure com as plataformas Azure Monitor Application Insights, NewRelic e AppDynamics Application Performance Monitoring (APM).

Configurar o Application Insights

O Azure Monitor Application Insights é um serviço de monitoramento de aplicativos nativo da nuvem que permite que os clientes observem falhas, gargalos e padrões de uso para melhorar o desempenho do aplicativo e reduzir o tempo médio de resolução (MTTR). Com alguns cliques ou comandos da CLI, você pode habilitar o monitoramento para seus aplicativos Node.js ou Java, coletando automaticamente logs, métricas e rastreamentos distribuídos, eliminando a necessidade de incluir um SDK em seu aplicativo. Para obter mais informações sobre as configurações de aplicativo disponíveis para configurar o agente, consulte a documentação do Application Insights.

Portal do Azure

Para habilitar o Application Insights no portal do Azure, vá para Application Insights no menu do lado esquerdo e selecione Ativar Application Insights. Por padrão, um novo recurso do Application Insights com o mesmo nome do seu aplicativo Web é usado. Você pode optar por usar um recurso existente do Application Insights ou alterar o nome. Selecione Aplicar na parte inferior.

CLI do Azure

Para habilitar por meio da CLI do Azure, você precisa criar um recurso do Application Insights e definir algumas configurações de aplicativo no portal do Azure para conectar o Application Insights ao seu aplicativo Web.

Habilite a extensão do Applications Insights
```
az extension add -n application-insights
```
Crie um recurso do Application Insights usando o seguinte comando da CLI. Substitua os espaços reservados pelo nome e grupo de recursos desejados.
```
az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web
```
Observe os valores para connectionString e instrumentationKey, você precisará desses valores na próxima etapa.

Para recuperar uma lista de outros locais, execute az account list-locations.

Defina a chave de instrumentação, a cadeia de conexão e a versão do agente de monitoramento como configurações do aplicativo na Web. Substitua <instrumentationKey> e <connectionString> pelos valores da etapa anterior.

az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default" "XDT_MicrosoftApplicationInsights_Java=1"

az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default"

Configurar Nova Relíquia

Crie uma conta NewRelic no NewRelic.com
Faça o download do agente Java da NewRelic. Tem um nome de ficheiro semelhante ao newrelic-java-x.x.x.zip.
Copie sua chave de licença, você precisa dela para configurar o agente mais tarde.
SSH em sua instância do Serviço de Aplicativo e crie um novo diretório /home/site/wwwroot/apm.
Carregue os arquivos descompactados do agente NewRelic Java em um diretório em /home/site/wwwroot/apm. Os arquivos para seu agente devem estar em /home/site/wwwroot/apm/newrelic.
Modifique o arquivo YAML em /home/site/wwwroot/apm/newrelic/newrelic.yml e substitua o valor da licença de espaço reservado por sua própria chave de licença.
No portal do Azure, navegue até seu aplicativo no Serviço de Aplicativo e crie uma nova Configuração de Aplicativo.
- Para aplicativos Java SE , crie uma variável de ambiente nomeada JAVA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
- Para o Tomcat, crie uma variável de ambiente nomeada CATALINA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Crie uma conta NewRelic no NewRelic.com
Faça o download do agente Java da NewRelic. Tem um nome de ficheiro semelhante ao newrelic-java-x.x.x.zip.
Copie sua chave de licença, você precisará dela para configurar o agente mais tarde.
SSH em sua instância do Serviço de Aplicativo e crie um novo diretório /home/site/wwwroot/apm.
Carregue os arquivos descompactados do agente NewRelic Java em um diretório em /home/site/wwwroot/apm. Os arquivos para seu agente devem estar em /home/site/wwwroot/apm/newrelic.
Modifique o arquivo YAML em /home/site/wwwroot/apm/newrelic/newrelic.yml e substitua o valor da licença de espaço reservado por sua própria chave de licença.
No portal do Azure, navegue até seu aplicativo no Serviço de Aplicativo e crie uma nova Configuração de Aplicativo.
- Para aplicativos Java SE , crie uma variável de ambiente nomeada JAVA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
- Para o Tomcat, crie uma variável de ambiente nomeada CATALINA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Se você já tiver uma variável de ambiente para JAVA_OPTS ou CATALINA_OPTS, acrescente a -javaagent:/... opção ao final do valor atual.

Configurar AppDynamics

Crie uma conta do AppDynamics no AppDynamics.com
Faça o download do agente Java no site do AppDynamics. O nome do arquivo é semelhante ao AppServerAgent-x.x.x.xxxxx.zip
Use o console Kudu para criar um novo diretório /home/site/wwwroot/apm.
Carregue os arquivos do agente Java em um diretório em /home/site/wwwroot/apm. Os arquivos para seu agente devem estar em /home/site/wwwroot/apm/appdynamics.
No portal do Azure, navegue até seu aplicativo no Serviço de Aplicativo e crie uma nova Configuração de Aplicativo.
- Para aplicativos Java SE , crie uma variável de ambiente nomeada JAVA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> é o nome do Serviço de Aplicativo.
- Para aplicativos Tomcat , crie uma variável de ambiente nomeada CATALINA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> é o nome do Serviço de Aplicativo.

Crie uma conta do AppDynamics no AppDynamics.com
Faça o download do agente Java no site do AppDynamics. O nome do arquivo é semelhante ao AppServerAgent-x.x.x.xxxxx.zip
SSH em sua instância do Serviço de Aplicativo e crie um novo diretório /home/site/wwwroot/apm.
Carregue os arquivos do agente Java em um diretório em /home/site/wwwroot/apm. Os arquivos para seu agente devem estar em /home/site/wwwroot/apm/appdynamics.
No portal do Azure, navegue até seu aplicativo no Serviço de Aplicativo e crie uma nova Configuração de Aplicativo.
- Para aplicativos Java SE , crie uma variável de ambiente nomeada JAVA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> é o nome do Serviço de Aplicativo.
- Para aplicativos Tomcat , crie uma variável de ambiente nomeada CATALINA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> é o nome do Serviço de Aplicativo.

Nota

Se você já tiver uma variável de ambiente para JAVA_OPTS ou CATALINA_OPTS, acrescente a -javaagent:/... opção ao final do valor atual.

Configurar fontes de dados

Java SE

Para se conectar a fontes de dados em aplicativos Spring Boot, sugerimos criar cadeias de conexão e injetá-las em seu arquivo application.properties .

Na seção "Configuração" da página Serviço de Aplicativo, defina um nome para a cadeia de caracteres, cole a cadeia de conexão JDBC no campo de valor e defina o tipo como "Personalizado". Opcionalmente, você pode definir essa cadeia de conexão como configuração de slot.

Essa cadeia de conexão é acessível ao nosso aplicativo como uma variável de ambiente chamada CUSTOMCONNSTR_<your-string-name>. Por exemplo, CUSTOMCONNSTR_exampledb.
No arquivo application.properties , faça referência a essa cadeia de conexão com o nome da variável de ambiente. Para o nosso exemplo, usaríamos o seguinte.
```
app.datasource.url=${CUSTOMCONNSTR_exampledb}
```

Para obter mais informações, consulte a documentação do Spring Boot sobre acesso a dados e configurações externalizadas.

Tomcat

Estas instruções se aplicam a todas as conexões de banco de dados. Você precisa preencher os espaços reservados com o nome da classe de driver do banco de dados escolhido e o arquivo JAR. Fornecida é uma tabela com nomes de classe e downloads de drivers para bancos de dados comuns.

Base de Dados	Nome da classe do driver	Controlador JDBC
PostgreSQL	`org.postgresql.Driver`	Transferir
MySQL	`com.mysql.jdbc.Driver`	Download (Selecione "Independente da plataforma")
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Transferir

Para configurar o Tomcat para usar o Java Database Connectivity (JDBC) ou a Java Persistence API (JPA), primeiro personalize a variável de ambiente que é lida CATALINA_OPTS pelo Tomcat na inicialização. Defina esses valores por meio de uma configuração de aplicativo no plug-in do App Service Maven:

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Ou defina as variáveis de ambiente na página Definições do Aplicativo de Configuração>no portal do Azure.

Em seguida, determine se a fonte de dados deve estar disponível para um aplicativo ou para todos os aplicativos em execução no servlet Tomcat.

Fontes de dados no nível do aplicativo

Crie um arquivo context.xml no diretório META-INF/ do seu projeto. Crie o diretório META-INF/ se ele não existir.

No context.xml, adicione um Context elemento para vincular a fonte de dados a um endereço JNDI. Substitua o espaço reservado driverClassName pelo nome da classe do motorista na tabela acima.

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

Atualize a web.xml do seu aplicativo para usar a fonte de dados em seu aplicativo.

<resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Recursos compartilhados no nível do servidor

As instalações do Tomcat no Serviço de Aplicativo no Windows existem em espaço compartilhado no Plano do Serviço de Aplicativo. Não é possível modificar diretamente uma instalação do Tomcat para configuração em todo o servidor. Para fazer alterações na configuração no nível do servidor na instalação do Tomcat, você deve copiar o Tomcat para uma pasta local, na qual você pode modificar a configuração do Tomcat.

Automatize a criação de Tomcat personalizado no início do aplicativo

Você pode usar um script de inicialização para executar ações antes que um aplicativo Web seja iniciado. O script de inicialização para personalizar o Tomcat precisa concluir as seguintes etapas:

Verifique se o Tomcat já foi copiado e configurado localmente. Se foi, o script de inicialização pode terminar aqui.
Copie o Tomcat localmente.
Faça as alterações de configuração necessárias.
Indique que a configuração foi concluída com êxito.

Para aplicativos do Windows, crie um arquivo com o wwwroot nome startup.cmd ou startup.ps1 no diretório. Esse arquivo é executado automaticamente antes que o servidor Tomcat seja iniciado.

Aqui está um script do PowerShell que conclui estas etapas:

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" -Destination "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    {... customization ...}

    # Mark that the operation was a success
    New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File

Transformações

Um caso de uso comum para personalizar uma versão do Tomcat é modificar os arquivos de configuração do server.xml, context.xmlou web.xml do Tomcat. O Serviço de Aplicativo já modifica esses arquivos para fornecer recursos da plataforma. Para continuar a usar esses recursos, é importante preservar o conteúdo desses arquivos quando você fizer alterações neles. Para fazer isso, recomendamos que você use uma transformação XSL (XSLT). Use uma transformação XSL para fazer alterações nos arquivos XML, preservando o conteúdo original do arquivo.

Exemplo de arquivo XSLT

Este exemplo de transformação adiciona um novo nó de conector ao server.xml. Observe a transformação de identidade, que preserva o conteúdo original do arquivo.

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes"/>

    <!-- Identity transform: this ensures that the original contents of the file are included in the new file -->
    <!-- Ensure that your transform files include this block -->
    <xsl:template match="@* | node()" name="Copy">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="@* | node()" mode="insertConnector">
      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                   contains(., '&lt;Connector') and
                                   (contains(., 'scheme=&quot;https&quot;') or
                                    contains(., &quot;scheme='https'&quot;))]">
      <xsl:value-of select="." disable-output-escaping="yes" />
    </xsl:template>

    <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                     comment()[contains(., '&lt;Connector') and
                                               (contains(., 'scheme=&quot;https&quot;') or
                                                contains(., &quot;scheme='https'&quot;))]
                                    )]
                        ">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="insertConnector" />
      </xsl:copy>
    </xsl:template>

    <!-- Add the new connector after the last existing Connnector if there's one -->
    <xsl:template match="Connector[last()]" mode="insertConnector">
      <xsl:call-template name="Copy" />

      <xsl:call-template name="AddConnector" />
    </xsl:template>

    <!-- ... or before the first Engine if there's no existing Connector -->
    <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                  mode="insertConnector">
      <xsl:call-template name="AddConnector" />

      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template name="AddConnector">
      <!-- Add new line -->
      <xsl:text>&#xa;</xsl:text>
      <!-- This is the new connector -->
      <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
                 maxThreads="150" scheme="https" secure="true" 
                 keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
                 clientAuth="false" sslProtocol="TLS" />
    </xsl:template>

    </xsl:stylesheet>

Função para transformação XSL

O PowerShell tem ferramentas internas para transformar arquivos XML usando transformações XSL. O script a seguir é uma função de exemplo que você pode usar para startup.ps1 executar a transformação:

    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);

        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            Write-Host  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

Definições da aplicação

A plataforma também precisa saber onde sua versão personalizada do Tomcat está instalada. Você pode definir o local da instalação na configuração do CATALINA_BASE aplicativo.

Você pode usar a CLI do Azure para alterar essa configuração:

    az webapp config appsettings set -g $MyResourceGroup -n $MyUniqueApp --settings CATALINA_BASE="%LOCAL_EXPANDED%\tomcat"

Ou, você pode alterar manualmente a configuração no portal do Azure:

Vá para Configurações>Configuração>Definições Definições do aplicativo.
Selecione Nova Definição de Aplicação.
Use estes valores para criar a configuração:
1. Designação: CATALINA_BASE
2. Valor: "%LOCAL_EXPANDED%\tomcat"

Exemplo startup.ps1

O script de exemplo a seguir copia um Tomcat personalizado para uma pasta local, executa uma transformação XSL e indica que a transformação foi bem-sucedida:

    # Locations of xml and xsl files
    $target_xml="$Env:LOCAL_EXPANDED\tomcat\conf\server.xml"
    $target_xsl="$Env:HOME\site\server.xsl"

    # Define the transform function
    # Useful if transforming multiple files
    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);
        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            echo  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    md -Path "$Env:LOCAL_EXPANDED\tomcat"

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Mark that the operation was a success if successful
    if($success){
        New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
    }

Finalizar a configuração

Por fim, coloque os JARs do driver no classpath do Tomcat e reinicie o Serviço de Aplicativo. Certifique-se de que os arquivos do driver JDBC estejam disponíveis para o carregador de classes Tomcat colocando-os no diretório /home/site/lib . No Cloud Shell, execute az webapp deploy --type=lib para cada JAR de driver:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --target-path <jar-name>.jar

Tomcat

Base de Dados	Nome da classe do driver	Controlador JDBC
PostgreSQL	`org.postgresql.Driver`	Transferir
MySQL	`com.mysql.jdbc.Driver`	Download (Selecione "Independente da plataforma")
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Transferir

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Ou defina as variáveis de ambiente na página Definições do Aplicativo de Configuração>no portal do Azure.

Em seguida, determine se a fonte de dados deve estar disponível para um aplicativo ou para todos os aplicativos em execução no servlet Tomcat.

Fontes de dados no nível do aplicativo

Crie um arquivo context.xml no diretório META-INF/ do seu projeto. Crie o diretório META-INF/ se ele não existir.

No context.xml, adicione um Context elemento para vincular a fonte de dados a um endereço JNDI. Substitua o espaço reservado driverClassName pelo nome da classe do motorista na tabela acima.

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

Atualize a web.xml do seu aplicativo para usar a fonte de dados em seu aplicativo.

<resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Recursos compartilhados no nível do servidor

Adicionar uma fonte de dados compartilhada no nível do servidor requer que você edite o server.xml do Tomcat. Primeiro, carregue um script de inicialização e defina o caminho para o script em Configuration>Startup Command. Você pode carregar o script de inicialização usando FTP.

Seu script de inicialização fará uma transformação xsl para o arquivo server.xml e enviará o arquivo xml resultante para /usr/local/tomcat/conf/server.xml. O script de inicialização deve instalar libxslt via apk. Seu arquivo xsl e script de inicialização podem ser carregados via FTP. Abaixo está um exemplo de script de inicialização.

# Install libxslt. Also copy the transform file to /home/tomcat/conf/
apk add --update libxslt

# Usage: xsltproc --output output.xml style.xsl input.xml
xsltproc --output /home/tomcat/conf/server.xml /home/tomcat/conf/transform.xsl /usr/local/tomcat/conf/server.xml

O arquivo XSL de exemplo a seguir adiciona um novo nó de conector ao server.xml Tomcat.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes"/>

  <xsl:template match="@* | node()" name="Copy">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@* | node()" mode="insertConnector">
    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                 contains(., '&lt;Connector') and
                                 (contains(., 'scheme=&quot;https&quot;') or
                                  contains(., &quot;scheme='https'&quot;))]">
    <xsl:value-of select="." disable-output-escaping="yes" />
  </xsl:template>

  <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                   comment()[contains(., '&lt;Connector') and
                                             (contains(., 'scheme=&quot;https&quot;') or
                                              contains(., &quot;scheme='https'&quot;))]
                                  )]
                      ">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()" mode="insertConnector" />
    </xsl:copy>
  </xsl:template>

  <!-- Add the new connector after the last existing Connnector if there's one -->
  <xsl:template match="Connector[last()]" mode="insertConnector">
    <xsl:call-template name="Copy" />

    <xsl:call-template name="AddConnector" />
  </xsl:template>

  <!-- ... or before the first Engine if there's no existing Connector -->
  <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                mode="insertConnector">
    <xsl:call-template name="AddConnector" />

    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template name="AddConnector">
    <!-- Add new line -->
    <xsl:text>&#xa;</xsl:text>
    <!-- This is the new connector -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
               maxThreads="150" scheme="https" secure="true" 
               keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

Finalizar a configuração

Por fim, coloque os JARs do driver no classpath do Tomcat e reinicie o Serviço de Aplicativo.

Certifique-se de que os arquivos do driver JDBC estejam disponíveis para o carregador de classes Tomcat colocando-os no diretório /home/site/lib . No Cloud Shell, execute az webapp deploy --type=lib para cada JAR de driver:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --path <jar-name>.jar

Se você criou uma fonte de dados no nível do servidor, reinicie o aplicativo Linux do Serviço de Aplicativo. O Tomcat redefinirá CATALINA_BASE e /home/tomcat usará a configuração atualizada.

Fontes de dados do JBoss EAP

Há três etapas principais ao registrar uma fonte de dados com o JBoss EAP: carregar o driver JDBC, adicionar o driver JDBC como um módulo e registrar o módulo. O Serviço de Aplicativo é um serviço de hospedagem sem monitoração de estado, portanto, os comandos de configuração para adicionar e registrar o módulo de fonte de dados devem ser roteirizados e aplicados à medida que o contêiner é iniciado.

Obtenha o driver JDBC do seu banco de dados.

Crie um arquivo de definição de módulo XML para o driver JDBC. O exemplo a seguir mostra uma definição de módulo para PostgreSQL.

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT : REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

Coloque os comandos da CLI do JBoss em um arquivo chamado jboss-cli-commands.cli. Os comandos do JBoss devem adicionar o módulo e registrá-lo como fonte de dados. O exemplo a seguir mostra os comandos JBoss CLI para PostgreSQL.

#!/usr/bin/env bash
module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

Crie um script de inicialização, startup_script.sh que chame os comandos da CLI do JBoss. O exemplo a seguir mostra como chamar seu jboss-cli-commands.cliarquivo . Mais tarde, você configurará o Serviço de Aplicativo para executar esse script quando o contêiner for iniciado.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
```
Usando um cliente FTP de sua escolha, carregue seu driver JDBC, jboss-cli-commands.cli, startup_script.she a definição do módulo para /site/deployments/tools/.
Configure seu site para ser executado startup_script.sh quando o contêiner for iniciado. No portal do Azure, navegue até Comando de Inicialização de Configurações>Gerais de Configuração.> Defina o campo de comando de inicialização como /home/site/deployments/tools/startup_script.sh. Salve suas alterações.

Para confirmar que a fonte de dados foi adicionada ao servidor JBoss, SSH em seu webapp e execute $JBOSS_HOME/bin/jboss-cli.sh --connect. Quando estiver conectado ao JBoss, execute o /subsystem=datasources:read-resource para imprimir uma lista das fontes de dados.

robots933456 nos registos

Pode ver a seguinte mensagem nos registos do contentor:

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 simplesmente que o caminho não existe, mas permite que o Serviço de Aplicações saiba que o contentor está em bom estado de funcionamento e pronto para responder aos pedidos.

Escolhendo 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 dos casos, os aplicativos de produção devem usar versões JVM de patch fixo. Isso evita interrupções imprevistas durante uma atualização automática da versão do 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 do patch do Tomcat. No Windows, você pode fixar as versões de patch da JVM e do Tomcat de forma independente. No Linux, você pode fixar a versão patch do Tomcat; a versão de patch da JVM também é fixada, mas não é configurável 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 seu aplicativo seja executado na versão secundária mais recente, crie um slot de preparo e incremente a versão secundária no slot de preparo. 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.

JBoss EAP

Clustering no JBoss EAP

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

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 protocolo de descoberta JGroups FILE_PING para descobrir novas instâncias e manter 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 EAP a iniciar obtém permissões de leitura/gravação no arquivo de associação do cluster. Outras instâncias leem o arquivo, localizam o nó primário e coordenam-se com esse nó a ser incluído no cluster e adicionado ao arquivo.

Os tipos Premium V3 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 zona. 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: "Diminuir contagem por"
Arrefecimento: "5 minutos" ou superior
Contagem de instâncias: 1

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

Planos do Serviço de Aplicativo JBoss EAP

O JBoss EAP só está disponível nos tipos Premium v3 e Isolated v2 App Service Plan. Os clientes que criaram um site JBoss EAP em uma camada diferente durante a visualização pública devem escalar para a camada de hardware Premium ou Isolada para evitar comportamentos inesperados.

Configuração de linha de base do Tomcat nos serviços de aplicativo

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: Entendendo 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. Isso 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. 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.
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. Entender esses detalhes é essencial 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 servidor Web Tomcat.

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

Note que as versões mais recentes 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
conectionTimeout 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 configurações do aplicativo

A seguir estão exemplos de comandos da CLI que você pode 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 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 assume como predefinição TMP
errorReportValveClass Usa nossa válvula de relatório de erro personalizado

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 é para , que é padrão WEBSITE_HTTPLOGGING_RETENTION_DAYSpara 0 [para sempre]

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

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>

Próximos passos

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

Configurar um aplicativo Java para o Serviço de Aplicativo do Azure

Mostrar versão do Java

Implantando seu aplicativo

Build Tools

Maven

Gradle

IDEs

Kudu API

Java SE

Tomcat

JBoss EAP

Registro em log e depuração de aplicativos

Transmitir registos de diagnóstico em fluxo

Acesso ao console SSH

Ferramentas de resolução de problemas

Criador de perfis Java

Gravador de voo

Gravação Cronometrada

Gravação contínua

Analise .jfr arquivos

Registo de aplicações

Personalização e ajuste

Copiar conteúdo do aplicativo localmente

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

Ativar soquetes da Web

Definir codificação de caracteres padrão

Pré-compilação de arquivos JSP

Aplicações seguras

Autenticar usuários (autenticação fácil)

Java SE

Tomcat

Configurar TLS/SSL

Usar referências do KeyVault

Usar o Java Key Store

Inicializar o armazenamento de chaves Java

Carregue manualmente o armazenamento de chaves

Configurar plataformas APM

Configurar o Application Insights

Portal do Azure

CLI do Azure

Configurar Nova Relíquia

Configurar AppDynamics

Configurar fontes de dados

Java SE

Tomcat

Fontes de dados no nível do aplicativo

Recursos compartilhados no nível do servidor

Automatize a criação de Tomcat personalizado no início do aplicativo

Transformações

Exemplo de arquivo XSLT

Função para transformação XSL

Definições da aplicação

Exemplo startup.ps1

Finalizar a configuração

Tomcat

Fontes de dados no nível do aplicativo

Recursos compartilhados no nível do servidor

Finalizar a configuração

Fontes de dados do JBoss EAP

robots933456 nos registos

Escolhendo uma versão de tempo de execução Java

JBoss EAP

Clustering no JBoss EAP

Regras de dimensionamento automático

Planos do Serviço de Aplicativo JBoss EAP

Configuração de linha de base do Tomcat nos serviços de aplicativo

Conector

Host

Válvula

Próximos passos

Recursos adicionais

Analise `.jfr` arquivos