تحسين أداء Docker والحاويات: دليل شامل للأداء

إنفورماتيك ديجيتال » موارد » تحسين أداء Docker والحاويات: دليل شامل للأداء

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

لماذا يستحق تحسين أداء Docker بذل أقصى جهد؟

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

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

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

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

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

مؤشرات رئيسية لقياس أداء حاوياتك

قبل أن تبدأ بالعبث بملفات Dockerfiles أو معلمات daemon، يجب أن تكون واضحًا بشأن هذا الأمر. ما الذي ستقيسه وكيف ستعرف ما إذا كنت تتحسن بالفعل؟بدون مقاييس، من المستحيل اكتشاف الاختناقات أو التحقق من تأثير تغييراتك.

في حاويات Docker، المقاييس الأساسية التي يجب عليك مراقبتها هي: وحدة المعالجة المركزية، والذاكرة، وإدخال/إخراج القرص، والشبكة، ووقت بدء التشغيلومن هناك يمكنك الخوض في التفاصيل على مستوى التطبيق (زمن الاستجابة، الإنتاجية، الأخطاء، إلخ).

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

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

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

صور Docker: من الصور الضخمة بحجم غيغابايت إلى الصور الخفيفة والآمنة

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

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

أظهر هذا التحسين التدريجي بوضوح كيف أضافت كل خطوة قيمة: اختر صورة أساسية محددة وخفيفة أدى ذلك إلى تقليل وقت البناء من أكثر من 350 ثانية إلى ما يزيد قليلاً عن 38 ثانية؛ وخفضه استخدام التخزين المؤقت للطبقات إلى 24 ثانية؛ وأدى إعادة ترتيب الطبقات إلى تعديله إلى حوالي 18 ثانية؛ وإعادة تنظيمها بشكل استراتيجي COPY انخفض الوقت إلى حوالي 10 ثوانٍ، وأخيرًا، سمحت عمليات البناء متعددة المراحل بالحفاظ على الوقت عند حوالي 10 ثوانٍ، ولكن مع حجم الصورة النهائي 34 ميجابايت فقط.

يستند كل هذا إلى عدة أفكار رئيسية: استخدام صور أساسية مصغرة (Alpine، Debian Slim، Scratch)افصل بوضوح بين وقت الإنشاء ووقت التشغيل، وقلل عدد الطبقات، ونظف التبعيات والذاكرة المؤقتة في نفس الطبقة التي تم إنشاؤها فيها، واستخدم أداة جيدة .dockerignore لتجنب تحميل ملفات غير مرغوب فيها إلى سياق البناء.

أدوات مثل DockerSlim أو الغوص تساعد هذه الأدوات في تحليل محتويات كل طبقة، ومعرفة ما يشغل مساحة، وفهم سبب حجم الصورة الحالي. كما يُنصح بدمج ماسح أمني (مثل Docker Scan أو Trivy) في سير العمل لاكتشاف الثغرات الأمنية في الصور الأساسية والتبعيات.

كيفية اختيار وهيكلة صور الحاوية الأساسية

أحد أكثر الأخطاء شيوعًا عند البدء باستخدام Docker هو استخدام صور عامة وصور أساسية ثقيلة لكل شيء: أنظمة أوبونتو أو ديبيان كاملة للخدمات التي يمكن أن تعمل بشكل مثالي في شيء أصغر بكثير.

بالنسبة للخدمات الخفيفة جدًا أو الخدمات المصغرة التي تؤدي مهمة واحدة محددة للغاية، فإن الخيار الأمثل هو نظام التشغيل Alpine Linux، الذي يبلغ حجمه حوالي 5-6 ميجابايتإنه مثالي للتطبيقات البسيطة، على الرغم من أنه يستخدم musl بدلاً من glibc وهذا يتطلب أحيانًا تعديلات طفيفة على بعض المكتبات.

إذا كنت بحاجة إلى حل وسط بين الحجم والراحة، ديبيان سليم (حوالي 60-70 ميجابايت) عادةً ما يكون خيارًا متوازنًا للغاية: تتوفر باقات أكثر من Alpine، ولكن بدون كل الميزات الإضافية للتوزيع الكامل.

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

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

الطبقات، وعمليات البناء متعددة المراحل، وإدارة ذاكرة التخزين المؤقت

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

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

تتضمن الاستراتيجية الجيدة دمج الأوامر في أمر واحد RUN التسلسل مع &&بهذه الطريقة، تُنشئ طبقات أقل وتُزيل كل ما لن تحتاجه لاحقًا (ذاكرة التخزين المؤقت لمدير الحزم، والملفات المؤقتة، وما إلى ذلك) في نفس الخطوة. إذا كان لديك ثلاثة RUN إذا اتبعت مسارات يمكن ضمها، فمن المحتمل أنك تقوم بإنشاء طبقات إضافية.

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

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

إدارة وحدة المعالجة المركزية والذاكرة: لا تدع أي حاوية تستهلك موارد خادمك الافتراضي الخاص

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

على مستوى وحدة المعالجة المركزية، يوفر Docker العديد من الأدوات: يمكنك تحديد حصص وحدة المعالجة المركزية النسبية بحيث يكون لبعض الحاويات وزن أكبر من غيرهايمكنك تحديد حدود قصوى للاستخدام، بل وتخصيص الحاويات لأنوية معينة باستخدام مجموعات المعالجات. يُعد هذا مفيدًا للغاية للخدمات الحيوية أو عند الرغبة في عزل أحمال العمل الثقيلة.

لديك ما يلي في ذاكرتك: حدود صارمة (--memory) لمنع الحاوية من تجاوز مقدار معين من ذاكرة الوصول العشوائي (RAM)، الحجوزات (--memory-reservation) لضمان الحد الأدنى للخدمات المهمة ومعلمات التبديل لمنع ترحيل القرص بشكل عشوائي.

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

إذا ازدادت بنية نظامك تعقيداً، أدوات التنسيق مثل Docker Swarm أو Kubernetes فهي تتيح إدارة موارد أكثر تقدماً: الحجوزات، والضمانات، والحدود لكل وحدة، والتوسع التلقائي الأفقي، وسياسات جودة خدمة أكثر ثراءً من تلك الخاصة بمضيف واحد بسيط.

شبكات دوكر: زمن الاستجابة، وأنماط الشبكة، واكتشاف الخدمات

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

طريقة جسر هذا هو الإعداد الافتراضي: تتشارك الحاويات جسرًا افتراضيًا، وهي معزولة عن المضيف، وتُعرض عبر منافذ مُعينة. في البيئات البسيطة، يكون هذا الإعداد مثاليًا في الغالب، ولكنه قد يُضيف بعض العبء.

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

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

لتحقيق بعض النظام، فإن الشيء الأمثل هو إنشاء شبكات جسر مخصصة لمجموعات الخدمات ذات الصلة (على سبيل المثال، الواجهة الخلفية وقاعدة البيانات)، اضبط دقة تحليل نظام أسماء النطاقات باستخدام الخيار --dns عند الحاجة، وامتلاك نظام لاكتشاف الخدمات (Swarm، Consul، إلخ) يمنعك من الاضطرار إلى التعامل مع عناوين IP يدويًا.

التخزين والإدخال/الإخراج: وحدات التخزين، وبرامج التشغيل، وأداء القرص

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

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

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

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

يمكنك أيضًا تحسين الأمور عن طريق ترتيب التعليمات في ملف Dockerfile الخاص بك إلى قم بزيادة استخدام ذاكرة التخزين المؤقت للطبقة إلى أقصى حد، وقلل من كمية عمليات الكتابة على القرص. وتطبيق تقنيات تقييد الإدخال/الإخراج على الحاويات المكثفة للغاية لمنعها من استهلاك كل عرض النطاق الترددي لقرص VPS.

المراقبة، واستكشاف الأخطاء وإصلاحها، وتجربة المستخدم النهائي

بيئة Docker بدون إمكانية مراقبة جيدة تُصبح بمثابة صندوق أسود. وللعمل بثقة، أنت بحاجة إلى لمراقبة ما يحدث داخل الحاويات وما يدركه المستخدم من الخارج.

لقد ذكرنا بالفعل بروميثيوس، وجرافانا، وسي أدفايزر، والأمر docker statsوالتي تغطي المقاييس التقنية الداخلية (وحدة المعالجة المركزية، والذاكرة، وزمن الاستجابة الداخلي، وما إلى ذلك) بشكل جيد للغاية. إلى جانب ذلك، يُنصح بإضافة مكدس سجلات مثل ELK (Elasticsearch, Logstash, Kibana) أو حلول SaaS مماثلة لتجميع وتحليل السجلات على نطاق واسع.

القيادة docker events إنه حليف رائع لتصحيح الأخطاء: فهو يسمح لك برؤية ما يفعله برنامج Docker daemon في الوقت الفعلي (يبدأ، يتوقف، أخطاء، إعادة تشغيل) ومقارنته بمقاييسك وسجلاتك.

للتطهير المباشر في وعاء محدد، يمكنك استخدام docker inspect للاطلاع على تكوينه التفصيلي, docker exec -it للدخول إلى موقع صدفة والتحقق من الوضع في الموقع أو docker network inspect لحل مشاكل الاتصال.

وبعيدًا عن المنظور الداخلي، يُوصى بشدة بدمج أدوات مراقبة اصطناعية خارجية تحاكي سلوك المستخدمين الحقيقيين من مواقع جغرافية مختلفةتتيح لك منصات مثل Dotcom-Monitor إجراء فحوصات التوافر وأوقات الاستجابة ومعدلات نجاح المعاملات، مما يوفر رؤية شاملة تكمل Prometheus والشركات الأخرى بشكل جيد.

الأمان، وأفضل الممارسات، وأوامر Docker التي ستستخدمها كل يوم

إن تحسين الأداء دون مراعاة الأمن يُعدّ بمثابة إلحاق الضرر بنفسك. تجمع معظم أفضل ممارسات Docker بين هذين الجانبين: صور صغيرة، سطح هجوم أقلعدد أقل من التبعيات، وعدد أقل من نقاط الضعف المحتملة.

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

يُنصح أيضًا بأتمتة تحديثات الصور الأساسية في مسارات التكامل المستمر/التسليم المستمر (CI/CD)، مع دمج عمليات الفحص الأمني ​​كخطوة إلزامية في مسار العمل وحظر عمليات البناء التي تحتوي على ثغرات أمنية خطيرة. من الأفضل بكثير إيقاف عملية النشر في الوقت المناسب بدلاً من الاضطرار إلى إدارة حادثة في بيئة الإنتاج بسبب ثغرة أمنية معروفة (CVE).

في الاستخدام اليومي، تتضمن مجموعة أدوات أوامر Docker الأساسية ما يلي: docker --version y docker info لمعرفة ما قمت بتثبيته فوق docker pull لتحميل الصور، docker run لتشغيل حاويات تفاعلية أو حاويات تعمل في الخلفية، و docker ps / docker ps -a لمعرفة أي الحاويات نشطة وأيها غير نشطة.

لإنشاء صورك الخاصة، ستعمل باستمرار مع docker build -t وملفات Dockerfiles ذات الإصدارات في مستودعكلإدارة الحاويات النشطة بالفعل، docker stop, docker start, docker restart, docker logs y docker exec -it إنها ضرورية.

عندما ترغب في الارتقاء بالاستمرارية والتواصل الشبكي إلى مستوى أعلى، تدخل أوامر كهذه حيز التنفيذ. docker volume create y docker volume ls لمعالجة البيانات، أو docker network ls y docker network create لإنشاء بنى أكثر تعقيدًا بين خدماتك.

بالنسبة للمشاريع التي تحتوي على أكثر من حاوية واحدة (وهو الوضع الطبيعي في أي تطبيق ذي أهمية متوسطة)، أصبح Docker Compose شبه إلزامي.. مع بسيطة docker-compose up -d ترفع الرزمة بأكملها ومعها docker-compose down تقوم بإيقاف العملية وتنظيف الموارد المرتبطة بها. ومن ثم، تفتح ملفات تعريف Compose وBuildKit وbuildx الباب أمام عمليات بناء متعددة البنى، وإدارة متقدمة لذاكرة التخزين المؤقت، وعمليات نشر أكثر دقة.

على المستوى التشغيلي، من المفيد تبني عادات معينة: احرص دائمًا على وضع علامات واضحة على صورك.لا تقم بتجميع الحاويات والصور اليتيمة (أوامر مثل docker system prune, docker container prune o docker image prune (للمساعدة في الحفاظ على نظافة البيئة) واستخدام الصيغة --mount للحصول على أحجام عندما تريد تعبيرًا كاملاً ومفاجآت أقل من تلك الموجودة في الطراز الكلاسيكي -v.

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