تكوين فحوصات الحيوية

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

تشرح هذه المقالة كيفية نشر مجموعة حاويات تتضمن مسبارًا حيويًا؛ مما يوضح إعادة التشغيل التلقائي لحاوية غير صحية تمت محاكاتها.

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

نشر YAML

قم بإنشاء ملف liveness-probe.yaml بالمقتطف التالي. يعرّف هذا الملف مجموعة الحاويات التي تتكون من حاوية NGINX التي تصبح في النهاية غير صحية.

apiVersion: 2019-12-01
location: eastus
name: livenesstest
properties:
  containers:
  - name: mycontainer
    properties:
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      command:
        - "/bin/sh"
        - "-c"
        - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
      ports: []
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
      livenessProbe:
        exec:
            command:
                - "cat"
                - "/tmp/healthy"
        periodSeconds: 5
  osType: Linux
  restartPolicy: Always
tags: null
type: Microsoft.ContainerInstance/containerGroups

قم بتشغيل الأمر التالي لنشر مجموعة الحاوية هذه مع تكوين YAML السابق:

az container create --resource-group myResourceGroup --name livenesstest -f liveness-probe.yaml

ابدأ الأمر

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

أولا، يبدأ جلسة عمل bash وينشئ ملفا يسمى healthy داخل /tmp الدليل. ثم ينام لمدة 30 ثانية قبل حذف الملف، ثم يدخل في وضع السكون لمدة 10 دقائق:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

أمر الحياة

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

periodSeconds تحدد الخاصية أمر الحياة التي يجب تنفيذها كل 5 ثوان.

تحقق من إخراج الحياة

في غضون أول 30 ثانية، يوجد الملف الذي healthy تم إنشاؤه بواسطة أمر البدء. عندما يتحقق الأمر liveness من healthy وجود الملف، تقوم التعليمة البرمجية للحالة بإرجاع 0، مما يشير إلى النجاح، لذلك لا تحدث إعادة تشغيل.

بعد 30 ثانية، يبدأ الأمر في cat /tmp/healthy الفشل، مما يتسبب في حدوث أحداث غير صحية وقتل.

يمكن عرض هذه الأحداث من مدخل Microsoft Azure أو Azure CLI.

من خلال عرض الأحداث في مدخل Microsoft Azure، يتم تشغيل الأحداث من النوع Unhealthy عند فشل أمر الحياة. الحدث التالي من النوع Killing، مما يدل على حذف حاوية حتى يمكن بدء إعادة التشغيل. يتزايد عدد مرات إعادة التشغيل للحاوية في كل مرة يقع فيها هذا الحدث.

يتم إكمال عمليات إعادة التشغيل في نفس المكان؛ لذا يتم الاحتفاظ بالموارد؛ مثل: عناوين IP العامة، والمحتويات الخاصة بالعقدة.

إذا فشل مسبار الحياة بشكل مستمر، وأدى إلى إعادة تشغيل العديد من عمليات إعادة التشغيل، فستدخل الحاوية الخاصة بك في تأخير أسي للتراجع.

تحقيقات الحياة، وإعادة تشغيل السياسات

تحل سياسات إعادة التشغيل محل سلوك إعادة التشغيل الناتج عن تحقيقات الحيوية. على سبيل المثال، إذا قمت بتعيين restartPolicy = Never وفحص فعالية، فلن تتم إعادة تشغيل مجموعة الحاوية بسبب فشل فحص الحياة. مجموعة الحاوية بدلا من ذلك تلتزم بسياسة إعادة تشغيل مجموعة الحاوية الخاصة ب Never.

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

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