استكشاف المشكلات الشائعة وإصلاحها في Azure Container Instances

مقالة
05/24/2023

توضح هذه المقالة كيفية استكشاف الأخطاء وإصلاحها للمشكلات الشائعة في إدارة أو نشر حاويات إلى Azure Container Instances. انظر أيضاً الأسئلة المتداولة.

إذا كنت بحاجة إلى مزيد من الدعم، فشاهد خيارات المساعدة + الدعم المتوفرة في مدخل Microsoft Azure.

مشكلات أثناء نشر مجموعة الحاويات

تقاليد التسمية

عند تعريف مواصفات الحاوية، تتطلب معلمات معينة الالتزام بقيود التسمية. فيما يلي جدول مع متطلبات محددة لخصائص مجموعة الحاويات. لمزيد من المعلومات، راجع إصلاحات التسمية في Azure Architecture Center وقواعد التسمية والقيود الخاصة بموارد Azure.

النطاق	الطول	حالة الأحرف	الأحرف الصالحة	نمط مقترح	مثال
اسم الحاوية¹	1-63	أحرف صغيرة	الأبجدية الرقمية، والواصلة في أي مكان باستثناء الحرف الأول أو الأخير	`<name>-<role>-container<number>`	`web-batch-container1`
منافذ الحاويات	بين 1 و65535	رقم صحيح	عدد صحيح بين 1 و65535	`<port-number>`	`443`
تسمية اسم DNS	5-63	غير حساس لحالة الأحرف	الأبجدية الرقمية، والواصلة في أي مكان باستثناء الحرف الأول أو الأخير	`<name>`	`frontend-site1`
متغير البيئة	1-63	غير حساس لحالة الأحرف	الأبجدية الرقمية، وتسطير سفلي (_) في أي مكان باستثناء الحرف الأول أو الأخير	`<name>`	`MY_VARIABLE`
اسم وحدة التخزين	5-63	أحرف صغيرة	الأبجدية الرقمية، والواصلات في أي مكان باستثناء الحرف الأول أو الأخير. لا يمكن أن تحتوي على واصلتين متتاليتين.	`<name>`	`batch-output-volume`

¹ تقييد أيضاً لأسماء مجموعات الحاويات عند عدم تحديدها مستقلة عن مثيلات الحاوية، على سبيل المثال مع أمر عمليات النشر az container create.

إصدار نظم تشغيل الصورة غير مدعوم

إذا حددت صورة لا يدعمها Azure Container Instances، فسيُرجع خطأ OsVersionNotSupported. الخطأ مشابه لما يلي، حيث {0} هو اسم الصورة التي حاولت نشرها:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

غالباً تتلقى هذا الخطأ عند نشر صور Windows تستند إلى إصدار تحديث نصف سنوي 1709 أو 1803، وهي غير مدعومة. للحصول على صور Windows مدعومة في Azure Container Instances، راجع الأسئلة المتداولة.

غير قادر على سحب الصورة

إذا كانت Azure Container Instances غير قادرة في البداية على سحب صورتك، فإنها تعيد المحاولة للوقت. إذا استمر فشل عملية سحب الصور، فإن ACI يفشل في النشر في نهاية المطاف، وقد ترى خطأ Failed to pull image.

لحل هذه المشكلة، احذف مثيل الحاوية ثم أعد محاولة النشر. تأكد من وجود الصورة في السجل، ومن كتابة اسم الصورة بشكل صحيح.

إذا كان لا يمكن سحب الصورة، فستظهر الأحداث مثل ما يلي في إخراج az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

خطأ المورد غير متوفر

بسبب تحميل الموارد الإقليمية متفاوتة في Azure، قد تتلقى الخطأ التالي عند محاولة نشر مثيل حاوية:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

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

تحقق من أن إعدادات نشر الحاوية الخاصة بك تقع ضمن المعلمات المُعرفة في توفر المنطقة لـ Azure Container Instances
تحديد إعدادات CPU وذاكرة أقل للحاوية
النشر إلى منطقة Azure مختلفة
النشر في وقت لاحق

مشكلات أثناء وقت التشغيل مجموعة الحاويات

تمت إعادة تشغيل الحاوية بشكل منفصل بدون إدخال المستخدم الصريح

هناك فئتان رئيسيتان لسبب إمكانية إعادة تشغيل مجموعة الحاوية بدون إدخال المستخدم الصريح. أولاً، قد تواجه الحاويات عمليات إعادة تشغيل ناتجة عن تعطل عملية التطبيق. توصي خدمة ACI بتطبيق حلول إمكانية المراقبة مثل Application Insights SDK ومقاييس مجموعة الحاويات وسجلات مجموعة الحاويات لتحديد سبب مشكلات التطبيق. ثانياً، قد يواجه العملاء عمليات إعادة التشغيل التي بدأتها البنية الأساسية لـ ACI بسبب أحداث الصيانة. لزيادة توفر التطبيق الخاص بك، قم بتشغيل مجموعات حاويات متعددة خلف أحد مكونات الإدخال مثل Application بوابة أو Traffic Manager.

خروج الحاوية وإعادة تشغيلها باستمرار (ليست هناك عملية تشغيل طويلة)

تعيين مجموعات الحاويات الافتراضية إلى نهج إعادة تشغيل "Always"، لذلك يُعاد تشغيل الحاويات في مجموعة الحاويات دائماً بعد تشغيلها إلى الاكتمال. قد تحتاج إلى تغيير هذا إلى "OnFailure" أو "Never" إذا كنت تنوي تشغيل الحاويات المُستندة إلى المهام. إذا حددت OnFailure ولا تزال ترى عمليات إعادة التشغيل المستمرة، فقد تكون هناك مشكلة في التطبيق أو البرنامج النصي المُنفذ في الحاوية.

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

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

تتضمن واجهة برمجة تطبيقات مثيلات الحاوية ومدخل Azure خاصية restartCount . للتحقق من عدد عمليات إعادة التشغيل لحاوية، يمكنك استخدام الأمرaz container show في Azure CLI. في إخراج المثال التالي (المُقتطع للإيجاز)، يمكنك مشاهدة الخاصية restartCount في نهاية الإخراج.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

إشعار

معظم صور الحاويات لتوزيعات Linux تُعين shell، مثل Bash، كأمر افتراضي. نظراً لأن shell بمفردها ليست خدمة مستمرة لفترة طويلة، هذه الحاويات تخرج فوراً وتقع في تكرار حلقي من إعادة التشغيل عند تكوينها مع نهج إعادة التشغيل Always الافتراضي.

حاوية تستغرق وقتاً طويلاً للبدء

العوامل الأساسية الثلاثة التي تساهم في وقت بدء تشغيل الحاوية في Azure Container Instances هي:

حجم الصورة
موقع الصورة
الصور المُخزنة مؤقتاً

صور Windows لديها اعتبارات إضافية.

حجم الصورة

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

يمكنك عرض حجم صورة الحاوية باستخدام الأمر docker images في Docker CLI:

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

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

موقع الصورة

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

الصور المخزنة مؤقتاً

يستخدم Azure Container Instances آلية تخزين مؤقت للمساعدة في تسريع وقت بدء تشغيل الحاوية للصور المُضمنة في صور Windows أساسية شائعة، بما في ذلك nanoserver:1809، servercore:ltsc2019، وservercore:1809. تُخزن صور Linux شائعة الاستخدام مثل ubuntu:1604 وalpine:3.6 مؤقتاً. بالنسبة لكل من صور Windows وصور Linux، تجنب استخدام علامة latest. راجع أفضل ممارسات علامات الصور الخاصة بسجل الحاويات للحصول على إرشادات. للحصول على قائمة محدثة من الصور والعلامات المخزنة مؤقتاً، استخدم واجهة برمجة تطبيقات قائمة الصور المخزنة مؤقتاً.

إشعار

استخدام صور Windows المستندة إلى خادم 2019 في Azure Container Instances في الإصدار الأولي.

حاويات Windows تُبطئ جاهزية الشبكة

في الإنشاء الأولي، قد لا يكون لدى حاويات Windows اتصالية واردة أو صادرة لمدة تصل إلى 30 ثانية (أو أكثر، في حالات نادرة). إذا كان تطبيق الحاوية يحتاج إلى اتصال بالإنترنت، فأضف منطق التأخير وإعادة المحاولة للسماح بـ 30 ثانية لتأسيس اتصالية بالإنترنت. بعد الإعداد الأولي، يجب استئناف شبكة الحاوية بشكل مناسب.

لا يمكن الاتصال بواجهة برمجة تطبيقات Docker الأساسية أو تشغيل الحاويات المتميزة

لا يعرض Azure Container Instances الوصول المباشر إلى البنية الأساسية التي تستضيف مجموعات الحاويات. يتضمن ذلك الوصول إلى وقت تشغيل الحاوية وتكنولوجيا التنسيق وتشغيل عمليات الحاوية المتميزة. لمعرفة العمليات التي يدعمها ACI، تحقق من الوثائق المرجعية REST. إذا كان هناك شيء مفقود، فأرسل طلباً على منتديات تعليقات ACI.

قد يكون عنوان IP لمجموعة الحاويات غير قابل للوصول بسبب المنافذ غير المتطابقة

لا يدعم Azure Container Instances تعيين المنفذ كما هو الحال مع تكوين docker العادي. إذا وجدت عنوان IP لمجموعة حاويات غير قابل للوصول بينما تعتقد أنه يجب الوصول إليه، فتأكد من تكوين صورة الحاوية الخاصة بك للإنصات إلى نفس المنافذ التي تعرضها في مجموعة الحاويات الخاصة بك مع الخاصية ports.

إذا كنت تريد تأكيد أن Azure Container Instances يمكنه الإنصات على المنفذ الذي كونته في صورة الحاوية، فاختبر نشر الصورة aci-helloworld التي تعرض المنفذ. أيضاً تشغيل التطبيق aci-helloworld إنصات على المنفذ. يقبل aci-helloworld متغير بيئة اختياري PORT لمنع المنفذ الافتراضي 80 الذي ينصت عليه. على سبيل المثال، لاختبار المنفذ 9000، عيّن متغير البيئة عند إنشاء مجموعة الحاوية:

إعداد مجموعة الحاويات لكشف المنفذ 9000 وتمرير رقم المنفذ كقيمة متغير البيئة. يُنسق المثال لـ Bash shell. إذا كنت تفضل shell آخر مثل PowerShell أو موجه الأوامر، فستحتاج إلى ضبط تعيين متغير وفقاً لذلك.
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
البحث عن عنوان IP لمجموعة الحاويات في إخراج الأمر من az container create. ابحث عن قيمة ip.
بعد توفير الحاوية بنجاح، استعرض للوصول إلى عنوان IP ومنفذ تطبيق الحاوية في متصفحك، على سبيل المثال: 192.0.2.0:9000.

يجب أن تشاهد رسالة "!Welcome to Azure Container Instances" التي يعرضها تطبيق الويب.
عند الانتهاء من الحاوية، أزلها باستخدام الأمر az container delete:
```
az container delete --resource-group myResourceGroup --name mycontainer
```

المشكلات أثناء عمليات نشر مجموعة الحاويات السرية

أخطاء النهج أثناء استخدام نهج CCE المخصص

يجب إنشاء نهج CCE المخصصة لملحق Confcom Azure CLI. قبل إنشاء النهج، تأكد من أن جميع الخصائص المحددة في قالب ARM الخاص بك صالحة وتتطابق مع ما تتوقع تمثيله في نهج الحوسبة السرية. تتضمن بعض الخصائص التي يجب التحقق من صحتها صورة الحاوية ومتغيرات البيئة وتركيبات وحدة التخزين والأوامر الحاوية.

تجزئة مفقودة من النهج

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

تم إنهاء العملية/الحاوية برمز الخروج: 139

يحدث رمز الخروج هذا بسبب القيود مع الصورة الأساسية Ubuntu الإصدار 22.04. التوصية هي استخدام صورة أساسية مختلفة لحل هذه المشكلة.

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

تعلم كيفية استرداد سجلات الحاوية والأحداث للمساعدة في تصحيح الحاويات الخاصة بك.

مشاركة عبر