‫أمر Docker Health Check. لقد كانت ميزة جديدة تمت إضافتها في 1. 12 ، الذي صدر في منتصف عام 2016 ، في نفس الوقت
‫الذي كان فيه Swarm Kit و Swarm Mode متاحين في Docker. تمت إضافته حقًا كجزء من مجموعة الأدوات هذه
‫، لكنه لا يزال يعمل في جميع الملفات المختلفة مثل Dockerfile ، وملف Compose ، ويستخدمه أمر
‫docker run ، وتدعمه ملفات Stack ، وتحديث الخدمة وأمر إنشاء الخدمة يدعمه
‫.
‫انها في كل مكان.
‫أوصي بشدة أنه عندما تذهب إلى الإنتاج ، فإنك تشارك في خيارات الاختبار لأمر الفحص
‫الصحي هذا.
‫ستعمل مباشرة خارج الصندوق مع تنفيذي.
‫سيتم تنفيذ هذا الأمر داخل الحاوية تمامًا كما لو كنت تقوم بتشغيل أمر exec
‫الخاص بك.
‫لذا ، فهي لا تشغلها من خارج الحاوية ؛ إنه مجرد تشغيله بالداخل مما يعني أنه
‫حتى العمال البسطاء الذين ليس لديهم منافذ مكشوفة ، يمكنك تشغيل أمر بسيط فيها للتحقق مما إذا
‫كانوا يعيدون بيانات جيدة أو أي شيء آخر.
‫إنه تنفيذ بسيط للأمر ، مما يعني أنه يحصل على عائد بسيط. تتوقع 0 أو 1.
‫في Linux و Windows ، لديك أكواد خروج من الأوامر والرقم 0 هو شيء جيد.
‫هذا يعني أن كل شيء كان على ما يرام.
‫أي شيء بخلاف 0 سيكون خطأ في معظم التطبيقات.
‫لكن في Docker ، نحتاج إلى هذا التطبيق للخروج من 1 على وجه التحديد. سنعرض خلال دقيقة كيف تفعل
‫ذلك.
‫هناك ثلاث ولايات فقط للفحص الصحي في Docker. يبدأ بالبدء. البداية هي أول 30 ثانية ، افتراضيًا
‫، حيث لم يتم تشغيل أمر healthcheck حتى الآن.
‫ثم سيتم تشغيل واحد.
‫إذا كان هذا يعيد 0 ، فسيبدأ بالصحي. سوف يتغير إلى الخيار الصحي.
‫سيستغرق الأمر هذا الأمر وسيتم تشغيله كل 30 ثانية بشكل افتراضي مرة أخرى. إذا تلقى في أي وقت عائدًا غير صحي ، مثل
‫المخرج 1 ، فإنه يصنفه على أنه حاوية غير صحية.
‫لدينا خيارات للتحكم في كل هذا بما في ذلك عمليات إعادة المحاولة.
‫سنرى ذلك في غضون دقيقة.
‫هذا خيار أفضل بكثير مما كان لدينا في الماضي لأن Docker ، حتى الآن ، كان فقط يتأكد من أن
‫التطبيق لا يزال قيد التشغيل.
‫لم يكن لديه أي فكرة عما إذا كان هذا التطبيق يفعل ما كان من المفترض أن يفعله.
‫الآن يمكننا القيام بذلك داخل حاوية Docker نفسها.
‫لكن هذا ليس بديلاً عن حل المراقبة الخاص بطرف ثالث.
‫لن يمنحك هذا الرسوم البيانية ، أو الحالة بمرور الوقت ، أو أي نوع من أدوات الطرف الثالث التي تتوقعها
‫من حل المراقبة.
‫يتعلق الأمر بفهم Docker إذا كانت الحاوية نفسها تتمتع بمستوى أساسي من الصحة.
‫لذلك ، في Nginx ، قد يُرجع مضيفًا محليًا لملف فهرس الجذر. عودة 200 أو 300 أمر جيد وتعطيها رمز
‫خروج 0 ، وتعتبرها صحية.
‫هذه ليست أداة مراقبة فائقة التطور ، كما تعلمون.
‫ولكن إذا أرجع الخطأ 404 أو 500 ، فسوف يعتبره غير صحي ويمكننا فعل شيء
‫حيال ذلك.
‫أين سنرى فحص Docker الصحي هذا في واجهة المستخدم الرسومية؟
‫المكان الأول في حاوية ls.
‫سيراه فقط كخيار جديد.
‫إنه في المنتصف. سنرى في ثانية حيث سيظهر لنا إحدى الحالات الثلاث إذا كان الفحص الصحي
‫قيد التشغيل ، وبهذه الطريقة نعرف بالفعل أن هناك فحصًا صحيًا.
‫هذه هي أسهل طريقة لمعرفة ذلك على الأقل. سنرى السجل ، الخمسة الأخيرين من هذا
‫الفحص الصحي ، يظهر في فحص تلك الحاوية. ويمكننا أن نرى بعض الاتجاهات الأساسية مع مرور الوقت هناك.
‫لكن أمر Docker run لا يتخذ أي إجراء بشأن حاوية غير صحية.
‫بمجرد أن يعتبر healthcheck أن الحاوية غير صحية ، فإن تشغيل عامل الإرساء سيشير فقط إلى ذلك
‫في الأمر ls وفي الفحص ، لكنه لن يتخذ أي إجراء.
‫هذا هو المكان الذي نتوقع فيه أن تتخذ Swarm Services إجراءات.
‫لذا فإن المكدسات والخدمات ستحل بالفعل محل تلك الحاوية بمهمة جديدة ، ربما على مضيف جديد ، اعتمادًا
‫على المجدول.
‫حتى في أمر التحديث ، نرى القليل من المكافآت الإضافية باستخدام healthchecks لأن التحديثات
‫ستعتبر التحقق الصحي جزءًا من الجاهزية لتلك الحاوية قبل أن تذهب وتغير الحاوية التالية.
‫إذا ظهرت حاوية ، لكنها لم تجتاز الفحص الصحي الخاص بها ، فلن ينتقل تحديث الخدمة
‫إلى التحديث التالي. أو ستتخذ إجراءً بناءً على التغييرات التي تقدمها.
‫دعونا نلقي نظرة على بعض الأمثلة قبل أن ننتقل إلى سطر الأوامر.
‫هذا هو الذي نستخدمه في Docker run.
‫يتيح لنا ذلك استخدام صورة حالية ليس بها فحص صحي ، ونضيف الفحص
‫الصحي في وقت التشغيل.
‫في هذه الحالة ، نستخدم صورة Elasticsearch. يمكنك أن ترى أن الأمر هو cURL localhost 9200
‫، وهو المنفذ الذي يعمل عليه Elasticsearch داخل الحاوية ، وليس المنفذ المنشور ، ولكن
‫داخل الحاوية. بالنسبة إلى Elasticsearch
‫، يوجد عنوان URL حقيقي للصحة.
‫لذا ، يمكننا استخدام ذلك هنا.
‫ستلاحظ وجود أنبوبين بهما خطأ في نهاية الأمر.
‫وسيكون هذا شائعًا
‫جدًا إذا كنت تستخدم شيئًا مثل cURL أو أداة أخرى سترسل رمز خطأ بخلاف 1.
‫أتذكر عندما ذكرت ذلك منذ فترة؟ نحتاجها للخروج بالرقم 1 إذا كانت هناك مشكلة. لأن هذا هو رمز الخطأ الوحيد
‫الذي سيفعل Docker شيئًا حياله.
‫نحتاج إلى التأكد من أنه في هذه الحالة ، ستعيد الصدفة دائمًا كود الخروج 1 الخاطئ إذا
‫كان هناك أي شيء يخرج من هذا الأمر بخلاف 0.
‫إنها طريقة رائعة للتغلب على هذه المشكلة.
‫يحدث ذلك تمامًا مع cURL ، ستعطي cURL رموز خطأ محتملة أخرى ولا نريدها أن
‫تفعل ذلك.
‫في ملفات Docker الفعلية ، يمكننا إضافة نفس الأمر. الشكل مختلف قليلاً. لكنك ترى أن لدينا
‫هذه الخيارات هنا. لدينا الفاصل الزمني ، والمهلة ، وفترة البدء (وهي جديدة) ، وإعادة المحاولة.
‫الفاصل الزمني هو ما تعتقد أنه هو. إنه افتراضيًا كل 30 ثانية.
‫كم مرة سيتم إجراء هذا الفحص الصحي. المهلة هي المدة التي ستنتظرها قبل أن تنتهي وتعيد
‫رمزًا سيئًا ، إذا كان التطبيق بطيئًا على الأرجح. فترة البدء هي ميزة جديدة تتيح
‫لنا الآن بعد 17 عامًا. 09 والأحدث ، لإعطاء فترة انتظار أطول من أول 30 ثانية من المدة. من قبل ، كانت تنتظر دائمًا
‫فترة طويلة ... الوقت الفاصل قبل بدء الفحص الصحي.
‫ولكن ربما يكون لديك تطبيق Java أو قاعدة بيانات أو شيء يستغرق وقتًا أطول لبدء العمل.
‫ربما يستغرق الأمر خمس دقائق.
‫يمكنك إضافة فترة البداية هناك. ستستمر في إجراء الفحوصات الصحية. ولكن ما سيفعله هو أنه
‫لن ينبهك بشأن الفحص غير الصحي حتى انقضاء ذلك الوقت.
‫لذلك إذا قمت بتعيين دقيقتين هناك ، على الرغم من أنه يتم التحقق من صحته كل 30 ثانية ، فسوف يعتبره غير
‫صحي فقط بمجرد تجاوز علامة الدقيقتين هذه. آخر مرة هناك ، إعادة المحاولة ، يعني
‫أننا سنحاول هذا الفحص الصحي × عدد المرات قبل أن نعتبره غير صحي.
‫ربما يمنح ذلك التطبيق غير المستقر فرصة للعودة بصحة جيدة والتعافي من تلقاء
‫نفسه قبل أن نعتبر هذه الحاوية غير صحية حقًا.
‫يسمى الأمر healthcheck الأساسي الذي ستستخدمه في Dockerfile
‫HEALTHCHECK ، وكلها بأحرف كبيرة. يوجد نفس التنسيق في حالة قيامنا فقط بإجراء عملية تجعيد بسيطة للمضيف المحلي لأنه
‫ربما يكون تطبيق PHP أو شيء من هذا القبيل. بإمكاننا أن نفعل ذلك.
‫هذه هي الطريقة التي ستضيف بها كل هذه الخيارات إلى Dockerfile حتى ترى كيف
‫أقوم بإضافة الفاصل الزمني للمهلة وإعادة المحاولة قبل الأمر نفسه.
‫أول واحد هناك للأمر الأساسي ، لاحظ أنني لست مضطرًا لوضع CMD
‫إذا أعطيته الأمر للتشغيل. ولكن إذا كنت أرغب في إظهار الخيارات ، إذا كنت أرغب
‫في منحها خيارات مخصصة خارج المربع مع انتهاء المهلة وما إلى ذلك ، فيجب أن أحدد أيهما هو الأمر.
‫الآن هذان ليسا خطين مختلفين.
‫لاحظ الشرطة المائلة الخلفية في نهاية السطر الأول هناك.
‫لذلك لا تشوش على ذلك.
‫لدينا هنا مثال بسيط لما قد يكون عليه الأمر إذا كان لديك تطبيق ثابت يعمل داخل
‫خادم Nginx.
‫يمكنك تعيين الفاصل الزمني والوقت المستقطع من Dockerfile الخاص بك ، وسيكون عليك ببساطة
‫القيام بأمر cURL على المضيف المحلي.
‫إذا أرجع 200 أو 300 ، فإنه يعتبر تلك الغرامة. إذا أرجع 4 أو 5 أو أي شيء آخر ، فإنه يعتبر
‫هذا خطأ.
‫تلاحظ هنا أن لدي مخرج 1 ، وهو نفس الشيء مثل خطأ.
‫لقد فعلت ذلك فقط لأظهر لك أن بعض الأمثلة على الإنترنت سيكون لها خطأ. سيكون لبعض الأمثلة
‫مخرج 1.
‫كلاهما تفعل الشيء نفسه.
‫إليك مثال أكثر تقدمًا قليلاً.
‫في هذه الحالة ، نستخدم تطبيق PHP مدمج مع Nginx.
‫ما فعلته هو ، في الموارد ، ستجد رابطًا لمثال PHP هذا. لقد أضفت ملف تهيئة Nginx مخصصًا
‫يستخدم عناوين URL لحالة Nginx و PHP-FPM.
‫كل من هذين التطبيقين لهما صفحة الحالة الخاصة بهما ونوع من عنوان URL لفحص فحص الصحة.
‫يمكنك استخدام تلك الموجودة في تطبيقاتك إذا كنت تستخدم PHP أو Nginx. هناك نوعان من عناوين URL مختلفة ، ولكن يمكنك
‫استخدام كلاهما داخل نفس التحقق الصحي.
‫في هذه الحالة ، نستخدم واحدًا منهم فقط ، ونقوم بإدخال المضيف المحلي
‫/ ping ، وهو في الواقع
‫أمر حالة PHP-FPM ، ولكن عليك تمكين ذلك داخل PHP-FPM. مرة أخرى ، في موارد هذه المحاضرة ، هناك رابط
‫إلى PHP Docker Good Defaults.
‫يمكنك التحقق من ذلك على GitHub حيث عرضت في هذا المثال بمزيد من التفاصيل قليلاً.
‫بعد ذلك ، لدينا مثال Postgres لذلك في Dockerfile يمكنني استخدام عنوان URL مختلف.
‫هنا لدينا تطبيق Postgres حيث في الأمر healthcheck ، أستخدم أمر pg جاهز.
‫الآن ، مع تطبيقات مختلفة ، هناك أدوات مختلفة. مع Postgres ، يأتي مع أداة مدمجة ، وهذا
‫اختبار بسيط للغاية للاتصال بخادم Postgres.
‫لا يثبت أن لديك بيانات جيدة ، أو أن قاعدة البيانات الخاصة بك مثبتة بشكل صحيح. سيقول ببساطة ، "هل يسمح خادم قاعدة البيانات
‫هذا بالاتصالات؟ نعم ام لا؟ هذا أمر رائع يمكنك
‫القيام به خارج الصندوق.
‫هذا هو الشكل الذي سيبدو عليه في ملف الملحن / المكدس.
‫مشابه جدا.
‫ستلاحظ أن فترة البدء هناك تتطلب إصدارًا مختلفًا.
‫منذ أن صدر أمر healthcheck في 1. 12 ، تم دعمه بالفعل في 2. 1 من ملف الإنشاء
‫هذا.
‫ولكن ، إذا كنت ستستخدم فترة البدء ، فهذا يعني أنه يتعين عليك تحديث ملف الإنشاء
‫إلى الإصدار 3. 4 من أجل دعم ذلك. لأن فترة البدء خرجت بعد أكثر
‫من عام بعد أن فعل الأمر healthcheck.
‫لنبدأ ببعض أوامر التشغيل البسيطة.
‫ما سنفعله هنا هو أننا سنبدأ خادم قاعدة بيانات Postgres بدون التحقق من الصحة لأنه
‫لا يأتي مع واحد افتراضيًا.
‫ثم سنقوم بتشغيله مرة أخرى باستخدام أمر فحص الصحة
‫اليدوي الذي سيضيف في سطر الأوامر ، وسنرى الفرق.
‫هنا ، سنطلق على أول p1. سنقوم بتشغيله منفصلاً عن صورة Postgres
‫الرسمية.
‫إذا قمت بعمل حاوية عامل إرساء ، فسترى أنه لا يوجد شيء يشير إلى فحص صحي هنا.
‫إذا فعلنا نفس الأمر مرة أخرى ، وقمنا بتسميته p2 هذه المرة ، فسنضيف الأمر health.
‫هذه المرة ، سنستخدم صفحة pg جاهزة ، التي تحدثنا عنها سابقًا ، لاختبار
‫توفر الاتصالات على خادم Postgres هذا. سنخبرها أن المستخدم الذي نحتاجه
‫هو مستخدم postgres. لا نحتاج في الواقع إلى إعطائه كلمة مرور. لن يحاول تسجيل
‫الدخول. سيحاول فقط التحقق من صحة ذلك. سنستخدم صورة Postgres.
‫الآن إذا قمنا بعمل حاوية لرسو السفن ، وقمت بالتصغير قليلاً ، فسترى أنه يقول ، "بدأت الصحة لمدة 4
‫ثوانٍ. الآن نحصل على
‫هذه الميزة الإضافية في حالة أمر ls الخاص بنا. سيبقى في حالة البداية لمدة 30 ثانية الافتراضية
‫حتى يقوم بتشغيل الأمر
‫healthcheck لأول مرة.
‫الآن بعد أن انتظرنا أكثر من 30 ثانية ، سترى أنه تم تغيير الحالة إلى الحالة الصحية.
‫إذا أجرينا فحصًا لحاوية عامل إرساء على p2 ، فسنرى في الجزء العلوي من ذلك أن لدينا خيار الحالة
‫الصحية الجديد هذا. في هذه الحالة ، تمكنت من تشغيله مرتين فقط.
‫يمكنك رؤية الإخراج هناك ، وهو يظهر أنه يقبل الاتصالات.
‫حسنا. لنقم ببعض الخدمات لإنشاء أوامر لقاعدة البيانات نفسها ، في نفس الاختبار الصحي.
‫ما سنراه هنا عندما نفعل ذلك هو أن هناك ثلاث حالات مختلفة تمر بها الخدمة عند بدء
‫التشغيل.
‫إنها تستعد ، مما يعني عادةً أنها تقوم بتنزيل الصورة. إنها تبدأ ، مما يعني أنها تقوم بتنفيذ
‫الحاوية وإحضارها. ثم يتم تشغيله.
‫بدون الأمر healthcheck ، يكون البدء والتشغيل سريعًا جدًا. إنها فورية تقريبًا.
‫سنرى هنا مع خدمة عامل ميناء إنشاء اسم p1 postgres.
‫بمجرد الانتهاء من التحضير عن طريق تنزيل الصورة ، سترى أنها تنتقل فورًا
‫من بدء التشغيل ، لأنه لا يوجد فحص صحي. ليس لديها أي شيء آخر تفعله بخلاف بدء الحاوية والقول
‫، "نعم. الثنائي قيد التشغيل. ولكن إذا فعلنا
‫نفس الأمر ، فإن خدمة عامل الإرساء تنشئ ، وتسميها p2 كما كان من قبل ، ومنحها نفس الأمر الصحي.
‫نبدأ هذه الخدمة باستخدام الأمر healthcheck المدمج.
‫ما سنراه هو أنه سينتقل من الاستعداد إلى البداية ، وسيبقى في حالة البداية لمدة
‫30 ثانية الافتراضية حتى يتم تشغيل أول فحص صحي.
‫هذه هي الآن خدمة Docker التي تتوقع حالة صحية قبل أن تعتبر هذه الخدمة
‫تعمل بشكل كامل. بعد انتهاء الـ 30 ثانية ، سيتحول إلى حالة التشغيل. ثم نحصل على آخر عملية تحقق صغيرة
‫هناك ، فقط للتأكد من أنها تعتبر مستقرة ، ثم ننتهي.
‫يمكنك أن ترى بالفعل ، خارج الصندوق ، أنه مع الخدمات ، بالإضافة إلى تحديثات
‫الخدمة ، سنحصل على هذه المكافأة الإضافية لمفهوم الصحة إذا استخدمنا هذه الأوامر كلما أمكننا ذلك.