Aracılığıyla paylaş

Azure App Service'te Java SE, Tomcat veya JBoss EAP uygulaması dağıtma ve yapılandırma

Bu makalede, Azure App Service'teki Java uygulamaları için en yaygın dağıtım ve çalışma zamanı yapılandırması gösterilmektedir. Azure App Service'i ilk kez kullanıyorsanız, önce Java hızlı başlangıcını okumanız gerekir. App Service'i kullanma hakkında Java geliştirmeye özgü olmayan genel soruların yanıtlarını App Service SSS bölümünde bulabilirsiniz.

Azure Uygulaması Hizmeti, tam olarak yönetilen bir hizmette Java web uygulamalarını üç farklı şekilde çalıştırır:

  • Java Standard Edition (SE): Eklenmiş bir sunucu (Spring Boot, Quarkus, Dropwizard gibi) içeren bir Java Arşivi (JAR) paketi olarak dağıtılan bir uygulamayı ya da katıştırılmış Tomcat veya Jetty sunucusuna sahip bir uygulamayı çalıştırabilir.
  • Tomcat: Yerleşik Tomcat sunucusu, web uygulaması arşiv (WAR) paketi olarak dağıtılan bir uygulamayı çalıştırabilir.
  • JBoss Kurumsal Uygulama Platformu (EAP): Yerleşik JBoss EAP sunucusu, WAR veya kurumsal arşiv (EAR) paketi olarak dağıtılan bir uygulamayı çalıştırabilir. Ücretsiz, Premium v3 ve Yalıtılmış v2.gti içeren bir dizi fiyatlandırma katmanında Linux uygulamaları için desteklenir

Java sürümünü gösterme

Geçerli Java sürümünü göstermek için Azure Cloud Shell'de aşağıdaki komutu çalıştırın:

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

Desteklenen tüm Java sürümlerini göstermek için Cloud Shell'de aşağıdaki komutu çalıştırın:

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

Linux kapsayıcısında Java sürümünü alma

Linux kapsayıcısında daha ayrıntılı sürüm bilgileri için kapsayıcıyla bir SSH oturumu açın. Aşağıda çalıştırabileceğiniz öğelere birkaç örnek verilmiştir.

SSH oturumunda Java sürümünü görüntülemek için:

java -version

SSH oturumunda Tomcat sunucu sürümünü görüntülemek için:

sh /usr/local/tomcat/version.sh

Özel bir konumda Tomcat sunucunuz varsa, şunu kullanarak version.sh bulabilirsiniz:

find / -name "version.sh"

SSH oturumunda JBoss EAP sunucu sürümünü görüntülemek için:

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

Sürüm desteği hakkında daha fazla bilgi için bkz. App Service dil çalışma zamanı destek ilkesi.

App Service'te eski çalışma zamanlarına ne olur?

Eski çalışma zamanları, bakım kuruluşu tarafından kullanımdan kaldırılmıştır veya önemli güvenlik açıkları olduğu tespit edilir. Buna göre, portaldaki oluşturma ve yapılandırma sayfalarından kaldırılırlar. Süresi geçmiş bir çalışma zamanı portaldan gizlendiğinde, bu çalışma zamanını kullanmaya devam eden tüm uygulamalar çalışmaya devam eder.

Portalda artık gösterilmemiş bir eski çalışma zamanı sürümüne sahip bir uygulama oluşturmak istiyorsanız Azure CLI, ARM şablonu veya Bicep'i kullanın. Bu dağıtım alternatifleri, portalda kaldırılmış ancak hala desteklenmeye devam eden kullanım dışı çalışma zamanları oluşturmanıza olanak tanır.

Bir çalışma zamanı App Service platformundan tamamen kaldırılırsa, Azure aboneliği sahibiniz kaldırmadan önce bir e-posta bildirimi alır.

Uygulamanızı yayma

Yapı araçları

Maven

Azure Web Apps için Maven Eklentisini kullanarak proje kökünde tek bir komutla projenizi kolayca hazırlayabilirsiniz:

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

Bu komut, mevcut bir Azure Web Uygulamasını seçmenizi veya yeni bir uygulama oluşturmanızı isteyip istemediğinizi sorarak bir azure-webapp-maven-plugin eklenti ve ilgili yapılandırma ekler. Yapılandırma sırasında uygulamanızın Java SE, Tomcat veya (yalnızca Linux) JBoss EAP'ye dağıtılıp dağıtılmayacağını algılamaya çalışır. Ardından aşağıdaki komutu kullanarak Java uygulamanızı Azure'a dağıtabilirsiniz:

mvn package azure-webapp:deploy

İşte pom.xml içinde bir örnek yapılandırma:

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 17</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

  1. Azure Web Apps için Gradle Eklentisini ekleyerek ayarlayın.

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

  2. Web uygulamanızın ayrıntılarını yapılandırın. Eğer mevcut değilse, ilgili Azure kaynakları oluşturulur. Aşağıda örnek bir yapılandırma verilmiştır. Ayrıntılar için bu belgeye bakın.

    azurewebapp {
    subscription = '<your subscription id>'
    resourceGroup = '<your resource group>'
    appName = '<your app name>'
    pricingTier = '<price tier like 'P1v2'>'
    region = '<region like 'westus'>'
    runtime {
      os = 'Linux'
      webContainer = 'Tomcat 10.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 17'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

  3. Tek bir komutla dağıtın.

    gradle azureWebAppDeploy

IDE'ler

Azure, popüler Java Tümleşik Geliştirme Ortamlarında (IDE' ler) sorunsuz Java App Service geliştirme deneyimi sağlar:

Kudu ve OneDeploy API'leri

Maven eklentisi, azure/webapps-deploy@v3 ve daha yenilerini kullanarak GitHub Actions veya az webapp deploy komutu gibi dağıtım istemcileri, arka planda Kudu sitesinin /api/publish uç noktasını çağıran OneDeploy kullanır. Bu API hakkında daha fazla bilgi için bu belgelere bakın.

Bu dağıtım yöntemleri kullanıldığında, dağıtım işlemi sırasında sağlanan JAR dosyasını otomatik olarak app.jar olarak yeniden adlandırır. Bu, altına /home/site/wwwwrootyerleştirilir. JAR dosyalarını Java SE'ye dağıtmak için bu belgelere bakın.

Not

FTP veya eski ZipDeploy API'leri gibi alternatif yöntemler kullanırsanız, sağlanan JAR dosyasını yeniden adlandırma yöntemi çağrılmayacak. Jar dosyanızı açıkça çağırmak için portalın Yapılandırma bölümündeki Başlangıç Dosyası metin kutusunu kullanıyorsanız bunu not edin.

Bu belgeleri izleyerek WAR dosyalarını Tomcat uygulamanıza dağıtabilirsiniz. Yukarıdaki dağıtım yöntemleri kullanıldığında, dağıtım işlemi sırasında sağlanan War dosyası otomatik olarak app.war olarak yeniden adlandırılır. /home/site/wwwwroot altına yerleştirilir ve varsayılan olarak yalnızca bir WAR dosyası wwwroot altında dağıtmayı destekler. Bu, WarDeploy gibi dağıtım API'leri kullanılırken görüldüğü gibi dizinin altına /home/site/wwwroot/webapps. Dosya yapısı çakışmalarıyla ilgili sorunları önlemek için yalnızca bir veya diğer dağıtım türünü kullanmanız tavsiye edilir.

WAR dosyalarını JBoss EAP'ye dağıtmak için bu belgelere bakın. OneDeploy kullanıldığında, bu işlem WAR dosyasını otomatik olarak olarak app.war olarak yeniden adlandırır ve altına /home/site/wwwrootyerleştirilir.

EAR dosyalarını dağıtmak için FTP kullanın. EAR uygulamanız, uygulamanızın yapılandırmasında tanımlanan bağlam köküne dağıtılır. Web uygulamanızın kök yolda hizmet vermesini istiyorsanız, uygulamanızın bağlam kökünü kök yola ayarladığınızdan emin olun: <context-root>/</context-root>. Daha fazla bilgi için bkz . Web uygulamasının bağlam kökünü ayarlama.

WAR veya JAR'ınızı FTP kullanarak dağıtmayın. Başlangıç betiklerini, bağımlılıkları veya çalışma sırasında gerekli dosyaları karşıya yüklemek için FTP aracı tasarlanmıştır. Web uygulamalarını dağıtmak için en uygun seçenek bu değildir.

URL'yi yeniden yazma veya yeniden yönlendirme

Url'yi yeniden yazmak veya yeniden yönlendirmek için UrlRewriteFilter gibi kullanılabilir URL yeniden yazmalarından birini kullanın.

Tomcat ayrıca bir yeniden yazma vanası sağlar.

JBoss EAP ayrıca yeniden yazma vanası sağlar.

Uygulamaların kayıt alınması ve hata ayıklanması

Azure portalı üzerinden her uygulama için performans raporları, trafik görselleştirmeleri ve sistem durumu denetimleri kullanılabilir. Daha fazla bilgi için bkz. Azure App Service tanılamalarına genel bakış.

Tanılama günlüklerini yayınla

Kapsayıcının içinden oluşturulan konsol günlüklerine erişebilirsiniz.

Kapsayıcı günlüğünü açmak için aşağıdaki komutu çalıştırın:

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

<app-name> ve <resource-group-name> öğelerini web uygulamanız için uygun adlarla değiştirin.

Container günlüğünü açtıktan sonra günlük akışını görüntülemek için aşağıdaki komutu çalıştırın:

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

Konsol günlükleri hemen görünmüyorsa 30 saniye içinde yeniden denetleyin.

Günlük akışını istediğiniz zaman durdurmak için Ctrl+C tuşlarına basın.

Daha fazla bilgi için bkz . Cloud Shell'de akış günlükleri.

Linux'ta SSH konsol erişimi

Kapsayıcınızla doğrudan SSH oturumu açmak için uygulamanızın çalışıyor olması gerekir.

az webapp ssh komutunu kullanın.

Kimlik doğrulamasından geçmediyseniz bağlantıyı kurabilmek için Azure aboneliğinizle kimliğinizi doğrulamanız gerekir. Kimliğiniz doğrulandıktan sonra tarayıcı içi kabuk komut satırını görürsünüz ve bu ortamda kapsayıcınız içerisinde komutlar çalıştırabilirsiniz.

SSH bağlantısı

Not

Dizin dışında /home yaptığınız tüm değişiklikler kapsayıcının kendisinde depolanır ve uygulama yeniden başlatma işleminin ötesinde kalıcı olmaz.

Yerel makinenizden uzak bir SSH oturumunu açmak için bkz. Uzak kabuktan SSH oturumu açma.

Linux sorun giderme araçları

Yerleşik Java görüntüleri Alpine Linux işletim sistemini temel alır. apk Sorun giderme araçlarını veya komutlarını yüklemek için paket yöneticisini kullanın.

Java profil oluşturucu

Azure App Service'deki tüm Java çalışma zamanları, Java iş yüklerinin profilini oluşturmak için Java Development Kit (JDK) Flight Recorder ile birlikte gelir. Java Sanal Makinesi (JVM), sistem ve uygulama olaylarını kaydetmek ve uygulamalarınızdaki sorunları gidermek için kullanabilirsiniz.

Java profil oluşturucu hakkında daha fazla bilgi edinmek için Azure Application Insights belgelerini ziyaret edin.

Java Uçuş Kaydedici

App Service'te tüm Java çalışma zamanları Java Flight Recorder ile birlikte gelir. JVM, sistem ve uygulama olaylarını kaydetmek ve Java uygulamalarınızdaki sorunları gidermek için bunu kullanabilirsiniz.

App Service'e SSH ekleyin ve komutunu çalıştırarak jcmd çalışan tüm Java işlemlerinin listesini görün. Buna ek olarak jcmd , Java uygulamanızın bir işlem kimliği (PID) numarasıyla çalıştığını görmeniz gerekir.

078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

JVM'nin 30 saniyelik kaydını başlatmak için aşağıdaki komutu yürütün. JVM'nin profilini oluşturur ve giriş dizininde adlı jfr_example.jfr bir Java Flight Recorder (JFR) dosyası oluşturur. 116 öğesini Java uygulamanızın PID'siyle değiştirin.

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

30 saniyelik aralık boyunca, jcmd 116 JFR.check çalıştırarak kaydın gerçekleştiğini doğrulayabilirsiniz. komutu, verilen Java işlemi için tüm kayıtları gösterir.

Sürekli kayıt

Java uygulamanızın profilini çalışma zamanı performansı üzerinde en az etkiyle sürekli olarak görüntülemek için Java Flight Recorder'ı kullanabilirsiniz. Bunu yapmak için aşağıdaki Azure CLI komutunu çalıştırarak gerekli yapılandırmaya sahip adlı JAVA_OPTS bir uygulama ayarı oluşturun. Uygulamanız başlatıldığında, JAVA_OPTS ayarındaki içerikler java komutuna aktarılır.

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

Kayıt başladıktan sonra, JFR.dump komutunu kullanarak geçerli kayıt verilerinin dökümünü istediğiniz zaman çıkartabilirsiniz.

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

JFR dosyalarını analiz etme

JFR dosyanızı yerel makinenize indirmek için FTPS kullanın. JFR dosyasını analiz etmek için Java Mission Control'ü (JMC) indirip yükleyin. Java Mission Control'u kullanma yönergeleri için JMC belgelerine ve yükleme yönergelerine bakın.

Uygulama kayıtları

App Service'i uygulamanızın standart konsol çıkışını ve standart konsol hata akışlarını yerel dosya sistemine veya Azure Blob Depolama'ya yazacak şekilde yapılandırmak için aşağıdakileri yapın. Azure portalından veya Azure CLI'denuygulama günlüğünü etkinleştirin. Daha uzun bekletmeye ihtiyacınız varsa, uygulamayı bir Blob Depolama kapsayıcısına çıkış yazacak şekilde yapılandırın.

Java ve Tomcat uygulama günlükleriniz dizininde /home/LogFiles/Application/ bulunabilir.

Linux tabanlı uygulamalar için Azure Blob Depolama günlüğü yalnızca Azure İzleyici kullanılarak yapılandırılabilir.

Uygulamanız izleme için Logback veya Log4j kullanıyorsa bu izlemeleri gözden geçirmek üzere Azure Application Insights'a iletebilirsiniz. Application Insights'ta Java izleme günlüklerini keşfetme başlığındaki günlüğe kaydetme çerçevesi yapılandırma yönergelerini kullanın.

Not

Bilinen güvenlik açığı CVE-2021-44228nedeniyle Log4j sürüm 2.16 veya üzerini kullandığınızdan emin olun.

Özelleştirme ve ayarlama

Azure App Service, Azure portalı ve Azure CLI aracılığıyla kullanıma hazır ayarlamayı ve özelleştirmeyi destekler. Java'ya özgü olmayan web uygulaması yapılandırması için aşağıdaki makaleleri gözden geçirin:

Uygulama içeriğini yerel olarak kopyalama

Uygulama içeriğinizi paylaşılan dosya sisteminden yerel çalışana kopyalamak için uygulama ayarını JAVA_COPY_ALLtrue olarak ayarlayın. Bu ayar, dosya kilitleme sorunlarını gidermeye yardımcı olur.

Java çalışma zamanı seçeneklerini ayarlama

Ayrılmış bellek veya diğer JVM çalışma zamanı seçeneklerini ayarlamak için, seçenekleriyle adlı bir JAVA_OPTS oluşturun. App Service bu ayarı java çalışma zamanı başlatıldığında ortam değişkeni olarak geçirir.

Azure portalında, web uygulaması için Uygulama Ayarları altında, gibi JAVA_OPTSdiğer ayarları içeren adlı -Xms512m -Xmx1204m yeni bir uygulama ayarı oluşturun.

Azure portalında, web uygulaması için Uygulama Ayarları altında, gibi CATALINA_OPTSdiğer ayarları içeren adlı -Xms512m -Xmx1204m yeni bir uygulama ayarı oluşturun.

Maven eklentisinden uygulama ayarını yapılandırmak için Azure eklentisi bölümüne ayar/değer etiketleri ekleyin. Aşağıdaki örnek belirli bir en düşük ve en yüksek Java yığın boyutunu ayarlar:

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

Not

Windows App Service'te Tomcat kullanırken web.config dosyası oluşturmanız gerekmez.

Varsayılan olarak, App Service JVM Maksimum Yığın boyutunu App Service Planı için kullanılabilir toplam belleğin 70% olarak ayarlar. Varsayılan ayarı devre dışı bırakmak için WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true" uygulama ayarını kullanabilirsiniz.

Uygulamanızın platformdaki performansını geliştirmek için yığın boyutunun ihtiyaçlarınıza daha iyi uyacak şekilde ayarlanması gerekebilir. Uygulama yığını ayarlarını yaparken lütfen App Service planı ayrıntılarınızı gözden geçirin ve en uygun bellek ayırmayı bulmak için birden çok uygulama ve dağıtım yuvasının gereksinimlerini göz önünde bulundurun.

Web yuvalarını açma

Azure portalında web yuvaları desteğini uygulamanın Uygulama ayarları bölümünden açın. Ayarın geçerli olması için uygulamayı yeniden başlatmanız gerekir.

Aşağıdaki komutla Azure CLI'yi kullanarak web yuvası desteğini açın:

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

Ardından uygulamanızı yeniden başlatın:

az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

Varsayılan karakter kodlamayı ayarlama

Azure portalında, web uygulaması için Uygulama Ayarları altında, değeri JAVA_OPTS olan -Dfile.encoding=UTF-8 adında yeni bir uygulama ayarı oluşturun.

Alternatif olarak, App Service Maven eklentisini kullanarak uygulama ayarını yapılandırabilirsiniz. Eklenti yapılandırmasına ayar adını ve değer etiketlerini ekleyin:

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

JSP dosyalarını önceden derleme

Tomcat uygulamalarının performansını geliştirmek için, App Service'e dağıtmadan önce JSP dosyalarınızı derleyebilirsiniz. Apache Sling tarafından sağlanan Maven eklentisini veya bu Ant derleme dosyasını kullanabilirsiniz.

Günlüklerde robots933456 iletisini yoksay

Kapsayıcı günlüklerinde aşağıdaki iletiyi görebilirsiniz:

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

Bu iletiyi gönül rahatlığıyla yoksayabilirsiniz. /robots933456.txt, App Service'in kapsayıcının istekleri karşılayabilme yeteneğini kontrol etmek için kullandığı sahte bir URL yoludur. 404 yanıtı, yolun mevcut olmadığını gösterir ve App Service'e kapsayıcının iyi durumda olduğunu ve isteklere yanıt vermeye hazır olduğunu bildirir.

Java çalışma zamanı sürümü seçme

App Service, kullanıcıların JVM'nin Java 8 veya Java 11 gibi ana sürümünü ve 1.8.0_232 veya 11.0.5 gibi düzeltme eki sürümünü seçmesine olanak tanır. Ayrıca, yeni ikincil sürümler kullanılabilir hale geldikçe düzeltme eki sürümünün otomatik olarak güncelleştirilmasını da seçebilirsiniz. Çoğu durumda üretim uygulamaları, düzeltme eki sürümü otomatik güncelleştirmesi sırasında beklenmeyen kesintileri önleyen sabitlenmiş düzeltme eki JVM sürümlerini kullanmalıdır. Tüm Java web uygulamaları 64 bit JVM'ler kullanır ve yapılandırılamaz.

Tomcat kullanıyorsanız Tomcat'in yama sürümünü sabitlemeyi seçebilirsiniz. Windows'da JVM ve Tomcat'in düzeltme eki sürümlerini bağımsız olarak sabitleyebilirsiniz. Linux'ta Tomcat'in yama sürümünü sabitleyebilirsiniz. JVM'nin düzeltme eki sürümü de sabitlenir ancak ayrı olarak yapılandırılamaz.

İkincil sürümü sabitlemeyi seçerseniz, uygulamadaki JVM ikincil sürümünü düzenli aralıklarla güncelleştirmeniz gerekir. Uygulamanızın daha yeni ikincil sürümde çalıştığından emin olmak için bir hazırlama yuvası oluşturun ve hazırlama yuvasında ikincil sürümü artırın. Uygulamanın yeni ikincil sürümde doğru şekilde çalıştığını onayladıktan sonra hazırlama ve üretim yuvalarını değiştirebilirsiniz.

JBoss CLI'yi çalıştırma

JBoss EAP uygulamanızın SSH oturumunda JBoss CLI'yi aşağıdaki komutla çalıştırabilirsiniz:

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

JBoss EAP'nin sunucu yaşam döngüsünde nerede olduğuna bağlı olarak bağlanamayabilirsiniz. Birkaç dakika bekleyin ve tekrar deneyin. Bu yaklaşım, geçerli sunucunuzun durumunu hızlı bir şekilde denetlemek için yararlıdır (örneğin, bir veri kaynağının düzgün yapılandırılıp yapılandırılmamış olduğunu görmek için).

Ayrıca, SSH oturumunda JBoss CLI ile sunucuda yaptığınız değişiklikler uygulama yeniden başlatıldıktan sonra kalıcı olmaz. Uygulama her başlatıldığında JBoss EAP sunucusu temiz bir yüklemeyle başlar. App Service, başlangıç yaşam döngüsü sırasında gerekli sunucu yapılandırmalarını yapar ve uygulamayı dağıtır. JBoss EAP sunucusunda kalıcı değişiklikler yapmak için özel bir başlangıç betiği veya başlangıç komutu kullanın. Uçtan uca bir örnek için bkz. Azure App Service'te Java SE, Tomcat veya JBoss EAP uygulaması için veri kaynaklarını yapılandırma.

Alternatif olarak, App Service'i başlangıçta herhangi bir dosyayı çalıştıracak şekilde el ile yapılandırabilirsiniz. Örneğin:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Çalıştırabileceğiniz CLI komutları hakkında daha fazla bilgi için bkz:

Kümeleme

App Service, JBoss EAP sürüm 7.4.1 ve üzeri için kümeleme desteği sağlar. Kümelemeye olanak tanımak için web uygulamanızın bir sanal ağ ile tümleştirilmesi gerekir. Web uygulaması bir sanal ağ ile tümleştirildiğinde yeniden başlatılır ve JBoss EAP yüklemesi otomatik olarak kümelenmiş bir yapılandırmayla başlar. Otomatik ölçeklendirme ile birden çok örnek çalıştırdığınızda, JBoss EAP örnekleri sanal ağ tümleştirmesinde belirtilen alt ağ üzerinden birbirleriyle iletişim kurar. Herhangi bir değerle adlı WEBSITE_DISABLE_CLUSTERING bir uygulama ayarı oluşturarak kümele oluşturmayı devre dışı bırakabilirsiniz.

Sanal ağa entegre edilmiş JBoss EAP App Service uygulamasının üç örneğe ölçeklendirildiğini gösteren diyagram.

Not

Sanal ağ tümleştirmenizi bir ARM şablonuyla etkinleştiriyorsanız, özelliğini vnetPrivatePorts el ile değerine 2ayarlamanız gerekir. CLI veya portaldan sanal ağ tümleştirmesini etkinleştirirseniz, bu özellik sizin için otomatik olarak ayarlanır.

Kümeleme etkinleştirildiğinde, JBoss EAP örnekleri yeni örnekleri bulmak ve küme bilgilerini (örneğin, küme üyeleri, tanımlayıcıları ve IP adresleri) kalıcı hale getirmek için JGroups bulma protokollerini kullanır FILE_PING . App Service'te bu dosyalar altındadır /home/clusterinfo/. Küme üyeliği dosyasında okuma/yazma izinleri alan ilk başlatılan EAP örneğidir. Diğer örnekler dosyayı okur, birincil düğümü bulur ve kümeye dahil edilecek ve dosyaya eklenecek düğümle eşgüdüm sağlar.

Not

Uygulamanızın başlatılması sırasında eski bulma dosyalarını temizleyerek JBoss EAP kümeleme zaman aşımlarından kaçınabilirsiniz.

Premium V3, Premium V4 ve Yalıtılmış V2 App Service Planı türleri, iş açısından kritik iş yüklerinizin dayanıklılığını ve güvenilirliğini artırmak için isteğe bağlı olarak Kullanılabilirlik Alanları arasında dağıtılabilir. Bu mimari bölge yedekliliği olarak da bilinir. JBoss EAP kümeleme özelliği, alanlar arası yedeklilik özelliğiyle uyumludur.

Otomatik ölçeklendirme kuralları

Yatay ölçeklendirme için otomatik ölçeklendirme kurallarını yapılandırırken, kaldırılan her örneğin etkinliğini (veritabanı işlemini işleme gibi) kümenin başka bir üyesine aktaradığından emin olmak için örnekleri artımlı olarak (birer birer) kaldırmak önemlidir. Portalda otomatik ölçeklendirme kurallarınızı ölçeği azaltacak şekilde yapılandırırken aşağıdaki seçenekleri kullanın:

  • İşlem: "Sayıyı azalt"
  • Soğuma: "5 dakika" veya üzeri
  • Örnek sayısı: 1

Artımlı olarak örnek eklemeniz gerekmez (ölçeği genişletme). Kümeye aynı anda birden çok örnek ekleyebilirsiniz.

App Service planları

JBoss EAP şu fiyatlandırma katmanlarında kullanılabilir: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 ve P5mv4.

JBoss EAP sunucu yaşam döngüsü

App Service'teki bir JBoss EAP uygulaması, sunucuyu başlatmadan önce beş ayrı aşamadan geçer:

  1. Ortam kurulum aşaması
  2. Sunucu başlatma aşaması
  3. Sunucu yapılandırma aşaması
  4. Uygulama dağıtım aşaması
  5. Sunucu yeniden yükleme aşaması

Özelleştirmeye yönelik ayrıntılar ve fırsatlar (uygulama ayarları gibi) için aşağıdaki bölümlere bakın.

1. Ortam kurulum aşaması

  • Kapsayıcı ile güvenli SSH oturumlarını etkinleştirmek için SSH hizmeti başlatılır.
  • Java çalışma zamanı anahtar deposu, Azure portalında tanımlanan tüm genel ve özel sertifikalarla güncelleştirilir.
    • Ortak sertifikalar dizindeki /var/ssl/certs platform tarafından sağlanır ve öğesine $JRE_HOME/lib/security/cacertsyüklenir.
    • Özel sertifikalar dizindeki /var/ssl/private platform tarafından sağlanır ve öğesine $JRE_HOME/lib/security/client.jksyüklenir.
  • Bu adımda Java anahtar deposuna herhangi bir sertifika yüklenirse, , javax.net.ssl.keyStoreve javax.net.ssl.keyStorePassword özellikleri javax.net.ssl.keyStoreTypeortam değişkenine JAVA_OPTS eklenir.
  • Günlük dizinleri ve Java bellek yığını parametreleri gibi bazı ilk JVM yapılandırması belirlenir:
    • Uygulama ayarında bellek için –Xms veya –Xmx bayraklarını ya da JAVA_OPTS sağlarsanız, bu değerler platform tarafından sağlanan değerleri geçersiz kılar.
    • Uygulama ayarını WEBSITES_CONTAINER_STOP_TIME_LIMITyapılandırdığınızda, değer JBoss EAP durdurulduğunda en uzun kapatma bekleme süresini (saniye cinsinden) denetleyen runtime özelliğine org.wildfly.sigterm.suspend.timeoutgeçirilir.
  • Uygulama bir sanal ağ ile tümleştirilmişse, App Service çalışma zamanı ortam değişkeninde WEBSITE_PRIVATE_PORTS sunucular arası iletişim için kullanılacak bağlantı noktalarının listesini geçirir ve yapılandırmayı kullanarak JBoss EAP'yi clustering başlatır. Aksi takdirde standalone yapılandırması kullanılır.
    • Yapılandırma için clustering sunucu yapılandırma dosyası standalone-azure-full-ha.xml kullanılır.
    • Yapılandırma için standalone sunucu yapılandırma dosyası standalone-full.xml kullanılır.

2. Sunucu başlatma aşaması

  • Eğer JBoss EAP clustering yapılandırmasında başlatılırsa:
    • Her bir JBoss EAP örneği, 0 ile uygulamanın genişletildiği örnek sayısı arasında bir iç tanımlayıcı alır.
    • Bu sunucu örneğinin işlem deposu yolunda bazı dosyalar bulunursa (iç tanımlayıcısı kullanılarak), bu sunucu örneği aynı hizmet örneğinin yerini alıyor demektir. Diğer hizmet örneği daha önce kilitlendi ve kaydedilmemiş işlemleri geride bıraktı. Sunucu, bu işlemler üzerindeki çalışmayı sürdürecek şekilde yapılandırılmıştır.
  • JBoss EAP'nin veya clustering yapılandırmasında standalone başlayıp başlamadığına bakılmaksızın, sunucu sürümü 7.4 veya üzeriyse ve çalışma zamanı Java 17 kullanıyorsa, yapılandırma güvenlik için Elytron alt sistemini etkinleştirecek şekilde güncelleştirilir.
  • uygulama ayarını WEBSITE_JBOSS_OPTSyapılandırırsanız, değer JBoss başlatıcı betiğine geçirilir. Bu ayar, JBoss EAP'nin başlatılmasını etkileyen özellik dosyalarının ve daha fazla bayrağın yollarını sağlamak için kullanılabilir.

3. Sunucu yapılandırma aşaması

  • Bu aşamanın başlangıcında App Service, devam etmeden önce hem JBoss EAP sunucusunun hem de yönetici arabiriminin istekleri almaya hazır olmasını bekler. Application Insights etkinleştirilirse bu işlem birkaç saniye daha sürebilir.

  • Hem JBoss EAP Sunucusu hem de yönetici arabirimi hazır olduğunda App Service aşağıdaki eylemleri gerçekleştirir:

    • App Service ile günlüğe kaydetme ve tümleştirme için yardımcı program sınıfları sağlayan JBoss EAP modülünü azure.appserviceekler.
    • Konsol günlükçüsünün renksiz mod kullanacak şekilde güncelleştirilmesi, günlük dosyalarının renk kaçamak dizileriyle dolu olmasını sağlar.
    • Azure İzleyici günlükleriyle entegrasyonu kurar.
    • Web Hizmetleri Açıklama Dili (WSDL) ve yönetim arabirimlerinin bağlama IP adreslerini güncelleştirir.
    • azure.appservice.easyauth ve Microsoft Entra Id ile tümleştirme için JBoss EAP modülünü ekler.
    • Erişim günlüklerinin kaydedilme ayarlarını ve ana sunucu günlük dosyasının adını ve döndürme sıklığını günceller.

  • Uygulama ayarı WEBSITE_SKIP_AUTOCONFIGURE_DATABASE tanımlanmadığı sürece App Service, App Service uygulama ayarlarında Java Veritabanı Bağlantısı (JDBC) URL'lerini otomatik olarak algılar. PostgreSQL, MySQL, MariaDB, Oracle, SQL Server veya Azure SQL Veritabanı için geçerli JDBC URL'leri varsa, ilgili sürücüleri sunucuya ekler, JDBC URL'lerinin her biri için bir veri kaynağı ekler ve her veri kaynağı java:jboss/env/jdbc/<app-setting-name>_DSiçin Java Adlandırma ve Dizin Arabirimi (JNDI) adını olarak ayarlar; burada <app-setting-name> uygulama ayarının adıdır.

  • clustering Yapılandırma etkinleştirilirse, yapılandırılacak konsol günlükçü kontrol edilir.

  • Dizine dağıtılmış JAR dosyaları varsa, bu JAR dosyalarının tümüyle /home/site/libs yeni bir küresel modül oluşturulur.

  • Aşamanın sonunda App Service, varsa özel başlangıç betiğini çalıştırır. Özel başlangıç betiği için arama mantığı aşağıdaki gibi tanımlanır:

    • Bir başlangıç komutu yapılandırdıysanız (örneğin, Azure portalı veya Azure CLI aracılığıyla), komutunu çalıştırın; yoksa
    • Eğer yol /home/site/scripts/startup.sh varsa, kullanın; aksi takdirde,
    • Yol /home/startup.sh var ise kullanın.

Özel başlangıç komutu veya betiği kök kullanıcı olarak çalışır (buna gerek sudoyoktur), bu nedenle Linux paketlerini yükleyebilir veya veri kaynakları oluşturma ve kaynak bağdaştırıcıları yükleme gibi daha fazla JBoss EAP yükleme/özelleştirme komutu gerçekleştirmek için JBoss CLI'yi başlatabilir. Ubuntu paket yönetimi komutları hakkında bilgi için Ubuntu Server belgelerine bakın. JBoss CLI komutları için bkz. JBoss Yönetim CLI Kılavuzu.

4. Uygulama dağıtım aşaması

Başlangıç betiği, öncelik sırasına göre aşağıdaki konumlara bakarak uygulamaları JBoss EAP'ye dağıtır:

  • Uygulama ayarını WEBSITE_JAVA_WAR_FILE_NAME yapılandırdıysanız, onun belirlediği dosyayı dağıtın.
  • Eğer /home/site/wwwroot/app.war varsa, dağıtın.
  • içinde /home/site/wwwrootbaşka EAR ve WAR dosyaları varsa bunları dağıtın.
  • Varsa /home/site/wwwroot/webapps , içindeki dosyaları ve dizinleri dağıtın. WAR dosyaları kendileri uygulama olarak dağıtılırken, dizinler "açık" (sıkıştırılmamış) web uygulamaları olarak dağıtılır.
  • içinde /home/site/wwwroottek başına JSP sayfaları varsa, bunları web sunucusu köküne kopyalayın ve tek bir web uygulaması olarak dağıtın.
  • Dağıtılabilir dosya bulunamazsa varsayılan karşılama sayfasını (park sayfası) kök bağlamda dağıtın.

5. Sunucu yeniden yükleme aşaması

  • Dağıtım adımları tamamlandıktan sonra JBoss EAP sunucusu, sunucunun yeniden yüklenmesini gerektiren değişiklikleri uygulamak için yeniden yüklenir.
  • Sunucu yeniden yüklendikten sonra JBoss EAP sunucusuna dağıtılan uygulamalar isteklere yanıt vermeye hazır olmalıdır.
  • App Service uygulaması durdurulana veya yeniden başlatılana kadar sunucu çalışır. App Service uygulamasını el ile durdurabilir veya yeniden başlatabilir ya da App Service uygulamasında dosya dağıttığınızda veya yapılandırma değişiklikleri yaptığınızda yeniden başlatma tetikleyebilirsiniz.
  • JBoss EAP sunucusu, clustering yapılandırmasında anormal bir şekilde çıkarsa, adlı son işlev emit_alert_tx_store_not_empty yürütülür. İşlev, JBoss EAP işleminin diskte boş bir işlem deposu dosyası bırakıp bırakmadiğini denetler. Bu durumda konsolda bir hata kaydedilir: Error: finishing server with non-empty store for node XXXX. Yeni bir sunucu örneği başlatıldığında, çalışmaya devam etmek için bu hazır olmayan işlem deposu dosyalarını arar (bkz . 2. Sunucu başlatma aşaması).

Tomcat temel yapılandırması

Not

Bu bölüm yalnızca Linux için geçerlidir.

Java geliştiricileri Sunucu ayarlarını özelleştirebilir, sorunları giderebilir ve Tomcat'in server.xml dosyası ve yapılandırma ayrıntılarını biliyorlarsa uygulamaları Güvenle Tomcat'e dağıtabilir. Olası özelleştirmeler şunlardır:

  • Tomcat yapılandırmasını özelleştirme: server.xml dosyasını ve Tomcat'in yapılandırma ayrıntılarını anladığınızda, sunucu ayarlarını uygulamalarının gereksinimlerine uyacak şekilde ayarlayabilirsiniz.
  • Hata ayıklama: Tomcat sunucusunda bir uygulama dağıtıldığında, geliştiricilerin ortaya çıkabilecek sorunların hatalarını ayıklamak için sunucu yapılandırmasını bilmesi gerekir. Bu işlem sunucu günlüklerini denetlemeyi, yapılandırma dosyalarını incelemeyi ve oluşabilecek hataları belirlemeyi içerir.
  • Tomcat sorunlarını giderme: Java geliştiricileri kaçınılmaz olarak Tomcat sunucularında performans sorunları veya yapılandırma hataları gibi sorunlarla karşılaşır. server.xml dosyasını ve Tomcat'in yapılandırma ayrıntılarını anladığınızda, geliştiriciler bu sorunları hızla tanılayabilir ve giderebilir ve bu da zaman ve çabadan tasarruf edebilir.
  • Tomcat'e uygulama dağıtma: Bir Java web uygulamasını Tomcat'e dağıtmak için geliştiricilerin server.xml dosyasını ve diğer Tomcat ayarlarını nasıl yapılandıracaklarını bilmesi gerekir. Uygulamaları başarıyla dağıtmak ve sunucuda sorunsuz çalıştıklarından emin olmak için bu ayrıntıları anlamanız gerekir.

Java iş yükünüzü (WAR dosyası veya JAR dosyası) barındırmak için yerleşik Tomcat ile bir uygulama oluşturduğunuzda, Tomcat yapılandırması için kutudan çıkardığınız bazı ayarlar vardır. Tomcat Web Server için varsayılan yapılandırma da dahil olmak üzere ayrıntılı bilgi için resmi Apache Tomcat belgelerine başvurabilirsiniz.

Buna ek olarak, tomcat dağıtımı için server.xml üzerine başlangıçta uygulanan bazı dönüştürmeler vardır. Bu dönüşümler Bağlayıcı, Konak ve Vana ayarlarında yapılan değişiklikleri içerir.

Tomcat'in en son sürümleri server.xml (8.5.58 ve 9.0.38 ileri) sahiptir. Tomcat'in eski sürümleri dönüşümleri kullanmaz ve sonuç olarak farklı davranışlara sahip olabilir.

Bağlayıcı

<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 olarak ayarlanır 16384.
  • URIEncoding olarak ayarlanır UTF-8.
  • connectionTimeout, WEBSITE_TOMCAT_CONNECTION_TIMEOUT olarak ayarlanır ve varsayılan olarak 240000 ile ayarlanır.
  • maxThreads, WEBSITE_CATALINA_MAXTHREADS olarak ayarlanır ve varsayılan olarak 200 ile ayarlanır.
  • maxConnections, WEBSITE_CATALINA_MAXCONNECTIONS olarak ayarlanır ve varsayılan olarak 10000 ile ayarlanır.

Not

connectionTimeout, maxThreadsve maxConnections ayarları uygulama ayarlarıyla ayarlanabilir.

Aşağıda , connectionTimeoutveya maxThreadsdeğerlerini maxConnectionsdeğiştirmek için kullanabileceğiniz örnek CLI komutları verilmiştir:

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

Bağlayıcı, 127.0.0.1 yerine kapsayıcının adresini kullanır.

Sunucu

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase, AZURE_SITE_APP_BASE olarak ayarlanır ve varsayılan olarak yerel WebappsLocalPath değerini kullanır.
  • xmlBase, AZURE_SITE_HOME olarak ayarlanır ve varsayılan olarak /site/wwwroot ile ayarlanır.
  • unpackWARs, AZURE_UNPACK_WARS olarak ayarlanır ve varsayılan olarak true ile ayarlanır.
  • workDir, JAVA_TMP_DIR olarak ayarlanır ve varsayılanı TMP olur.
  • errorReportValveClass özel hata raporlama vanamızı kullanır.

Supap

<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, AZURE_LOGGING_DIR olarak ayarlanır ve varsayılan olarak home\logFiles ile ayarlanır.
  • maxDays, WEBSITE_HTTPLOGGING_RETENTION_DAYS olarak ayarlanır ve varsayılan olarak 7 ile ayarlanır. Bu değer, uygulama günlüğü platformunun varsayılan değeriyle uyumludur.

Linux'ta tümü aynı özelleştirmeye sahiptir ve vanaya bazı hata ve raporlama sayfaları ekler:

<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>

İlgili içerik

Java Geliştiricileri için Azure merkezini ziyaret ederek Azure hızlı başlangıçlarını, eğitimlerini ve Java referans belgelerini bulabilirsiniz.