هناك العديد من قوالب بناء الحاويات. الحاوية هي مجرد نسخة قابلة للتنفيذ من صورتها الخاصة. لذلك ، ترتبط طريقة بناء الحاوية ارتباطًا وثيقًا بكيفية بدء تشغيلها.
تعمل بعض صور الحاوية بشكل جيد دون أي امتيازات خاصة ؛ بينما يتطلب البعض الآخر امتيازات الجذر. علاوة على ذلك ، يمكن أن تجمع الصورة / الحاوية نفسها بين العديد من أنماط البناء وسيناريوهات الاستخدام في وقت واحد.
أدناه سننظر في حالات استخدام الحاويات الأكثر شيوعًا.
(للحصول على مقدمة لمصطلحات الحاويات ، انظر
الجزء الأول )
سيناريوهات استخدام الحاوية
حاويات التطبيق
حاويات التطبيق هي أكثر أنواع الحاويات شيوعًا. يتعامل معهم المطورون وأصحاب التطبيقات ، وهم أنفسهم يحتويون على شفرة المصدر ، بالإضافة إلى أشياء مثل MySQL و Apache و MongoDB و Node.js.
يتم تشكيل نظام بيئي واسع من حاويات التطبيقات. توفر مشاريع مثل مجموعات البرامج صور حاوية تطبيقات آمنة ومدعومة لـ Red Hat Enterprise Linux. في الوقت نفسه ، يقوم أعضاء مجتمع Red Hat بتطوير ودعم حاويات التطبيقات المبتكرة.
في Red Hat ، نعتقد أن حاويات التطبيقات عادة لا تحتاج إلى امتيازات خاصة. ومع ذلك ، عند بناء بيئات إنتاج الحاويات ، هناك حاجة إلى حاويات أخرى.
حاويات نظام التشغيل
حاوية نظام التشغيل عبارة عن حاوية تشبه إلى حد كبير نظام تشغيل افتراضي كامل. تستخدم هذه الحاويات أيضًا نواة المضيف ، ولكنها تشغل نظام التهيئة الكامل ، والذي يسمح لها بتنفيذ العديد من العمليات بسهولة. أمثلة حاويات نظام التشغيل هي LXC و LXD.
من حيث المبدأ ، يمكن محاكاة حاويات نظام التشغيل باستخدام حاويات docker / OCI ، شريطة أن يكون من الممكن تشغيل النظام داخلها حتى يتمكن المستخدم النهائي من تثبيت البرنامج داخل هذه الحاويات بالطريقة المعتادة ويرى أنها نظام تشغيل افتراضي كامل.
yum install mysql systemctl enable mysql
هذا يبسط بشكل كبير حاويات التطبيقات الموجودة. تعمل Red Hat بجد لتبسيط حاويات نظام التشغيل من خلال السماح بتشغيل systemd داخل الحاوية واستخدام البرنامج الخفي. على الرغم من أن العديد من العملاء ليسوا مستعدين حتى الآن لبنية الخدمات المصغرة ، إلا أن الانتقال إلى نموذج تسليم برامج حاويات يعتمد على صور الحاوية يمكن أن يمنحهم الكثير من المزايا.
حاويات الحيوانات الأليفة
على الرغم من أن Red Hat توصي بشدة وتروج وتدعم استخدام
النماذج المستندة إلى السحابة عند تطوير تطبيقات جديدة ، إلا أننا ندرك جيدًا أنه لن تتم إعادة كتابة جميع التطبيقات الحالية بهذه الطريقة. على وجه الخصوص ، لأن العديد منهم فريدون للغاية ولا يضاهى ، مقارنةً بالتطبيقات القياسية ، فإنهم يشبهون الحيوانات الأليفة (
الحيوانات الأليفة ) ضد قطيع من الأبقار. لمثل هذه التطبيقات تم تصميم
حاويات الحيوانات الأليفة الخاصة.
تجمع حاويات الحيوانات الأليفة بين سهولة وراحة البنية التحتية للحاويات المبنية على أساس خوادم التسجيل وصور الحاويات ومضيفات الحاويات مع مرونة بيئة تكنولوجيا المعلومات التقليدية ، التي يتم تنفيذها داخل حاوية منفصلة. تتمثل الفكرة هنا في تبسيط حاوية التطبيقات الحالية نظرًا لنفس
القدرة على استخدام systemd داخل الحاوية لاستخدام أدوات الأتمتة الحالية ، وتثبيتات البرامج والأدوات الأخرى لإنشاء صور جاهزة للحاويات بسهولة للإطلاق.
حاويات الامتياز الفائقة
عند بناء بنية تحتية للحاويات على أساس مضيفات حاويات مخصصة مثل Red Hat Enterprise Linux Atomic Host ، لا يزال يتعين على مسؤولي النظام إدارتها. وقد أثبتت
الحاويات الفائقة الامتياز (SPCs) أنها مفيدة جدًا في مثل هذه البيئات الموزعة ، سواء كانت Kubernetes أو OpenShift أو حتى الحاويات المستقلة. يمكن حتى SPCs تحميل وحدات النواة المتخصصة ، مثل تابست النظام.
في البنية التحتية التي تم إنشاؤها لتشغيل الحاويات ، من المحتمل أن يحتاج المسؤولون إلى حاويات SPC لأداء مهام مثل المراقبة والنسخ الاحتياطي ، وما إلى ذلك. من المهم أن نفهم أنه نظرًا لأن حاويات SPC عادة ما تكون أكثر ارتباطًا بالنواة المضيفة ، فيجب على المسؤولين انتبه بشكل خاص إلى مشكلات الموثوقية والتوحيد القياسي عند اختيار أنظمة التشغيل المضيفة ، خاصة في البيئات الكبيرة والموزعة والمجمعة التي تجعل من الصعب استكشاف الأخطاء وإصلاحها. بالإضافة إلى ذلك ، يحتاج المسؤولون إلى التأكد من أن مساحة المستخدم داخل SPC متوافقة مع النواة المضيفة.
أدوات وبرمجيات النظام
كانت توزيعات Linux دائمًا توفر للمستخدم برنامج النظام ، مثل Rsyslogd ، SSSD ، sadc ، إلخ. تقليديًا ، تم تثبيت هذا البرنامج في شكل حزم RPM أو DEB ، ولكن مع ظهور تنسيقات تغليف الحاويات أصبح من الأسهل والأكثر ملاءمة التثبيت باستخدام صور الحاوية. على وجه الخصوص ، تقدم Red Hat أشياء مثل الحاويات الجاهزة مثل أدوات المحاكاة الافتراضية Red Hat و rsyslog و sssd و sadc.
هندسة الحاويات
مع اكتساب تسليم البرمجيات المعبئة في الزخم ، تظهر أنماط جديدة لتصميم الحاويات. في هذا القسم سوف نتحدث عن بعضها.
يمكن أن تؤثر الطريقة التي يتم بها حفظ الحاوية على القرص (بعبارة أخرى ، تنسيق الصورة) بشكل كبير على كيفية بدء تشغيلها. على سبيل المثال ، يجب أن تتمتع الحاوية المصممة لتشغيل sssd بامتيازات خاصة في كل مرة يتم تشغيلها ، وإلا فلن تتمكن من القيام بعملها. أدناه ، ننظر بإيجاز في الأنماط الرئيسية التي تمر حاليًا بمرحلة التكوين النشط.
صور التطبيق
مع هذه الصور التي يتعامل معها المستخدمون النهائيون. تتراوح سيناريوهات استخدام هذه الصور من DBMS وخوادم الويب إلى التطبيقات الفردية وناقلات الخدمة. يمكن إنشاء هذه الصور داخليًا بواسطة المؤسسة أو توفيرها من قِبل موردي البرامج. لذلك ، غالبًا ما يرتبط المستخدمون النهائيون بمحتويات هذه الحاويات المستقلة بحذر ودقة. بالإضافة إلى ذلك ، على الرغم من أن هذا هو الخيار الأسهل للمستخدم النهائي للحاويات ، إلا أن الصور المستقلة أكثر صعوبة في التصميم والبناء والتصحيح.
صور أساسية
الصورة الأساسية هي واحدة من أبسط أنواع الصور. ومع ذلك ، يمكن للناس أن يشيروا إلى هذا المصطلح مع مجموعة متنوعة من الأشياء ، على سبيل المثال ، تجميع الشركات القياسي أو حتى صورة التطبيق. على الرغم من أن هذه الصور ليست بالمعنى الدقيق للكلمة ، ولكنها صور وسيطة.
لذا فقط أوضح أن الصورة الأساسية هي صورة لا تحتوي على طبقة أصل. عادةً ما تحتوي الصور الأساسية على نسخة نظيفة من نظام التشغيل ، بالإضافة إلى الأدوات اللازمة لتثبيت حزم البرامج أو تحديث الصورة لاحقًا (yum، rpm، apt-get، dnf، microdnf). يمكن للمستخدم النهائي جمع الصور الأساسية يدويًا ، ولكن في الممارسة العملية ، عادةً ما يتم إنشاؤها وإصدارها من قبل مجتمعات التطوير (مثل Debian أو Fedora أو CentOS) أو موردي البرامج (مثل Red Hat). أصل الصورة الأساسية أمر بالغ الأهمية للأمن. تلخيص ، الغرض الرئيسي والوحيد من الصورة الأساسية هو توفير أساس يمكنك من خلاله إنشاء صور طفلك. عند استخدام ملف dockerfile ، يتم تحديد الصورة الأساسية الأساسية بشكل صريح:
FROM registry.access.redhat.com/rhel7-atomic
صور باني
هذا هو نوع خاص من الصور بناءً على ذلك يتم إنشاء الصور الفرعية لحاويات التطبيقات. تتضمن صور المُنشئ كل شيء ما عدا كود المصدر الذي كتبه المطورون ، أي مكتبات نظام التشغيل ، وأوقات تشغيل اللغة ، والبرامج الوسيطة ، وأدوات
المصدر إلى الصورة .
عند بدء التشغيل ، تسحب صورة المنشئ رمز مصدر التطبيق الذي كتبه المطورون وينشئ صورة فرعية لحاوية التطبيق جاهزة للإطلاق ، والتي يمكن بعد ذلك تشغيلها في بيئة تطوير أو إنتاج.
لنفترض أن المطورين قد كتبوا كود PHP للتطبيق ويريدون تشغيله في الحاوية. للقيام بذلك ، يأخذون ببساطة صورة منشئ PHP ويمررها URL على موقع GitHub ، حيث يتم تخزين التعليمات البرمجية الخاصة بهم. ونتيجة لذلك ، يحصل المطورون على صورة حاوية تطبيق جاهزة للتشغيل تحتوي على Red Hat Enterprise Linux و PHP من مجموعات البرامج ، وبالطبع رمز PHP المصدر للتطبيق.
تعد صور الباني طريقة قوية وسهلة وسريعة لتحويل شفرة المصدر إلى حاوية مبنية على أساس المكونات الموثوقة.
مكونات حاويات
الغرض الأساسي من الحاوية هو نشرها كمكون لنظام برمجيات أكبر ، وليس كوحدة قائمة بذاتها. وهناك سببان رئيسيان لذلك.
أولاً ، تزيد بنية الخدمات المصغرة من حرية اختيار المكونات ، وتؤدي أيضًا إلى زيادة عدد المكونات التي تتكون منها التطبيقات وأنظمة البرامج. تساعد المكونات المعبأة في حاويات على نشر مثل هذه الأنظمة بشكل أسرع وأسهل. على سبيل المثال ، تجعل صور الحاوية من السهل حل مشكلة التعايش بين إصدارات مختلفة من نفس المكون.
وتوفر أدوات تعريف التطبيق مثل
عمليات النشر yaml / json في Kubernetes / OpenShift ،
ووسيط الخدمة المفتوح ، و
OpenShift Templates ، و
Helm Charts إنشاء أوصاف تطبيقات عالية المستوى.
ثانيًا ، بعيدًا عن جميع أجزاء النظام البرمجي دائمًا يمكن وضعها في حاويات بسهولة. لذلك ، من المنطقي القيام بالحاويات فقط للمكونات الفردية الأكثر ملاءمة لهذا أو الأكثر واعدة من حيث النتائج. في التطبيقات متعددة الخدمات ، يمكن نشر جزء من الخدمات كحاويات ، والآخر باستخدام الطرق التقليدية ، مثل RPM أو البرامج النصية للتثبيت ، انظر حاويات الحيوانات الأليفة. بالإضافة إلى ذلك ، قد يكون من الصعب تجميع بعض المكونات ، حيث أنها مقسمة بشكل سيء إلى مكونات ، أو مرتبطة ببعض الأجهزة الخاصة ، أو تستخدم مكالمات API kernel ذات المستوى المنخفض ، وما إلى ذلك. لذلك ، في نظام برمجيات كبير ، على الأرجح ستكون هناك أجزاء يمكن وضعها في حاويات وأجزاء لا يمكن تحميلها في حاوية. المكونات المعبأة في حاويات هي ما يمكن نقله في حاويات وحاويات بالفعل. تم تصميم المكونات المعبأة في حاويات للتشغيل كجزء من تطبيق معين ، وليس بمفردها. من المهم أن نفهم أنها ليست مخصصة للتشغيل المستقل ، لأنها مفيدة فقط كجزء من نظام برمجيات أكبر ومعزولة عنه غير مجدية عمليًا.
على سبيل المثال ، في OpenShift Enterprise 3.0 ، تم نشر معظم الكود الرئيسي باستخدام RPM ، ولكن بعد تثبيته ، قام المسؤولون بنشر جهاز التوجيه والتسجيل كحاويات. قدم OpenShift 3.1 خيار النشر بالحاويات للسيد ، والعقدة ، و openvswitch ، وما إلى ذلك ، وبمجرد تثبيته ، يمكن للمسؤولين أيضًا نشر elasticsearch و flentd و kibana كحاويات.
على الرغم من أن مثبت OpenShift لا يزال يجري تغييرات على نظام ملفات الخادم ، يمكن الآن تثبيت جميع مكونات البرنامج الرئيسية باستخدام صور الحاوية. لذلك ، يجب عدم استخدام هذه المكونات المعبأة في حاويات ، على سبيل المثال ، مثيل للصورة وما إلى ذلك المضمنة في OpenShift - ولن يتم أبدًا - لتخزين التعليمات البرمجية المصدر للتطبيق الذي يعمل معه عملاؤك ، ببساطة لأن هذه المكونات الحاوية مخصصة ليتم تشغيلها كجزء منصة OpenShift للحاويات.
في الإصدارات الجديدة من OpenShift ، يزداد الاتجاه نحو حاويات المكونات فقط ، ويستخدم مطورو البرامج الآخرون هذا النهج بشكل متزايد.
صور الناشر
صورة الناشر هي نوع خاص من الحاويات ، عند إطلاقها ، نشرها أو إدارتها في حاويات أخرى. يتيح لك Deployer تنفيذ مخططات النشر المعقدة ، على سبيل المثال ، إطلاق حاويات بترتيب معين أو تنفيذ بعض الإجراءات في البداية الأولى ، مثل إنشاء مخطط بيانات أو ملء قاعدة البيانات مبدئيًا.
على سبيل المثال ، في OpenShift ، يتم استخدام نموذج "image / container type" لنشر السجلات والمقاييس. يسمح نشر هذه المكونات باستخدام صور الناشرين لمهندسي OpenShift بالتحكم في ترتيب تشغيل المكونات المختلفة والتحقق من أنها تعمل بشكل صحيح.
صور وسيطة
الصورة الوسيطة هي أي صورة لحاوية تعتمد على الصورة الأساسية. عادةً ما يتم تنفيذ تجميعات Kernel والبرامج الوسيطة وأوقات تشغيل اللغة كطبقات إضافية أعلى الصورة الأساسية ثم يتم تحديدها في توجيه FROM مع هذه الصورة الأساسية. لا يتم استخدام الصور الوسيطة عادةً بمفردها ، ولكن كعناصر إنشاء في إنشاء صورة مستقلة.
تشارك طبقات مختلفة من الصورة ، كقاعدة عامة ، في مجموعات مختلفة من المتخصصين. على سبيل المثال ، مسؤولو النظام مسؤولون عن طبقة تجميع kernel والمطورين لطبقة البرامج الوسيطة. في الوقت نفسه ، تعمل الطبقات الأساسية التي أعدها فريق واحد كصورة وسيطة لأولئك المسؤولين عن الطبقات ذات المستوى الأعلى. على الرغم من أنه في بعض الأحيان يمكن استخدام هذه الصور الوسيطة بشكل مستقل ، خاصة عند الاختبار.
صور متعددة الأغراض (متعددة الوسائط)
صور الحاوية متعددة الأغراض هي صور ذات بنية مختلطة. على سبيل المثال ، يمكن استخدام العديد من الصور في مجموعات برامج Red Hat بطريقتين. أولاً ، كحاويات تطبيق عادية مع روبي كامل على ريلز وخادم أباتشي. ثانيًا ، يمكن استخدامها كصور منشئ لـ OpenShift Container Platform وبناءً عليها صور فرعية تحتوي على Ruby on Rails و Apache ورمز التطبيق الذي قمت بتمريره إلى
المصدر لمعالجة
الصورة عند بناء مثل هذه الصورة الفرعية.
لاحظ أن الصور متعددة الأغراض تكتسب شعبية لأنها تسمح لك بحل مهمتين مختلفتين بشكل أساسي باستخدام نفس الصورة.
حاويات النظام
عند نشر برمجيات النظام على شكل حاويات ، غالبًا ما تتطلب الأخيرة امتيازات المستخدم الفائق. لتبسيط خيار النشر هذا والتأكد من تشغيل هذه الحاويات قبل تشغيل الحاوية وتشغيل نظام التنسيق ، طورت Red Hat نموذجًا خاصًا يسمى
حاويات النظام . يتم إطلاق هذه الحاويات أثناء عملية تمهيد نظام التشغيل باستخدام systemd والأمر الذري ، مما يجعلها مستقلة عن أي نظام تشغيل أو تنظيم للحاويات. اليوم ، تقدم Red Hat حاويات نظام ل rsyslog ، قمرة القيادة ، وما إلى ذلك و flanneld وسوف توسع هذه القائمة في المستقبل.
تبسط حاويات النظام بشكل كبير الإضافة الانتقائية لهذه الخدمات إلى Red Hat Enterprise Linux و Atomic Host.
الخلاصة
تبدو الحاويات شيئًا بسيطًا إلى حد ما بالنسبة للمستهلك النهائي ، ولكن الكثير من الأسئلة تبرز عند بناء بيئة إنتاج الحاويات. لمناقشة معمارية وأساليب بناء مثل هذه البيئات بشكل مثمر ، هناك حاجة إلى مصطلحات موحدة لجميع المشاركين. كلما تعمقت في تصميم وبناء مثل هذه البيئات ، ظهرت المزيد من المزالق. وأخيرًا ، نتذكر اثنين منهم فقط.
لا يرى الأشخاص غالبًا الفرق بين مصطلحي "صورة الحاوية" و "المستودع" ، خاصةً عند استخدامهما في أوامر عامل الميناء. ولكن إذا كان بإمكانك استخدام الأوامر دون فهم الاختلافات ، فعند العمل على بنية بيئات الحاوية ، يجب أن تفهم بوضوح أن المستودع هو بالفعل هيكل البيانات الرئيسي.
من السهل أيضًا إساءة فهم الفرق بين مساحات الأسماء والمستودعات وطبقات الصور والعلامات. كل من هذه الأشياء لها غرضها في هندسة الحاويات. وعلى الرغم من أن الموردين والمستخدمين يستخدمونها لأغراض متنوعة ، إلا أنها مجرد أدوات.
الغرض من هذه المقالة هو مساعدتك على فهم المصطلحات حتى تتمكن من إنشاء بنيات أكثر تقدمًا. على سبيل المثال ، تخيل أنك قد تم تكليفك للتو بتطوير بنية أساسية يجب أن تحدد توافر مساحات الأسماء والمستودعات وما هو أكثر ، والعلامات والطبقات اعتمادًا على الأدوار وقواعد العمل. والأخير - تذكر أن الطريقة التي يتم بها تجميع الحاوية تحدد إلى حد كبير كيف تبدأ (التنسيق ، الامتيازات ، إلخ).