تقنيات تقليص صورة عامل الميناء

هل تساءلت يومًا عن سبب كون حجم حاوية Docker التي تحتوي على تطبيق واحد فقط حوالي 400 ميجابايت؟ أو ربما كنت قلقًا بشأن الحجم الكبير إلى حد ما لصورة Docker التي تحتوي على ثنائي واحد من عدة عشرات من ميغابايت في الحجم؟



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

طبقات صورة عامل الميناء

تعد صورة حاوية Docker عبارة عن مجموعة من الملفات مكدسة فوق بعضها البعض في عدة طبقات. يتم تجميع حاوية العمل من هذه الملفات. يستخدم Docker نظام ملفات UnionFS ، حيث يتم تجميع الملفات في طبقات. يمكن أن تحتوي الطبقة على ملف واحد أو عدة ملفات ، تتداخل الطبقات مع بعضها البعض. أثناء تنفيذ الحاوية ، يتم دمج محتويات الطبقات ، ونتيجة لذلك ، يرى المستخدم النهائي للحاوية المواد "الموضوعة" في الطبقات كنظام ملف واحد.


عرض UnionFS المبسط

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


يحتوي حاوية التشغيل على طبقة للقراءة والكتابة الموجودة أعلى الطبقات للقراءة فقط

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

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

انتبه إلى المسار إلى المجلد ، بناءً على المواد التي يتم جمع الصور منها

ما هي الطريقة الأكثر شيوعًا لتجميع صور Docker؟ على ما يبدو - مثل هذا:

 docker build . 

تخبر النقطة الموجودة في هذا الأمر Docker بأننا نعتبر دليل العمل الحالي هو جذر نظام الملفات المستخدم في عملية تجميع الصور.

من أجل فهم أفضل لما يحدث بعد تنفيذ الأمر أعلاه ، يجدر بنا أن نتذكر أن بناء صورة Docker هو عملية عميل خادم. تستخدم واجهة سطر الأوامر Docker (العميل) ، والتي نعطيها docker build ، محرك Docker (الخادم) لبناء صورة الحاوية. لتقييد الوصول إلى نظام الملفات الأساسي للعميل ، يحتاج نظام تجميع الصور إلى معرفة مكان وجود جذر نظام الملفات الظاهري. يوجد هناك تعليمات من ملف Dockerfile بالبحث عن موارد الملفات التي قد تنتهي في النهاية في الصورة التي يتم تجميعها.

تخيل مكانًا يتم فيه وضع Dockerfile عادةً. ربما هذا هو الدليل الجذر للمشروع؟ إذا كان هناك ملف Dockerfile في جذر المشروع ، والذي يتم استخدامه بواسطة docker build لبناء الصورة ، Dockerfile أن جميع ملفات المشروع يمكن أن تدخل الصورة. يمكن أن يؤدي هذا إلى حقيقة أن الآلاف من الملفات غير الهامة التي يصل حجمها إلى عدة ميغابايت يمكن أن تدخل في سياق مجموعة الصور. إذا كنت تستخدم أوامر ADD و COPY في Dockerfile ، فقد تصبح جميع ملفات المشروع جزءًا من الصورة النهائية. في أغلب الأحيان ، لا يحتاج الأشخاص الذين يجمعون الصور إلى هذا ، لأن الصورة النهائية يجب أن تتضمن فقط بعض الملفات المحددة فقط.

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

تحسين طبقات الصور

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

كما ذكر في القسم السابق ، نظرًا لحقيقة استخدام UnionFS عند تجميع الصور ، تظل الملفات التي تقع في طبقة معينة موجودة حتى إذا تم حذفها من الطبقات الفوقية. دعنا نعرف ذلك باستخدام Dockerfile التجريبية:

 FROM alpine RUN wget http://xcal1.vodafone.co.uk/10MB.zip -P /tmp RUN rm /tmp/10MB.zip 

لنقم بتجميع الصورة:


تجميع لصورة تجريبية يوجد فيها مساحة غير عقلانية

استكشف الصورة باستخدام الغوص :


مؤشر أداء الصورة هو 34 ٪

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

كيف تتخلص من هذه المشكلة؟ لننظر في العديد من الخيارات.

results دمج نتائج عمل الفريق

هل سبق لك أن رأيت Dockerfile تحتوي على توجيهات RUN طويلة جدًا يتم فيها دمج العديد من أوامر shell باستخدام && ؟ هذا هو دمج نتائج الفرق.

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

 FROM alpine RUN wget http://xcal1.vodafone.co.uk/10MB.zip -P /tmp && rm /tmp/10MB.zip 

بعد ذلك ، نقوم بتحليل الصورة:


سمح لك دمج الفرق بإنشاء صورة محسّنة بنسبة 100٪

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

the تطبيق الخيار - سحق

في الحالات التي تستخدم فيها Dockerfile الخاصة Dockerfile التي لا تريدها أو لا تستطيع تغييرها ، يمكن أن يتمثل بديل لدمج الأوامر في تجميع صورة باستخدام خيار --squash .

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

 docker build --squash . 

تبين أيضًا أن الصورة الناتجة قد تم تحسينها بنسبة 100٪:


باستخدام خيار --squash أثناء التجميع ، سمح بإنشاء صورة تم تحسينها بنسبة 100٪

هنا يمكنك الانتباه إلى تفاصيل واحدة مثيرة للاهتمام. وهي ، في Dockerfile تم إنشاء طبقة لإضافة ملف وطبقة أخرى لحذف هذا الملف. يعد خيار --squash ذكيًا بما يكفي لفهم أنك في هذا السيناريو لا تحتاج إلى إنشاء طبقات إضافية على الإطلاق (في الصورة النهائية لا يوجد سوى 9ccd9… طبقة 9ccd9… من الصورة الأساسية التي نستخدمها). بشكل عام ، لهذا يمكننا وضع - --squash زائد إضافية. صحيح ، باستخدام - --squash ، يجب أن تفكر في أن هذا يمكن أن يتداخل مع استخدام الطبقات المخزنة مؤقتًا.

نتيجة لذلك ، يوصى بمراعاة حقيقة أنه عند العمل مع Dockerfile لشخص آخر لا ترغب في تغييره ، يمكنك تقليل مقدار مساحة الصورة المستخدمة بطريقة غير عقلانية من خلال جمع الصور باستخدام خيار --squash . لتحليل الصورة النهائية ، يمكنك استخدام أداة الغوص .

حذف ذاكرة التخزين المؤقت والملفات المؤقتة

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

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

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

 APK: ... && rm -rf /etc/apk/cache YUM: ... && rm -rf /var/cache/yum APT: ... && rm -rf /var/cache/apt 

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

اختر الصورة الأساسية بعناية

يبدأ كل Dockerfile بتوجيه FROM . هذا هو المكان الذي حددنا فيه الصورة الأساسية التي سيتم إنشاء صورتنا عليها.

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

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

كما قد تتوقع ، تختلف أحجام الصور الأساسية الشائعة بشكل كبير:


أحجام الصور عامل ميناء الأساسي شعبية

لذا ، فإن إضافة حاوية التطبيق باستخدام الصورة الأساسية لأوبونتو 19.10 ستؤدي إلى حقيقة أن حجم الصورة ، بالإضافة إلى حجم التطبيق ، سيضاف 73 ميغابايت أخرى. إذا قمنا بجمع نفس الصورة على أساس صورة Alpine 3.10.3 ، فسنحصل على "مادة مضافة" فقط بمبلغ 6 ميغابايت. نظرًا لأن Docker يقوم بتخزين طبقات الصور مؤقتًا ، يتم إنفاق موارد الشبكة على تحميل صورة فقط عندما يتم تشغيل الحاوية لأول مرة بالطريقة المناسبة (بمعنى آخر ، عند تحميل الصورة لأول مرة). لكن حجم الصورة نفسها لا يصبح أصغر من ذلك.

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

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

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

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

النظر في إنشاء صورة لا تحتوي على صورة أساسية.

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

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

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

استخدام بنيات متعددة المراحل

تم بناء متعدد المراحل محور الاهتمام منذ Docker 05/17. كانت فرصة كانت تنتظر لفترة طويلة. يسمح لمُنشئي الصور بالتخلي عن البرامج النصية الخاصة بهم لإنشاء الصور وتنفيذ كل ما يحتاجون إليه باستخدام تنسيق Dockerfile المعروف.

بشكل عام ، يمكن التفكير في تجميع متعدد Dockerfile أنه يجمع بين Dockerfile متعددة ، أو Dockerfile ، الذي يحتوي على عدة تعليمات FROM .

قبل ظهور التجميعات متعددة المراحل ، إذا كان عليك إنشاء تجميع لمشروعك وتوزيعه في حاوية باستخدام Dockerfile ، فربما تحتاج إلى تنفيذ عملية التجميع ، مما قد يؤدي إلى ظهور الحاوية ، كما هو موضح أدناه:


بناء وتوزيع تطبيق دون استخدام تقنية بناء متعدد المراحل

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

تتيح لك التجميعات متعددة المراحل فصل مراحل إنشاء وتحضير مواد المشروع عن البيئة التي يتم فيها تنفيذ رمز المشروع.


تجميع متعدد المراحل ، وفصل عملية إنشاء وإعداد مواد المشروع عن بيئة التنفيذ

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

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

النتائج

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

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

ملاحظة : أطلقنا السوق على موقع RUVDS. في السوق ، يتم تثبيت صورة Docker بنقرة واحدة ، ويمكنك التحقق من كيفية عمل الحاويات على VPS ، ويتم توفير 3 أيام للاختبارات مجانًا لجميع العملاء الجدد.

أعزائي القراء! كيف يمكنك تحسين حجم صور Docker الخاصة بك؟