مشاركة عبر

نظرة عامة على .NET على Azure Container Apps

  • مقالة

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

Azure Container Apps هي خدمة حاوية بدون خادم مدارة بالكامل تسمح لك بتشغيل التطبيقات الحاوية دون الحاجة إلى إدارة البنية الأساسية. تتضمن تطبيقات الحاوية دعما مضمنا للميزات بما في ذلك التحجيم التلقائي والفحوصات الصحية وشهادات أمان طبقة النقل (TLS).

توضح هذه المقالة بالتفصيل المفاهيم والمخاوف المهمة بالنسبة لك أثناء نشر تطبيق .NET على Azure Container Apps.

حدد نوع مورد

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

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

حالة الاستخدام نوع المورد
واجهة برمجة تطبيقات ويب ASP.NET Core التي تخدم طلبات HTTP التطبيق
تطبيق وحدة تحكم .NET Core يعالج بعض البيانات، ثم يخرج الوظيفة
خدمة خلفية قيد التشغيل باستمرار تعالج الرسائل من قائمة انتظار التطبيق
خدمة تحسين الصور التي يتم تشغيلها فقط عند حفظ الصور الكبيرة في حساب تخزين. الوظيفة
تطبيق يستخدم إطار عمل مثل Hangfire أو Quartz.NET أو Azure WebJobs SDK التطبيق

تعبئة تطبيق .NET ونشره في حاويات

لكل من التطبيقين أو الوظائف، تحتاج إلى إنشاء صورة حاوية لحزم تطبيق .NET الخاص بك. لمزيد من المعلومات حول إنشاء صورة الحاوية، راجع صور Docker ل ASP.NET Core.

بمجرد الإعداد، يمكنك نشر التطبيق الخاص بك إلى Azure Container Apps باتباع هذه الإرشادات:

استخدام دخول HTTP

تتضمن Azure Container Apps دخول HTTP مضمنا يسمح لك بعرض تطبيقاتك لحركة المرور القادمة من خارج الحاوية. يقع دخول Container Apps بين تطبيقك والمستخدم النهائي. نظرا لأن الدخول يعمل كوسيط، أيا كان ما يراه المستخدم النهائي ينتهي عند الدخول، وأيا كان ما يراه تطبيقك يبدأ عند الدخول.

يدير الدخول إنهاء TLS والمجالات المخصصة، مما يلغي الحاجة إلى تكوينها يدويا في تطبيقك. من خلال الدخول، يتم عرض المنفذ 443 لحركة مرور HTTPS، والمنفذ 80 اختياريا لحركة مرور HTTP. يقوم الدخول بإعادة توجيه الطلبات إلى تطبيقك في المنفذ الهدف الخاص به.

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

لمعرفة المزيد، راجع دخول HTTP في Azure Container Apps.

تعريف منفذ هدف

لتلقي نسبة استخدام الشبكة، يتم تكوين الدخول على منفذ هدف حيث يستمع تطبيقك لحركة المرور.

عند تشغيل ASP.NET Core في حاوية، يستمع التطبيق إلى المنافذ كما تم تكوينها في صورة الحاوية. عند استخدام صور ASP.NET Core الرسمية، يتم تكوين تطبيقك للاستماع إلى HTTP على منفذ افتراضي. يعتمد المنفذ الافتراضي على إصدار ASP.NET Core.

وقت التشغيل المنفذ الهدف
ASP.NET Core 7 والإصدارات السابقة 80
ASP.NET Core 8 والإحدث 8080

عند تكوين الدخول، قم بتعيين المنفذ الهدف إلى الرقم المقابل لصورة الحاوية التي تستخدمها.

تعريف الرؤوس التي تمت إعادة توجيهها X

بينما يتعامل الدخول مع طلب HTTP الأصلي، يرى التطبيق الخاص بك الدخول على أنه العميل. هناك بعض الحالات التي يحتاج فيها تطبيقك إلى معرفة عنوان IP الخاص بالعميل الأصلي أو البروتوكول الأصلي (HTTP أو HTTPS). يمكنك الوصول إلى البروتوكول ومعلومات IP عبر عنوان الطلبX-Forwarded-*.

يمكنك قراءة القيم الأصلية من هذه الرؤوس عن طريق الوصول إلى ForwardedHeaders الكائن.

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

لمزيد من المعلومات حول العمل مع رؤوس الطلبات، راجع تكوين ASP.NET Core للعمل مع خوادم الوكيل وموازنات التحميل.

إنشاء تطبيقات .NET أصلية على السحابة

غالبا ما تعمل التطبيقات المنشورة في Container Apps بشكل أفضل عند البناء على أسس المبادئ الأصلية على السحابة. تساعد الأقسام التالية في تفاصيل المخاوف الشائعة المحيطة بالتطبيقات الأصلية على السحابة.

تكوين التطبيق

عند نشر تطبيق .NET الخاص بك إلى Azure Container Apps، استخدم متغيرات البيئة لتخزين معلومات التكوين بدلا من استخدام appsettings.json. تسمح لك هذه الممارسة بتكوين تطبيقك بطرق مختلفة في بيئات مختلفة. بالإضافة إلى ذلك، يؤدي استخدام متغيرات البيئة إلى تسهيل إدارة قيم التكوين دون الحاجة إلى إعادة إنشاء صورة الحاوية وإعادة نشرها.

في Azure Container Apps، يمكنك تعيين متغيرات البيئة عند تعريف التطبيق أو حاوية الوظيفة. تخزين القيم الحساسة في البيانات السرية والإشارة إليها كمتغيرات البيئة. لمعرفة المزيد حول إدارة الأسرار، راجع إدارة الأسرار في Azure Container Apps.

الهوية المُدارة

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

تسجيل الدخول

في بيئة سحابية أصلية، يعد التسجيل أمرا بالغ الأهمية لمراقبة تطبيقاتك واستكشاف الأخطاء وإصلاحها. بشكل افتراضي، تستخدم Azure Container Apps Azure Log Analytics لجمع السجلات من حاوياتك. يمكنك تكوين موفري تسجيل آخرين. لمعرفة المزيد حول تسجيل التطبيق، راجع تخزين السجل وخيارات المراقبة في Azure Container Apps.

عند تكوين موفر تسجيل يكتب سجلات إلى وحدة التحكم، تجمع Azure Container Apps رسائل السجل وتخزنها نيابة عنك.

تحقيقات الصحة

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

للحصول على فرصة لتنفيذ منطق مخصص لتحديد صحة التطبيق الخاص بك، يمكنك تكوين نقطة نهاية فحص السلامة. لمعرفة المزيد حول نقاط نهاية التحقق من الصحة، راجع عمليات التحقق من الصحة في ASP.NET Core.

اعتبارات التحجيم التلقائي

بشكل افتراضي، تقوم Azure Container Apps تلقائيا بتغيير حجم تطبيقات ASP.NET Core استنادا إلى عدد طلبات HTTP الواردة. يمكنك أيضا تكوين قواعد التحجيم التلقائي المخصصة استنادا إلى مقاييس أخرى، مثل وحدة المعالجة المركزية أو استخدام الذاكرة. لمعرفة المزيد حول التحجيم، راجع تعيين قواعد التحجيم في Azure Container Apps.

في .NET 8.0.4 والإحدث، يتم تكوين تطبيقات ASP.NET Core التي تستخدم حماية البيانات تلقائيا للحفاظ على البيانات المحمية في متناول جميع النسخ المتماثلة مع تحجيم التطبيق. عندما يبدأ تطبيقك في التوسع، يتعامل مدير المفاتيح مع مفاتيح الكتابة والمشاركة عبر مراجعات متعددة. عند نشر التطبيق، يتم تعيين true متغير autoConfigureDataProtection البيئة تلقائيا لتمكين هذه الميزة. لمزيد من المعلومات حول هذا التكوين التلقائي، راجع طلب سحب GitHub هذا.

يغير التحجيم التلقائي عدد النسخ المتماثلة لتطبيقك استنادا إلى القواعد التي تحددها. بشكل افتراضي، توجه Container Apps حركة المرور الواردة عشوائيا إلى النسخ المتماثلة لتطبيق ASP.NET Core. نظرا لأن نسبة استخدام الشبكة يمكن أن تقسم بين نسخ متماثلة مختلفة، يجب أن يكون تطبيقك عديم الحالة حتى لا يواجه تطبيقك مشكلات متعلقة بالحالة.

تعتمد ميزات مثل مكافحة التزوير والمصادقة و SignalR و Blazor Server و Razor Pages على حماية البيانات تتطلب تكوينا إضافيا للعمل بشكل صحيح عند التحجيم إلى نسخ متماثلة متعددة.

تكوين حماية البيانات

يحتوي ASP.NET Core على ميزات خاصة لحماية البيانات وإلغاء حمايةها، مثل بيانات الجلسة والرموز المميزة لمكافحة التزوير. بشكل افتراضي، يتم تخزين مفاتيح حماية البيانات على نظام الملفات، وهو غير مناسب لبيئة سحابية أصلية.

إذا كنت تقوم بنشر تطبيق .NET Aspire، يتم تكوين حماية البيانات تلقائيا لك. في جميع الحالات الأخرى، تحتاج إلى تكوين حماية البيانات يدويا.

تكوين ASP.NET Core SignalR

يتطلب ASP.NET Core SignalR مخططا خلفيا لتوزيع الرسائل على نسخ متماثلة متعددة للخادم. عند نشر تطبيق ASP.NET Core باستخدام SignalR إلى Azure Container Apps، يجب عليك تكوين إحدى الخطط الخلفية المدعومة، مثل Azure SignalR Service أو Redis. لمعرفة المزيد حول الطائرات الخلفية، راجع ASP.NET استضافة وتحجيم Core SignalR.

تكوين خادم Blazor

ASP.NET تخزن تطبيقات Core Blazor Server حالة على الخادم، ما يعني أنه يجب توصيل كل عميل بنفس النسخة المتماثلة للخادم أثناء جلسة العمل الخاصة به. عند نشر تطبيق Blazor Server إلى Azure Container Apps، يجب تمكين جلسات العمل الملصقة للتأكد من توجيه العملاء إلى نفس النسخة المتماثلة. لمعرفة المزيد، راجع ترابط الجلسة في Azure Container Apps.