الخطوة الأولى للنشر في Kubernetes هي وضع تطبيقك في حاوية. في هذه السلسلة، سنلقي نظرة على كيفية إنشاء صورة حاوية صغيرة وآمنة.
بفضل Docker، أصبح إنشاء صور الحاوية أسهل من أي وقت مضى. حدد صورة أساسية، وأضف تغييراتك، وأنشئ حاوية.
على الرغم من أن هذه التقنية رائعة للبدء، إلا أن استخدام الصور الأساسية الافتراضية يمكن أن يؤدي إلى عمل غير آمن مع صور كبيرة مليئة بالثغرات الأمنية.
بالإضافة إلى ذلك، تستخدم معظم الصور في Docker Debian أو Ubuntu للصورة الأساسية، وبينما يوفر ذلك توافقًا ممتازًا وتخصيصًا سهلاً (يستغرق ملف Docker سطرين فقط من التعليمات البرمجية)، يمكن للصور الأساسية إضافة مئات الميجابايت من التحميل الإضافي إلى حاويتك. على سبيل المثال، يبلغ حجم ملف Node.js البسيط لتطبيق Go "hello-world" حوالي 700 ميغابايت، في حين أن حجم التطبيق الفعلي لا يتجاوز بضعة ميغابايت.
لذا فإن عبء العمل الإضافي هذا يعد مضيعة للمساحة الرقمية ومكانًا رائعًا لاختباء الثغرات الأمنية والأخطاء. لذلك دعونا نلقي نظرة على طريقتين لتقليل حجم صورة الحاوية.
الأول هو استخدام الصور الأساسية الصغيرة، والثاني هو استخدام نموذج البناء. ربما يكون استخدام الصور الأساسية الأصغر هو أسهل طريقة لتقليل حجم الحاوية الخاصة بك. على الأرجح، توفر اللغة أو المجموعة التي تستخدمها صورة تطبيق أصلية أصغر بكثير من الصورة الافتراضية. دعونا نلقي نظرة على حاوية Node.js الخاصة بنا.
افتراضيًا في Docker، يبلغ حجم الصورة الأساسية للعقدة: 8 670 ميجابايت، ويبلغ حجم الصورة للعقدة: 8-alpine 65 ميجابايت فقط، أي أصغر بـ 10 مرات. باستخدام صورة قاعدة جبال الألب الأصغر، سوف تقلل بشكل كبير من حجم الحاوية الخاصة بك. Alpine عبارة عن توزيعة Linux صغيرة وخفيفة الوزن تحظى بشعبية كبيرة بين مستخدمي Docker لأنها متوافقة مع العديد من التطبيقات مع الحفاظ على الحاويات صغيرة. على عكس صورة "عقدة" Docker القياسية، تزيل "node:alpine" الكثير من ملفات وبرامج الخدمة، وتترك فقط تلك التي تكفي لتشغيل التطبيق الخاص بك.
للانتقال إلى صورة أساسية أصغر، ما عليك سوى تحديث ملف Dockerfile لبدء العمل مع الصورة الأساسية الجديدة:
الآن، على عكس صورة onbuild القديمة، تحتاج إلى نسخ التعليمات البرمجية الخاصة بك إلى الحاوية وتثبيت أي تبعيات. في ملف Dockerfile الجديد، تبدأ الحاوية بصورة العقدة:alpine، ثم تقوم بإنشاء دليل للكود، وتثبيت التبعيات باستخدام مدير الحزم NPM، وأخيرًا تشغيل server.js.
تؤدي هذه الترقية إلى حاوية أصغر حجمًا بعشر مرات. إذا كانت لغة البرمجة أو الحزمة الخاصة بك لا تحتوي على وظيفة أساسية لتقليل الصورة، فاستخدم Alpine Linux. وسيوفر أيضًا القدرة على إدارة محتويات الحاوية بشكل كامل. يعد استخدام الصور الأساسية الصغيرة طريقة رائعة لإنشاء حاويات صغيرة بسرعة. ولكن يمكن تحقيق تخفيض أكبر باستخدام نمط البناء.
في اللغات المترجمة، يتم تمرير كود المصدر أولاً إلى المترجم ثم يتم تنفيذه مباشرة. في اللغات المترجمة، يتم تحويل التعليمات البرمجية المصدر أولاً إلى تعليمات برمجية مجمعة. ومع ذلك، غالبًا ما يستخدم التجميع أدوات غير مطلوبة فعليًا لتشغيل التعليمات البرمجية. هذا يعني أنه يمكنك إزالة هذه الأدوات بالكامل من الحاوية النهائية. يمكنك استخدام Builder Pattern لهذا الغرض.
يتم إنشاء الكود في الحاوية الأولى وتجميعه. يتم بعد ذلك تجميع التعليمات البرمجية المترجمة في حاوية نهائية دون الحاجة إلى المترجمين والأدوات اللازمة لتجميع هذا الرمز. لنقم بتشغيل تطبيق Go خلال هذه العملية. أولاً، سننتقل من صورة onbuild إلى Alpine Linux.
في ملف Dockerfile الجديد، تبدأ الحاوية بصورة golang:alpine. ثم يقوم بعد ذلك بإنشاء دليل للتعليمات البرمجية، ونسخه إلى التعليمات البرمجية المصدرية، وإنشاء التعليمات البرمجية المصدرية تلك، وتشغيل التطبيق. هذه الحاوية أصغر بكثير من حاوية onbuild، لكنها لا تزال تحتوي على المترجم وأدوات Go الأخرى التي لا نحتاجها حقًا. لذلك دعونا فقط نستخرج البرنامج المترجم ونضعه في حاويته الخاصة.
قد تلاحظ شيئًا غريبًا في ملف Docker هذا: فهو يحتوي على سطرين من FROM. يبدو قسم الأسطر الأربعة الأول تمامًا مثل ملف Dockerfile السابق باستثناء أنه يستخدم الكلمة الأساسية AS لتسمية هذه المرحلة. يحتوي القسم التالي على سطر FROM جديد لبدء صورة جديدة، حيث بدلاً من صورة golang:alpine سنستخدم Raw alpine كصورة أساسية.
لا يحتوي Raw Alpine Linux على أي شهادات SSL مثبتة، مما سيؤدي إلى فشل معظم استدعاءات API عبر HTTPS، لذلك دعونا نقوم بتثبيت بعض شهادات CA الجذرية.
الآن يأتي الجزء الممتع: لنسخ التعليمات البرمجية المترجمة من الحاوية الأولى إلى الثانية، يمكنك ببساطة استخدام أمر COPY الموجود في السطر 5 من القسم الثاني. سيتم نسخ ملف تطبيق واحد فقط ولن يؤثر على أدوات Go المساعدة. سيحتوي ملف Docker الجديد متعدد المراحل على صورة حاوية يبلغ حجمها 12 ميجابايت فقط، مقارنة بصورة الحاوية الأصلية التي كان حجمها 700 ميجابايت، وهو فرق كبير!
لذا فإن استخدام الصور الأساسية الصغيرة ونمط البناء يعدان من الطرق الرائعة لإنشاء حاويات أصغر بكثير دون الكثير من العمل.
من الممكن أنه اعتمادًا على حزمة التطبيق، هناك طرق إضافية لتقليل حجم الصورة والحاوية، ولكن هل تتمتع الحاويات الصغيرة حقًا بفائدة قابلة للقياس؟ دعونا نلقي نظرة على مجالين حيث تكون الحاويات الصغيرة فعالة للغاية - الأداء والأمان.
لتقييم زيادة الأداء، ضع في اعتبارك مدة عملية إنشاء الحاوية، وإدراجها في التسجيل (الدفع)، ثم استعادتها من هناك (السحب). يمكنك أن ترى أن الحاوية الأصغر لها ميزة واضحة على الحاوية الأكبر.
سيقوم Docker بتخزين الطبقات مؤقتًا، لذا ستكون عمليات الإنشاء اللاحقة سريعة جدًا. ومع ذلك، فإن العديد من أنظمة CI المستخدمة لبناء واختبار الحاويات لا تقوم بتخزين الطبقات مؤقتًا، لذلك يتم توفير الوقت بشكل كبير. كما ترون، فإن الوقت اللازم لبناء حاوية كبيرة، اعتمادًا على قوة جهازك، يتراوح من 34 إلى 54 ثانية، وعند استخدام حاوية يتم تقليله باستخدام Builder Pattern - من 23 إلى 28 ثانية. وبالنسبة للعمليات من هذا النوع، فإن زيادة الإنتاجية ستكون 40-50%. لذا فكر فقط في عدد المرات التي قمت فيها بإنشاء التعليمات البرمجية الخاصة بك واختبارها.
بعد إنشاء الحاوية، تحتاج إلى دفع صورتها (صورة الحاوية الدفعية) إلى سجل الحاوية بحيث يمكنك استخدامها بعد ذلك في مجموعة Kubernetes الخاصة بك. أوصي باستخدام Google Container Registry.
باستخدام Google Container Registry (GCR)، فإنك تدفع فقط مقابل التخزين الأولي والشبكات، ولا توجد رسوم إضافية لإدارة الحاويات. إنه خاص وآمن وسريع جدًا. يستخدم GCR العديد من الحيل لتسريع عملية السحب. كما ترون، فإن إدخال حاوية Docker Container Image باستخدام go:onbuild سيستغرق من 15 إلى 48 ثانية، اعتمادًا على أداء الكمبيوتر، وستستغرق نفس العملية مع حاوية أصغر من 14 إلى 16 ثانية، وبالنسبة للأجهزة الأقل إنتاجية الميزة في سرعة التشغيل تزيد 3 مرات. بالنسبة للأجهزة الأكبر حجمًا، يكون الوقت هو نفسه تقريبًا، نظرًا لأن GCR يستخدم ذاكرة تخزين مؤقت عامة لقاعدة بيانات مشتركة من الصور، مما يعني أنك لا تحتاج إلى تحميلها على الإطلاق. في جهاز كمبيوتر منخفض الطاقة، تكون وحدة المعالجة المركزية هي عنق الزجاجة، وبالتالي فإن ميزة استخدام الحاويات الصغيرة تكون أكبر بكثير هنا.
إذا كنت تستخدم GCR، فإنني أوصي بشدة باستخدام Google Container Builder (GCB) كجزء من نظام البناء الخاص بك.
كما ترون، يتيح لك استخدامه تحقيق نتائج أفضل بكثير في تقليل مدة عملية Build+Push حتى من الآلة الإنتاجية - في هذه الحالة، تكون عملية بناء الحاويات وإرسالها إلى المضيف أسرع مرتين تقريبًا. بالإضافة إلى ذلك، تحصل على 2 دقيقة بناء مجانية كل يوم، وهو ما يغطي احتياجات بناء الحاويات الخاصة بك في معظم الحالات.
بعد ذلك يأتي مقياس الأداء الأكثر أهمية - سرعة استرداد أو تنزيل حاويات السحب. وإذا كنت لا تهتم كثيرًا بالوقت الذي تقضيه في عملية الدفع، فإن طول عملية السحب له تأثير خطير على الأداء العام للنظام. لنفترض أن لديك مجموعة من ثلاث عقد وفشلت إحداها. إذا كنت تستخدم نظام إدارة مثل Google Kubernetes Engine، فسيقوم تلقائيًا باستبدال العقدة الميتة بعقدة جديدة. ومع ذلك، ستكون هذه العقدة الجديدة فارغة تمامًا وسيتعين عليك سحب جميع الحاويات الخاصة بك إليها حتى تبدأ العمل. إذا استغرقت عملية السحب وقتًا كافيًا، فسيتم تشغيل مجموعتك بأداء أقل طوال الوقت.
هناك العديد من الحالات التي يمكن أن يحدث فيها ذلك: إضافة عقدة جديدة إلى مجموعة، أو ترقية العقد، أو حتى التبديل إلى حاوية جديدة للنشر. وبالتالي، يصبح تقليل وقت استخراج السحب عاملاً رئيسياً. لا يمكن إنكار أن الحاوية الصغيرة يتم تنزيلها بشكل أسرع بكثير من الحاوية الكبيرة. إذا كنت تقوم بتشغيل حاويات متعددة في مجموعة Kubernetes، فقد يكون توفير الوقت كبيرًا.
ألقِ نظرة على هذه المقارنة: تستغرق عملية السحب على الحاويات الصغيرة وقتًا أقل بـ 4-9 مرات، اعتمادًا على قوة الجهاز، من نفس العملية باستخدام go:onbuild. يؤدي استخدام صور قاعدة الحاويات الصغيرة المشتركة إلى تسريع الوقت والسرعة التي يمكن بها نشر عقد Kubernetes الجديدة واتصالها بالإنترنت.
دعونا ننظر إلى مسألة الأمن. تعتبر الحاويات الصغيرة أكثر أمانًا من الحاويات الأكبر حجمًا لأنها تحتوي على سطح هجوم أصغر. هل هو حقا؟ إحدى الميزات الأكثر فائدة في Google Container Registry هي القدرة على فحص حاوياتك تلقائيًا بحثًا عن نقاط الضعف. منذ بضعة أشهر، قمت بإنشاء حاويات onbuild وحاويات متعددة المراحل، لذلك دعونا نرى ما إذا كانت هناك أي ثغرات أمنية هناك.
وكانت النتيجة مذهلة: تم اكتشاف 3 نقاط ضعف متوسطة فقط في حاوية صغيرة، وتم العثور على 16 نقطة ضعف حرجة و376 نقطة ضعف أخرى في حاوية كبيرة. إذا نظرنا إلى محتويات حاوية كبيرة، يمكننا أن نرى أن معظم المشاكل الأمنية ليس لها علاقة بتطبيقنا، ولكنها مرتبطة ببرامج لا نستخدمها حتى. لذلك عندما يتحدث الناس عن سطح هجوم كبير، فهذا ما يقصدونه.
الفكرة واضحة: قم ببناء حاويات صغيرة لأنها توفر فوائد حقيقية للأداء والأمان لنظامك.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com