Configure um aplicativo Java para Serviço de Aplicações do Azure

Serviço de Aplicações do Azure permite que os desenvolvedores de Java construam, implementem e escalam rapidamente as suas aplicações web Java SE, Tomcat e JBoss EAP num serviço totalmente gerido. Implementar aplicações com plugins Maven, a partir da linha de comando, ou em editores como IntelliJ, Eclipse ou Visual Studio Code.

Este guia fornece conceitos e instruções fundamentais para os desenvolvedores de Java que usam Serviço de Aplicações. Se nunca usou Serviço de Aplicações do Azure, deve ler primeiro o quickstart java. As questões gerais sobre o uso de Serviço de Aplicações que não são específicas para o desenvolvimento de Java são respondidas na Serviço de Aplicações FAQ.

Mostrar versão java

Para mostrar a versão java atual, executar 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, executar o seguinte comando no Cloud Shell:

az webapp list-runtimes --os windows | grep java

Para mostrar a versão java atual, executar 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, executar o seguinte comando no Cloud Shell:

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

Implementação da sua app

Ferramentas de construção

Maven

Com o Maven Plugin para a Azure Aplicações Web, pode preparar facilmente o seu projeto Maven Java para a Azure Web App com um comando na raiz do seu projeto:

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

Este comando adiciona um azure-webapp-maven-plugin plugin e configuração relacionada, levando-o a selecionar uma Aplicação Web Azure existente ou a criar uma nova. Em seguida, pode implementar a sua aplicação Java para Azure utilizando o seguinte comando:

mvn package azure-webapp:deploy

Aqui está uma configuração de amostra em pom.xml:

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.2.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

  1. Configurar o Plugin Gradle para a Azure Aplicações Web adicionando o plugin ao seu build.gradle:

    plugins {
      id "com.microsoft.azure.azurewebapp" version "1.2.0"
    }
    
  2. Configure os seus dados da Web App, os recursos Azure correspondentes serão criados se não existirem. Aqui está uma configuração de amostra, para mais 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
        }
    }
    
  3. Desdobre-se com um comando.

    gradle azureWebAppDeploy
    

IDEs

A Azure proporciona uma experiência de desenvolvimento Serviço de Aplicações java perfeita em IDEs java populares, incluindo:

Kudu API

Java SE

Para implementar ficheiros .jar para a Java SE, utilize o /api/publish/ ponto final do site kudu. Para mais informações sobre esta API, consulte esta documentação.

Nota

O seu .jar pedido deve ser nomeado app.jar para Serviço de Aplicações identificar e executar a sua aplicação. O Maven Plugin (mencionado acima) mudará automaticamente o nome da sua aplicação durante a implementação. Se não quiser mudar o nome do seu JAR para app.jar, pode carregar um script de concha com o comando para executar a sua aplicação .jar. Cole o caminho absoluto para este script na caixa de texto 'Ficheiro', na secção de Configuração do portal. O script de arranque não é executado a partir do diretório no qual é colocado. Por isso, utilize sempre caminhos absolutos para referenciar ficheiros no script de arranque (por exemplo: java -jar /home/myapp/myapp.jar).

Tomcat

Para implementar ficheiros de .war para Tomcat, use o /api/wardeploy/ ponto final para registar o seu ficheiro de arquivo. Para mais informações sobre esta API, consulte esta documentação.

JBoss EAP

Para implementar ficheiros de .war para JBoss, utilize o ponto final para registar o /api/wardeploy/ seu ficheiro de arquivo. Para mais informações sobre esta API, consulte esta documentação.

Para implementar ficheiros .auriculares, utilize FTP. A sua aplicação .auricular será implantada na raiz de contexto definida na configuração da sua aplicação. Por exemplo, se a raiz de contexto da sua aplicação for <context-root>myapp</context-root>, então pode navegar no site no /myapp caminho: http://my-app-name.azurewebsites.net/myapp. Se quiser que a sua aplicação web seja servida no caminho raiz, certifique-se de que a sua aplicação define a raiz do contexto para o caminho raiz: <context-root>/</context-root>. Para obter mais informações, consulte Definição da raiz de contexto de uma aplicação web.

Não desloque a sua .guerra ou .jar utilizando FTP. A ferramenta FTP foi concebida para carregar scripts de arranque, dependências ou outros ficheiros de tempo de execução. Não é a escolha ideal para implementar aplicações web.

Aplicativos de registo e depuragem

Relatórios de desempenho, visualizações de tráfego e check-ups de saúde estão disponíveis para cada aplicação através do portal do Azure. Para mais informações, consulte Serviço de Aplicações do Azure visão geral dos diagnósticos.

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.

Pode aceder aos registos de consola gerados a partir do interior do contentor.

Primeiro, ligue a registo de contentores 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 a sua aplicação web.

Uma vez ligado o registo do contentor, erguia o seguinte comando para ver o fluxo de registo:

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 parar o streaming de registo a qualquer momento, digite Ctrl+C.

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

Para obter mais informações, consulte os registos de stream em Cloud Shell.

Acesso à consola 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 de Java incorporadas são baseadas no sistema operativo Alpine Linux . Utilize o apk gestor de pacotes para instalar quaisquer ferramentas ou comandos de resolução de problemas.

Gravador de Voo

Todos os tempos de corrida de Java em Serviço de Aplicações usando os JVMs Azuis vêm com o Gravador de Voo Zulu. Pode usar isto para gravar eventos de JVM, sistema e aplicações e problemas de resolução de problemas nas suas aplicações Java.

Gravação cronometrada

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

Em seguida, abra a Consola Debug na barra de ferramentas superior do site SCM e executar o seguinte comando. Substitua-o <pid> pelo ID de processo que copiou anteriormente. Este comando iniciará uma gravação de perfis de 30 segundos da sua aplicação Java e gerará um ficheiro nomeado timed_recording_example.jfr no diretório D:\home .

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

SSH na sua Serviço de Aplicações e executar o jcmd comando para ver uma lista de todos os processos java em execução. Além do próprio jcmd, deve ver a sua aplicação Java a funcionar 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 abaixo para iniciar uma gravação de 30 segundos do JVM. Isto irá perfilar o JVM e criar um ficheiro JFR chamado jfr_example.jfr no diretório doméstico. (Substitua 116 pela pid da sua app Java.)

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

Durante o intervalo de 30 segundos, pode validar a gravação funcionando jcmd 116 JFR.check. Isto mostrará todas as gravações para o processo java dado.

Gravação Contínua

Pode utilizar o Gravador de Voo Zulu para perfilar continuamente a sua aplicação Java com o mínimo impacto no desempenho do tempo de execução. Para tal, executar o seguinte comando Azure CLI para criar uma Definição de Aplicação com o nome JAVA_OPTS com a configuração necessária. Os conteúdos da JAVA_OPTS Definição de Aplicações são transmitidos ao comando quando a java sua aplicação é iniciada.

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 iniciada a gravação, pode despejar os dados de gravação atuais a qualquer momento utilizando o JFR.dump comando.

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

Analisar .jfr ficheiros

Utilize o FTPS para descarregar o seu ficheiro JFR para a sua máquina local. Para analisar o ficheiro JFR, descarregue e instale o Zulu Mission Control. Para obter instruções sobre o Controlo da Missão Zulu, consulte a documentação azul e as instruções de instalação.

Registo de aplicativos

Habilita a inscrição de aplicações através do portal do Azure ou Azure CLI para configurar Serviço de Aplicações para escrever a saída padrão da consola da sua aplicação e fluxos de erros de consola padrão para o sistema de ficheiros local ou Armazenamento de Blobs do Azure. O registo no sistema de ficheiros local Serviço de Aplicações é desativado 12 horas após a sua configuração. Se precisar de uma retenção mais longa, configuure a aplicação para escrever a saída num recipiente de armazenamento Blob. Os seus registos de aplicações Java e Tomcat podem ser encontrados no /home/LogFiles/Application/Diretório .

Habilita a inscrição de aplicações através do portal do Azure ou Azure CLI para configurar Serviço de Aplicações para escrever a saída padrão da consola da sua aplicação e fluxos de erros de consola padrão para o sistema de ficheiros local ou Armazenamento de Blobs do Azure. Se precisar de uma retenção mais longa, configuure a aplicação para escrever a saída num recipiente de armazenamento Blob. Os seus registos de aplicações Java e Tomcat podem ser encontrados no /home/LogFiles/Application/Diretório .

Armazenamento de Blobs do Azure registo de serviços de aplicações baseados em Linux só pode ser configurado usando o Azure Monitor

Se a sua aplicação utilizar Logback ou Log4j para rastreio, pode encaminhar estes vestígios para revisão em Aplicação Azure Insights utilizando as instruções de configuração de quadro de registo em Explore Java trace logs in Application Insights.

Nota

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

Personalização e afinação

Serviço de Aplicações do Azure suporta a afinação e personalização da caixa através do portal do Azure e CLI. Reveja os seguintes artigos para configuração de aplicações web não específicas de Java:

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

Para definir a memória alocada ou outras opções de tempo de execução JVM, crie uma definição de aplicação nomeada JAVA_OPTS com as opções. Serviço de Aplicações passa esta definição como uma variável ambiental para o tempo de execução de Java quando começa.

No portal do Azure, em Definições de Aplicação para a aplicação web, crie uma nova configuração de aplicação nomeada JAVA_OPTS para Java SE ou CATALINA_OPTS para Tomcat que inclua outras configurações, tais como -Xms512m -Xmx1204m.

Para configurar a definição da aplicação a partir do plugin Maven, adicione etiquetas de definição/valor na secção plugin Azure. O exemplo a seguir define um tamanho mínimo e máximo de pilha de Java específico:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms512m -Xmx1204m</value>
    </property>
</appSettings>

Nota

Não é necessário criar um ficheiro web.config quando utilizar o Tomcat no Windows Serviço de Aplicações.

Os desenvolvedores que executam uma única aplicação com uma ranhura de implementação no seu plano de Serviço de Aplicações podem utilizar as seguintes opções:

  • Casos B1 e S1: -Xms1024m -Xmx1024m
  • Casos B2 e S2: -Xms3072m -Xmx3072m
  • Casos 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
  • I1 casos: -Xms3072m -Xmx3072m
  • I2 instâncias: -Xms6144m -Xmx6144m
  • I3 instâncias: -Xms12800m -Xmx12800m
  • I1v2 instâncias: -Xms6656m -Xmx6656m
  • I2v2 instâncias: -Xms14848m -Xmx14848m
  • I3v2 instâncias: -Xms30720m -Xmx30720m

Ao sintonizar as definições da pilha de aplicações, reveja os detalhes do seu plano de Serviço de Aplicações e tenha em conta várias aplicações e slots de implementação para encontrar a alocação ideal de memória.

Ligue as tomadas web

Ligue o suporte para tomadas web no portal do Azure nas definições de Aplicação para a aplicação. Terá de reiniciar a aplicação para a definição para fazer efeito.

Ligue o suporte da tomada web utilizando o CLI Azure com o seguinte comando:

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

Em seguida, reinicie a sua aplicação:

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 Definições de Aplicação para a aplicação web, crie uma nova configuração de aplicação nomeada JAVA_OPTS com valor -Dfile.encoding=UTF-8.

Em alternativa, pode configurar a definição da aplicação utilizando o plugin maven Serviço de Aplicações. Adicione o nome de definição e as etiquetas de valor na configuração do plugin:

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

Pré-Compilar ficheiros JSP

Para melhorar o desempenho das aplicações Tomcat, pode compilar os seus ficheiros JSP antes de ser implantado para Serviço de Aplicações. Pode utilizar o plugin Maven fornecido pela Apache Sling ou utilizar este ficheiro de construção de Formiga.

Aplicações seguras

As aplicações java em execução em Serviço de Aplicações têm o mesmo conjunto de boas práticas de segurança que outras aplicações.

Autenticar utilizadores (Easy Auth)

Configurar a autenticação da aplicação no portal do Azure com a opção Autenticação e Autorização. A partir daí, pode ativar a autenticação através do Azure Ative Directory ou de logins sociais como Facebook, Google ou GitHub. portal do Azure configuração só funciona quando configurar um único fornecedor de autenticação. Para mais informações, consulte a sua aplicação Serviço de Aplicações para utilizar o login do Azure Ative Directory e os artigos relacionados com outros fornecedores de identidade. Se necessitar de ativar vários fornecedores de inscrição, siga as instruções no artigo de inscrição personalizada e de assinaturas .

Java SE

Os desenvolvedores de Boot de mola podem usar o arranque Azure Ative Directory Spring Boot para garantir aplicações usando anotações familiares de Segurança da primavera e APIs. Certifique-se de que aumenta o tamanho máximo do cabeçalho no ficheiro application.properties . Sugerimos um valor de 16384.

Tomcat

A sua aplicação Tomcat pode aceder diretamente às reclamações do utilizador a partir do servlet, lançando o objeto principal para um objeto de Mapa. O objeto mapa irá mapear cada tipo de reivindicação para uma coleção das reclamações para esse tipo. No código abaixo, request é um exemplo de HttpServletRequest.

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

Agora pode inspecionar o Map objeto para obter qualquer reclamação específica. Por exemplo, o seguinte código corta iterados através de todos os tipos de reclamaçã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 assinar os utilizadores, use o /.auth/ext/logout caminho. Para realizar outras ações, consulte a documentação sobre Personalizar ins e sign-outs. Há também documentação oficial sobre a interface Tomcat HttpServletRequest e seus métodos. Os seguintes métodos de servidão também são hidratados com base na sua configuração Serviço de Aplicações:

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

Para desativar esta função, crie uma Definição de Aplicação com WEBSITE_AUTH_SKIP_PRINCIPAL o valor de 1. Para desativar todos os filtros de servidão adicionados por Serviço de Aplicações, crie uma definição com WEBSITE_SKIP_FILTERS o valor de 1.

Configurar TLS/SSL

Siga as instruções no Secure um nome DNS personalizado com uma ligação TLS/SSL em Serviço de Aplicações do Azure para carregar um certificado TLS/SSL existente e ligá-lo ao nome de domínio da sua aplicação. Por predefinição, a sua aplicação continuará a permitir que as ligações HTTP sigam os passos específicos do tutorial para impor o TLS/SSL.

Utilizar referências KeyVault

A Azure KeyVault fornece uma gestão secreta centralizada com políticas de acesso e histórico de auditoria. Pode armazenar segredos (como palavras-passe ou cadeias de ligação) no KeyVault e aceder a estes segredos na sua aplicação através de variáveis ambientais.

Em primeiro lugar, siga as instruções para conceder à sua aplicação acesso a Key Vault e fazer uma referência KeyVault ao seu segredo numa Definição de Aplicação. Pode validar que a referência se resolve com o segredo, imprimindo a variável ambiente ao aceder remotamente ao terminal Serviço de Aplicações.

Para injetar estes segredos no seu ficheiro de configuração primavera ou Tomcat, utilize sintaxe de injeção variável ambiental (${MY_ENV_VAR}). Para ficheiros de configuração da Mola, consulte esta documentação sobre configurações externas.

Use a Loja de Chaves Java

Por predefinição, quaisquer certificados públicos ou privados enviados para Serviço de Aplicações o Linux serão carregados nas respetivas Lojas de Chaves Java à medida que o contentor começar. Depois de carregar o seu certificado, terá de reiniciar a sua Serviço de Aplicações para que seja carregado na Loja de Chaves Java. Os certificados públicos são carregados na Loja-Chave em $JRE_HOME/lib/security/cacerts, e os certificados privados são armazenados em $JRE_HOME/lib/security/client.jks.

Poderá ser necessária mais configuração para encriptar a sua ligação JDBC com certificados na Loja de Chaves Java. Consulte a documentação do seu motorista JDBC escolhido.

Inicialize a Loja de Chaves Java

Para rubricar o import java.security.KeyStore objeto, carregue o ficheiro da loja com a palavra-passe. A palavra-passe padrão para ambas as lojas principais é 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 a loja de chaves

Pode carregar os certificados manualmente na loja de chaves. Crie uma configuração de aplicação, SKIP_JAVA_KEYSTORE_LOADcom o valor de 1 desativar Serviço de Aplicações de carregar automaticamente os certificados na loja de chaves. Todos os certificados públicos enviados para Serviço de Aplicações através do portal do Azure são armazenados sob /var/ssl/certs/. Os certificados privados são armazenados em ./var/ssl/private/

Pode interagir ou depurar a Ferramenta chave Java abrindo uma ligação SSH à sua Serviço de Aplicações e executando o comando keytool. Consulte a documentação da Ferramenta Chave para obter uma lista de comandos. Para obter mais informações sobre a API keyStore, consulte a documentação oficial.

Configurar plataformas APM

Esta secção mostra como ligar as aplicações java implementadas em Serviço de Aplicações do Azure com as plataformas de monitorização de aplicações do Azure Monitor, NewRelic e AppDynamics (APM).

Configurar o Application Insights

O Azure Monitor é um serviço de monitorização de aplicações nativas em nuvem que permite aos clientes observar falhas, estrangulamentos e padrões de utilização para melhorar o desempenho da aplicação e reduzir o tempo médio de resolução (MTTR). Com alguns cliques ou comandos CLI, pode ativar a monitorização das suas aplicações Node.js ou Java, recolher automaticamente registos, métricas e vestígios distribuídos, eliminando a necessidade de incluir um SDK na sua aplicação. Consulte a documentação do Application Insights para obter mais informações sobre as definições de aplicações disponíveis para configurar o agente.

Portal do Azure

Para ativar os Insights de Aplicação a partir do portal do Azure, aceda a Insights de Aplicação no menu do lado esquerdo e selecione Verção de Informações de Aplicação. Por padrão, será utilizado um novo recurso de insights de aplicação com o mesmo nome que a sua Web App. Pode optar por utilizar um recurso de insights de aplicação existente ou alterar o nome. Clique Em Aplicar na parte inferior

CLI do Azure

Para ativar através do CLI Azure, terá de criar um recurso Application Insights e definir algumas definições de aplicações no portal do Azure para ligar o Application Insights à sua aplicação web.

  1. Ativar a extensão de Insights de Aplicações

    az extension add -n application-insights
    
  2. Crie um recurso Application Insights utilizando o comando CLI abaixo. Substitua os espaços reservados pelo nome e grupo de recursos pretendidos.

    az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web
    

    Note os valores para connectionString e instrumentationKey, você precisará destes valores no passo seguinte.

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

  1. Defina a chave de instrumentação, o fio de ligação e a versão do agente de monitorização como definições de aplicações na aplicação web. Substitua <instrumentationKey> e <connectionString> pelos valores do passo 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"
    
  1. Defina a chave de instrumentação, o fio de ligação e a versão do agente de monitorização como definições de aplicações na aplicação web. Substitua <instrumentationKey> e <connectionString> pelos valores do passo 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"
    

Configure nova relíquia

  1. Criar uma conta NewRelic na NewRelic.com

  2. Descarregue o agente Java da NewRelic, terá um nome de ficheiro semelhante ao newrelic-java-x.x.x.zip.

  3. Copie a chave da sua licença e vai precisar dela para configurar o agente mais tarde.

  4. SSH no seu Serviço de Aplicações instância e crie um novo diretório /home/site/wwwroot/apm.

  5. Faça o upload dos ficheiros de agente NewRelic Java desembalados para um diretório em /home/site/wwwroot/apm. Os ficheiros do seu agente devem estar em /home/site/wwwroot/apm/newrelic.

  6. Modifique o ficheiro YAML em /home/site/wwwroot/apm/newrelic/newrelic.yml e substitua o valor da licença de espaço reservado pela sua própria chave de licença.

  7. No portal do Azure, navegue na sua aplicação em Serviço de Aplicações e crie uma nova Definição de Aplicação.

    • Para aplicações Java SE , crie uma variável ambiental com JAVA_OPTS o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
    • Para o Tomcat, crie uma variável ambiental nomeada CATALINA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
  1. Criar uma conta NewRelic na NewRelic.com

  2. Descarregue o agente Java da NewRelic, terá um nome de ficheiro semelhante ao newrelic-java-x.x.x.zip.

  3. Copie a chave da sua licença e vai precisar dela para configurar o agente mais tarde.

  4. SSH no seu Serviço de Aplicações instância e crie um novo diretório /home/site/wwwroot/apm.

  5. Faça o upload dos ficheiros de agente NewRelic Java desembalados para um diretório em /home/site/wwwroot/apm. Os ficheiros do seu agente devem estar em /home/site/wwwroot/apm/newrelic.

  6. Modifique o ficheiro YAML em /home/site/wwwroot/apm/newrelic/newrelic.yml e substitua o valor da licença de espaço reservado pela sua própria chave de licença.

  7. No portal do Azure, navegue na sua aplicação em Serviço de Aplicações e crie uma nova Definição de Aplicação.

    • Para aplicações Java SE , crie uma variável ambiental com JAVA_OPTS o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
    • Para o Tomcat, crie uma variável ambiental nomeada CATALINA_OPTS com o valor -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Se já tiver uma variável ambiental para JAVA_OPTS ou CATALINA_OPTS, anexar a opção -javaagent:/... até ao fim do valor atual.

Configurar a AppDynamics

  1. Criar uma conta AppDynamics na AppDynamics.com

  2. Descarregue o agente Java a partir do site appDynamics, o nome do ficheiro será semelhante ao AppServerAgent-x.x.x.xxxxx.zip

  3. Utilize a consola Kudu para criar um novo diretório /home/site/wwwroot/apm.

  4. Faça o upload dos ficheiros do agente Java para um diretório em /home/site/wwwroot/apm. Os ficheiros do seu agente devem estar em /home/site/wwwroot/apm/appdynamics.

  5. No portal do Azure, navegue na sua aplicação em Serviço de Aplicações e crie uma nova Definição de Aplicação.

    • Para aplicações Java SE, crie uma variável ambiental com JAVA_OPTS o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> está o seu nome Serviço de Aplicações.
    • Para aplicações Tomcat, crie uma variável ambiental com CATALINA_OPTS o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> está o seu nome Serviço de Aplicações.
  1. Criar uma conta AppDynamics na AppDynamics.com

  2. Descarregue o agente Java a partir do site appDynamics, o nome do ficheiro será semelhante ao AppServerAgent-x.x.x.xxxxx.zip

  3. SSH no seu Serviço de Aplicações instância e crie um novo diretório /home/site/wwwroot/apm.

  4. Faça o upload dos ficheiros do agente Java para um diretório em /home/site/wwwroot/apm. Os ficheiros do seu agente devem estar em /home/site/wwwroot/apm/appdynamics.

  5. No portal do Azure, navegue na sua aplicação em Serviço de Aplicações e crie uma nova Definição de Aplicação.

    • Para aplicações Java SE, crie uma variável ambiental com JAVA_OPTS o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> está o seu nome Serviço de Aplicações.
    • Para aplicações Tomcat, crie uma variável ambiental com CATALINA_OPTS o valor -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> onde <app-name> está o seu nome Serviço de Aplicações.

Nota

Se já tiver uma variável ambiental para JAVA_OPTS ou CATALINA_OPTS, anexar a opção -javaagent:/... até ao fim do valor atual.

Configurar origens de dados

Java SE

Para ligar a fontes de dados em aplicações Spring Boot, sugerimos criar cadeias de ligação e injetá-las no ficheiro aplicações.properties .

  1. Na secção "Configuração" da página Serviço de Aplicações, desacione um nome para a cadeia, cole a sua cadeia de ligação JDBC no campo de valor e desaver o tipo de "Personalizado". Pode configurar opcionalmente esta cadeia de ligação como definição de ranhura.

    Esta cadeia de ligação é acessível à nossa aplicação como uma variável ambiental chamada CUSTOMCONNSTR_<your-string-name>. Por exemplo, a cadeia de ligação que criamos acima será nomeada CUSTOMCONNSTR_exampledb.

  2. No ficheiro application.properties , refira esta cadeia de ligação com o nome variável ambiente. Para o nosso exemplo, usaríamos o seguinte.

    app.datasource.url=${CUSTOMCONNSTR_exampledb}
    

Consulte a documentação do Boot de Mola sobre o acesso aos dados e configurações externas para obter mais informações sobre este tópico.

Tomcat

Estas instruções aplicam-se a todas as ligações de base de dados. Terá de preencher os espaços reservados com o nome da classe de condutor e o ficheiro JAR da sua base de dados escolhida. Fornecido é uma tabela com nomes de classe e transferências de motorista para bases de dados comuns.

Base de Dados Nome da classe do motorista Controlador JDBC
PostgreSQL org.postgresql.Driver Transferência
MySQL com.mysql.jdbc.Driver Download (Selecione "Plataforma Independente")
SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver Transferência

Para configurar o Tomcat para utilizar a Conectividade da Base de Dados de Java (JDBC) ou a API de Persistência de Java (JPA), primeiro personalize a CATALINA_OPTS variável ambiental que é lida pela Tomcat no arranque. Defina estes valores através de uma definição de aplicação no plugin maven Serviço de Aplicações:

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

Ou definir as variáveis de ambiente na páginadefinições de aplicação deconfiguração> no portal do Azure.

Em seguida, determine se a fonte de dados deve estar disponível para uma aplicação ou para todas as aplicações em execução na servidão Tomcat.

Fontes de dados ao nível da aplicação

  1. Crie um ficheiro context.xml no meta-INF/ diretório do seu projeto. Crie o meta-INF/ diretório se não existir.

  2. Em context.xml, adicione um Context elemento para ligar a fonte de dados a um endereço JNDI. Substitua o driverClassName espaço reservado pelo nome da classe do seu condutor 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>
    
  3. Atualize as web.xml da sua aplicação para utilizar a fonte de dados na sua aplicação.

    <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 ao nível do servidor partilhados

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

Automatizar a criação de Tomcat personalizado no início da app

Pode usar um script de arranque para executar ações antes do início de uma aplicação web. O script de arranque para personalizar o Tomcat precisa de completar os seguintes passos:

  1. Verifique se Tomcat já foi copiado e configurado localmente. Se fosse, o guião da startup pode acabar aqui.
  2. Copie Tomcat localmente.
  3. Faça as alterações de configuração necessárias.
  4. Indique que a configuração foi concluída com sucesso.

Para sites windows, crie um ficheiro com o nome startup.cmd ou startup.ps1 no diretório wwwroot . Isto será executado automaticamente antes do início do servidor Tomcat.

Aqui está um roteiro powerShell que completa estes passos:

    # 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 could not be 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 Tomcat é modificar os server.xmlficheiros de configuração , context.xmlou web.xml Tomcat. Serviço de Aplicações já modifica estes ficheiros para fornecer funcionalidades da plataforma. Para continuar a utilizar estas funcionalidades, é importante preservar o conteúdo destes ficheiros quando estão a fazer alterações nos mesmos. Para isso, recomendamos que utilize uma transformação XSL (XSLT). Utilize uma transformação XSL para escoar alterações nos ficheiros XML, preservando o conteúdo original do ficheiro.

Arquivo exemplo XSLT

Esta transformação de exemplo adiciona um novo nó de conector a server.xml. Note a Transformação de Identidade, que preserva o conteúdo original do ficheiro.

    <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 is 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 is 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" 
                 keystroreFile="${{user.home}}/.keystore" keystorePass="changeit"
                 clientAuth="false" sslProtocol="TLS" />
    </xsl:template>

    </xsl:stylesheet>
Função para transformação de XSL

A PowerShell tem ferramentas incorporadas para transformar ficheiros XML utilizando transformações XSL. O seguinte script é uma função de exemplo que pode usar startup.ps1 para 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 de saber onde está instalada a sua versão personalizada do Tomcat. Pode definir a localização da instalação na definição da CATALINA_BASE aplicação.

Pode utilizar o CLI Azure para alterar esta definição:

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

Ou pode alterar manualmente a definição na portal do Azure:

  1. Aceda às definições de>aplicação de configuração> dedefinições.
  2. Selecione Nova Definição de Aplicação.
  3. Utilize estes valores para criar a definição:
    1. Nome: CATALINA_BASE
    2. Valor: "%LOCAL_EXPANDED%\tomcat"
Exemplo startup.ps1

O seguinte exemplo de script 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 could not be 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

Finalmente, colocaremos os JARs de motorista no apágio tomcat e reiniciaremos o seu Serviço de Aplicações. Certifique-se de que os ficheiros do controlador JDBC estão disponíveis para o carregador de classe Tomcat colocando-os no diretório /home/tomcat/lib . (Criar este diretório se já não existir.) Para fazer o upload destes ficheiros para a sua Serviço de Aplicações instância, execute os seguintes passos:

  1. No Cloud Shell, instale a extensão do webapp:

    az extension add -–name webapp
    
  2. Executar o seguinte comando CLI para criar um túnel SSH do seu sistema local para Serviço de Aplicações:

    az webapp remote-connection create --resource-group <resource-group-name> --name <app-name> --port <port-on-local-machine>
    
  3. Ligue-se à porta de túneis local com o seu cliente SFTP e faça o upload dos ficheiros para a pasta /home/tomcat/lib .

Em alternativa, pode utilizar um cliente FTP para carregar o controlador JDBC. Siga estas instruções para obter as suas credenciais FTP.


Tomcat

Estas instruções aplicam-se a todas as ligações de base de dados. Terá de preencher os espaços reservados com o nome da classe de condutor e o ficheiro JAR da sua base de dados escolhida. Fornecido é uma tabela com nomes de classe e transferências de motorista para bases de dados comuns.

Base de Dados Nome da classe do motorista Controlador JDBC
PostgreSQL org.postgresql.Driver Transferência
MySQL com.mysql.jdbc.Driver Download (Selecione "Plataforma Independente")
SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver Transferência

Para configurar o Tomcat para utilizar a Conectividade da Base de Dados de Java (JDBC) ou a API de Persistência de Java (JPA), primeiro personalize a CATALINA_OPTS variável ambiental que é lida pela Tomcat no arranque. Defina estes valores através de uma definição de aplicação no plugin maven Serviço de Aplicações:

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

Ou definir as variáveis de ambiente na páginadefinições de aplicação deconfiguração> no portal do Azure.

Em seguida, determine se a fonte de dados deve estar disponível para uma aplicação ou para todas as aplicações em execução na servidão Tomcat.

Fontes de dados ao nível da aplicação

  1. Crie um ficheiro context.xml no meta-INF/ diretório do seu projeto. Crie o meta-INF/ diretório se não existir.

  2. Em context.xml, adicione um Context elemento para ligar a fonte de dados a um endereço JNDI. Substitua o driverClassName espaço reservado pelo nome da classe do seu condutor 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>
    
  3. Atualize as web.xml da sua aplicação para utilizar a fonte de dados na sua aplicação.

    <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 ao nível do servidor partilhados

A adição de uma fonte de dados partilhada e ao nível do servidor exigirá que edite a server.xml do Tomcat. Em primeiro lugar, faça o upload de um script de arranque e desemcora o caminho para o script noComando de Arranquede Configuração>. Pode fazer o upload do script de arranque utilizando o FTP.

O seu script de arranque fará uma transformação de xsl para o ficheiro server.xml e descolou o ficheiro XML resultante para /usr/local/tomcat/conf/server.xml. O script de arranque deve instalar libxslt via apk. O seu ficheiro xsl e o script de arranque podem ser carregados via FTP. Abaixo está um script de arranque exemplo.

# 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

Um ficheiro xsl de exemplo é fornecido abaixo. O ficheiro xsl exemplo 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 is 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 is 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" 
               keystroreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

Finalizar a configuração

Finalmente, coloque os JARs do condutor no apágio de Tomcat e reinicie a sua Serviço de Aplicações.

  1. Certifique-se de que os ficheiros do controlador JDBC estão disponíveis para o carregador de classe Tomcat colocando-os no diretório /home/tomcat/lib . (Criar este diretório se já não existir.) Para fazer o upload destes ficheiros para a sua Serviço de Aplicações instância, execute os seguintes passos:

    1. No Cloud Shell, instale a extensão do webapp:
    az extension add -–name webapp
    
    1. Executar o seguinte comando CLI para criar um túnel SSH do seu sistema local para Serviço de Aplicações:
    az webapp remote-connection create --resource-group <resource-group-name> --name <app-name> --port <port-on-local-machine>
    
    1. Ligue-se à porta de túneis local com o seu cliente SFTP e faça o upload dos ficheiros para a pasta /home/tomcat/lib .

    Em alternativa, pode utilizar um cliente FTP para carregar o controlador JDBC. Siga estas instruções para obter as suas credenciais FTP.

  2. Se criou uma fonte de dados ao nível do servidor, reinicie a aplicação Serviço de Aplicações Linux. O Tomcat irá reiniciar CATALINA_BASE/home/tomcat e utilizar a configuração atualizada.

Fontes de dados EAP JBoss

Existem três passos fundamentais ao registar uma fonte de dados com o JBoss EAP: carregar o controlador JDBC, adicionar o condutor JDBC como módulo e registar o módulo. Serviço de Aplicações é um serviço de hospedagem apátrida, pelo que os comandos de configuração para adicionar e registar o módulo de origem de dados devem ser scriptados e aplicados à medida que o recipiente começa.

  1. Obtenha o motorista JDBC da sua base de dados.

  2. Crie um ficheiro de definição de módulo XML para o controlador JDBC. O exemplo mostrado abaixo é 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>
    
  3. Coloque os seus comandos JBoss CLI num ficheiro chamado jboss-cli-commands.cli. Os comandos JBoss devem adicionar o módulo e registá-lo como fonte de dados. O exemplo abaixo 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
    
  4. Crie um script de arranque que startup_script.sh chame os comandos JBoss CLI. O exemplo abaixo mostra como chamar o seu jboss-cli-commands.cli. Mais tarde, irá configurar Serviço de Aplicações para executar este script quando o recipiente começar.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
    
  5. Utilizando um cliente FTP à sua escolha, faça o upload do seu controlador JDBC, jboss-cli-commands.clistartup_script.she a definição do módulo para /site/deployments/tools/.

  6. Configure o seu site para funcionar startup_script.sh quando o recipiente começar. No portal do Azure, navegue para oComandode Arranque de Configurações Gerais> de Configuração>. Desa estale o campo de comando de arranque para /home/site/deployments/tools/startup_script.sh. Guarde as suas alterações.

Para confirmar que a fonte de dados foi adicionada ao servidor JBoss, SSH no seu webapp e executada $JBOSS_HOME/bin/jboss-cli.sh --connect. Assim que estiver ligado ao JBoss, faça a /subsystem=datasources:read-resource impressão 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.

Escolher uma versão de tempo de execução java

Serviço de Aplicações permite que os utilizadores escolham a versão principal do JVM, como Java 8 ou Java 11, e a versão patch, como 1.8.0_232 ou 11.0.5. Também pode optar por ter a versão patch atualizada automaticamente à medida que novas versões menores ficam disponíveis. Na maioria dos casos, os locais de produção devem utilizar versões JVM de patch fixa. Isto evitará interrupções inesperadas durante uma versão de patch de atualização automática. Todas as aplicações web java usam JVMs de 64 bits, isto não é configurável.

Se estiver a usar o Tomcat, pode optar por fixar a versão patch do Tomcat. No Windows, pode fixar as versões de correção do JVM e do Tomcat de forma independente. No Linux, pode fixar a versão patch de Tomcat; a versão patch do JVM também será fixada, mas não é separadamente configurável.

Se optar por fixar a versão menor, terá de atualizar periodicamente a versão menor JVM no site. Para garantir que a sua aplicação é executado na versão menor mais recente, crie uma ranhura de encenação e incremente a versão menor no site de preparação. Uma vez confirmada a aplicação que funciona corretamente na nova versão menor, pode trocar as ranhuras de encenação e de produção.

JBoss EAP

Agrupamento em JBoss EAP

Serviço de Aplicações suporta o agrupamento para as versões JBoss EAP 7.4.1 e maior. Para ativar o agrupamento, a sua aplicação web deve ser integrada com uma rede virtual. Quando a aplicação web é integrada com uma rede virtual, a aplicação web reiniciará e o JBoss EAP iniciará automaticamente com uma configuração agrupada. As instâncias JBoss EAP comunicarão através da sub-rede especificada na integração da rede virtual, utilizando as portas mostradas na variável ambiente WEBSITES_PRIVATE_PORTS em tempo de execução. Pode desativar o agrupamento criando uma definição de aplicação com o nome WEBSITE_DISABLE_CLUSTERING de qualquer valor.

Nota

Se estiver a permitir a integração da sua rede virtual com um modelo ARM, terá de definir manualmente a propriedade vnetPrivatePorts para um valor de 2. Se ativar a integração da rede virtual a partir do CLI ou Portal, esta propriedade será configurada automaticamente para si.

Quando o agrupamento está ativado, as instâncias JBoss EAP usam o protocolo de descoberta FILE_PING JGroups para descobrir novas instâncias e persistir a informação do cluster como os membros do cluster, os seus identificadores e os seus endereços IP. Na Serviço de Aplicações, estes ficheiros estão em ./home/clusterinfo/ A primeira instância EAP a iniciar obtém permissões de leitura/escrita no ficheiro de membro do cluster. Outras instâncias lerão o ficheiro, encontrarão o nó primário e coordenarão com esse nó a ser incluído no cluster e adicionados ao ficheiro.

Os tipos premium V3 e Plano de Serviço de Aplicações V2 isolados podem opcionalmente ser distribuídos por Zonas de Disponibilidade para melhorar a resiliência e a fiabilidade das suas cargas de trabalho críticas ao negócio. Esta arquitetura também é conhecida como redundância de zona. A funcionalidade de clustering JBoss EAP é compatabile com a função de redundância de zona.

Regras de escala automática

Ao configurar regras de escala automática para a escala horizontal, é importante remover as instâncias de forma incremental (uma de cada vez) para garantir que cada instância removida possa transferir a sua atividade (como manusear uma transação de base de dados) para outro membro do cluster. Ao configurar as suas regras de autoescala no Portal para reduzir a escala, utilize as seguintes opções:

  • Operação: "Diminuição da contagem por"
  • Arrefecer: "5 minutos" ou mais
  • Contagem de exemplos: 1

Não precisa de adicionar gradualmente casos (escalonamento), pode adicionar várias instâncias ao cluster de cada vez.

Planos de Serviço de Aplicações JBoss EAP

JBoss EAP só está disponível nos tipos Premium v3 e Serviço de Aplicações Plano De Serviço de Aplicações Isolado. Os clientes que criaram um site EAP JBoss num nível diferente durante a pré-visualização pública devem escalar até ao nível de hardware Premium ou Isolado para evitar comportamentos inesperados.

Declaração de apoio em tempo de execução de Java

Versões e manutenção JDK

As construções da Microsoft e do Adoptium do OpenJDK são fornecidas e suportadas em Serviço de Aplicações para Java 8, 11 e 17. Estes binários são fornecidos como uma distribuição sem custos, multi-plataforma, pronto para a produção do OpenJDK para a Azure. Eles contêm todos os componentes para a construção e runnning aplicações Java SE. Para desenvolvimento local ou testes, pode instalar a construção microsoft do OpenJDK a partir da página de downloads. O quadro abaixo descreve as novas versões Java incluídas no lançamento da plataforma Serviço de Aplicações de janeiro de 2022:

Versão Java Linux Windows
Java 8 1.8.0_312 (Zulu) * 1.8.0_312 (Adoptium)
Java 11 11.0.13 (MSFT) 11.0.13 (MSFT)
Java 17 17.0.1 (MSFT) 17.0.1 (MSFT)

* Nos lançamentos seguintes, Java 8 em Linux será distribuído a partir de construções adoptium do OpenJDK.

Se estiver preso a uma versão menor mais antiga da Java, o seu site poderá estar a utilizar os binários Zulu para Azure fornecidos através da Azul Systems. Pode continuar a utilizar estes binários para o seu site, mas quaisquer patches de segurança ou melhorias só estarão disponíveis em novas versões do OpenJDK, pelo que recomendamos que atualize periodicamente os seus Aplicações Web para uma versão posterior de Java.

As principais atualizações da versão serão fornecidas através de novas opções de tempo de execução em Serviço de Aplicações do Azure. Os clientes atualizam estas versões mais recentes da Java configurando a sua implementação Serviço de Aplicações e são responsáveis por testar e garantir que a grande atualização atende às suas necessidades.

Os JDKs suportados são automaticamente corrigidos trimestralmente em janeiro, abril, julho e outubro de cada ano. Para mais informações sobre Java sobre Azure, consulte este documento de suporte.

Atualizações de segurança

Patches e correções para grandes vulnerabilidades de segurança serão lançados assim que ficarem disponíveis nas construções da Microsoft do OpenJDK. Uma vulnerabilidade "importante" é definida por uma pontuação base de 9.0 ou superior no Sistema de Pontuação Comum de Vulnerabilidade NIST, versão 2.

Tomcat 8.0 chegou ao Fim da Vida (EOL) a 30 de setembro de 2018. Embora o tempo de execução ainda esteja disponível no Serviço de Aplicações do Azure, o Azure não aplicará atualizações de segurança ao Tomcat 8.0. Se possível, migrar as suas aplicações para Tomcat 8.5 ou 9.0. Tanto o Tomcat 8.5 como o 9.0 estão disponíveis no Serviço de Aplicações do Azure. Consulte o site oficial do Tomcat para mais informações.

O apoio comunitário a Java 7 terminará a 29 de julho de 2022 e Java 7 será retirado do Serviço de Aplicações nessa altura. Se tiver uma aplicação web em Java 7, por favor atualize para Java 8 ou 11 antes de 29 de julho.

Depreciação e reforma

Se um tempo de execução java suportado for retirado, os desenvolvedores Azure que usam o tempo de execução afetado receberão um aviso de depreciação pelo menos seis meses antes do tempo de execução ser retirado.

Desenvolvimento local

Os desenvolvedores podem descarregar a Edição de Produção da Azul Zulu Enterprise JDK para o desenvolvimento local a partir do site de descarregamento da Azul.

Apoio ao desenvolvimento

O suporte ao produto para a Microsoft Build of OpenJDK está disponível através da Microsoft quando se desenvolve para Azure ou Azure Stack com um plano de suporte do Azure qualificado.

Passos seguintes

Visite o centro de Azure para java Developers para encontrar quickstarts, tutoriais e documentação de referência java.