مشاركة عبر

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

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

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

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

إشعار

يدعم JBoss EAP على App Service الآن فوترة "إحضار الترخيص الخاص بك" (BYOL)، وهذا يسمح للعملاء الذين لديهم اشتراكات Red Hat الحالية بتطبيق هذه التراخيص مباشرة على عمليات توزيع JBoss EAP الخاصة بهم على Azure App Service. التعرف على المزيد.

إظهار إصدار Java

لإظهار إصدار Java الحالي، قم بتشغيل الأمر التالي في Azure 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/bin/version.sh

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

find / -name "version.sh"

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

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

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

ماذا يحدث لأقات التشغيل القديمة في App Service؟

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

إذا كنت ترغب في إنشاء تطبيق بإصدار وقت تشغيل قديم لم يعد معروضا على المدخل، فاستخدم Azure CLI أو قالب ARM أو Bicep. تتيح لك بدائل التوزيع هذه إنشاء أوقات تشغيل مهملة تمت إزالتها من المدخل ولكن لا تزال مدعومة.

إذا تمت إزالة وقت التشغيل بالكامل من النظام الأساسي لخدمة التطبيقات، يتلقى مالك اشتراك Azure إشعارا بالبريد الإلكتروني قبل الإزالة.

توزيع تطبيقك

أدوات الإنشاء

مخضرم

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

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

ايديس

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

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

يستخدم عملاء النشر مثل المكون الإضافي Maven أو إجراءات GitHub باستخدام azure/webapps-deploy@v3 وأحدث أو الأمر az webapp deploy OneDeploy، والذي يتم استدعاؤه عن طريق استدعاء /api/publish نقطة نهاية موقع Kudu تحت الغطاء. لمزيد من المعلومات حول واجهة برمجة التطبيقات هذه، راجع هذه الوثائق.

عند استخدام أساليب النشر هذه، ستتم إعادة تسمية ملف JAR المتوفر تلقائيا أثناء app.jar عملية التوزيع. سيتم وضع هذا ضمن /home/site/wwwwroot. لنشر ملفات JAR إلى Java SE، راجع هذه الوثائق.

إشعار

إذا كنت تستخدم أساليب بديلة مثل FTP أو واجهات برمجة التطبيقات ZipDeploy الأقدم، فلن يتم استدعاء طريقة إعادة تسمية ملف JAR المتوفر. لاحظ هذا إذا كنت تستخدم مربع النص ملف بدء التشغيل في قسم التكوين في المدخل لاستدعاء ملف JAR بشكل صريح.

يمكنك نشر ملفات WAR إلى تطبيق Tomcat باتباع هذه الوثائق. عند استخدام أساليب النشر المذكورة أعلاه، ستتم إعادة تسمية ملف الحرب المتوفر تلقائيا أثناء app.war عملية النشر. سيتم وضع هذا ضمن /home/site/wwwwroot وبشكل افتراضي يدعم فقط نشر ملف WAR واحد ضمن wwwroot. لن يتم وضع هذا ضمن /home/site/wwwroot/webapps الدليل كما هو الحال عند استخدام واجهات برمجة التطبيقات للتوزيع مثل WarDeploy. لتجنب أي مشكلات في اشتباكات بنية الملف، ينصح باستخدام نوع نشر واحد أو آخر فقط.

لنشر ملفات WAR إلى JBoss EAP، راجع هذه الوثائق. عند استخدام OneDeploy، سيعيد هذا تلقائيا تسمية ملف WAR إلى app.war وسيتم وضعه ضمن /home/site/wwwroot.

لنشر ملفات EAR، استخدم FTP. يتم نشر تطبيق EAR الخاص بك إلى جذر السياق المحدد في تكوين التطبيق الخاص بك. إذا كنت تريد تقديم تطبيق الويب الخاص بك في المسار الجذر، فتأكد من أن تطبيقك يعين جذر السياق إلى المسار الجذر: <context-root>/</context-root>. لمزيد من المعلومات، راجع تعيين جذر السياق لتطبيق ويب.

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

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

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

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

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

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

تتوفر تقارير الأداء ومرئيات نسبة استخدام الشبكة وفحوصات السلامة لكل تطبيق من خلال مدخل 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.

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

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

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

استخدم الأمر az webapp ssh .

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

اتصال SSH

إشعار

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

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

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

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

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

تأتي جميع أوقات تشغيل Java على Azure App Service مع مسجل رحلة Java Development Kit (JDK) من أجل جمع معلومات حول أحمال عمل Java. يمكنك استخدامه لتسجيل Java Virtual Machine (JVM) والنظام وأحداث التطبيق واستكشاف المشكلات وإصلاحها في تطبيقاتك.

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

مسجل Java Flight

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

SSH في خدمة التطبيقات وتشغيل 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 وإنشاء ملف Java Flight Recorder (JFR) المسمى jfr_example.jfr في الدليل الرئيسي. استبدل 116 ب PID لتطبيق 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 (JMC). للحصول على إرشادات حول كيفية استخدام Java Mission Control، راجع وثائق JMCوإرشادات التثبيت.

سجل التطبيق

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

يمكن العثور على سجلات تطبيق 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 وAzure CLI. راجع المقالات التالية لتكوين تطبيق ويب محدد غير مرتبط بـ Java:

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

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

تعيين خيارات وقت تشغيل 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 حجم كومة الذاكرة المؤقتة القصوى ل JVM إلى 70% من إجمالي الذاكرة المتوفرة لخطة App Service. لتعطيل الإعداد الافتراضي، يمكنك استخدام إعداد التطبيق WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

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

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

قم بتشغيل دعم مآخذ الويب في مدخل Microsoft 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>

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

في مدخل Microsoft Azure، ضمن Application Settings لتطبيق الويب، قم بإنشاء إعداد تطبيق جديد باسم JAVA_OPTS بالقيمة -Dfile.encoding=UTF-8.

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

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

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

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

تجاهل رسالة الروبوتات933456 في السجلات

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

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 EAP، يمكنك تشغيل JBoss CLI باستخدام الأمر التالي:

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

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

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

إشعار

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

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

إشعار

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

يمكن توزيع أنواع خطة خدمة تطبيقات Premium V3 وPremium V4 وV2 المعزولة اختياريا عبر مناطق التوفر لتحسين المرونة والموثوقية لأحمال العمل المهمة لأعمالك. تعرف هذه البنية أيضا باسم تكرار المنطقة. تتوافق ميزة تجميع JBoss EAP مع ميزة تكرار المنطقة.

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

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

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

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

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

يتوفر JBoss EAP في مستويات التسعير التالية: F1وP0v3وP1mv3وP2mv3وP3mv3وP4mv3وP5mv3وP0v4وP1mv4وP2mv4وP3mv4وP4mv4وP5mv4.

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

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

  1. مرحلة إعداد البيئة
  2. مرحلة تشغيل الخادم
  3. مرحلة تكوين الخادم
  4. مرحلة نشر التطبيق
  5. مرحلة إعادة تحميل الخادم

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

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

  • يتم بدء تشغيل خدمة SSH لتمكين جلسات SSH الآمنة مع الحاوية.
  • يتم تحديث مخزن مفاتيح وقت تشغيل 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.keyStorePasswordو javax.net.ssl.keyStoreType إلى JAVA_OPTS متغير البيئة.
  • يتم تحديد بعض تكوين JVM الأولي، مثل دلائل التسجيل ومعلمات كومة ذاكرة Java:
    • إذا قمت بتوفير –Xms علامات أو –Xmx للذاكرة في إعداد JAVA_OPTSالتطبيق ، فإن هذه القيم تتجاوز تلك التي يوفرها النظام الأساسي.
    • إذا قمت بتكوين إعداد WEBSITES_CONTAINER_STOP_TIME_LIMITالتطبيق ، يتم تمرير القيمة إلى خاصية org.wildfly.sigterm.suspend.timeoutوقت التشغيل ، والتي تتحكم في الحد الأقصى لوقت انتظار إيقاف التشغيل (بالثوان) عند إيقاف JBoss EAP.
  • إذا تم دمج التطبيق مع شبكة ظاهرية، يمرر وقت تشغيل App Service قائمة بالمنافذ لاستخدامها للاتصال بين الخوادم في متغير WEBSITE_PRIVATE_PORTS البيئة ويطلق JBoss EAP باستخدام clustering التكوين. وإلا، standalone يتم استخدام التكوين.
    • للتكوين clustering ، يتم استخدام ملف standalone-azure-full-ha.xml تكوين الخادم.
    • للتكوين standalone ، يتم استخدام ملف standalone-full.xml تكوين الخادم.

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

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

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

  • في بداية هذه المرحلة، تنتظر App Service أولا أن يكون كل من خادم JBoss EAP وواجهة المسؤول جاهزة لتلقي الطلبات قبل المتابعة. يمكن أن تستغرق هذه العملية بضع ثوان إضافية إذا تم تمكين Application Insights.

  • عندما يكون كل من خادم JBoss EAP وواجهة المسؤول جاهزة، تتخذ App Service الإجراءات التالية:

    • يضيف وحدة JBoss EAP ، azure.appserviceالتي توفر فئات أدوات مساعدة للتسجيل والتكامل مع App Service.
    • يحدث مسجل وحدة التحكم لاستخدام وضع بدون لون بحيث لا تمتلئ ملفات السجل بتسلسلات إلغاء الألوان.
    • إعداد التكامل مع سجلات Azure Monitor.
    • تحديث عناوين IP الملزمة للغة وصف خدمات الويب (WSDL) وواجهات الإدارة.
    • يضيف وحدة azure.appservice.easyauth JBoss EAP للتكامل مع مصادقة App Service ومعرف Microsoft Entra.
    • يحدث تكوين تسجيل سجلات الوصول واسم ملف سجل الخادم الرئيسي وتدارته.

  • ما لم يتم تعريف إعداد WEBSITE_SKIP_AUTOCONFIGURE_DATABASE التطبيق، تقوم App Service تلقائيا بكشف عناوين URL لاتصال قاعدة بيانات Java (JDBC) في إعدادات تطبيق App Service. إذا كانت عناوين URL JDBC صالحة ل PostgreSQL أو MySQL أو MariaDB أو Oracle أو SQL Server أو قاعدة بيانات Azure SQL، فإنه يضيف برامج التشغيل المقابلة إلى الخادم، ويضيف مصدر بيانات لكل عنوان URL ل JDBC، ويعين اسم Java Naming and Directory Interface (JNDI) لكل مصدر بيانات إلى java:jboss/env/jdbc/<app-setting-name>_DS، حيث <app-setting-name> يكون اسم إعداد التطبيق.

  • clustering إذا تم تمكين التكوين، يتم التحقق من مسجل وحدة التحكم الذي سيتم تكوينه.

  • إذا كانت هناك ملفات JAR تم نشرها في /home/site/libs الدليل، يتم إنشاء وحدة نمطية عمومية جديدة مع جميع ملفات JAR هذه.

  • في نهاية المرحلة، تقوم App Service بتشغيل البرنامج النصي لبدء التشغيل المخصص، إذا كان موجودا. يتم تعريف منطق البحث للبرنامج النصي لبدء التشغيل المخصص كما يلي:

    • إذا قمت بتكوين أمر بدء تشغيل (على سبيل المثال، من خلال مدخل Azure أو Azure CLI)، فقم بتشغيله؛ خلاف ذلك
    • إذا كان المسار /home/site/scripts/startup.sh موجودا، فاستخدمه؛ وإلا،
    • إذا كان المسار /home/startup.sh موجودا، فاستخدمه.

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

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

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

  • إذا قمت بتكوين إعداد 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 EAP لتطبيق أي تغييرات تتطلب إعادة تحميل الخادم.
  • بعد إعادة تحميل الخادم، يجب أن تكون التطبيقات المنشورة على خادم JBoss EAP جاهزة للاستجابة للطلبات.
  • يتم تشغيل الخادم حتى يتم إيقاف تطبيق App Service أو إعادة تشغيله. يمكنك إيقاف تطبيق App Service أو إعادة تشغيله يدويا، أو تشغيل إعادة التشغيل عند نشر الملفات أو إجراء تغييرات التكوين على تطبيق App Service.
  • إذا خرج خادم JBoss EAP بشكل غير طبيعي في clustering التكوين، يتم تنفيذ دالة نهائية تسمى emit_alert_tx_store_not_empty . تتحقق الدالة من أن عملية JBoss EAP تركت ملف مخزن معاملات غير مرن في القرص. إذا كان الأمر كذلك، يتم تسجيل خطأ في وحدة التحكم: 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 for Java Developers للعثور على قوالب التشغيل السريع والبرامج التعليمية ووثائق Java المرجعية.

  • Last updated on