تكوين تطبيق ASP.NET Core لخدمة تطبيقات Azure
ملاحظة
للحصول على ASP.NET في .NET Framework، راجع تكوين تطبيق ASP.NET لخدمة تطبيقات Azure
يجب نشر التطبيقات الأساسية ASP.NET إلى Azure App Service كثنائيات مجمعة. تقوم أداة نشر Visual Studio بإنشاء الحل ثم نشر الثنائيات المترجمة مباشرة ، بينما يقوم محرك نشر App Service بنشر مستودع التعليمات البرمجية أولا ثم يقوم بتجميع الثنائيات.
يوفر هذا الدليل المفاهيم والتعليمات الأساسية للمطورين الأساسيين ASP.NET. إذا لم يسبق لك استخدام Azure App Service، فاتبع البرنامج التعليمي ASP.NET Core quickstart و ASP.NET Core مع قاعدة بيانات SQL أولا.
إظهار إصدارات وقت تشغيل .NET Core المعتمدة
في App Service، تحتوي مثيلات Windows بالفعل على كافة إصدارات .NET Core المعتمدة المثبتة. لإظهار وقت تشغيل .NET Core وإصدارات SDK المتوفرة لك، انتقل إلى الأمر التالي وقم بتشغيله في وحدة التحكم المستندة إلى https://<app-name>.scm.azurewebsites.net/DebugConsole المستعرض:
dotnet --info
إظهار إصدار .NET Core
لإظهار إصدار .NET Core الحالي، قم بتشغيل الأمر التالي في Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
لإظهار كافة إصدارات .NET Core المدعومة، قم بتشغيل الأمر التالي في Cloud Shell:
az webapp list-runtimes --os linux | grep DOTNET
تعيين إصدار .NET Core
قم بتعيين الإطار المستهدف في ملف المشروع لمشروع ASP.NET Core الخاص بك. لمزيد من المعلومات، راجع تحديد إصدار .NET Core لاستخدامه في وثائق .NET Core.
قم بتشغيل الأمر التالي في Cloud Shell لتعيين إصدار .NET Core إلى 3.1:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|3.1"
تخصيص أتمتة البناء
إذا قمت بنشر تطبيقك باستخدام Git، أو حزم مضغوطة مع تمكين التشغيل التلقائي للبناء، فإن خطوات أتمتة إنشاء خدمة التطبيقات من خلال التسلسل التالي:
- قم بتشغيل برنامج نصي مخصص إذا تم تحديده بواسطة
PRE_BUILD_SCRIPT_PATH. - تشغيل
dotnet restoreلاستعادة تبعيات NuGet. - تشغيل
dotnet publishلبناء ثنائي للإنتاج. - قم بتشغيل برنامج نصي مخصص إذا تم تحديده بواسطة
POST_BUILD_SCRIPT_PATH.
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 وإنشائها ASP.NET Core في Linux، راجع وثائق Oryx: كيفية اكتشاف تطبيقات .NET Core وإنشائها.
الوصول إلى متغيرات البيئة
في App Service، يمكنك تعيين إعدادات التطبيق خارج التعليمات البرمجية للتطبيق. ثم يمكنك الوصول إليها في أي فئة باستخدام نمط حقن التبعية الأساسي ASP.NET القياسي:
using Microsoft.Extensions.Configuration;
namespace SomeNamespace
{
public class SomeClass
{
private IConfiguration _configuration;
public SomeClass(IConfiguration configuration)
{
_configuration = configuration;
}
public SomeMethod()
{
// retrieve nested App Service app setting
var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
// retrieve App Service connection string
var myConnString = _configuration.GetConnectionString("MyDbConnection");
}
}
}
إذا قمت بتكوين إعداد تطبيق بنفس الاسم في App Service وفي appsettings.json، على سبيل المثال، فإن قيمة خدمة التطبيقات لها الأسبقية على قيمة appsettings.json. تتيح لك قيمة appsettings.json المحلية تصحيح أخطاء التطبيق محليا، ولكن تتيح لك قيمة خدمة التطبيق تشغيل التطبيق في الإنتاج باستخدام إعدادات الإنتاج. تعمل سلاسل الاتصال بنفس الطريقة. بهذه الطريقة، يمكنك الحفاظ على أسرار التطبيق خارج مستودع التعليمات البرمجية الخاص بك والوصول إلى القيم المناسبة دون تغيير التعليمات البرمجية الخاصة بك.
ملاحظة
لاحظ أنه يتم الوصول إلى بيانات التكوين الهرمي في appsettings.json باستخدام __ محدد (تسطير سفلي مزدوج) قياسي على Linux إلى .NET Core. لتجاوز إعداد تكوين هرمي معين في App Service، قم بتعيين اسم إعداد التطبيق بنفس التنسيق المحدد في المفتاح. يمكنك تشغيل المثال التالي في Cloud Shell:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
ملاحظة
لاحظ أنه يتم الوصول إلى بيانات التكوين الهرمي في appsettings.json باستخدام : المحدد القياسي ل .NET Core. لتجاوز إعداد تكوين هرمي معين في App Service، قم بتعيين اسم إعداد التطبيق بنفس التنسيق المحدد في المفتاح. يمكنك تشغيل المثال التالي في Cloud Shell:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"
نشر حلول متعددة المشاريع
عندما يتضمن حل Visual Studio مشاريع متعددة، تتضمن عملية النشر Visual Studio بالفعل تحديد المشروع المراد نشره. عند النشر إلى محرك نشر خدمة التطبيقات، كما هو الحال مع Git، أو مع نشر ZIP مع تمكين التشغيل التلقائي للبناء، يختار محرك نشر خدمة التطبيقات أول موقع ويب أو تطبيق ويب Project يجده كتطبيق خدمة التطبيقات. يمكنك تحديد المشروع الذي يجب أن تستخدمه خدمة التطبيقات عن طريق تحديد PROJECT إعداد التطبيق. على سبيل المثال، قم بتشغيل ما يلي في Cloud Shell:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
الوصول إلى سجلات التشخيص
يوفر ASP.NET Core موفر تسجيل مدمج لخدمة التطبيقات. في البرنامج.cs مشروعك، أضف الموفر إلى التطبيق الخاص بك من خلال طريقة الامتداد ConfigureLogging ، كما هو موضح في المثال التالي:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.AddAzureWebAppDiagnostics();
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
يمكنك بعد ذلك تكوين وإنشاء سجلات باستخدام نمط .NET Core القياسي.
للوصول إلى سجلات وحدة التحكم التي تم إنشاؤها من داخل التعليمة البرمجية للتطبيق في خدمة التطبيقات، قم بتشغيل تسجيل التشخيص عن طريق تشغيل الأمر التالي في 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.
لمزيد من المعلومات حول استكشاف أخطاء تطبيقات ASP.NET Core وإصلاحها في App Service، راجع استكشاف أخطاء ASP.NET Core على Azure App Service وIIS وإصلاحها
صفحة الحصول على استثناءات مفصلة
عندما ينشئ تطبيق ASP.NET Core استثناء في مصحح أخطاء Visual Studio، يعرض المستعرض صفحة استثناء مفصلة، ولكن في خدمة التطبيقات يتم استبدال هذه الصفحة بخطأ HTTP 500 عام أو حدث خطأ أثناء معالجة طلبك. لعرض صفحة الاستثناء التفصيلية في App Service، أضف ASPNETCORE_ENVIRONMENT إعداد التطبيق إلى تطبيقك عن طريق تشغيل الأمر التالي في Cloud Shell.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"
الكشف عن جلسة عمل HTTPS
في خدمة التطبيقات، يحدث إنهاء طبقة النقل الآمنة/طبقة المقابس الآمنة (TLS) في موازنات تحميل الشبكة، بحيث تصل جميع طلبات HTTPS إلى تطبيقك كطلبات HTTP غير مشفرة. إذا كان منطق التطبيق يحتاج إلى معرفة ما إذا كانت طلبات المستخدم مشفرة أم لا، فقم بتكوين البرامج الوسيطة للرؤوس المعاد توجيهها في بدء التشغيل.cs:
- قم بتكوين البرامج الوسيطة باستخدام ForwardedHeadersOptions لإعادة توجيه الرؤوس
X-Forwarded-ForوالرؤوسX-Forwarded-ProtoفيStartup.ConfigureServices. - أضف نطاقات عناوين IP خاصة إلى الشبكات المعروفة، بحيث يمكن للبرامج الوسيطة الوثوق بموازن تحميل خدمة التطبيقات.
- استدعاء أسلوب UseForwardedHeaders قبل
Startup.Configureاستدعاء البرامج الوسيطة الأخرى.
عند وضع العناصر الثلاثة معا، تبدو التعليمة البرمجية الخاصة بك مثل المثال التالي:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
// These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseForwardedHeaders();
...
app.UseMvc();
}
لمزيد من المعلومات، راجع تكوين ASP.NET Core للعمل مع الخوادم الوكيلة وموازنات التحميل.
فتح جلسة SSH في المستعرض
لفتح جلسة SSH مباشرة مع حاويتك، يجب أن يكون تطبيقك قيد التشغيل.
الصق عنوان URL التالي في المتصفح واستبدله<app-name> باسم التطبيق:
https://<app-name>.scm.azurewebsites.net/webssh/host
إذا لم تتم مصادقتكَ بعد، يجب عليك المصادقة باستخدام اشتراك Azure للاتصال. بمجرد المصادقة، سترى shell في المستعرض، حيث يمكنك تشغيل الأوامر داخل حاويتك.

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