ما هي الحاوية ، وما علاقتها بـ Docker و Kubernetes؟ – CloudSavvy IT

بالنسبة للعديد من الأشخاص ، لا تزال الحاويات تعني “Docker”. قام Docker بتعميم الاستخدام الحديث للحاويات في تطوير البرامج ونشرها. اليوم ، ظهرت تقنيات أخرى أيضًا. هذه هي العلاقة بين Containerd و Docker و Kubernetes.

نقطة البداية

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

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

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

واجهة مستخدم Docker المتمحورة حول المطور تعيق Kubernetes. يجب استخدام الأداة المخصصة Dockershim لتجاوز الجانب الإنساني للمشروع. اتجاهات التطوير المختلفة لـ Docker و Kubernetes تجعل المشكلة أكثر تعقيدًا. أطلقت Docker منتجها البديل Kubernetes الخاص بها ، Swarm ، الذي يقدم التناغم كنمط Docker مدمج.

صعود شحن الحاويات

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

ثم تستخرج Docker وقت تشغيل الحاوية الخاص بها في مشروع حاوية جديد. يتضمن ذلك إمكانات Docker لتنفيذ الحاويات ، والتعامل مع التخزين منخفض المستوى ، وإدارة عمليات نقل الصور. تم التبرع بـ Containerd إلى Cloud Native Computing Foundation (CNCF) من أجل تزويد مجتمع Containerd بأساس لإنشاء حلول حاوية جديدة.

سهّل ظهور الحاويات على مشاريع مثل Kubernetes الوصول إلى عناصر “Docker” ذات المستوى المنخفض المطلوبة. الآن ، لم يعودوا يستخدمون Docker فعليًا ، ولكن بدلاً من ذلك لديهم واجهة تشغيل حاوية يسهل الوصول إليها. يعني توحيد OCI لتقنية الحاوية أنه يمكن أيضًا استخدام أوقات تشغيل أخرى.

افهم دور الحاويات

لفهم الحاوية تمامًا ، من الضروري فهم طبيعة الحاوية. الحاوية هي في الواقع تجريد من وظائف Linux kernel المختلفة. لتشغيل الحاوية ، تحتاج إلى استخدام syscall لإعداد بيئة الحاوية. تختلف الخطوات حسب النظام الأساسي والتوزيع.

سيؤدي إدخال نوع الحاوية إلى تجريد هذا النوع من الأسلاك منخفضة المستوى. والمقصود منها أن تكون “طبقة العميل” التي يبني عليها برنامج الحاوية بعد ذلك. قد يكون هذا برنامجًا للمطورين (مثل Docker) أو أدوات مطوري السحابة (مثل Kubernetes).

في السابق ، كان لدى تطوير Kubernetes خياران خاطئان: الاستمرار في كتابة الحشوات حول واجهة Docker الخرقاء ، أو البدء في التفاعل مباشرة مع وظائف Linux kernel. من خلال فصل الحاوية عن Docker ، يمكن استخدام بديل ثالث: استخدام الحاوية كطبقة تجريد للنظام دون استخدام Docker.

فيما يلي ملخص لكيفية دمج هذه التقنيات الثلاث:

• رستابوت – برنامج موجه للمطورين مع واجهة متقدمة تتيح لك إنشاء الحاويات وتشغيلها بسهولة من الجهاز. الآن ، يستخدم الحاوية كوقت تشغيل الحاوية.
• وضع في صندوق – تجريد وظيفة النواة ، التي توفر واجهة حاوية عالية المستوى نسبيًا. يمكن لمشاريع البرامج الأخرى استخدامه لتشغيل الحاويات وإدارة صور الحاويات.
• كوبرنيتيس -منسق حاوية يستخدم مع أوقات تشغيل متعددة للحاويات (بما في ذلك الحاويات). يركز Kubernetes على تجميع الحاويات ونشرها على “عقد” مادية واحدة أو أكثر. تاريخيًا ، يرتبط Kubernetes بـ Docker.

الحاوية هي مجرد واجهة خلفية للحاوية. تتضمن الحاويات الأخرى التي تطبق مواصفات وقت تشغيل الحاوية المفتوحة runC و CRI-O. يمكن أيضًا استخدام أوقات التشغيل هذه مع Docker و Kubernetes. لكل منها اختلافه الخاص.

OCI

OCI هي المنظمة المسؤولة عن تحديد معايير الحاويات. يساعد عملها على تعزيز قابلية التشغيل البيني بين تقنيات المكونات المختلفة.

تحدد مواصفات صورة OCI مظهر الحاوية. تسرد مواصفات وقت التشغيل الواجهات المستخدمة لتشغيل الحاوية. بعد ذلك ، ستنفذ مشاريع مثل الحاويات هذه المواصفات.

الأهم من ذلك ، تتمثل إحدى أولويات OCI في دعم تجربة الحاوية الشائعة لـ Docker. يجب أن تكون صورتها قابلة للتنفيذ على النظام الأساسي الهدف بدون أي معلمات يحددها المستخدم (على سبيل المثال ، docker operate good day-earth:hottest). لذلك ، يجب أن تحتوي صورة OCI على بيانات وصفية كافية لتمكين هذا التكوين التلقائي.

قد ترى أيضًا مراجع لواجهة وقت تشغيل الحاوية (CRI). هذا تجريد خاص بـ Kubernetes في مواصفات OCI. يعتمد CRI على مواصفات OCI لدعم أوقات تشغيل الحاوية القابلة للتبديل في Kubernetes.

ماذا عن صورة Docker الخاصة بي؟

الصورة التي تم إنشاؤها باستخدام Docker ليست “صورة Docker” حقيقية على الإطلاق. مع استخدام Docker الآن لوقت تشغيل حاوية ، سيتم إنشاء صورك بتنسيق Open Container Initiative (OCI) القياسي.

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

Kubernetes و Docker

أوقفت Kubernetes وقت تشغيل Docker في نهاية عام 2020. سيتم حذفه في إصدار مستقبلي ومن المقرر حاليًا إصداره في نهاية عام 2021. بعد ذلك ، لن يوفر Kubernetes Docker بعد ذلك. يركض تعليق. بدلاً من ذلك ، يجب استخدام أوقات تشغيل بديلة متوافقة مع مواصفات OCI ، مثل الحاوية.

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

يتم النظر في تقنيتين مختلفتين – Docker واجهة خط الأوامر تستخدم لإنشاء وتشغيل الحاويات و Docker يركض واجهة سطر الأوامر تحيط به.

إنه محير للغاية!

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

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

يمكن الآن لكل واجهة عالية المستوى موجهة للمستخدم (مثل Docker و Kubernetes) الاستفادة من أوقات تشغيل الحاوية منخفضة المستوى القابلة للتبديل (مثل containerd و runC). وهذا يسمح بدرجة أكبر من المرونة ويسمح للتقنيات الجديدة القائمة على الحاويات بإثبات وجودها بطريقة متوافقة مع المعايير.