الأسئلة المتداولة FAQ حول تكوين تطبيق Azure

يساعد تكوين التطبيق المطورين على إدارة إعدادات التطبيق والتحكم في توفر الميزات. يهدف إلى تبسيط العديد من مهام العمل مع بيانات التكوين المعقدة.

يدعم تكوين التطبيق:

• مساحات الاسم الهرمية
• التسمية
• استفسارات واسعة النطاق
• استرجاع الدفعة
• عمليات الإدارة المتخصصة
• واجهة مستخدم لإدارة الميزات

يكمل تكوين التطبيق Key Vault، ويجب استخدام الاثنَين جنبًا إلى جنب في معظم عمليات نشر التطبيقات.

على الرغم من أن تكوين التطبيق يوفر أمانًا أكثر صرامة، فلإن Key Vault لا يزال أفضل مكان لتخزين أسرار التطبيق. يوفر Key Vault تشفيرًا على مستوى الأجهزة وسياسات وصول دقيقة وعمليات إدارية مثل تدوير الشهادة.

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

نعم. يقوم تكوين التطبيق دائمًا بتشفير جميع البيانات في أثناء النقل وفي حالة الثبات. جميع اتصالات الشبكة عبر TLS 1.2 أو TLS 1.3. يدعم تكوين التطبيق التشفير في وضع الثبات إما باستخدام المفاتيح التي تديرها Microsoft أو المفاتيح التي يديرها العميل.

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

في المقابل، يسمح لك تكوين تطبيق Azure بتحديد الإعدادات التي يمكن مشاركتها بين تطبيقات متعددة. يتضمن ذلك التطبيقات التي تعمل في خدمة التطبيقات، بالإضافة إلى الأنظمة الأساسية الأخرى. يصل رمز التطبيق الخاص بك إلى هذه الإعدادات من خلال موفري التكوين لـ .NET وJava، من خلال Azure SDK، أو مباشرة عبر REST APIs.

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

هناك حد 10 كيلوبايت لقيمة مفتاح واحدة، بما في ذلك خصائص مثل عنوان، نوع المحتوى، علامات التمييز، وبيانات أولية أخرى.

يجب أن يكون هذا الحد كافيًا لإعداد واحد في معظم التطبيقات. إذا وجدت أن الإعداد أكبر من هذا الحد، فقد تفكر في تخزين بياناتك في مكان آخر، وإضافة مرجع لتلك البيانات في App Configuration.

لمزيد من المعلومات، راجع حدود الاشتراك والخدمة في Azure.

يمكنك التحكم فيمن يمكنه الوصول إلى تكوين التطبيق على مستوى كل متجر. استخدم متجرًا منفصلاً لكل بيئة تتطلب أذونات مختلفة. يوفر هذا الأسلوب عزل الأمان الأفضل.

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

راجع أفضل الممارسات.

هناك نوعان من مستويات الأسعار:

• المستوى المجاني
• المستوى القياسي

إذا قمت بإنشاء متجر قبل تقديم المستوى القياسي، فإنه ينتقل تلقائيًا إلى الطبقة المجانية عند التوفر العام. يمكنك اختيار الترقية إلى المستوى القياسي أو البقاء في المستوى المجاني.

لا يمكنك إرجاع متجر من المستوى القياسي إلى المستوى المجاني. يمكنك إنشاء متجر جديد في الطبقة المجانية ثم استيراد بيانات التكوين إلى هذا المتجر.

يوفر كلا مستويي App Configuration وظائف أساسية، بما في ذلك إعدادات التكوين وعلامات الميزات ومراجع Key Vault ولقطات التكوين وعمليات الإدارة الأساسية والمقاييس والسجلات.

فيما يلي اعتبارات لاختيار الطبقة.

• الموارد لكل اشتراك: يتكون المورد من مخزن تكوين واحد. يقتصر كل اشتراك على مخزن تكوين واحد لكل منطقة في المستوى المجاني. يمكن أن تحتوي الاشتراكات على عدد غير محدود من مخازن التكوين في المستوى القياسي.

• التخزين لكل مورد: في المستوى المجاني، يقتصر كل مخزن تكوين على 10 ميغابايت من التخزين العادي و10 ميغابايت من تخزين اللقطة. في المستوى القياسي، يمكن لكل مخزن تكوين استخدام ما يصل إلى 1 غيغابايت من التخزين العادي ومساحة تخزين لقطات إضافية 1 غيغابايت.

• محفوظات المراجعة: يخزن App Configuration محفوظات لجميع التغييرات التي تم إجراؤها على المفاتيح. في الطبقة المجانية، يتم تخزين هذا السجل لمدة سبعة أيام. في المستوى القياسي، يتم تخزين هذا السجل لمدة 30 يومًا.

• الحصة النسبية للطلبات: تقتصر مخازن الطبقة المجانية على 1000 طلب في اليوم. عندما يصل المتجر إلى 1000 طلب، فإنه يُرجع HTTP رمز حالة 429 لجميع الطلبات حتى منتصف الليل بالتوقيت العالمي المنسق.

  تقتصر متاجر المستوى القياسي على 30000 طلب في الساعة. عند استنفاد الحصة المحددة لكل ساعة، قد تُرجع طلبات HTTP الى رمز حالة 429 الذي يشير إلى عدد كبير جدًا من الطلبات حتى نهاية الساعة. نظرًا لإرسال المزيد من الطلبات التي تزيد عن الحصة المحددة، فقد تُرجع نسبة أعلى منها رمز الحالة 429.

• اتفاقية مستوى الخدمة: يحتوي المستوى القياسي على اتفاقية مستوى الخدمة (SLA) بنسبة توفر بنسبة 99.9٪ وتوافر بنسبة 99.95٪ مع تمكين النسخ المتماثل الجغرافي. لا تحتوي الطبقة المجانية على اتفاقية مستوى الخدمة (SLA).

• الميزات: يتضمن كلا المستويين وظائف، بما في ذلك التشفير باستخدام المفاتيح المدارة من Microsoft، والمصادقة عبر مفتاح الوصول أو معرف Microsoft Entra، والتحكم في الوصول المستند إلى الدور في Azure (RBAC)، والهوية المدارة، وعلامات الخدمة، وتكرار منطقة التوفر. يوفر المستوى القياسي المزيد من الوظائف، بما في ذلك دعم الارتباط الخاص، والتشفير باستخدام المفاتيح التي يديرها العميل، وحماية الحذف المبدئي، وقدرة النسخ المتماثل الجغرافي.

• التكلفة: مخازن المستوى القياسي لها رسوم استخدام يومية. يتم تضمين أول 200,000 طلب كل يوم في الرسوم اليومية. هناك أيضًا رسوم زائدة للطلبات التي تتجاوز التخصيص اليومي. لا توجد تكلفة لاستخدام متجر فئة مجاني.

يمكنك الترقية من المستوى المجاني إلى المستوى القياسي في أي وقت.

لا يمكنك إرجاع متجر من المستوى القياسي إلى المستوى المجاني. يمكنك إنشاء مخزن جديد في المستوى المجاني ثم استيراد بيانات التكوين إلى هذا المخزن.

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

يدعم Azure App Configuration النسخ المتماثل الجغرافي لتحسين المرونة في الانقطاعات الإقليمية.

Azure App Configuration يدعم Azure availability zones لحماية التطبيق والبيانات من حالات فشل مركز البيانات الفردي. تتكون جميع المناطق الممكّنة من مناطق توفر من 3 مناطق توفر على الأقل، حيث يكون كل منها مركز بيانات مستقلاً فعليًا. من أجل المرونة، يتم تمكين هذا الدعم في تكوين التطبيق لجميع العملاء دون أي تكلفة إضافية. فيما يلي المناطق التي مكّن فيها App Configuration دعم منطقة توفر. لمزيد من المعلومات، راجع المناطق وAvailability Zones في Azure.

فيما يلي المناطق حيث مكّن فيها App Configuration دعم منطقة توفر.

مخازن التهيئة في الطبقة المجانية محدودة بـ 1000 طلب في اليوم. قد تواجه مخازن التكوين في الطبقة القياسية اختناقًا مؤقتًا عندما يتجاوز معدل الطلب 30000 طلب في الساعة.

عندما يصل المتجر إلى حده في المستوى القياسي، فقد يرجع HTTP لرمز حالة 429 لبعض الطلبات التي يتم إجراؤها حتى نهاية الساعة. retry-after-ms يعطي العنوان في الاستجابة وقت انتظار مقترح (بالمللي ثانية) قبل إعادة محاولة الطلب.

إذا كان تطبيقك يواجه بانتظام استجابات HTTP كود حالة 429 ففكر في إعادة تصميمه لتقليل عدد الطلبات المقدمة. لمزيد من المعلومات، راجع كيفية تقليل الطلبات المقدمة إلى App Configuration.

ستتلقى استجابة HTTP رمز حالة 429 في ظل هذه الظروف:

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

تحقق من نص الاستجابة 429 لمعرفة السبب المحدد لفشل الطلب.

قد يواجه مخزن تكوين †A تقييدا لحظيا إذا تلقى اندفاعا كبيرا من الطلبات أو نقل حجم مفرط من البيانات. يقوم عملاء تكوين التطبيق، مثل Azure SDK ومكتبات موفر التكوين ومهام Azure Pipelines، بإعادة المحاولة تلقائيا على الطلبات المقيدة. بالنسبة لأي تطبيق يستخدم أحد هذه التطبيقات أو عميل مخصص يقوم بإعادة المحاولة بناء على طلبات مضغوطة، يجب عدم ملاحظة هذا الاختناق اللحظي إذا حدث.

لنأخذ مثالا ونفترض أن لديك تطبيقا يحتوي على 1000 إعداد تكوين. يقوم تطبيقك بتحميل كل هذه الإعدادات من App Configuration عند بدء التشغيل. بعد ذلك، يتحقق من مفتاح sentinel لتغييرات التكوين كل 30 ثانية. سواء كنت تعمل على Kubernetes أو App Service أو VMs، فلنفترض أن لديك 50 مثيلا من تطبيقك قيد التشغيل في وقت واحد.

أولا، دعونا نقدر طلبات مراقبة التكوين. سيرسل كل مثيل من تطبيقك طلبا واحدا لمفتاح sentinel إلى App Configuration كل 30 ثانية، لذلك سيرسل 120 طلبا (=3600/30) في ساعة واحدة. نظرا لأن لديك 50 مثيلا للتطبيق الخاص بك، يرسل التطبيق الخاص بك إجمالي 6000 طلب (=120x50) كل ساعة لمراقبة التكوين. لاحظ أنه نظرا لأن طلبات مفتاح sentinel متكررة وغير متغيرة في الغالب، فلن يتم احتساب معظمها مقابل حدود الحصة النسبية للساعة للمتجر†.

ثانيا، لنقدر طلبات تحميل/إعادة تحميل التكوين. يقوم التطبيق الخاص بك بتحميل جميع الإعدادات عند بدء التشغيل أو كلما تم الكشف عن تغيير مفتاح sentinel. يمكن لكل طلب إلى App Configuration استرداد ما يصل إلى 100 قيمة مفتاح، لذلك سيستغرق تحميل جميع الإعدادات 10 طلبات (=1000/100). نظرا لأن لديك 50 مثيلا للتطبيق، فإنك ترسل إجمالي 500 طلب (=10x50) عند إعادة تشغيل التطبيق أو إعادة تحميل التكوين الخاص به.

وأخيرا، دعونا نضعها معا. بافتراض أنك قمت بتحديث مفتاح sentinel مرتين في غضون ساعة، سيتلقى متجر App Configuration 7000 طلب إجمالي لتلك الساعة (=6000+500x2). لاحظ أنه من بين هذه الطلبات، سيستخدم حوالي 1000 طلب فقط (=500x2) الحصة النسبية المتوفرة بالساعة. قم بتحديث الأرقام الموجودة في هذا المثال لمطابقة الإعداد والتصميم المحددين وفقا لذلك بحيث يكون لديك مخزن مؤقت كاف مقابل حد التقييد بالساعة. لمزيد من المعلومات، راجع كيفية تقليل الطلبات المقدمة إلى App Configuration.

† لا تحتوي مخازن المستوىFree على طلبات متكررة ومتكررة مستبعدة من حدها اليومي.

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

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

نعم. بينما يمكنك إدارة علامات الميزات ومراجع Key Vault في تكوين التطبيق من خلال مدخل Microsoft Azure أو CLI، يمكنك أيضا إنشاؤها وتحديثها برمجيا باستخدام حزم SDK لتكوين التطبيق. لذلك، يمكنك كتابة مدخل الإدارة المخصص أو إدارتها في CI/CD برمجيا. تتوفر علامة الميزة وواجهات برمجة التطبيقات المرجعية Key Vault في حزم SDK من جميع اللغات المدعومة. تحقق من نماذج الارتباطات للحصول على أمثلة في كل لغة مدعومة.

يتطلب تقييم علامات الميزات واستهلاكها في التطبيق الخاص بك موفر تكوين التطبيق ومكتبات إدارة الميزات، والتي تتوفر في .NET وJava Spring. راجع قسم إدارة الميزات ضمن التشغيل السريع والبرامج التعليمية لمزيد من المعلومات.

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

يوصى بتعيين تسمية قيم المفاتيح الخاصة بك لمطابقة ملفات تعريف Spring الخاصة بك. بشكل افتراضي، ستقوم مكتبة موفر Spring لتكوين التطبيق بتحميل قيم المفاتيح مع التسمية (التسميات) المطابقة لملف تعريف (ملفات) Spring النشط الحالي (${spring.profiles.active}) إذا لم يتم تعيين عامل تصفية التسمية بشكل صريح. إذا لم تكن هناك مجموعة ملفات تعريف Spring نشطة، فسيتم تحميل قيم المفاتيح التي تحتوي على "بلا تسمية".

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

عند تعيين ملف تعريف Spring إلى dev، ستكون Hello from devقيمة config.message . عند تعيين ملف تعريف Spring إلى prod، ستكون Hello from prodقيمة config.message .

يمكن تجاوز هذا السلوك الافتراضي عن طريق تعيين عامل تصفية التسمية في ملف bootstrap. ستقوم مكتبة موفر Spring بتحميل قيم المفاتيح بالتسمية (التسميات) المحددة بغض النظر عن ملف تعريف Spring النشط.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

لتحديد تسميات أخرى وملف تعريف (ملفات) Spring، يمكنك استخدام عامل تصفية تسمية مثل ',${spring.profiles.active}'، والذي سيحدد جميع المفاتيح بدون تسمية وتلك التي تطابق ملفات تعريف Spring. تأخذ التسمية (التسميات) الموجودة في أقصى اليمين الأولوية عند العثور على مفاتيح مكررة.

بدءا من الإصدار 3.1.0، Microsoft.FeatureManagement تسمح المكتبة بتشغيل خدمات إدارة الميزات، بما في ذلك عوامل تصفية الميزات، كخدمات محددة النطاق في تطبيقات .NET المستندة إلى حقن التبعية. للاستفادة من هذه الميزة، يمكنك ببساطة استبدال AddFeatureManagement الاستدعاء في التعليمات البرمجية الخاصة بك ب AddScopedFeatureManagement، كما هو موضح في القصاصة البرمجية التالية:

services.AddScopedFeatureManagement();

يمكن لعوامل تصفية الميزات تقييم علامة ميزة استنادا إلى خصائص طلب HTTP. يتم تنفيذ هذا عادة عن طريق فحص HttpContext من خلال نمط singletonIHttpContextAccessor. ومع ذلك، لا يعمل هذا النمط لتطبيقات خادم Blazor حيث يجب استخدام الخدمات محددة النطاق بدلا من ذلك. في هذه الحالة، AddScopedFeatureManagement يجب استخدام الأسلوب.

اشترك في مستودع إعلانات GitHub.

يمكنك الوصول إلينا مباشرة على GitHub.

• حول تكوين تطبيق Azure