تكوين تطبيق Node.js لخدمة تطبيقات Azure

مقالة
04/06/2022
قراءة خلال 11 دقائق

يجب نشر Node.js التطبيقات مع جميع تبعيات NPM المطلوبة. يعمل محرك نشر خدمة التطبيقات تلقائيا npm install --production نيابة عنك عند نشر مستودع Git أو حزمة Zip مع تمكين التشغيل التلقائي للإنشاء. ومع ذلك، إذا قمت بنشر ملفاتك باستخدام FTP/S، فستحتاج إلى تحميل الحزم المطلوبة يدويا.

يوفر هذا الدليل المفاهيم والإرشادات الأساسية لمطوري Node.js الذين ينشرون في App Service. إذا لم يسبق لك استخدام Azure App Service، فاتبع Node.js بدء التشغيل السريع Node.js البرنامج التعليمي MongoDB أولا.

إظهار الإصدار Node.js

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

az webapp config appsettings list --name <app-name> --resource-group <resource-group-name> --query "[?name=='WEBSITE_NODE_DEFAULT_VERSION'].value"

لإظهار جميع إصدارات Node.js المدعومة، انتقل إلى https://<sitename>.scm.azurewebsites.net/api/diagnostics/runtime الأمر التالي أو قم بتشغيله في Cloud Shell:

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

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

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

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

az webapp list-runtimes --os linux | grep NODE

تعيين الإصدار Node.js

لتعيين تطبيقك إلى إصدار Node.js مدعوم، قم بتشغيل الأمر التالي في Cloud Shell لتعيينه WEBSITE_NODE_DEFAULT_VERSION إلى إصدار مدعوم:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_NODE_DEFAULT_VERSION="~16"

ملاحظة

يستخدم هذا المثال "بناء جملة tilde" الموصى به لاستهداف أحدث إصدار متوفر من وقت تشغيل Node.js 16 على App Service.

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

ملاحظة

يجب عليك تعيين الإصدار Node.js في مشروعك package.json. يعمل مشغل النشر في عملية منفصلة تحتوي على كافة إصدارات Node.js المعتمدة.

لتعيين تطبيقك إلى إصدار Node.js مدعوم، قم بتشغيل الأمر التالي في Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|14-lts"

يحدد هذا الإعداد الإصدار Node.js للاستخدام، سواء في وقت التشغيل أو أثناء استعادة الحزمة التلقائية في Kudu.

ملاحظة

يجب عليك تعيين الإصدار Node.js في مشروعك package.json. يعمل مشغل النشر في حاوية منفصلة تحتوي على كافة إصدارات Node.js المعتمدة.

الحصول على رقم المنفذ

تحتاج Node.js التطبيق إلى الاستماع إلى المنفذ الصحيح لتلقي الطلبات الواردة.

في App Service على Windows، تتم استضافة تطبيقات Node.js باستخدام IISNode، ويجب أن يستمع تطبيق Node.js إلى المنفذ المحدد في المتغيرprocess.env.PORT. يوضح المثال التالي كيفية القيام بذلك في تطبيق Express بسيط:

تقوم App Service بتعيين متغير PORT البيئة في حاوية Node.js، وإعادة توجيه الطلبات الواردة إلى الحاوية الخاصة بك برقم المنفذ هذا. لتلقي الطلبات، يجب أن يستمع تطبيقك إلى هذا المنفذ باستخدام process.env.PORT. يوضح المثال التالي كيفية القيام بذلك في تطبيق Express بسيط:

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

تخصيص أتمتة البناء

إذا قمت بنشر تطبيقك باستخدام Git، أو حزم مضغوطة مع تمكين التشغيل التلقائي للبناء، فإن خطوات أتمتة إنشاء خدمة التطبيقات من خلال التسلسل التالي:

قم بتشغيل برنامج نصي مخصص إذا تم تحديده بواسطة PRE_BUILD_SCRIPT_PATH.
تشغيل npm install دون أي أعلام ، والتي تشمل npm preinstall والبرامج postinstall النصية وأيضا تثبيت devDependencies.
تشغيل npm run build إذا تم تحديد برنامج نصي للإنشاء في package.json.
تشغيل npm run build:azure إذا تم تحديد البرنامج النصي build:azure في package.json الخاص بك.
قم بتشغيل برنامج نصي مخصص إذا تم تحديده بواسطة POST_BUILD_SCRIPT_PATH.

ملاحظة

كما هو موضح في مستندات npm ، يتم تسمية prebuild البرامج النصية وتشغيلها postbuild قبل وبعد build، على التوالي ، إذا تم تحديدها. preinstall وتشغيل postinstall قبل وبعد install، على التوالي.

PRE_BUILD_COMMAND وهي POST_BUILD_COMMAND متغيرات البيئة الفارغة افتراضيا. لتشغيل أوامر ما قبل الإنشاء، حدد PRE_BUILD_COMMAND. لتشغيل أوامر ما بعد الإنشاء، حدد POST_BUILD_COMMAND.

يحدد المثال التالي المتغيرين لسلسلة من الأوامر، مفصولة بفواصل.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

للحصول على متغيرات بيئة إضافية لتخصيص أتمتة البناء، راجع تكوين Oryx.

لمزيد من المعلومات حول كيفية تشغيل App Service وإنشائها Node.js التطبيقات في Linux، راجع وثائق Oryx: كيفية اكتشاف التطبيقات Node.js وإنشائها.

تكوين خادم Node.js

تأتي حاويات Node.js مع PM2 ، وهو مدير عملية إنتاج. يمكنك تكوين تطبيقك للبدء ب PM2 أو باستخدام NPM أو بأمر مخصص.

الأداة	الغرض
تشغيل مع PM2	موصى به - استخدام الإنتاج أو التدريج. يوفر PM2 نظاما أساسيا كاملا لإدارة التطبيقات.
تشغيل npm بداية	استخدام التطوير فقط.
تشغيل الأمر المخصص	إما التطوير أو التدريج.

تشغيل مع PM2

تبدأ الحاوية تلقائيا تشغيل تطبيقك باستخدام PM2 عند العثور على أحد ملفات Node.js الشائعة في مشروعك:

بن / شبكة الاتصالات العالمية
server.js
app.js
index.js
hostingstart.js
أحد ملفات PM2 التالية: process.json و ecosystem.config.js

يمكنك أيضا تكوين ملف بدء مخصص بالملحقات التالية:

ملف .js
ملف PM2 بامتداد .json أو .config.jsأو .yaml أو .yml

ملاحظة

بدءا من العقدة 14 LTS، لا تبدأ الحاوية تلقائيا تشغيل تطبيقك باستخدام PM2. لبدء تشغيل تطبيقك باستخدام PM2، قم بتعيين أمر بدء التشغيل إلى pm2 start <.js-file-or-PM2-file> --no-daemon. تأكد من استخدام الوسيطة لأن PM2 يحتاج إلى التشغيل في المقدمة حتى تعمل الحاوية --no-daemon بشكل صحيح.

لإضافة ملف بدء مخصص، قم بتشغيل الأمر التالي في Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filname-with-extension>"

تشغيل الأمر المخصص

يمكن ل App Service بدء تشغيل تطبيقك باستخدام أمر مخصص، مثل أمر قابل للتنفيذ مثل run.sh. على سبيل المثال، لتشغيل npm run start:prod، قم بتشغيل الأمر التالي في Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "npm run start:prod"

تشغيل npm بداية

لبدء تشغيل تطبيقك npm start، ما عليك سوى التأكد من وجود start برنامج نصي في ملف package.json. على سبيل المثال:

{
  ...
  "scripts": {
    "start": "gulp",
    ...
  },
  ...
}

لاستخدام package.json مخصص في مشروعك، قم بتشغيل الأمر التالي في Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename>.json"

تصحيح الأخطاء عن بعد

ملاحظة

تصحيح الأخطاء عن بعد حاليا في المعاينة.

يمكنك تصحيح أخطاء تطبيق Node.js عن بعد في التعليمات البرمجية Visual Studio إذا قمت بتكوينه ليعمل باستخدام PM2، إلا عند تشغيله باستخدام .config.js أو .yml أو .yaml.

في معظم الحالات، لا يلزم إجراء تهيئة إضافية لتطبيقك. إذا تم تشغيل تطبيقك باستخدام ملف process.json (افتراضي أو مخصص)، فيجب أن يحتوي على خاصية script في جذر JSON. على سبيل المثال:

{
  "name"        : "worker",
  "script"      : "./index.js",
  ...
}

لإعداد رمز Visual Studio لتصحيح الأخطاء عن بعد، قم بتثبيت ملحق خدمة التطبيق. اتبع الإرشادات الموجودة على صفحة الإضافة وسجل الدخول إلى Azure في Visual Studio Code.

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

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

الوصول إلى متغيرات البيئة

في App Service، يمكنك تعيين إعدادات التطبيق خارج التعليمات البرمجية للتطبيق. ثم يمكنك الوصول إليها باستخدام نمط Node.js القياسي. على سبيل المثال، للوصول إلى إعداد تطبيق يسمى NODE_ENV، استخدم التعليمات البرمجية التالية:

process.env.NODE_ENV

تشغيل النخر / باور / بلع

بشكل افتراضي، يتم تشغيل npm install --production التشغيل التلقائي لإنشاء App Service عندما يتعرف على تطبيق Node.js يتم نشره من خلال Git، أو من خلال نشر Zip مع تمكين التشغيل التلقائي للبناء. إذا كان تطبيقك يتطلب أيا من أدوات التشغيل التلقائي الشائعة، مثل Grunt أو Bower أو Gulp، فستحتاج إلى توفير برنامج نصي مخصص للنشر لتشغيله.

لتمكين المستودع الخاص بك من تشغيل هذه الأدوات، تحتاج إلى إضافتها إلى التبعيات في package.json. على سبيل المثال:

"dependencies": {
  "bower": "^1.7.9",
  "grunt": "^1.0.1",
  "gulp": "^3.9.1",
  ...
}

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

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

يحتوي جذر المستودع الآن على ملفين إضافيين: .deployment و deploy.sh.

افتح deploy.sh وابحث عن Deployment القسم الذي يبدو كما يلي:

##################################################################################################################################
# Deployment
# ----------

ينتهي هذا القسم بتشغيل npm install --production. أضف قسم التعليمات البرمجية الذي تحتاجه لتشغيل الأداة المطلوبة في نهايةDeployment القسم:

باور
جرع
نعر

راجع مثالا في نموذج MEAN.js، حيث يقوم البرنامج النصي للنشر أيضا بتشغيل أمر مخصص npm install .

باور

يتم تشغيل bower installهذا المقتطف .

if [ -e "$DEPLOYMENT_TARGET/bower.json" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/bower install
  exitWithMessageOnError "bower failed"
  cd - > /dev/null
fi

جرع

يتم تشغيل gulp imageminهذا المقتطف .

if [ -e "$DEPLOYMENT_TARGET/gulpfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/gulp imagemin
  exitWithMessageOnError "gulp failed"
  cd - > /dev/null
fi

نعر

يتم تشغيل gruntهذا المقتطف .

if [ -e "$DEPLOYMENT_TARGET/Gruntfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/grunt
  exitWithMessageOnError "Grunt failed"
  cd - > /dev/null
fi

الكشف عن جلسة عمل HTTPS

في خدمة التطبيقات، يحدث إنهاء طبقة النقل الآمنة/طبقة المقابس الآمنة (TLS) في موازنات تحميل الشبكة، بحيث تصل جميع طلبات HTTPS إلى تطبيقك كطلبات HTTP غير مشفرة. إذا كان منطق التطبيق الخاص بك يحتاج إلى التحقق مما إذا كانت طلبات المستخدم مشفرة أم لا، فافحص ترويسة X-Forwarded-Proto.

وتتيح لك أطر عمل الويب الشائعة الوصول إلى معلومات X-Forwarded-* في نمط التطبيق القياسي. في Express، يمكنك استخدام بروكسيات الثقة. على سبيل المثال:

app.set('trust proxy', 1)
...
if (req.secure) {
  // Do something when HTTPS is used
}

الوصول إلى سجلات التشخيص

للوصول إلى سجلات وحدة التحكم التي تم إنشاؤها من داخل التعليمة البرمجية للتطبيق في خدمة التطبيقات، قم بتشغيل تسجيل التشخيص عن طريق تشغيل الأمر التالي في Cloud Shell:

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

القيم المحتملة لـ --level هي: Error وWarning وInfo وVerbose. يتضمن كل مستوى لاحق المستوى السابق. على سبيل المثال: Error يتضمن رسائل الخطأ فقط بينما Verbose يتضمن جميع الرسائل.

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

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

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

ملاحظة

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

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

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

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

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.

المراقبة باستخدام Application Insights

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

سيراقب هذا الوكيل تطبيق Node.js من جانب الخادم. لمراقبة جافا سكريبت من جانب العميل، أضف حزمة تطوير البرامج (SDK) لجافا سكريبت إلى مشروعك.

لمزيد من المعلومات، راجع ملاحظات إصدار ملحق Insights التطبيق.

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

عندما يتصرف تطبيق Node.js يعمل بشكل مختلف في App Service أو يحتوي على أخطاء، جرب ما يلي:

الوصول إلى دفق السجل.
اختبر التطبيق محليا في وضع الإنتاج. تقوم خدمة التطبيقات بتشغيل تطبيقات Node.js في وضع الإنتاج، لذلك تحتاج إلى التأكد من أن مشروعك يعمل كما هو متوقع في وضع الإنتاج محليا. على سبيل المثال:
- اعتمادا على package.json الخاص بك ، قد يتم تثبيت حزم مختلفة لوضع الإنتاج (dependencies مقابل devDependencies).
- قد تقوم بعض أطر عمل الويب بنشر ملفات ثابتة بشكل مختلف في وضع الإنتاج.
- قد تستخدم بعض أطر عمل الويب برامج نصية مخصصة لبدء التشغيل عند التشغيل في وضع الإنتاج.
قم بتشغيل تطبيقك في App Service في وضع التطوير. على سبيل المثال، في MEAN.js، يمكنك تعيين تطبيقك إلى وضع التطوير في وقت التشغيل عن طريق تعيين NODE_ENV إعداد التطبيق.

ليس لديك إذن لعرض هذا الدليل أو الصفحة

بعد نشر شفرة Node.js الخاصة بك إلى تطبيق Windows أصلي في App Service، قد ترى الرسالة You do not have permission to view this directory or page. في المتصفح عند الانتقال إلى عنوان URL لتطبيقك. هذا على الأرجح لأنه ليس لديك ملف web.config (راجع القالب ومثال).

إذا قمت بنشر ملفاتك باستخدام Git، أو باستخدام نشر ZIP مع تمكين التشغيل التلقائي للإنشاء، يقوم مشغل النشر بإنشاء web.config في جذر الويب الخاص بتطبيقك (%HOME%\site\wwwroot) تلقائيا إذا تحقق أحد الشروط التالية:

يحتوي جذر المشروع على package.json الذي يحدد البرنامج النصي الذي start يحتوي على مسار ملف جافا سكريبت.
يحتوي جذر مشروعك إما على server.js أو app.js.

تم تصميم web.config التي تم إنشاؤها وفقا للبرنامج النصي للبدء المكتشف. بالنسبة لطرق النشر الأخرى، أضف هذا web.config يدويا. تأكد من تنسيق الملف بشكل صحيح.

إذا كنت تستخدم نشر ZIP (من خلال التعليمات البرمجية Visual Studio، على سبيل المثال)، فتأكد من تمكين التشغيل التلقائي للإنشاء لأنه غير ممكن افتراضيا. az webapp up يستخدم نشر ZIP مع تمكين أتمتة الإنشاء.

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 ببساطة إلى أن المسار غير موجود، ولكنه يتيح لـ"خدمة التطبيقات" معرفة أن الحاوية سليمة وجاهزة للاستجابة للطلبات.

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

البرنامج التعليمي: تطبيق Node.js مع MongoDB

الأسئلة الشائعة حول App Service بنظام Linux

أو راجع موارد إضافية:

متغيرات البيئة ومرجع إعدادات التطبيق

تكوين تطبيق Node.js لخدمة تطبيقات Azure

هل هذه الصفحة مفيدة؟

إظهار الإصدار Node.js

تعيين الإصدار Node.js

الحصول على رقم المنفذ

تخصيص أتمتة البناء

تكوين خادم Node.js

تشغيل مع PM2

تشغيل الأمر المخصص

تشغيل npm بداية

تصحيح الأخطاء عن بعد

الوصول إلى متغيرات البيئة

تشغيل النخر / باور / بلع

باور

جرع

نعر

الكشف عن جلسة عمل HTTPS

الوصول إلى سجلات التشخيص

المراقبة باستخدام Application Insights

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

ليس لديك إذن لعرض هذا الدليل أو الصفحة

robots933456 في السجلات

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