مشاركة عبر


نشر وتكوين تطبيق Tomcat أو JBoss أو Java SE في Azure App Service

توضح لك هذه المقالة التكوين الأكثر شيوعا للتوزيع ووقت التشغيل لتطبيقات Java في App Service. إذا لم يسبق لك استخدام Azure App Service، فيجب عليك قراءة التشغيل السريع لـ Java أولاً. تتوفر الإجابة عن الأسئلة العامة حول استخدام App Service غير الخاصة بتطوير Java في الأسئلة المتداولة حول App Service.

تقوم Azure App Service بتشغيل تطبيقات ويب Java على خدمة مدارة بالكامل في ثلاثة متغيرات:

  • Java SE - يمكنه تشغيل تطبيق تم نشره كحزمة JAR تحتوي على خادم مضمن (مثل Spring Boot أو Dropwizard أو Quarkus أو تطبيق مع خادم Tomcat أو Jetty مضمن).
  • Tomcat - يمكن لخادم Tomcat المضمن تشغيل تطبيق تم نشره كحزمة WAR.
  • JBoss EAP - مدعوم لتطبيقات Linux في مستويات التسعير Free وPremium v3 و Isolated v2 فقط. يمكن لخادم JBoss EAP المضمن تشغيل تطبيق تم نشره كحزمة WAR أو EAR.

إشعار

بالنسبة لتطبيقات Spring، نوصي باستخدام Azure Spring Apps. ومع ذلك، لا يزال بإمكانك استخدام Azure App Service كوجهة. راجع إرشادات وجهة حمل عمل Java للحصول على المشورة.

إظهار إصدار Java

لإظهار إصدار Java الحالي، قم بتشغيل الأمر التالي في Cloud Shell:

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

لإظهار كافة إصدارات Java المدعمة، قم بتشغيل الأمر التالي في Cloud Shell:

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

الحصول على إصدار Java في حاوية Linux

للحصول على معلومات إصدار أكثر تفصيلا في حاوية Linux، افتح جلسة SSH مع الحاوية. فيما يلي بعض الأمثلة على ما يمكنك تشغيله.

لعرض إصدار Java في جلسة SSH:

java -version

لعرض إصدار خادم Tomcat في جلسة SSH:

sh /usr/local/tomcat/version.sh

أو، إذا كان خادم Tomcat الخاص بك في موقع مخصص، فابحث version.sh عن مع:

find / -name "version.sh"

لعرض إصدار خادم JBoss في جلسة SSH:

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

لمزيد من المعلومات حول دعم الإصدار، راجع نهج دعم وقت تشغيل لغة خدمة التطبيقات.

توزيع تطبيقك

Build Tools

Maven

باستخدام وظيفة Maven الإضافية لـ Azure Web Apps، يمكنك إعداد مشروع Maven Java لـ Azure Web App بسهولة باستخدام أمر واحد في جذر المشروع:

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

يضيف هذا الأمر مكونا إضافيا azure-webapp-maven-plugin والتكوين ذي الصلة عن طريق مطالبتك بتحديد Azure Web App موجود أو إنشاء واحد جديد. أثناء التكوين، يحاول اكتشاف ما إذا كان يجب نشر التطبيق الخاص بك إلى Java SE أو Tomcat أو (Linux فقط) JBoss EAP. بعد ذلك، يمكنك توزيع تطبيق Java إلى Azure باستخدام الأمر التالي:

mvn package azure-webapp:deploy

فيما يلي نموذج تكوين في pom.xml:

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

Gradle

  1. إعداد المكون الإضافي Gradle لتطبيقات ويب Azure عن طريق إضافة المكون الإضافي إلى build.gradle:

    plugins {
      id "com.microsoft.azure.azurewebapp" version "1.10.0"
    }
    
  2. تكوين تفاصيل تطبيق الويب الخاص بك. يتم إنشاء موارد Azure المقابلة إذا لم تكن موجودة. فيما يلي نموذج تكوين، للحصول على التفاصيل، راجع هذا المستند.

    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. توزيع باستخدام أمر واحد.

    gradle azureWebAppDeploy
    

IDEs

يوفر Azure تجربة تطوير سلسة لـ Java App Service في Java IDEs الشائعة، بما في ذلك:

واجهة برمجة تطبيقات Kudu

لتوزيع ملفات .jar إلى Java SE، استخدم نقطة نهاية /api/publish لموقع Kudu. لمزيد من المعلومات حول واجهة برمجة التطبيقات هذه، راجع هذه الوثائق.

إشعار

يجب تسمية تطبيق .jar لـ App Service بـ app.jar، لتحديد التطبيق وتشغيله. يقوم المكون الإضافي Maven بذلك تلقائيا أثناء النشر. إذا كنت لا ترغب في إعادة تسمية JAR الخاص بك إلى app.jar، يمكنك تحميل برنامج نصي shell باستخدام الأمر لتشغيل تطبيق .jar. الصق المسار المطلق لهذا البرنامج النصي في مربع نص ملف بدء التشغيل في المقطع "التكوين" بالمدخل. لا يتم تشغيل البرنامج النصي لبدء التشغيل من الدليل الذي تم وضعه فيه. لذلك، يجب عليك دائماً استخدام المسارات المطلقة للإشارة إلى الملفات في البرنامج النصي لبدء التشغيل (على سبيل المثال: java -jar /home/myapp/myapp.jar).

لتوزيع ملفات .war إلى Tomcat، استخدم نقطة نهاية /api/wardeploy/ لنشر ملف الأرشيف. لمزيد من المعلومات حول واجهة برمجة التطبيقات هذه، راجع هذه الوثائق.

لتوزيع ملفات .war إلى Tomcat، استخدم نقطة نهاية /api/wardeploy/ لنشر ملف الأرشيف. لمزيد من المعلومات حول واجهة برمجة التطبيقات هذه، راجع هذه الوثائق.

لتوزيع ملفات .ear، استخدم FTP. يتم نشر تطبيق .ear الخاص بك إلى جذر السياق المحدد في تكوين التطبيق الخاص بك. على سبيل المثال، إذا كان جذر سياق تطبيقك هو <context-root>myapp</context-root>، يمكنك استعراض الموقع في المسار /myapp: http://my-app-name.azurewebsites.net/myapp. إذا كنت تريد تقديم تطبيق الويب الخاص بك في المسار الجذر، فتأكد من أن تطبيقك يعين جذر السياق إلى المسار الجذر: <context-root>/</context-root>. لمزيد من المعلومات، راجع تعيين جذر السياق لتطبيق ويب.

لا تنشر .war أو .jar باستخدام FTP. تم تصميم أداة FTP لتحميل البرامج النصية لبدء التشغيل أو التبعيات أو ملفات وقت التشغيل الأخرى. إنه ليس الخيار الأمثل لنشر تطبيقات الويب.

إعادة كتابة عنوان URL أو إعادة توجيهه

لإعادة كتابة عنوان URL أو إعادة توجيهه، استخدم إحدى عمليات إعادة كتابة عنوان URL المتوفرة، مثل UrlRewriteFilter.

يوفر Tomcat أيضا صماما لإعادة الكتابة.

JBoss يوفر أيضا صمام إعادة الكتابة.

التسجيل وتتبع أخطاء التطبيقات

تتوفر تقارير الأداء ومرئيات نسبة استخدام الشبكة وفحوصات السلامة لكل تطبيق من خلال مدخل Azure. لمزيد من المعلومات، راجع نظرة عامة على تشخيصات Azure App Service.

دفق سجلات التشخيص

يمكنك الوصول إلى سجلات وحدة التحكم المنشأة من داخل الحاوية.

أولًا، قم بتشغيل تسجيل الحاويات عن طريق تشغيل الأمر التالي:

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

استبدل <app-name> و<resource-group-name> بالأسماء المناسبة لتطبيق الويب الخاص بك.

بمجرد تشغيل تسجيل الحاويات، قم بتشغيل الأمر التالي لمشاهدة تدفق السجل:

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

وفي حال عدم رؤية سجلات وحدة التحكم على الفور، فتحقق مجددًا في غضون 30 ثانية.

لإيقاف دفق السجل في أي وقت، اكتب Ctrl+C.

يمكنك أيضًا فحص ملفات السجل من المتصفح الموجود في https://<app-name>.scm.azurewebsites.net/api/logs/docker.

لمزيد من المعلومات، راجع سجلات Stream في Cloud Shell.

الوصول إلى وحدة تحكم SSH في Linux

لفتح جلسة SSH مباشرة مع حاويتك، يجب أن يكون تطبيقك قيد التشغيل.

الصق عنوان URL التالي في المتصفح واستبدله<app-name> باسم التطبيق:

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

إذا لم تتم مصادقتكَ بعد، يجب عليك المصادقة باستخدام اشتراك Azure للاتصال. بمجرد المصادقة، سترى shell في المستعرض، حيث يمكنك تشغيل الأوامر داخل حاويتك.

اتصال SSH

إشعار

تخزن أي تغييرات تقوم بها خارج الدليل /home في الحاوية نفسها ولا تستمر بعد إعادة تشغيل التطبيق.

لفتح جلسة SSH بعيدة من الجهاز المحلي، راجعجلسة SSH المفتوحة من واجهة بعيدة.

أدوات استكشاف أخطاء Linux وإصلاحها

تستند صور Java المضمَّنة إلى نظام التشغيل Alpine Linux. استخدم مدير حزمة apk لتثبيت أي أدوات أو أوامر لاستكشاف الأخطاء وإصلاحها.

محلل ملفات تعريف Java

تأتي جميع أوقات تشغيل Java على Azure App Service مع مسجل JDK Flight Recorder لإنشاء ملفات تعريف لأحمال عمل Java. يمكنك استخدامه لتسجيل أحداث JVM والنظام والتطبيق واستكشاف المشكلات وإصلاحها في تطبيقاتك.

لمعرفة المزيد حول محلل ملفات تعريف Java، تفضل بزيارة وثائق Azure Application Insights.

Flight Recorder

تأتي جميع أوقات تشغيل Java على App Service مع مسجل Java Flight Recorder. يمكنك استخدامه لتسجيل أحداث JVM والنظام والتطبيق واستكشاف المشكلات وإصلاحها في تطبيقات Java الخاصة بك.

استخدم SSH في App Service وقم بتشغيل الأمر jcmd لعرض قائمة بجميع عمليات Java قيد التشغيل. بالإضافة إلى jcmd نفسه، يجب أن تشاهد تطبيق Java الخاص بك يعمل برقم معرف العملية (pid).

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

تنفيذ الأمر التالي لبدء تسجيل 30 ثانية من JVM. يقوم بملفات تعريف JVM وإنشاء ملف JFR يسمى jfr_example.jfr في الدليل الرئيسي. (استبدل 116 برقم معرِّف العملية لتطبيق Java.)

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

أثناء الفاصل الزمني الذي مدته 30 ثانية، يمكنك التحقق من صحة التسجيل عن طريق تشغيل jcmd 116 JFR.check. يعرض الأمر جميع التسجيلات لعملية Java المحددة.

تسجيل مستمر

يمكنك استخدام Java Flight Recorder لملفات تعريف تطبيق Java الخاص بك باستمرار بأقل تأثير على أداء وقت التشغيل. لفعل ذلك، قم بتشغيل أمر Azure CLI التالي لإنشاء إعداد تطبيق يسمى JAVA_OPTS باستخدام التكوين الضروري. يتم تمرير محتويات إعداد التطبيق JAVA_OPTS إلى الأمر java عند بدء تشغيل تطبيقك.

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

بمجرد بدء التسجيل، يمكنك تفريغ بيانات التسجيل الحالية في أي وقت باستخدام JFR.dump الأمر .

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

تحليل ملفات .jfr

استخدم FTPS لتنزيل ملف JFR إلى جهازك المحلي. لتحليل ملف JFR، قم بتنزيل وتثبيت Java Mission Control. للحصول على إرشادات حول Java Mission Control، راجع وثائق JMC وإرشادات التثبيت.

سجل التطبيق

يمكنك تمكين سجل التطبيق من خلال مدخل Azure أو Azure CLI لتكوين App Service لكتابة إخراج وحدة التحكم القياسية لتطبيقك ودفق أخطاء وحدة التحكم القياسية إلى نظام الملفات المحلي أو Azure Blob Storage. إذا كنت بحاجة إلى استبقاء البيانات فترة أطول، فقم بتكوين التطبيق لكتابة الإخراج في حاوية تخزين Blob.

يمكن العثور على سجلات تطبيق Java وTomcat في دليل /home/LogFiles/Application/.

يمكن تكوين تسجيل Azure Blob Storage للتطبيقات المستندة إلى Linux فقط باستخدام Azure Monitor.

إذا كان تطبيقك يستخدم Logback أو Log4j للتتبع، يمكنك إعادة توجيه هذه التتبعات للمراجعة إلى Azure Application Insights باستخدام إرشادات تكوين إطار التسجيل في استكشاف سجلات تتبع Java في Application Insights.

إشعار

بسبب وجود الثغرة الأمنية المعروفة CVE-2021-44228، يجب استخدام Log4j الإصدار 2.16 أو الأحدث.

التخصيص والضبط

تدعم Azure App Service الضبط والتخصيص خارج الأطر النمطية من خلال مدخل Azure وCLI. راجع المقالات التالية لتكوين تطبيق ويب محدد غير مرتبط بـ Java:

نسخ محتوى التطبيق محليا

قم بتعيين إعداد JAVA_COPY_ALL التطبيق إلى true لنسخ محتويات التطبيق إلى العامل المحلي من نظام الملفات المشتركة. يساعد هذا الإعداد في معالجة مشكلات تأمين الملفات.

تعيين خيارات وقت تشغيل Java

لتعيين ذاكرة مخصصة أو خيارات وقت تشغيل JVM الأخرى، أنشئ إعداد تطبيق باسم JAVA_OPTS مع الخيارات. يمرر App Service هذا الإعداد باعتباره متغير بيئة إلى وقت تشغيل Java عند بدء تشغيله.

في مدخل Microsoft Azure، ضمن Application Settings لتطبيق الويب، قم بإنشاء إعداد تطبيق جديد باسم JAVA_OPTS يتضمن إعدادات أخرى، مثل -Xms512m -Xmx1204m.

في مدخل Microsoft Azure، ضمن Application Settings لتطبيق الويب، قم بإنشاء إعداد تطبيق جديد باسم CATALINA_OPTS يتضمن إعدادات أخرى، مثل -Xms512m -Xmx1204m.

لتكوين إعداد التطبيق من وظيفة Maven الإضافية، أضف علامات القيمة/الإعداد في مقطع الوظيفة الإضافية في Azure. يعين المثال التالي حداً أدنى وحداً أقصى محددين لحجم كومة الذاكرة المؤقتة لـ Java:

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

إشعار

لا تحتاج إلى إنشاء ملف web.config عند استخدام Tomcat على خدمة تطبيقات Windows.

يمكن للمطورين الذين يستخدمون تطبيقاً واحداً مع فتحة توزيع واحدة في خطة App Service استخدام الخيارات التالية:

  • مثيلات B1 وS1: -Xms1024m -Xmx1024m
  • مثيلات B2 وS2: -Xms3072m -Xmx3072m
  • مثيلات B3 وS3: -Xms6144m -Xmx6144m
  • مثيلات P1v2: -Xms3072m -Xmx3072m
  • مثيلات P2v2: -Xms6144m -Xmx6144m
  • مثيلات P3v2: -Xms12800m -Xmx12800m
  • مثيلات P1v3: -Xms6656m -Xmx6656m
  • مثيلات P2v3: -Xms14848m -Xmx14848m
  • مثيلات P3v3: -Xms30720m -Xmx30720m
  • مثيلات I1: -Xms3072m -Xmx3072m
  • مثيلات I2: -Xms6144m -Xmx6144m
  • مثيلات I3 : -Xms12800m -Xmx12800m
  • مثيلات I1v2: -Xms6656m -Xmx6656m
  • مثيلات I2v2: -Xms14848m -Xmx14848m
  • مثيلات I3v2: -Xms30720m -Xmx30720m

عند ضبط إعدادات كومة ذاكرة مؤقتة للتطبيق، راجع تفاصيل خطة App Service، مع مراعاة احتياجات العديد من التطبيقات وفتحة التوزيع للعثور على التخصيص الأمثل للذاكرة.

تشغيل مآخذ توصيل الويب

يمكنك تشغيل دعم مآخذ الويب في مدخل Azure من إعدادات التطبيق للتطبيق. تحتاج إلى إعادة تشغيل التطبيق حتى يصبح الإعداد ساري المفعول.

قم بتشغيل دعم مأخذ توصيل الويب باستخدام Azure CLI باستخدام الأمر التالي:

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

بعد ذلك، أعد تشغيل تطبيقك:

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

تعيين ترميز الأحرف الافتراضي

في مدخل Azure، أسفل إعدادات التطبيق لتطبيق الويب، أنشئ إعداد تطبيق جديداً بالاسم JAVA_OPTS باستخدام القيمة -Dfile.encoding=UTF-8.

أو بدلاً من ذلك، يمكنك تكوين إعداد التطبيق باستخدام وظيفة Maven الإضافية لـ App Service. أضف اسم الإعداد وعلامات القيم في تكوين الوظيفة الإضافية:

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

التحويل البرمجي المسبق لملفات JSP

لتحسين أداء تطبيقات Tomcat، يمكنك إجراء تحويل برمجي لملفات JSP قبل التوزيع إلى App Service. يمكنك استخدام وظيفة Maven الإضافية التي توفرها Apache Sling، أو استخدام ملف بنية Ant هذا.

robots933456 في السجلات

قد تشاهد الرسالة التالية في سجلات الحاوية:

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

يمكنك تجاهل هذه الرسالة بأمان. /robots933456.txt هو مسار عنوان URL وهمي يستخدم "خدمة التطبيقات" للتحقق من إمكانية تقديم الحاوية "طلبات". يُشير رد 404 ببساطة إلى أن المسار غير موجود، ولكنه يتيح لـ"خدمة التطبيقات" معرفة أن الحاوية سليمة وجاهزة للاستجابة للطلبات.

اختيار إصدار وقت تشغيل Java

تسمح App Service للمستخدمين باختيار الإصدار الرئيسي من JVM، مثل Java 8 أو Java 11، وإصدار التصحيح، مثل 1.8.0_232 أو 11.0.5. يمكنك أيضاً اختيار تحديث إصدار التصحيح تلقائياً بينما تتوفر إصدارات ثانوية جديدة. في معظم الحالات، يجب أن تستخدم تطبيقات الإنتاج إصدارات JVM التصحيحية مثبتة. يمنع هذا الانقطاعات غير المتوقعة أثناء التحديث التلقائي لإصدار التصحيح. تستخدم جميع تطبيقات الويب Java JVMs 64 بت، وهي غير قابلة للتكوين.

إذا كنت تستخدم Tomcat، يمكنك اختيار تثبيت إصدار التصحيح من Tomcat. في نظام التشغيل Windows، يمكنك تثبيت إصدارات التصحيح من JVM وTomcat كل على حدة. على Linux، يمكنك تثبيت إصدار التصحيح من Tomcat؛ يتم أيضا تثبيت إصدار التصحيح من JVM ولكنه غير قابل للتكوين بشكل منفصل.

إذا اخترت تثبيت الإصدار الثانوي، فستحتاج إلى تحديث الإصدار الثانوي ل JVM بشكل دوري على التطبيق. للتأكد من تشغيل التطبيق الخاص بك على الإصدار الثانوي الأحدث، قم بإنشاء فتحة التقسيم المرحلي و زيادة الإصدار الثانوي على فتحة التقسيم المرحلي. بمجرد تأكيد تشغيل التطبيق بشكل صحيح على الإصدار الثانوي الجديد، يمكنك تبديل فتحات التشغيل المرحلي والإنتاج.

تشغيل JBoss CLI

في جلسة عمل SSH لتطبيق JBoss، يمكنك تشغيل JBoss CLI باستخدام الأمر التالي:

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

اعتمادا على مكان تواجد JBoss في دورة حياة الخادم، قد لا تتمكن من الاتصال. انتظر بضع دقائق وحاول مرة أخرى. هذا الأسلوب مفيد لإجراء عمليات فحص سريعة لحالة الخادم الحالي (على سبيل المثال، لمعرفة ما إذا كان مصدر البيانات قد تم تكوينه بشكل صحيح).

أيضا، لا تستمر التغييرات التي تجريها على الخادم باستخدام JBoss CLI في جلسة SSH بعد إعادة تشغيل التطبيق. في كل مرة يبدأ فيها التطبيق، يبدأ خادم JBoss EAP بتثبيت نظيف. أثناء دورة حياة بدء التشغيل، تقوم App Service بإجراء تكوينات الخادم الضرورية ونشر التطبيق. لإجراء أي تغييرات مستمرة في خادم JBoss، استخدم برنامج نصي مخصص لبدء التشغيل أو أمر بدء تشغيل. للحصول على مثال شامل، راجع تكوين مصادر البيانات لتطبيق Tomcat أو JBoss أو Java SE في Azure App Service.

بدلا من ذلك، يمكنك تكوين App Service يدويا لتشغيل أي ملف عند بدء التشغيل. على سبيل المثال:

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

لمزيد من المعلومات حول أوامر CLI التي يمكنك تشغيلها، راجع:

تكوين أنظمة المجموعات

تدعم App Service تكوين أنظمة المجموعات لإصدارات JBoss EAP 7.4.1 والإصدارات الأحدث. لتمكين تكوين أنظمة المجموعات، يجب دمج تطبيق الويب لديك مع شبكة ظاهرية. عند دمج تطبيق الويب مع شبكة ظاهرية، يتم إعادة تشغيله، ويبدأ تثبيت JBoss EAP تلقائيا بتكوين متفاوت المسافات. عند تشغيل مثيلات متعددة مع التحجيم التلقائي، تتواصل مثيلات JBoss EAP مع بعضها البعض عبر الشبكة الفرعية المحددة في تكامل الشبكة الظاهرية. يمكنك تعطيل تكوين أنظمة المجموعات عن طريق إنشاء إعداد تطبيق بالاسم WEBSITE_DISABLE_CLUSTERING باستخدام أي قيمة.

رسم تخطيطي يوضح تطبيق JBoss App Service المتكامل من vnet، تم توسيع نطاقه إلى ثلاثة مثيلات.

إشعار

إذا كنت تقوم بتمكين تكامل الشبكة الظاهرية مع قالب ARM، فستحتاج إلى تعيين الخاصية vnetPrivatePorts يدويا إلى قيمة 2. إذا قمت بتمكين تكامل الشبكة الظاهرية من CLI أو المدخل، يتم تعيين هذه الخاصية لك تلقائيا.

عند تمكين تكوين أنظمة المجموعات، تستخدم مثيلات JBoss EAP بروتوكول اكتشاف FILE_PING JGroups لاكتشاف مثيلات جديدة والمحافظة على معلومات نظام المجموعة مثل، أعضاء نظام المجموعة ومعرفاتهم وعناوين IP الخاصة بهم. في App Service، يمكنك العثور على هذه الملفات ضمن /home/clusterinfo/. يحصل مثيل EAP الأول الذي يبدأ على أذونات القراءة/الكتابة على ملف عضوية نظام المجموعة. تقرأ مثيلات أخرى الملف، وتبحث عن العقدة الأساسية، وتنسق مع تلك العقدة لتضمينها في نظام المجموعة وإضافتها إلى الملف.

إشعار

يمكنك تجنب مهلات تجميع JBoss عن طريق تنظيف ملفات الاكتشاف القديمة أثناء بدء تشغيل التطبيق.

يمكن توزيع نوعي خطة App Service ‏Premium V3 وIsolated V2، عبر مناطق التوفر لتحسين المرونة والوثوقية لأحمال العمل الحرجة لأعمالك. تُعرف هذه البنية أيضاً باسم التكرار عبر المناطق. تتوافق ميزة تجميع JBoss EAP مع ميزة تكرار المنطقة.

قواعد التحجيم التلقائي

عند تكوين قواعد التحجيم التلقائي للتحجيم الأفقي، من المهم إزالة المثيلات بشكل متزايد (واحد في كل مرة) للتأكد من أن كل مثيل تمت إزالته يمكنه نقل نشاطه (مثل معالجة معاملة قاعدة بيانات) إلى عضو آخر في المجموعة. عند تكوين قواعد التحجيم التلقائي في المدخل لتقليل الحجم، استخدم الخيارات التالية:

  • الإجراء: "تقليل العدد بمقدار"
  • تهدئة: "5 دقائق" أو أكبر
  • عدد المثيلات: 1

لا تحتاج إلى إضافة مثيلات بشكل متزايد (توسيع النطاق)، يمكنك إضافة مثيلات متعددة إلى نظام المجموعة في كل مرة.

الخطط الخاصة بـ App Service

يتوفر JBoss EAP في مستويات التسعير التالية: F1 وP0v3 وP1mv3 وP2mv3 وP3mv3 وP4mv3 وP5mv3.

دورة حياة خادم JBoss

يمر تطبيق JBoss EAP في App Service بخمس مراحل مميزة قبل تشغيل الخادم فعليا.

راجع الأقسام المعنية أدناه للحصول على التفاصيل بالإضافة إلى فرص تخصيصها (مثل من خلال إعدادات التطبيق).

1. مرحلة إعداد البيئة

  • يتم بدء تشغيل خدمة SSH لتمكين جلسات SSH الآمنة مع الحاوية.
  • يتم تحديث Keystore لوقت تشغيل Java بأي شهادات عامة وخاصة محددة في مدخل Microsoft Azure.
    • يتم توفير الشهادات العامة بواسطة النظام الأساسي في الدليل /var/ssl/certs ، ويتم تحميلها إلى $JRE_HOME/lib/security/cacerts.
    • يتم توفير الشهادات الخاصة بواسطة النظام الأساسي في الدليل /var/ssl/private ، ويتم تحميلها إلى $JRE_HOME/lib/security/client.jks.
  • إذا تم تحميل أي شهادات في مخزن مفاتيح Java في هذه الخطوة، تتم إضافة الخصائص javax.net.ssl.keyStoreو javax.net.ssl.keyStorePasswordjavax.net.ssl.keyStoreType إلى JAVA_TOOL_OPTIONS متغير البيئة.
  • يتم تحديد بعض تكوين JVM الأولي مثل دلائل التسجيل ومعلمات كومة ذاكرة Java:
    • إذا قمت بتوفير –Xms علامات أو –Xmx للذاكرة في إعداد JAVA_OPTSالتطبيق ، فإن هذه القيم تتجاوز تلك التي يوفرها النظام الأساسي.
    • إذا قمت بتكوين إعداد WEBSITES_CONTAINER_STOP_TIME_LIMITالتطبيق ، يتم تمرير القيمة إلى خاصية org.wildfly.sigterm.suspend.timeoutوقت التشغيل ، والتي تتحكم في الحد الأقصى لوقت انتظار إيقاف التشغيل (بالثوان) عند إيقاف JBoss.
  • إذا تم دمج التطبيق مع شبكة ظاهرية، يمرر وقت تشغيل App Service قائمة بالمنافذ لاستخدامها للاتصال بين الخوادم في متغير WEBSITE_PRIVATE_PORTS البيئة وتشغيل JBoss باستخدام clustering التكوين. وإلا، standalone يتم استخدام التكوين.
    • للتكوين clustering ، يتم استخدام ملف تكوين الخادم standalone-azure-full-ha.xml .
    • للتكوين standalone ، يتم استخدام ملف تكوين الخادم standalone-full.xml .

2. مرحلة تشغيل الخادم

  • إذا تم تشغيل JBoss في clustering التكوين:
    • يتلقى كل مثيل JBoss معرفا داخليا بين 0 وعدد المثيلات التي تم توسيع نطاق التطبيق إليها.
    • إذا تم العثور على بعض الملفات في مسار مخزن المعاملات لمثيل الخادم هذا (باستخدام المعرف الداخلي الخاص به)، فهذا يعني أن مثيل الخادم هذا يأخذ مكان مثيل خدمة متطابق تعطل سابقا وترك المعاملات غير الملتزم بها خلفه. تم تكوين الخادم لاستئناف العمل على هذه المعاملات.
  • بغض النظر عما إذا كان JBoss يبدأ في clustering أو standalone التكوين، إذا كان إصدار الخادم هو 7.4 أو أعلى ويستخدم وقت التشغيل Java 17، تحديث التكوين لتمكين النظام الفرعي Elytron للأمان.
  • إذا قمت بتكوين إعداد WEBSITE_JBOSS_OPTSالتطبيق ، يتم تمرير القيمة إلى البرنامج النصي لمشغل JBoss. يمكن استخدام هذا الإعداد لتوفير مسارات لملفات الخصائص والمزيد من العلامات التي تؤثر على بدء تشغيل JBoss.

3. مرحلة تكوين الخادم

  • في بداية هذه المرحلة، تنتظر App Service أولا أن يكون كل من خادم JBoss وواجهة المسؤول جاهزة لتلقي الطلبات قبل المتابعة. قد يستغرق هذا بضع ثوان إضافية إذا تم تمكين Application Insights.
  • عندما يكون كل من خادم JBoss وواجهة المسؤول جاهزة، تقوم App Service بتنفيذ ما يلي:
    • يضيف وحدة JBoss ، azure.appserviceالتي توفر فئات أدوات مساعدة للتسجيل والتكامل مع App Service.
    • يحدث مسجل وحدة التحكم لاستخدام وضع بدون لون بحيث لا تمتلئ ملفات السجل بتسلسلات إلغاء الألوان.
    • إعداد التكامل مع سجلات Azure Monitor.
    • تحديث عناوين IP الملزمة لواجهة WSDL والإدارة.
    • إضافة وحدة azure.appservice.easyauth JBoss للتكامل مع مصادقة App Service ومعرف Microsoft Entra.
    • يحدث تكوين تسجيل سجلات الوصول واسم ملف سجل الخادم الرئيسي وتدارته.
  • ما لم يتم تعريف إعداد WEBSITE_SKIP_AUTOCONFIGURE_DATABASE التطبيق، تقوم App Service تلقائيا بكشف عناوين URL ل JDBC في إعدادات تطبيق App Service. إذا كانت عناوين URL JDBC صالحة ل PostgreSQL أو MySQL أو MariaDB أو Oracle أو SQL Server أو قاعدة بيانات Azure SQL، فإنه يضيف برنامج التشغيل (برامج) التشغيل المقابلة إلى الخادم ويضيف مصدر بيانات لكل عنوان URL ل JDBC ويعين اسم JNDI لكل مصدر بيانات إلى java:jboss/env/jdbc/<app-setting-name>_DS، حيث <app-setting-name> هو اسم إعداد التطبيق.
  • clustering إذا تم تمكين التكوين، يتم التحقق من مسجل وحدة التحكم الذي سيتم تكوينه.
  • إذا كانت هناك ملفات JAR تم نشرها في الدليل /home/site/libs ، يتم إنشاء وحدة نمطية عمومية جديدة مع جميع ملفات JAR هذه.
  • في نهاية المرحلة، تقوم App Service بتشغيل البرنامج النصي لبدء التشغيل المخصص، إذا كان موجودا. منطق البحث للبرنامج النصي لبدء التشغيل المخصص كما يلي:
    • إذا قمت بتكوين أمر بدء تشغيل (في مدخل Microsoft Azure، باستخدام Azure CLI، وما إلى ذلك)، فقم بتشغيله؛ خلاف ذلك
    • إذا كان المسار /home/site/scripts/startup.sh موجودا، فاستخدمه؛ وإلا،
    • إذا كان المسار /home/startup.sh موجودا، فاستخدمه.

يتم تشغيل أمر بدء التشغيل المخصص أو البرنامج النصي كمستخدم جذر (لا حاجة ل sudo)، حتى يتمكنوا من تثبيت حزم Linux أو تشغيل JBoss CLI لتنفيذ المزيد من أوامر تثبيت/تخصيص JBoss (إنشاء مصادر البيانات، وتثبيت محولات الموارد)، وما إلى ذلك. للحصول على معلومات حول أوامر إدارة حزمة Ubuntu، راجع وثائق خادم Ubuntu. للحصول على أوامر JBoss CLI، راجع دليل JBoss Management CLI.

4. مرحلة نشر التطبيق

ينشر البرنامج النصي لبدء التشغيل التطبيقات إلى JBoss من خلال البحث في المواقع التالية، بترتيب الأسبقية:

  • إذا قمت بتكوين إعداد WEBSITE_JAVA_WAR_FILE_NAMEالتطبيق، فوزع الملف المعين من قبله.
  • إذا كان /home/site/wwwroot/app.war موجودا، فوزعه.
  • إذا كان هناك أي ملفات EAR و WAR أخرى في /home/site/wwwroot، فوزعها.
  • إذا كان /home/site/wwwroot/webapps موجودا، فوزع الملفات والدلائل فيه. يتم نشر ملفات WAR كتطبيقات نفسها، ويتم نشر الدلائل كتطبيقات ويب "مفجرة" (غير مضغوطة).
  • إذا كانت هناك أي صفحات JSP مستقلة في /home/site/wwwroot، فانسخها إلى جذر خادم الويب وانشرها كتطبيق ويب واحد.
  • إذا لم يتم العثور على ملفات قابلة للنشر بعد، فوزع صفحة الترحيب الافتراضية (صفحة وقوف السيارات) في سياق الجذر.

5. مرحلة إعادة تحميل الخادم

  • بمجرد اكتمال خطوات النشر، تتم إعادة تحميل خادم JBoss لتطبيق أي تغييرات تتطلب إعادة تحميل الخادم.
  • بعد إعادة تحميل الخادم، يجب أن يكون التطبيق (التطبيقات) المنشورة على خادم JBoss EAP جاهزا للاستجابة للطلبات.
  • يتم تشغيل الخادم حتى يتم إيقاف تطبيق App Service أو إعادة تشغيله. يمكنك إيقاف تطبيق App Service أو إعادة تشغيله يدويا، أو تشغيل إعادة التشغيل عند نشر الملفات أو إجراء تغييرات التكوين على تطبيق App Service.
  • إذا خرج خادم JBoss بشكل غير طبيعي في clustering التكوين، يتم تنفيذ دالة نهائية تسمى emit_alert_tx_store_not_empty . تتحقق الدالة من ترك عملية JBoss لملف مخزن معاملات غير مرن في القرص؛ إذا كان الأمر كذلك، يتم تسجيل خطأ في وحدة التحكم: Error: finishing server with non-empty store for node XXXX. عند بدء تشغيل مثيل خادم جديد، فإنه يبحث عن ملفات مخزن المعاملات غير الضرورية هذه لاستئناف العمل (راجع 2. مرحلة تشغيل الخادم).

تكوين أساس Tomcat

إشعار

ينطبق هذا القسم على Linux فقط.

يمكن لمطوري Java تخصيص إعدادات الخادم واستكشاف المشكلات وإصلاحها ونشر التطبيقات إلى Tomcat بثقة إذا كانوا يعرفون عن ملف server.xml وتفاصيل التكوين الخاصة ب Tomcat. تتضمن التخصيصات المحتملة ما يلي:

  • تخصيص تكوين Tomcat: من خلال فهم ملف server.xml وتفاصيل تكوين Tomcat، يمكنك ضبط إعدادات الخادم لمطابقة احتياجات تطبيقاتها.
  • تصحيح الأخطاء: عند نشر تطبيق على خادم Tomcat، يحتاج المطورون إلى معرفة تكوين الخادم لتصحيح أي مشكلات قد تنشأ. يتضمن ذلك التحقق من سجلات الخادم، وفحص ملفات التكوين، وتحديد أي أخطاء قد تحدث.
  • استكشاف مشكلات Tomcat وإصلاحها: يواجه مطورو Java حتما مشكلات في خادم Tomcat الخاص بهم، مثل مشكلات الأداء أو أخطاء التكوين. من خلال فهم ملف server.xml وتفاصيل تكوين Tomcat، يمكن للمطورين تشخيص هذه المشكلات واستكشافها وإصلاحها بسرعة، ما يمكن أن يوفر الوقت والجهد.
  • نشر التطبيقات إلى Tomcat: لنشر تطبيق ويب Java إلى Tomcat، يحتاج المطورون إلى معرفة كيفية تكوين ملف server.xml وإعدادات Tomcat الأخرى. يعد فهم هذه التفاصيل أمرا ضروريا لنشر التطبيقات بنجاح وضمان تشغيلها بسلاسة على الخادم.

عند إنشاء تطبيق مع Tomcat مضمن لاستضافة حمل عمل Java (ملف WAR أو ملف JAR)، هناك إعدادات معينة يمكنك الخروج منها لتكوين Tomcat. يمكنك الرجوع إلى وثائق Apache Tomcat الرسمية للحصول على معلومات مفصلة، بما في ذلك التكوين الافتراضي ل Tomcat Web Server.

بالإضافة إلى ذلك، هناك بعض التحويلات التي يتم تطبيقها بشكل أكبر أعلى server.xml لتوزيع Tomcat عند البدء. هذه هي التحويلات إلى إعدادات الموصل والمضيف والصمامات.

أحدث إصدارات Tomcat لها server.xml (8.5.58 و9.0.38 فصاعدا). لا تستخدم الإصدارات القديمة من Tomcat التحويلات وقد يكون لها سلوك مختلف نتيجة لذلك.

الموصل

<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 تم تعيين إلى 16384
  • URIEncoding تم تعيين إلى UTF-8
  • connectionTimeout يتم تعيين إلى WEBSITE_TOMCAT_CONNECTION_TIMEOUT، الذي يتم تعيينه افتراضيا إلى 240000
  • maxThreads يتم تعيين إلى WEBSITE_CATALINA_MAXTHREADS، الذي يتم تعيينه افتراضيا إلى 200
  • maxConnections يتم تعيين إلى WEBSITE_CATALINA_MAXCONNECTIONS، الذي يتم تعيينه افتراضيا إلى 10000

إشعار

يمكن ضبط إعدادات connectionTimeout وmaxThreads وmaxConnections مع إعدادات التطبيق

فيما يلي أمثلة لأوامر CLI التي قد تستخدمها لتغيير قيم connectionTimeout أو maxThreads أو maxConnections:

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000
  • يستخدم الموصل عنوان الحاوية بدلا من 127.0.0.1

المضيف

<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، الذي يتم تعيينه افتراضيا إلى محلي WebappsLocalPath
  • xmlBase يتم تعيين إلى AZURE_SITE_HOME، الذي يتم تعيينه افتراضيا إلى /site/wwwroot
  • unpackWARs يتم تعيين إلى AZURE_UNPACK_WARS، الذي يتم تعيينه افتراضيا إلى true
  • workDir يتم تعيين إلى JAVA_TMP_DIR، أي الإعدادات الافتراضية TMP
  • errorReportValveClass يستخدم صمام تقرير الخطأ المخصص

صمام

<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، الذي يتم تعيينه افتراضيا إلى home\logFiles
  • maxDays هو إلى WEBSITE_HTTPLOGGING_RETENTION_DAYS، الذي يتم تعيينه افتراضيا إلى 7. يتوافق هذا مع النظام الأساسي لتسجيل التطبيق الافتراضي

على Linux، يحتوي على كل التخصيص نفسه، بالإضافة إلى:

  • يضيف بعض صفحات الخطأ وإعداد التقارير إلى الصمام:

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

الخطوات التالية

تفضل بزيارة مركز Azure لمطوري برامج Java للعثور على التشغيل السريع لـ Azure والبرامج التعليمية ووثائق Java المرجعية.