تكوين تطبيق ASP.NET Core لخدمة تطبيقات Azure

إشعار

للحصول على ASP.NET في .NET Framework، راجع تكوين تطبيق ASP.NET لخدمة تطبيقات Azure. إذا كان تطبيق ASP.NET Core يعمل في حاوية Windows أو Linux مخصصة، فشاهد تكوين حاوية مخصصة لخدمة تطبيقات Azure.

يجب توزيع تطبيقات ASP.NET Core في Azure App Service كثنائيات مجمعة. تنشئ أداة نشر Visual Studio الحل ثم توزيع الثنائيات المحولة برمجياً مباشرةً، بينما يقوم محرك توزيع App Service بتوزيع مستودع التعليمات البرمجية أولاً ثم يقوم بتجميع الثنائيات.

يوفر هذا الدليل المفاهيم الأساسية والإرشادات لمطوري ASP.NET Core. إذا لم تستخدم Azure App Service مطلقاً، فاتبع البرنامج التعليمي ASP.NET Core تشغيل سريع وASP.NET Core with SQL Database التعليمي أولاً.

عرض إصدارات وقت تشغيل NET Core. المدعومة

في خدمة التطبيقات، تم تثبيت جميع إصدارات .NET Core المدعومة في مثيلات Windows بالفعل. لإظهار إصدارات وقت تشغيل 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، أو حزم zip مع تمكين أتمتة الإنشاء، فإن App Service ينشئ خطوات أتمتة من خلال التسلسل التالي:

  1. قم بتشغيل برنامج نصي مخصص إذا تم تحديده بواسطة PRE_BUILD_SCRIPT_PATH.
  2. قم بتشغيل dotnet restore لاستعادة تبعيات NuGet.
  3. شغّل dotnet publish لإنشاء ثنائي للإنتاج.
  4. قم بتشغيل برنامج نصي مخصص إذا تم تحديده بواسطة 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.

لمزيد من المعلومات حول كيفية تشغيل خدمة التطبيقات وإنشائها لتطبيقات ASP.NET Core في Linux، راجع وثائق Oryx: كيفية اكتشاف تطبيقات .NET Core وإنشائها.

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

في App Service، يمكنك تعيين إعدادات التطبيق خارج التعليمات البرمجية للتطبيق. ثم يمكنك الوصول إليها في أي فئة باستخدام نمط إدخال التبعية القياسي ASP.NET Core:

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

إشعار

لاحظ أن بيانات التكوين الهرمي في appsettings.json يتم الوصول إليها باستخدام __ (شرطة سفلية مزدوجة) المحدد القياسي في Linux إلى .NET Core. لتجاوز إعداد تكوين هرمي معين في خدمة التطبيقات، قم بتعيين اسم إعداد التطبيق بنفس التنسيق المحدد في المفتاح. يمكنك تشغيل المثال التالي في 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. لتجاوز إعداد تكوين هرمي معين في خدمة التطبيقات، قم بتعيين اسم إعداد التطبيق بنفس التنسيق المحدد في المفتاح. يمكنك تشغيل المثال التالي في 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 تتضمن بالفعل تحديد المشروع لتوزيعه. عند التوزيع إلى محرك توزيع App Service، مثل Git، أو مع توزيع ZIP مع تمكين أتمتة الإنشاء، يختار محرك توزيع App Service أول موقع ويب أو مشروع تطبيق ويب يعثر عليه باعتباره خدمة التطبيقات تطبيق. يمكن تحديد المشروع الذي يجب أن تستخدمه App Service من خلال تحديد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 موفر تسجيل مضمناً لخدمة التطبيقات. في Program.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/SSL في موازنات تحميل الشبكة، لذلك تصل جميع طلبات HTTPS إلى تطبيقك كطلبات HTTP غير مشفرة. إذا كان منطق التطبيق الخاص بك يحتاج إلى معرفة ما إذا كانت طلبات المستخدم مشفرة أم لا، فقم بتكوين البرامج الوسيطة Forwarded Headers في Startup.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 في المستعرض، حيث يمكنك تشغيل الأوامر داخل حاويتك.

SSH connection

إشعار

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

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

أو، راجع المزيد من الموارد:

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