حاويات الكبار (الجزء 01): دليل عملي للمصطلحات

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



لذا ، بدون معرفة المصطلحات ، سيكون من الصعب فهم كيف يختلف عامل الميناء عن CRI-O أو rkt أو lxc / lxd ؛ أو تقييم دور مبادرة الحاويات المفتوحة في توحيد تقنيات الحاويات.

مقدمة

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

• الحاوية
• صورة
• صورة الحاوية
• طبقة الصورة
• التسجيل
• المستودع
• العلامة
• الصورة الأساسية
• صورة النظام الأساسي
• طبقة

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

الحاويات: أساسيات

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

هناك عدة تنسيقات لصور الحاوية ( Docker ، Appc ، LXD ) ، لكن الصناعة تتحرك تدريجيًا نحو معيار مبادرة Open Open Initiative القياسية ، والتي تسمى أحيانًا Open Containers أو ببساطة OCI. يحدد هذا المعيار مواصفات تنسيق صورة الحاوية ، التي تحدد تنسيق القرص لتخزين صور الحاوية ، بالإضافة إلى البيانات الوصفية ، والتي بدورها تحدد أشياء مثل بنية الأجهزة ونظام التشغيل (Linux و Windows وما إلى ذلك). يُعد تنسيق صورة واحدة على مستوى الصناعة هو المفتاح لإنشاء نظام بيئي برمجي يسمح للمطورين ومشاريع مفتوحة المصدر وموردي البرامج بإنشاء صور متوافقة وأدوات متنوعة ، مثل التوقيع الإلكتروني والمسح الضوئي والتجميع والإطلاق والنقل ونقل الصور الحاوية.

بالإضافة إلى ذلك ، هناك العديد من محركات الحاويات ، مثل Docker و CRI-O و Railcar و RKT و LXC . يلتقط محرك الحاوية صورة للحاوية ويحولها إلى حاوية (أي عملية تشغيل). يتم تعريف عملية التحويل أيضًا من خلال معيار OCI ، والذي يتضمن مواصفات وقت تشغيل الحاوية وتنفيذ مرجع وقت التشغيل المسمى RunC ، وهو نموذج مفتوح المصدر ينظمه مجتمع التطوير المناسب. تستخدم العديد من محركات الحاويات هذا النموذج للتفاعل مع نواة المضيف عند إنشاء الحاويات.

توفر الأدوات التي تدعم مواصفات تنسيق صورة الحاوية وبيئة تنفيذ الحاوية لمعيار OCI قابلية النقل داخل النظام البيئي للعديد من منصات الحاويات ومحركات الحاويات والأدوات الداعمة على الأنظمة الأساسية السحابية المختلفة والمعماريات الداخلية. سيسمح لك فهم المصطلحات والمعايير والهندسة المعمارية لأنظمة الحاويات بالتواصل المثمر مع المتخصصين الآخرين وتصميم تطبيقات وبيئات حاوية قابلة للتطوير ومدعومة تضمن الاستخدام الفعال للحاويات لسنوات قادمة.

المفردات الأساسية

صورة الحاوية

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

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

بالإضافة إلى ذلك ، يشير مفهوم صورة الحاوية ضمنيًا إلى وجود تنسيق لهذه الصورة.

تنسيق صورة الحاوية

في البداية ، كان لكل محرك حاوية ، بما في ذلك LXD و RKT و Docker ، تنسيق الصورة الخاص به. تسمح بعض هذه التنسيقات بطبقة واحدة فقط ، بينما يدعم البعض الآخر بنية شجرة من عدة طبقات. اليوم ، تحولت جميع أدوات ومحركات الحاويات الرئيسية تقريبًا إلى تنسيق OCI ، الذي يحدد كيفية ترتيب الطبقات والبيانات الوصفية في صورة الحاوية. في الأساس ، يحدد تنسيق OCI صورة حاوية تتكون من ملفات قطران منفصلة لكل طبقة وملف manifest.json شائع يحتوي على بيانات التعريف.

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

محرك الحاوية

محرك الحاوية هو ذلك الجزء من البرنامج الذي يقبل طلبات المستخدم ، بما في ذلك معلمات سطر الأوامر ، وتنزيل الصور ، ومن وجهة نظر المستخدم النهائي ، يشغل الحاويات. هناك العديد من محركات الحاويات ، بما في ذلك عامل الميناء ، RKT ، CRI-O ، و LXD. بالإضافة إلى ذلك ، تحتوي العديد من الأنظمة الأساسية السحابية وخدمات PaaS ومنصات الحاويات على محركاتها الخاصة التي تفهم الصور بتنسيق Docker أو OCI. يضمن وجود معيار صناعي لتنسيق الصورة إمكانية التشغيل المتبادل لجميع هذه المنصات.

بالانتقال إلى المستوى ، يمكننا القول أن معظم محركات الحاويات لا تبدأ في الواقع تشغيل الحاويات نفسها ، ولكن من خلال وقت تشغيل متوافق مع OCI ، مثل runc. عادةً ما يقوم وقت تشغيل الحاوية بالأشياء التالية:

• يعالج المعلمات وإدخال المستخدم
• يعالج المعلمات التي تم تمريرها من خلال واجهة برمجة التطبيقات (غالبًا نظام تنسيق الحاوية)
• قم بتنزيل صور الحاوية من خادم التسجيل
• يزيل ويحفظ صورة الحاوية على القرص باستخدام برنامج تشغيل الرسم البياني (كتلة أو ملف ، حسب برنامج التشغيل)
• تحضير نقطة تحميل للحاوية ، عادةً في تخزين النسخ عند الكتابة (مرة أخرى ، كتلة أو ملف ، اعتمادًا على برنامج التشغيل)
• تحضير البيانات الوصفية التي سيتم تمريرها إلى وقت التشغيل لتشغيل الحاوية بشكل صحيح باستخدام:
  
  • الإعدادات الافتراضية المحددة المضمنة لصورة الحاوية (على سبيل المثال ، ArchX86 )
  • إدخال المستخدم لتجاوز القيم الافتراضية الموجودة في صورة الحاوية (على سبيل المثال ، CMD ، ENTRYPOINT)
  • المعلمات الافتراضية المحددة بواسطة صورة الحاوية (على سبيل المثال ، قواعد SECCOM )
• استدعاء وقت تشغيل الحاوية

الحاوية

توجد الحاويات في أنظمة التشغيل لبعض الوقت ، لأنه في الواقع هذا مجرد مثال على تشغيل صورة الحاوية. الحاوية هي عملية Linux قياسية يتم إنشاؤها عادةً باستخدام استدعاء النظام clone () بدلاً من fork () أو exec (). بالإضافة إلى ذلك ، غالبًا ما يتم تطبيق إجراءات عزل إضافية على الحاويات التي تستخدم مجموعات cg أو SELinux أو AppArmor .

مضيف الحاوية

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

يمكنك تحديد المستودعات التي تتم مزامنتها مع ذاكرة التخزين المؤقت المحلية باستخدام الأمر التالي:

  [root @ rhel7 ~] # صور عامل إرساء -أ

 تم إنشاء معرف صورة العلامة المخزنة الحجم الظاهري
 register.access.redhat.com/rhel7 آخر 6883d5422f4e قبل 3 أسابيع 201.7 ميغابايت 

خادم التسجيل

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

إذا لم يعثر برنامج docker على نسخة من المستودع في ذاكرة التخزين المؤقت المحلية ، فإنه يقوم بتنزيله تلقائيًا من خادم التسجيل. في معظم توزيعات لينكس ، سيستخدم برنامج docker موقع docker.io لهذا ، ولكن في بعض التوزيعات يمكن تكوينه بطريقته الخاصة. على سبيل المثال ، يحاول Red Hat Enterprise Linux أولاً التنزيل من register.access.redhat.com ، وبعد ذلك فقط من docker.io (Docker Hub).

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

يسمح لك Red Hat Enterprise Linux بتكوين سجل عامل الميناء الافتراضي. بالإضافة إلى ذلك ، يسمح لك RHEL7 و RHEL7 Atomic بإضافة أو قفل خوادم التسجيل من خلال ملف التكوين :

  سادسا / الخ / sysconfig / عامل الميناء

يستخدم كل من RHEL7 و RHEL 7 Atomic خادم تسجيل Red Hat بشكل افتراضي:

  ADD_REGISTRY = '- add-register register.access.redhat.com'

في بعض الحالات ، ولأسباب أمنية ، من المنطقي منع سجلات عامل الميناء العام ، مثل DockerHub:

  # BLOCK_REGISTRY = '- حظر التسجيل'

تقدم Red Hat أيضًا خادم التسجيل المدمج كجزء من OpenShift Container Platform ، بالإضافة إلى خادم تسجيل الشركات المستقل Quay Enterprise والسحابة والمستودعات الخاصة والعامة Quay.io.

تنسيق الحاويات

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

ينظم نظام تنظيم الحاويات شيئين فقط:

1. إرسال حمولات الحاوية ديناميكيًا عبر أجهزة كمبيوتر المجموعة (يشار إليها غالبًا باسم "الحوسبة الموزعة")
2. يوفر ملف وصف تطبيق قياسي (kube yaml ، docker compose ، إلخ.)

يوفر هذان الشيئان في الواقع مجموعة من الفوائد:

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

تقدم مجتمعات المصادر المفتوحة وبائعي البرامج العديد من أدوات التنسيق المختلفة. في البداية ، تضمنت الأدوات الثلاثة الكبرى هذه الأدوات Swarm و Mesos و Kubernetes ، ولكن أصبحت Kubernetes اليوم معيار الصناعة بالفعل ، لأنه حتى Docker و Mesosphere أعلنا دعمهما ، ناهيك عن جميع مقدمي الخدمات الرئيسيين تقريبًا. ومع ذلك ، إذا كنت تبحث عن نظام تنسيق الشركات ، نوصيك بإلقاء نظرة على Red Hat OpenShift .

قاموس متقدم

وقت تشغيل الحاوية

وقت تشغيل الحاوية هو مكون ذو مستوى منخفض يستخدم عادةً كجزء من محرك الحاوية ، ولكن يمكن أيضًا استخدامه يدويًا لاختبار الحاويات. يحدد معيار OCI التنفيذ المرجعي لوقت التشغيل المعروف باسم runc . هذا هو التطبيق الأكثر استخدامًا ، ولكن هناك أوقات تشغيل أخرى متوافقة مع OCI مثل crun و railcar و katacontainers . Docker و CRI-O والعديد من محركات الحاويات الأخرى تستخدم runc.

وقت تشغيل الحاوية مسؤول عن الأمور التالية:

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

القليل من الانحدار التاريخي: عندما ظهر محرك Docker لأول مرة ، استخدم LXC كبيئة وقت تشغيل. ثم كتب مطورو Docker مكتبتهم الخاصة لتشغيل الحاويات التي تسمى libcontainer. تم كتابته بلغة الجولانج وأصبح جزءًا من محرك Docker. بعد إنشاء منظمة OCI ، قدم Docker رمز مصدر libcontainer في هذا المشروع وأصدر هذه المكتبة كأداة مساعدة منفصلة تسمى runc ، والتي أصبحت بعد ذلك التنفيذ المرجعي لوقت تشغيل الحاوية ضمن معيار OCI وتستخدم في محركات الحاويات الأخرى ، مثل CRI-O . Runc هو أداة بسيطة للغاية تنتظر فقط لتمرير نقطة تحميل (دليل) والبيانات الوصفية (config.json) إليها. يمكن العثور على مزيد من المعلومات حول runc هنا .

لفهم أعمق ، راجع فهم معايير الحاويات ووقت تشغيل الحاوية .

طبقات الصورة

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

دعونا نلقي نظرة على طبقات المستودع على مضيف الحاوية المحلي. منذ البدء بالإصدار 1.7 ، لا يحتوي Docker على أداة مضمنة لعرض طبقات الصور في المستودع المحلي (ولكن هناك أدوات للتسجيلات عبر الإنترنت) ، سنستخدم الأداة المساعدة Dockviz . لاحظ أن كل طبقة لها علامة ومعرف فريد عالمي (UUID) . لعرض معرّفات UUID المختصرة التي عادة ما تكون فريدة داخل نفس الجهاز ، نستخدم الأمر التالي (إذا كنت بحاجة إلى UUID كامل ، استخدم الأمر نفسه مع الخيار -no-trunc):

تشغيل docker --rm - مميز - v /var/run/docker.sock:/var/run/docker.sock nate / dockviz images -t

  Virtual2332d8973c93 الحجم الافتراضي: 187.7 ميغابايت
  Virtual 187ea358092da77 الحجم الافتراضي: 187.9 ميغابايت
  Virtuala467a7c6794f الحجم الافتراضي: 187.9 ميغابايت
  Virtualca4d7b1b9a51 الحجم الافتراضي: 187.9 ميغابايت
  Virtual 84084976dd96d الحجم الافتراضي: 384.2 ميغابايت
  Virtual943128b20e28 الحجم الظاهري: 386.7 ميغابايت
  Virtualdb20cc018f56 الحجم الظاهري: 386.7 ميغابايت
  Virtual b45b3c59b9130 الحجم الظاهري: 398.2 ميغابايت
  Virtual91275de1a5d7 الحجم الظاهري: 422.8 ميغابايت
  Virtual └─e7a97058d51f الحجم الافتراضي: 422.8 ميغابايت
  Virtuald5c963edfcb2 الحجم الظاهري: 422.8 ميغابايت
  Virtual5cfc0ce98e02 الحجم الظاهري: 422.8 ميغابايت
  Virtual 287728f71a4bcd الحجم الظاهري: 422.8 ميغابايت
  │ └─0542f67da01b الحجم الافتراضي: 422.8 ميغابايت العلامات: docker.io/registry:latest

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

  تشغيل عامل الميناء - 45b3c59b9130 باش

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

العلامات

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

, – latest, , . , , .

, ( jq ):

 curl -s registry.access.redhat.com/v1/repositories/rhel7/tags | jq
 {
 "7.0-21": "e1f5733f050b2488a17b7630cb038bfbea8b7bdfa9bdfb99e63a33117e28d02f",
 "7.0-23": "bef54b8f8a2fdd221734f1da404d4c0a7d07ee9169b1443a338ab54236c8c91a",
 "7.0-27": "8e6704f39a3d4a0c82ec7262ad683a9d1d9a281e3c1ebbb64c045b9af39b3940",
 "7.1-11": "d0a516b529ab1adda28429cae5985cab9db93bfd8d301b3a94d22299af72914b",
 "7.1-12": "275be1d3d0709a06ff1ae38d0d5402bc8f0eeac44812e5ec1df4a9e99214eb9a",
 "7.1-16": "82ad5fa11820c2889c60f7f748d67aab04400700c581843db0d1e68735327443",
 "7.1-24": "c4f590bbcbe329a77c00fea33a3a960063072041489012061ec3a134baba50d6",
 "7.1-4": "10acc31def5d6f249b548e01e8ffbaccfd61af0240c17315a7ad393d022c5ca2",
 "7.1-6": "65de4a13fc7cf28b4376e65efa31c5c3805e18da4eb01ad0c8b8801f4a10bc16",
 "7.1-9": "e3c92c6cff3543d19d0c9a24c72cd3840f8ba3ee00357f997b786e8939efef2f",
 "7.2": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "7.2-2": "58958c7fafb7e1a71650bc7bdbb9f5fd634f3545b00ec7d390b2075db511327d",
 "7.2-35": "6883d5422f4ec2810e1312c0e3e5a902142e2a8185cd3a1124b459a7c38dc55b",
 "7.2-38": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "latest": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e"
 }

docker , . , «rhel7» – .

 docker pull rhel7

:

 docker pull registry.access.redhat.com/rhel7:latest

, . , , , docker images. , , , «» (manifest.json):

 docker images

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
 registry.access.redhat.com/rhel7 latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel6 latest 05c3d56ba777 4 weeks ago 166.1 MB
 registry.access.redhat.com/rhel6/rhel latest 05c3d56ba777 4 weeks ago 166.1 MB
  ...

, . docker ( , ) , «rhel7» .

, docker URL. , , URL .



, :

 REGISTRY/NAMESPACE/REPOSITORY[:TAG]

URL , , , . URL , docker , . , : :

 docker pull registry.access.redhat.com/rhel7/rhel:latest
 docker pull registry.access.redhat.com/rhel7/rhel
 docker pull registry.access.redhat.com/rhel7
 docker pull rhel7/rhel:latest

– . DockerHub , , .

Red Hat , Red Hat Federated Registry . registry.access.redhat.com . , . , Red Hat , - :

 registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/openshift3/mongodb-24-rhel7
registry.access.redhat.com/rhscl/mongodb-26-rhel7
registry.access.redhat.com/rhscl_beta/mongodb-26-rhel7
registry-mariadbcorp.rhcloud.com/rhel7/mariadb-enterprise-server:10.0

, URL . . fedora, latest. :

 docker pull fedora
docker pull docker.io/fedora
docker pull docker.io/library/fedora:latest

, , . , , , , , . , , , . .

Bash Enter, Bash Linux- exec() . , , docker, docker , clone() . clone () , , , , , ..

, Linux - , clone ().


…