البحث في الموقع

مقدّمةيكتسي التّواصل Communication والتّشبيك Networking أهميّةً بالغة عند بناء نُظُم موزَّعة تعمل عليها حاويّات Docker؛ حيثُ تعتمد بنية التّطبيقات الّتي تتبع التّصميم خَدَمي التّوجّه Service-oriented بشكل كبير على تواصُل المكوِّنات في ما بينها حتى تعمل كما يُرادُ لها. سنذكُر في هذا الدّرس أدواتِ وإستراتيجيّات التّشبيك المُتعدّدة المُستخدَمة لضبط الشّبكات الّتي تعمل عليها الحاويّات؛ وذلك من أجل الوصول إلى الوضعية المرغوبة للشّبكة. يُمكن في بعض الحالات الاعتماد على الحلول الّتي يُوفّرها Docker افتراضيًّا، إلّا أنّ في بعض الحالات تتطلّب الاستعانة ببعض المشاريع البديلة. الحل الافتراضي للتّشبيك على Dockerيقدّم Docker افتراضيًا العديد من الأدوات القاعديّة المطلوبة للتّواصل بين الحاويّات Container-to-container وبين الحاويّات والنِّظام المُستضيف Container-to-host. يضبُطُ Docker عند تشغيله واجهة وهميّة Virtual interface جديدة للشّبكة باسم docker0 على النّظام المُستضيف. تعمل هذه الواجهة كجسر Bridge يُمكّن Docker من إنشاء شبكة فرعيّة Subnet تستخدمها الحاويّات في ما بعد؛ إضافةً إلى عملها كنقطة وصل بين آلية التّشبيك في الحاويّة وتلك الموجودة في المُستضيف. تُنشَأ واجهة وهميّة عندما يبدأ Docker تشغيل حاوية جديدة، وتُمنح عنوان IP ضمن مجال الشّبكة الفرعيّة المذكورة سابقًا. يدخُل عنوان IP الواجهة الوهمية الجديدة في إطارالشّبكة الدّاخليّة للحاويّة ممّا يوفِّر مسارًا يُمكن للحاويّة الاتّصال عن طريقه بالجسر docker0 الموجود على المُستضيف. يضبُط Docker آليًّا قواعد Iptables للسّماح بإعادة التّوجيه Forwarding ويُعدّ آليّة ترجمة العناوين على الشّبكة Network address translation (أو NAT اختصارًا) للاستخدام عند تبادل البيانات بين docker0 والعالم الخارجي. 1- كيف تعرِض الحاويّات الخدماتِ للعملاء؟لا تحتاج الحاويّة لأي إعدادات إضافيّة للحصول على الخدمات المُقدَّمة من طرف الحاويّات المتواجدة على نفس المُستضيف، حيثُ إنّ المُستضيف سيُوجِّه الطّلبات الّتي تُرسَل من الواجهة docker0 وتتّجه إليها (كلّ من المصدَر والوِجهة يوجدان على نفس الشّبكة الفرعيّة) إلى المكان المُناسِب. يُمكن للحاويّات عرضُ expose منافذها Ports عبرَ المُستضيف لتلقي البيانات ينقلها هذا الأخير إليها من العالم الخارجي. يُمكن قرن Mapping منافذ الحاويّة المعروضة بمنفذ من النِّظام المستضيف (تُنقل البيانات المُتبادلَة عبر منفذ المُستضيف إلى منافذ الحاويّة المقرونة بها) إمّا باختيار منفَذ مُحدَّد؛ أو ترك هذه المهمّة لـ Docker، في هذه الحالة يختار Docker منفذًا عشوائيًا غير مُستعمل برقم عالٍ. يتولّى Docker في هذا الإطار إدارة قواعد التوّجيه وإعدادت iptables لإيصال البيانات إلى وجهتها الصّحيحة. 2- ما الفرق بين عرض ونشر منفَذ Publishing ؟يُمكِن عند إعداد صورة أو بدْء تشغيل حاويّة، الاختيارُ بين عرض أو نشر المنافذ. من المهمّ التّفريقُ بين الاثنين. يعني عرضُ منفَذ مّا إعلامَ Docker أنّ الحاويّة تستخدِم المنفَذ المذكور، ويُمكن بالتّالي استخدام هذا المنفذ لأغراض الرّبط Linking أو الاستكشاف. يُعطي فحصُ حاويّة - على سبيل المثال - معلوماتٍ عن المنافذ المعروضة، وعند ربط حاويّات فإنّ متغيّرات البيئة تُضبَط لمعرفة المنافِذ المعروضة في الحاويّة الأصليّة.يُمكن - في الإعداد الافتراضي - للنِّظام المُستضيف الوصولُ إلى الحاويّة؛ نفس الشّيء بالنّسبة للحاويّات الموجودة على نفس المُستضيف. تقتصِر فائدة عرض المنافِذ في هذه الحالة على توثيق استخدام المنفذ وجعل هذه المعلومة مُتاحةً للرّبط والتّعيين الآليّيْن. على الجانب الآخر، يؤدّي نشر منفذ إلى جعله متاحًا للعالم الخارجي عبر قرنه بواجهة المُستضيف. 3- ماهيّ روابِط Docker؟يُوفّر Docker آليةً لإعداد الاتّصالات بين الحاويّات، تُسَمّى "روابط Docker" . تحصُل حاويّة جديدة عندَ ربطها بأخرى موجودة على معلومات اتّصال الأخيرة عبر متغيّرات مُشترَكة في بيئة التّنفيذ. تُشكّل هذه الوسيلة طريقةً سهلة للتّأسيس لاتّصال بين حاويّتيْن عبر إعطاء الحاويّة الجديدة معلومات مُفصَّلة عن كيفية النفاذ إلى الحاوية المُصاحِبة. تُضبَط المتغيّرات المُشترَكة حسب المنافذ الّتي تعرضها الحاويّة بينما يضبط Docker عنوان IP الحاويّة ومعلومات اتّصال أخرى. مشاريع للرّفع من قدرات Docker في التّشبيكنموذج التّشبيك المُقدَّم أعلاه يُشكِّل نقطة بدْء جيّدة في بناء وربط الشّبكات. الاتّصال بين الحاويّات الموجودة على نفس المُستضيف يعمل بشكل مُباشر. بالنّسبة للاتّصال بين المُستضيفات فيعمل عن طريق الشّبكات العمومية Public networks ما دامت المنافذ مقرونة بشكل صحيح ومعلومات الاتّصال متوفّرة لدى الطّرف الآخر. على الرّغم من ما سبق، تتطلّب بعض التّطبيقات بيئات شبكيّة خاصّة (نظرًا لبعض الأهداف الأمنيّة أو الوظيفيّة) لا يستطيع نموذج التّشبيك الأصلي في Docker توفيرها. لهذا السّبب أُنشِئت مشاريع عديدة لزيادة قُدُرات Docker في الرّبط بين الشّبكات. 1- إنشاء شبكات فوقيّة Overlay لتجريد Abstract البنية التّحتيّةركّزت العديد من المشاريع على تحسين وظيفي يتمثّل في التأسيس لشبكات فوقيّة Overlay Networks؛ وهيّ عبارة عن شبكات افتراضيّة مبنيّة على اتّصالات موجودة مُسبَقًا. يُمكّن التّأسيس لشبكات فوقيّة من إنشاء بيئات تشبيك منتظِمة يُمكن التّنبّؤ بها، وتربط بين عدّة مستضيفات. يُساعد هذا الأمر في تسهيل ربط الحاويّات بالشّبكة دون الاهتمام بالمُستضيف الذي تعمل عليه هذه الحاويّات. يُمكِن استخدام هذه الطّريقة لبناء شبكة افتراضيّة واحدة تمتدّ على عدّة مُستضيفات، أو لبناء شبكات فرعيّة لكل مُستضيف اعتمادًا على نفس الشبكة الفوقيّة. تُتيح الشّبكات الفوقيّة أيضًا بناء نسيج عنقودي Fabric clusters. تعمل الحوسبة النسيجيّة Fabric computing (يُطلَق عليها أحيانًا الحوسبة التوحيديّة Unified computing) على توحيد عدّة مُستضيفات وإدارتها كما لو كانت كيانًا واحدًا بموارد أكبر. يسمح إنجاز مبدأ الحوسبة النسيجيّة للمُستخدِم النّهائي بإدارة العنقود كوحدة بدلًا من مستضيفات متفرّقة. يلعب ربطُ الشّبكات جزءًا كبيرًا من إنشاء عناقيد حسب هذا المبدأ. 2- الإعداد المتقدّم للتّشبيكتتولّى مشاريعُ أخرى الرّفع من قدرات Docker التّشبيكيّة عن طريق توفير مرونة أكبر. إعداد التّشبيك الأصلي في Docker يقوم بالوظيفة الّتي أُنشئ من أجلها، ولكنّه بسيط جدّا. على الرغم من أنّ الحواجز الوظيفيّة للإعداد الافتراضي للشّبكات في Docker قد تظهر عند تخصيص مُتطلَّبات التّشبيك في مستضيف واحد، إلّا أنّها تظهر بشكل أوضح عند التّعامل مع شبكات عابرة للمُستضيفات. يُلجأ - من أجل إضافة وظائف جديدة إلى "تطويع" تلك الموجودة مُسبَقًا. لا تُضيف هذه المشاريع إعدادات خارقة لكنّها تسمح بربط أجزاء في ما بينها لإنشاء تصوّرات أكثر تعقيدًا لعمل الشّبكات. تمتد الوظائف الّتي تُضيفها هذه المشاريع من مجرّد إنشاء وربط شبكات خاصّة بين بعض المستضيفات إلى ضبط جسور، شبكات محليّة افتراضيّة، تخصيص الشّبكات الفرعيّة والبوّابات Gateways. توجد مشاريع وأدوات أخرى تُستخدم كثيرًا في بيئات Docker لتوفير وظائف جديدة، وذلك رغم أنّها لم تُطوَّر خصّيصًا لـDocker. يتعلّق الأمر خصوصًا بتقنيّات وصلت لمرحلة النّضوج في إنشاء الشّبكات الخاصّة والأنفاق Tunnels الّتي تُستخدَم غالِبًا لتأمين التّواصل بين المستضيفات وعبر المُستضيفات. هل من مشاريع شائعة الاستخدام للتحسين من أداء الشّبكات في Docker؟توجد عدّة مشاريع تُركِّز على توفير شبكة فوقيّة لمستضيفات Docker. في ما يلي بعض أكثر هذه المشاريع شيوعًا: flannel: يُطوِّره فريق CoreOs. أُنشئ هذا المشروع أصلًا لإعطاء كل مُستضيف شبكة فرعيّة خاصّة به ضمنَ شبكة مُشترَكة؛ وهو شرط ضروري لعمل أداة التّنسيق kubernetes الّتي تُطوِّرها Google، لكنّه مفيد أيضًا في حالات أخرى. weave: تُنشئ أداة Wweave شبكة افتراضيّة تربط بين مختلف مُستضيفات Docker. يُسهّل هذا الأمر من توجيه بيانات التّطبيق، إذ أنّ الحاويّات تبدو كما لو كانت كلّها على نفس المُوزِّع Switch. بالنسبة للتّشبيك المتقدّم، تهدف المشاريع أدناه إلى توفير قدرات تطويع أكثر للشّبكة. pipework: يهدف هذا المشروع إلى سد الفجوة في آلية التّشبيك الأصليّة في Docker من حيث نقص الوظائف المتقدِّمة، في انتظار تطّورها حيثُ يُسهّل التحكّم في وضبطَ إعدادات متقدّمة للتّشبيك. الأداة التّاليّة هي مثال على اختيّار برمجيّات موجودة خارج النّظام البيئي لـDocker واستخدامها بإضافة وظائف جديدة إليه. tinc: عبارة عن برنامج لإنشاء شبكة افتراضيّة خاصّة Virtual private network (أو VPN اختصارًا) يعتمد على التّعميّة Encryption والأنفاق. تُقدّم هذه الأداة طريقة وسيلة صلبة لجعل استخدام الشّبكة الخاصّة شفّافًا بالنّسبة لأيّ تطبيق. خاتمةيعتمد نموذج Docker على توفير خدمات عبر عناصر داخليّة وأخرى خارجيّة، وهو ما يجعل من الاعتبارات المُتعلّقة بالشّبكة مهمّةً للغاية. يُوفّر Docker وظائف أساسيّة لإعداد الشّبكات مثل الواجهات الافتراضيّة، الشّبكات الفرعيّة، iptables وإدارة ترجمة العناوين على الشّبكة (NAT)؛ وهيّ الوظائف الّتي تُكمّلها مشاريع أخرى أُنشِئت لإتاحة إمكانية ضبط إعدادات أكثر تقدّمًا. سنتطرّق في الدّرس القادم لكيفيّة عمل المُجدوِلات Schedulers وأدوات التّنسيق orchestration المبنيّة على هذا الأساس بهدف إدارة عنقود حاويّات.

وفّر Docker للعديد من المُطوّرين ومُدراء الأنظمة منصّة سهلة تسمح لهم ببناء ونشر تطبيقات قابلة للتّوسّع. سنستعرض في هذه السلسلة (Docker Ecosystem) كيف يوفّر Docker والمُكوّنات التّي صُمّمت للتكامل معه الأدوات اللازمة لتوفير تطبيقات مُوزّعة عالية التّوفر 1- مقدّمةيُطلَق مصطلح إعداد الحاويات Containerization على نشر وتوزيع التّطبيقات بشكل محمول ويُمكن التنبؤ به predictable. نلجأ - للحصول على هيئة النّشر والتّوزيع المذكورة آنِفًا - إلى تحزيم العناصِر واعتماديّاتِها في بيئة عمليّات قيّاسيّة، معزولة وخفيفة تُسمَّى حاويّة Container. تهتمّ الكثير من المنظَّمات الآن بتصميم تطبيقات وخدمات يسهُل توزيعها ونشرُها عبر نُظُم موّزَّعَة ممّا يُمكِّن من التّوسّع Scale بسهولة والتّغلّب على إخفاق التّطبيقات والأجهزة أثناء العمل. حفَّز Docker -الّذي هو منصّة لإعداد الحاويّات أُعِدَّ لتبسيط وتوحيد معايير النّشر في بيئات مختلفة- تبنّي هذا الأسلوب في تصميم وإدارة الخدمات؛ إذ أنّ الكثير من البرامج أُنشِئت لتتّخد من هذا الأسلوب في الإدارة المُوَزَّعة للحاويّات، قاعدةً تُبنى عليها. 2- إعداد حاويّات Dockerعلى الرّغم من وجود أنظمة أخرى لإعداد الحاويّات إلا أنّ Docker هو الأكثر استخداما هذه الأيّام نظرًا للبساطة الّتي يوفّرها في إنشاء وإدارة الحاويّات إضافةً إلى سهولة إدماجه في عدد من المشاريع مفتوحة المصدر. يُمكن، في الصّورة السّابقة، رؤية كيف ترتبط الحاويّات مع نظام التّشغيل المُستضيف (عَرض مُبسَّط). تعزِل الحاويّات كلّ تطبيق على حِدة مع استغلال موارد نظام التّشغيل الّتي يعمل Docker على تقديمها بطريقة مُجرّدة Abstracted (لا تظهر التّعقيداتُ المُصاحِبة لهذه الموارد للتّطبيقات، حيثُ يتولّى Docker التعاملَ معها). نرى في الجانب الأيمن أنّه يُمكن بناء الحاويّات اعتمادًا على طبقات Layers؛ بحيثُ تشترك عدّة حاويّات في الطّبقات الموجودة في الأساس وبالتّالي التّقليل من استخدام الموارد. المزايا الأساسيّة لـ Docker هيّ: التّخفيف من استخدام الموارد: تعمل الحاويّات على مستوى الـ Process وتستخدم نواة Kernel نظام التّشغيل المُستضيف ، بدلًا من الحوسبة التّخيّليّة Virtualization لكل نظام التّشغيل. قابليّة النّقل Portability: تُضَمَّن كلّ اعتماديّات التّطبيق داخل الحاويّة ممّا يسمح بتشغيل التّطبيق على أي مستضيف يعمل عليه Docker. إمكانية التّنبؤ Predictability: لا يهتمّ النّظام المُستضيف بما يجري داخل الحاويّة، كما أنّ الحاويّة لا تهتمّ بماهيّة نظام التّشغيل الذّي تعمل عليه، فالواجهات Interfaces معياريّة ويُمكن التّنبّؤ بالتّفاعلات بين العناصِر. من الأفضل، عند تصميم تطبيق يستخدم Docker، تقسيمُ وظائفه بين عدّة حاويّات. تُسمّى هذه الطّريقة ببُنية خَدَميّة التّوجّه Service-oriented architecture. يمنح هذا التّصميم سهولةً عند التّوسّع أو أثناء تحديث العناصِر المكوّنة للتّطبيق في المستقبل، كلٌّ على حِدَة. يُنظَر لهذه المرونة على أنّها أحد أهم أسباب اللّجوء إلى Docker للتّطوير والنّشر. 3- استكشاف الخدمة Service discovery ومخازن الإعداد العامّة Global Configuration Storesاستكشاف الخدمة هو أحد عناصرِ إستراتيجيّةٍ شاملة تهدِف إلى جعل نشر الحاويّات مرِنًا وقابِلًا للتّوسّع. يُمكِن للحاويّات عبر استكشاف الخدمة العثورُ على معلومات عن بيئةٍ مّا، دون الحاجة للتّدخّل البشري. يُمكِن للحاويّات مثلًا العثورُ على معلومات الاتّصال بالعناصر الّتي يجب عليها الاتّصال بها، كما يُمكنها تسجيل أنفسها لتعرف بقيّةُ الأدوات أنها مُتاحة. تعمل هذه الأدوات عادةً على شكل مخازن إعدادات عامّة موزَّعة، يُمكِن عبرها ضبطُ خيارات إعدادٍ للخدمات العامِلة ضمن البنية التّحتيّة التّي تشغِّلها. يوجد في الصّورة أعلاه مثال لتطبيق يُسجِّل معلومات الاتّصال به عن طريق نظام استكشاف الخدمة، ممّا يُتيح لبقيّة التّطبيقات إمكانيةَ إرسال استعلامات إلى خدمة الاستكشاف للعثور على طريقة الاتّصال بالتّطبيق المذكور. تُنجَز هذه الأدوات عادةً على شكل مخازن ذات صيغة مفتاح-قيمة Key-value (جدول من عموديْن، في الأوّل يوجد مفتاح وفي الثّاني قيمة لهذا المفتاح) موّزعة بين عدّة مستضيفات ضمن بيئة عنقوديّة Clustered. تُوفِّر المخازن المذكورة واجهةَ تطبيقات برمجيّة Application programming interface, API يُتوَصَّل إليها عبر ابروتوكول HTTP لقراءة وضبط القِيّم. تُضيف بعض المخازن إجراءاتٍ أمنيةً مثل تعميّة (تشفير) Encryption المُدخَلات وآليّات التّحكّم في الوصول Access control. المخازن المُوَزَّعة أساسيّة لإدارة عنقود من مستضيفات Docker زيادةً على وظيفتها الأولى التّي هيّ توفير تفاصيل الإعداد الذّاتي للحاويّات الجديدة. في ما يلي بعض مسؤوليّات مخازن استكشاف الخدمة: السّماح للتّطبيقات بالحصول على البيانات المطلوبة للاتّصال بالخدمات التّي تعتمد عليها. السّماح للتّطبيقات بتسجيل بيانات الاتّصال بها، وهو ما يُمكّن من القيام بالمسؤوليّة السّابقة. توفير مساحةٍ يُمكن للجميع الوصولُ إليها لتخزين بيانات ضبط الإعدادات. تخزين معلومات الأعضاء في العنقود حسب حاجة برنامج إدارة العنقود. في ما يلي أدوات شهيرة لاستكشاف الخدمة مع بعض المشروعات المتعلِّقة بها: etcd: استكشاف الخدمة. مخزن مُوزَّع يستخدم صيغة مفتاح-قيمة. consul: استكشاف الخدمة. مخزن مُوزَّع يستخدم صيغة مفتاح-قيمة. zookeeper: استكشاف الخدمة. مخزن مُوزَّع يستخدم صيغة مفتاح-قيمة. crypt: مشروع لتعميّة المُدخلات في أداة etcd. confd: تُراقِب مخازن تستخدم صيغة مفتاح-قيمة بحثًا عن تغييرات ثم تعمَد إلى إعداد الخدمات بالقيّم الجديدة. 4- أدوات التّشبيك Networkingتستجيب التّطبيقات التّي تعمل ضمن حاويّات إلى تصميم خَدَميّ التوجّه يُشجّع على تقسيم الوظائف بين عدّة عناصِر أقلَّ تعقيدًا. يُتيح هذا الأسلوب في التّصميم سهولةً في الإدارة والتّوسّع، ولكنّه يتطلّب تأمينًا وثباتًا أكثر في تشبيك مختلف العناصر مع بعضها. يُوفِّر Docker في هذا الإطار البُنية الأساسيّة لتأمين التّواصل بين الحاويّات Container-to-container وبين الحاويّات والمُستضيف Container-to-host. يُتيح Docker افتراضيًا آليّتيْن لربط الحاويّات معًا. الأولى هي عرض منافذ Ports الحاويّة، عبر النظام المُستضيف للتوجيه Routing إلى الخارج، وذلك بشكل اختياري. يُمكِن تعيين منفذ من الحاويّة إلى منفذ في النّظام المُستضيف أو السّماح لDocker باختيّار منفذ عالٍ (منفذ ذو رقم أعلى) غير مُستخدَم. هذه طريقة عامّة تعمل في أغلب الحالات لتوفير الولوج إلى الحاويّة. الطّريقة الثّانيّة هيّ السّماح للحاويّات بالتّواصل عن طريق "روابط" Docker. تحصُل الحاويّات في هذه الحالة على معلومات عن الحاويّة الموجودة على الطّرف الآخر من الرابط؛ ممّا يسمح لها بالاتصال مباشرة إذا كانت مضبوطة للإنصات لمعلومات الطّرف الآخر. تُتاح عبر هذه الطّريقة إمكانيّةُ الاتّصال بين حاويّات موجودة على نفس المُستضيف دون الحاجة لمعرفة منفَذ أو عنوان الخدمة سَلفًا. تُناسِب البُنيةُ الأساسيّة للتّشبيك التي يوفّرها Docker المستضيفات المنفردة أو البيئات المُدارَة بشكل مُباشر. غير أنّ النِّظام البيئي لـDocker أنتجَ مشاريع عديدة تُرَكِّز على زيادة وظائف التّشبيك لصالح المُتعاملين والمُطوِّرين. يُمكن الحصول عبر الأدوات الإضافيّة، من بين أمور أخرى، على: تعديل آلية التّشبيك لإنشاء فضاء عناوين سهل ومُوحَّد بين عدّة مستضيفات. شبكات افتراضيّة خاصّة Virtual private networks لتأمين الاتّصالات بين مختلف المُكوِّنات. تعيين شبكات فرعيّة Sub networks حسب المُستضيف أو حسب التّطبيق. التّأسيس لواجهات اتّصال عبر شبكات محليّة افتراضيّة من النّوع الثّاني (VLAN 2/Macvlan). إعداد وتخصيص عناوين MAC وبوّابات Gateways، ..إلخ للحاويّات. المشاريع التّالية تعمَل على التّحسين من إدارة الشّبكات في Docker: flannel: إضافة طبقة فوقَ آليّة التّشبيك للحصول على شبكات فرعيّة مستقلَّة لكل مُستضيف. weave: جعل كل الحاويّات ضمن نفس الشّبكة عبر إعادة تمثيل بنية التّشبيك. pipework: مجموعة أدوات للإعداد المتقدِّم للشّبكات. 5- الجدولة Scheduling، إدارة العنقود والتّنسيق Orchestrationالمُجدوِل Scheduler هوالآخر عنصر مطلوب لبناء بيئة عنقوديّة للحاويّات. تتولّى المُجدوِلات بدْء تشغيل الحاويّات على المُستضيفات المُتاحة. تُوضِّح الصورة أعلاه نموذجًا مبسَّطًا لاتخاذ قرار الجدولة. يأتي الطّلب للمُجدوِل عبر واجهة تطبيقات برمجية API أو عن طريق أداة إدارة؛ يُقدِّر المُجدوِل بعدها شروط الطّلب وحالة المُستضيفات المُتاحة. يسحب المُجدوِل في المثال معلومات عن كثافة وتمركز الحاويات من مخزن مُوزَّع للبيانات واستكشاف الخدمة (كما تطرَّقنا له سابقًا)، ممّا يُمكّنه من اختيار المُستضيف الأقل انشغالًا للتّطبيق الجديد. تقع عمليّة اختيار المُستضيف في قلب مهام المُجدوِل، وتوجد لديه عادةً دوّال Functions لأتمَمة Automate هذه العمليّة مع ترك خيّار يُمكّن المُدير من تحديد بعض القيود. من الأمثلة على هذه القيود: جدولة الحاويّة للعمل على نفس المُستضيف الذي تعمل عليه حاويّة أخرى مُعطاة. التّأكّد من عدم وضع حاويّة على مُستضيف تعمل عليه حاويّة أخرى مُعطاة. وضع حاويّة على مُستضيف يتطابق مع بيانات وصفيّة Metadata أو علامة مُعطاة. وضع الحاويّة على المُستضيف الأقل نشاطًا. تشغيل الحاويّة على جميع المُستضيفات المُكوِّنة للعنقود. يهتم المُجدوِل بتحميل الحاويّات إلى المستضيفات المناسِبة إضافةً إلى بدْء تشغيلها، إيقافها وإدارة دورة حياة العمليّة ككلّ. تُضمَّن عادةً وظائفُ إدارة العنقود إلى المُجدوِل نظرًا لضرورة تفاعله مع كل مستضيف من المجموعة المكوِّنة للعنقود، وهو ما يُعطي للمُجدوِل القدرةَ على الحصول على معلومات عن مكوّنات العنقود والقدرة على إجراء مهام إداريّة. يُشير التّنسيق في هذا الإطار إلى المُزاوجة بين جدولة الحاويّات وإدارة المُستضيفات. المشاريع التالية من الأشهر في تقديم أدواتٍ للجدولة والإدارة: fleet: أداة للجدولة وإدارة العناقيد. marathon: مُجدوِل ومُدير خدمات. Swarm: مُجدوِل ومُدير خدمات. mesos: خدمة لإسناد وتوطيد موارد المُستضيف لاستغلالها من طرف المُجدوِل. kubernetes: مُجدوِل متقدِّم يستطيع إدارة الحاويّات على شكل مجموعات. compose: أداة تنسيق لإنشاء مجموعات حاويّات. خاتمةيُقدّم Docker عبر المشاريع الدّاعمة له أدواتٍ لإدارة البرامج، التصميم، وإستراتيجيةً للنشر تُعطي المرونة في التوسّع الشّامل. بعد النّظرة العامة التي قدّمتْها الفقرات السّابقة يُمكن الانتقال إلى دراسة وفهم القدرات التي توفرها الأدوات الدّاخلة في النِّظام البيئي المُحيط بDocker ثم تنفيذ ونشر تطبيقات مُعقَّدة ومرنة كفاية لتعمَل على نُظُم تشغيل مختلفة. ترجمة -وبتصرّف- للمقال:The Docker Ecosystem: An Introduction to Common Components

يُوفِّر Docker كل الدّوال (Functions) المطلوبة لبناء، رفع Upload، تنزيل Download، بدْء تشغيل وإيقاف الحاويّات؛ وهو مناسِب جدًّا لإدارة كل هذه العمليّات في بيئة من مُستضيف وحيد بعدد محدود من الحاويّات. رغم ذلك يلجأ كثيرون لاستخدام هذه المنصّة كأداة لبناء حاويّات تتوزَّع على عدّة مستضيفات مختلفة. تُمثِّل إدارة عناقيد من المُستضيفات Clustered hosts تحدِّيًّا جدّيًا يتطلّب مجموعةً مختلفة من الأدوات. سنعرِض في هذا المقال المُجدوِلاتِ Schedulers وأدواتِ التّنسيق Orchestration المُستَخدمةَ مع Docker. تُمثّل هذه الأدوات الواجهة الرّئيسة لإدارة الحاويّات والنّشر المُوزَّع. جدولة الحاويات، التنسيق وإدراة العنقودالقدرة على إدارة كل نظام مُستضيف وتفادي تعقيدات البنية التّحتيّة لبيئة العمل هي إحدى الوظائف الأكثر جاذبية عند التّطرق إلى توسّع Scaling التّطبيقات عبر عدة أنظمة مستضيفة. يظهر في هذا الإطار مُصطلح التّنسيق الّذي يشمل جدولة الحاويّات، وإدارة العنقود، وفي بعض الأحيان تجهيز وإعداد مُستضيفات جديدة. تُحيل الجدولة Scheduling عند الحديث عن النّظام البيئي لDocker إلى القدرة على رفع ملفّ يُعرِّف كيفيّة تشغيل حاويّة مُعيَّنة إلى النّظام المُستضيف؛ في حين نعني بالمُجدوِلات الأدواتِ المسؤولةَ عن التّدخّل في نِظام التّهيِئة الأوّليّة Init system لإدارة الخدمات حسب المطلوب. أمّا إدارة العنقود فتُشير إلى التّحكّم في مجموعة من المُستضيفات. يُمكِن أن تشمل هذه العمليّة إضافة أو إخراج مُستضيفات من العنقود، الحصول على معلومات عن حالة المُستضيفات أو الحاويّات، وبدْء تشغيل أو إيقاف العمليّات Processes. ترتبط إدارة العنقود بشكل وثيق مع الجدولة، إذ يجب أن تكون لدى المُجدوِل القدرةُ على الوصول إلى كل واحد من المستضيفات الموجودة في العنقود من أجل جدولة الخدمات. لهذا السبّب يغلُب استخدام نفس الأداة للتّنسيق والجدولة. من أجل إدارة وتشغيل الحاويّات على المُستضيفات المتواجدة على العنقود، يجب على المُجدوِل التّعاطي مع نظام التهيئة الأوّليّة لكلّ واحد من المُستضيفات. يجب على المُجدوِل في نفس الوقت، لتسهيل الإدارة، تقديمُ رؤية مُوَّحّدة لحالة الخدمات على كامل العنقود؛ ممّا يقوده إلى أن يعمل كنظام تهيئة أوليّة عابر للعنقود. لهذا السّبب تلجأ العديد من المُجدوِلات إلى أخذ صوّر طبق الأصل من بنية أوامر أنظمة التّهيئة الأوّليّة، ثمّ تعمل على تجريدها Abstract (إخفاء تعقيدات التّعامل مع بنية هذه الأنظمة). يُعتَبر اختيّارُ المُستضيف أحد أهمّ مسؤوليّات المُجدوِل، حيثُ إنه يتولّى تحديد المُستضيف الّذي ستعمل عليه الخدمة (الحاويّة) أوتوماتيكِيًّا بعدَ اتّخاذ المُدير قرار تنفيذها. يُمكِن للمُدير تحديد قيود على اختيّار المُستضيف، لكن في النّهاية المُجدوِل هو من سيُنفّذ هذه التّعليمات. كيف يتّخذ المُجدوِل قراراته؟تُعرِّف المجدوِلات عادةً سياسة افتراضيّة للجدولة. تُحدِّد هذه السّيّاسة كيف ستُنَفَّذ الخدمات في حال عدم وجود مُدخَلات من طرف المُدير. على سبيل يُمكن أن تكون السّيّاسة الافتراضيّة هيّ وضع الخدمات الجديدة على المُستضيفات الّتي يوجد بها أقلّ عدد من التّطبيقات النّشِطة. تُتيح المُجدوِلات إمكانيّة إعادة كتابة آليّاتِها، ممّا يسمح للمُديرين بتدقيق ضبط عمليّة الاختيّار لتستجيبَ لمُتطَلَّبات مُحدَّدة. على سبيل المثال، إذا وجَب تشغيل حاويّتَين على نفس المُستضيف لكونهما تعملان كوِحدة Unit، فيُمكِن إعلان هذا الغرض أثناء الجدولة. بالمِثل، يُمكِن فصلُ حاويَّتيْن بحيثُ لا تعملان على نفس المُستضيف، لأغراض تتعلّق بالتّوفّر العالي High availability لنظيرَيْن Instances من نفس الخدمة على سبيل المثال. قد تُمثَّل القيود الّتي يُمكِن لمُجدوِل أخذها في الحسبان، على هيأة بيانات وصفيّة Metadata مُوَّجَّهة لأغراض التّحكّم، فتُوضع لصائق Labels على المُستضيفات ليستعين بها المُجدوِل. يكون هذا ضروريًّا إذا كان المُستضيف يحوي تجزئةَ بيانات Data volume يحتاجها أحد التّطبيقات. تحتاج بعض الخدمات إلى أن تُنشَر على كلّ مُستضيف في العنقود، وهو ما تُتيحه المُجدوِلات. ما وظائف إدارة العنقود التي توفرها المُجدوِلات؟ترتبِط وظيفتا الجدولة وإدارة العنقود ارتباطًا وثيقًا لأنّ كلًّا منهما تتطلّب القدرة على العمل على مُستضيفات مُحدَّدة وعلى العنقود ككلّ. تُستخدَم برامج إدارة العناقيد لطلب معلومات عن أعضاء عنقود، إضافة أو حذف أعضاء، أو حتّى الاتّصال بمُستضيف مُعيَّن لإدارة أكثر تخصيصًا. يُمكِن أن تُضاف هذه الوظائف إلى المُجدوِل كما يُمكِن إدراجها ضمن مسؤوليّة برنامج مُستقلّ. ترتبِط إدارة العنقود في كثيرٍ من الحالات بأداة استكشاف الخدمة أو مخزن إعدادات بصيغة مفتاح-قيمة. يُفيد هذا الارتباط في توزيع المعلومات وحفظها عبرَ كامل العنقود، كما أنّ المنصّة في هذه الحالة جاهزة لوظيفتها الأوليّة. في هذه الحالة (ارتباط أداة الإدارة باستكشاف الخدمة ومخزن الإعدادات) يحتاج إجراء بعض مهامّ إدارة العنقود، إن لم تتوفّّر طُرُق Methods للتّخاطُب مع المُجدوِل، إلى تغيير قيّم موجودة في مخزن الإعدادات عن طريق واجهته لبرمجة التّطبيقات Application programming interface, API. على سبيل المثال: تُغَيَّر عضويّات العنقود عن طريق التّعديل على قيّم في مخزن الإعدادات. يُحتفَظ بالبيانات الوصفيّة المُتعلِّقة بالمُستضيفات في مخزن الإعدادات؛ حيثُ يُمكن استخدامها كما ذكرنا سابِقًا لاستهداف مستضيف أو مجموعة من المُستضيفات بقرارات جدولة. كيف تكون الجدولة في حالة تجميع الحاويّات؟يتوجّب في بعض الأحيان إدارة عدّة خدمات كما لو كانت تطبيقًا واحدًا، ففي بعض الحالات لا يُمكن حتى نشر خدمة دون نشر خدمة أخرى مُصاحِبة لها، لارتباط عملهما. تُوفّر عدّة مشاريع تنسيقًا متقدِّمًا يأخذ في الحسبان تجميع الحاويّات، ولهذه الوظيفة عدّة فوائد. تسمح إدارة الحاويّات على مجموعات للمُدير بالتّعامل مع تشكيلة من الحاويّات على أنّها تطبيق واحد. يُبسِّط تشغيلُ عدّة عناصر مُرتبِطة بإحكام إدارةَ التّطبيقات دون أن يكون ذلك على حساب فوائد تقسيمها إلى حاويّات لكلٍّ منها وظيفة منفصِلة؛ حيثُ يسمح للمُدير بالحفاظ على فوائد استخدام التّصميم خدَمي التّوجّه Service-oriented مع تقليل جهد الإدارة. يُمكِن أن يعنيَ تجميعُ التّطبيقات ببساطة جدولتَها وإتاحة إمكانيّة تشغيلها أو إيقافها معًا؛ كما أنّه قد يُشير إلى تصوّرات أكثر تعقيدًا مثل فصل كل مجموعة ضمن شبكة فرعيّة أو العمل على توسّع Scaling مجموعة من الحاويّات بدل العناية بالتّوسّع الفردي لكل واحدة منها. ماذا نعني بالتّجهيز Provisioning؟يرتبِط مفهوم التّجهيز بإدارة العناقيد. نعني بالتّجهيز مجموعة الآليّات الّتي تسمح بإضافة وإعداد مُستضيفات جديدة لتكون جاهزةً للعمل ضمن العنقود. في حالة نشر التّطبيقات عبر Docker فإنّ التّجهيز يعني إعداد Docker وضبطَ المُستضيف الجديد للالتحاق بعنقود موجود. تختلف طريقة التّجهيز بشكل كبير حسب الأدوات المُستخدَمة ونوعيّة المُستضيف، ولكن الهدف في الأخير هو نظام جديد جاهز للعمل. على سبيل المثال، إذا كان المُستضيف آلة تخيّليّة Virtual machine فإن أدواتٍ مثل Vagrant يُمكِن أن تُستخدَم لإعداد المستضيف الجديد. يسمح معظَم مزوّدي الخدمات السّحابية Cloud providers بإنشاء مُستضيفات جديدة اعتمادًا على واجهة تطبيقات برمجيّة API. على الجانب الآخر، يحتاج تجهيزُ عتاد خام (حاسوب بدون نظام تشغيل) لتدخّل يدوي أكثر؛ يُمكن اللّجوء إلى أدوات مثل Ansible، Puppet، Chef أو Salt من أجل الإعداد التّمهيدي للمُستضيف وتجهيزه بالمعلومات المطلوبة للاتّصال بالعنقود. يوجد خيارات للتّجهيز: إمّا أن يكون عمليّة يدويّة يُطلِقها المُدير، أو أن يكون جزْءًا من أدوات إدارة العنقود من أجل أتممة التوسّع Automation. يتطلّب الخيّارُ الأخير تعريفَ إجراء يطلُب مُستضيفات جديدة والشّروط الّتي يجب أن يحصُل حسبها الطّلب. على سبيل المثال، إذا كان تطبيقٌ يُعاني من الحِمل الزّائد على الخادوم، فيُمكِن ضبط مُستضيفات وإلحاقُها بالنِّظام لتتوسَّعَ الحاويّات أفقيًّا عبر البُنية التّحتيّة الجديدة، من أجل التّخفيف من الضّغط على الخادوم. ماهيّ المُجدوِلات الأكثر انتشارًا؟من بين المشاريع الأكثر شهرةً في الجدولة وإدارة العناقيد (الوظائف الأساسيّة): Fleet: أداة الجدولة وإدارة العناقيد ضمن توزيعة CoreOs. تقرأ Fleet معلومات الاتّصال لكل مُستضيف في العنقود من etcd ( أداة استكشاف خدمة وإعداد عموميّ مُوزَّع لكل من الحاويّات والأنظمة المُستضيفة، جزْء من توزيعة CoreOs) وتُوفِّر خدمة إدارة شبيهة بSystemd (نِظام تهيئة أوّليّة بدأت الكثير من توزيعات غنو/لينوكس اعتمادَه ليكون بديلًا عن أنظمة التّهيِئة الأوّليّة التّقليديّة). Marathon: وهو العنصُر المسؤول عن الجدولة وإدارة الخدمات في Mesosphere (نظام تشغيل مُوجَّه لإدارة مراكز البيانات Data centers). يعمل مع mesos (أداة لتجريد وإدارة جميع موارد العنقود) للتّحكّم في الخدمات الّتي تعمل لفترات زمنيّة طويلة. كما أنّه يُوفِّر واجهة ويب لإدارة الحاويّات. Swarm: أعلن مشروع Docker عن مُجدوِل Swarm في ديسمبر/كانون الأوّل سنة 2014، ويأمل في أن يُقدِّمَ مجدوِلًا جيّدًا يُمكنه تقسيم الحاويّات على المُستضيفات المُجهَّزَة على Docker، وذلك باستخدام نفس الصّيّاغة Syntax الّتي يستخدمها Docker. بالنّسبة للجدولة المُتقدّمة والتّحكّم في مجموعات الحاويّات، توجد المشاريع التّاليّة: kubernetes: مُجدوِل مُتقدّم من Google. يُتيح kubernetes تحكّمًا متقدّمًا في الحاويّات؛ حيث يُمكِن توصيف الحاويّات، تجميعها، وإعطاءُها شبكات فرعيّة مستقلّة للاتّصال. compose: مشروع تابِع لـ Docker، أُنشِئ لإضافة إمكانيّة إدارة مجموعات من الحاويّات باستخدام ملفّات إعداد تقريريّة Declarative. يستخدِم روابط Docker لمعرفة معلومات عن علاقات التّبعيّة بين الحاويّات. خلاصةتُمثِّل إدارة العناقيد والجدولة جزأين مهمَّيْن من إعداد وتنفيذ خدمات تعتمد على الحاويّات في بيئة مُوزَّعة مُكوَّنة من عدّة مُستضيفات، إذ تُوفِّران الوظائف الأساسيّة من أجل بدْء تشغيل الخدمات والتّحكّم فيها. يُمكِن عبر استخدام المُجدوِلات بفعاليّة إحداثُ تغييرات كبيرة على عمل التّطبيقات، بالقليل من الجُهد.

مقدّمةتُمثِّل الحاويّات حلًّا أنيقًا لمن يبحث عن تصميم ونشر تطبيقات تعمل على نطاق واسع. يُوفّر Docker التّقنيّة المسؤولة عن إعداد الحاويّات، وتُساعده مشاريع أخرى عديدة عبر تطوير الأدوات المطلوبة لتحضير النّشر في بيئة العمل وللتّواصل بين مختلف مكوّناته. استكشاف الخدمة Service discovery هي إحدى التّقنيّات المركزيّة الّتي تعتمد عليها العديد من بيئات Docker. تُمكّن هذه التّقنيّة التّطبيقاتِ أو العناصرَ المُكوّنةَ لها من معرفة معلومات عن بيئة عملها. يُستعان عادةً بمخازن تعتمد صيغة مفتاح-قيمة key-value لهذا الغرض. تُستخدَم هذه المخازن أيضًا لإملاء تفاصيل حول ضبط الإعدادات. يُتيح ضبطُ أداة استكشاف الخدمة الاحتفاظَ بإعداد تشغيل الحاويّة خارجها وهو ما يُساعد من إعادة استخدام نفس الحاويّة في عدّة بيئات عبر إنشاء صورة منها. يهدف هذا المقال إلى عرض فوائد استخدام آليّة استكشاف الخدمة في بيئة عنقوديّة Clustered من مستضيفات Docker. سنُركّز على المفاهيم العامّة مع إعطاء أمثلة مُحدَّدة عندما يكون ذلك مناسِبًا. استكشاف الخدمة ومخازن الإعداد العامّة Global Configuration Storesتقوم تقنيّة استكشاف الخدمة على فكرة أساسيّة تتمثّل في أنّه يجب أن تكون لدى أي نظير من التّطبيق Instance القُدرة على التّعرف برمجيًّا على تفاصيل البيئة التي يعمل فيها. هذا الأمر ضروري لتمكين "زرع" النّظير الجديد في بيئة التّطبيق دون الحاجة للتّدخل اليدوي. تُنَفَّذ أدوات استكشاف الخدمة في العادة على هيئة سجلّات تُخزّن معلوماتٍ عن التّطبيقات أو الخدمات العاملة حاليًّا ضمن بيئة العمل، ويُمكن الوصول إليها من جميع عناصر البيئة. تُوزَّع هذه السّجلّات بين عدّة مُستضيفات لجعلها قابلةً للتّوسّعScalable وقادرةً على العمل عند حصول أخطاء. يُمكِن استخدام منصّات استكشاف الخدمة لحفظ أيّ نوع من معلومات الإعداد، رغم أنّ الهدف الأوليّ من إنشائها هو تقديم بيانات الاتّصال لربط العناصِر في ما بينها. تستفيد العديد من عمليّات النّشر من هذه الميزة عن طريق حفظ بيانات الإعداد لدى أداة الاستكشاف؛ حيثُ إن الحاويّات تستطيع تغيير سلوكها اعتمادًا على ما تعثُر عليه من إعدادات، إذا كانت مضبوطةً للقيّام بذلك. كيف تعمل أداة استكشاف الخدمة؟تُوفِّر كل أداة استكشاف واجهةَ تطبيقات برمجيّة API يُمكن للعناصِر استخدامُها لضبط إعداداتها أو الحصول على بيانات. لهذا السّبب نجد أنّ كل تطبيق يُضمِّن عنوانَ استكشاف الخدمة مُباشرةً في المصدَر Source أو يُوفّره كخيّار أثناء التّشغيل. تُتيح أدوات استكشاف الخدمة الوصول إلى القيّم الّتي تحتفِظ بها عن طريق طلبات Http. تسجيلُ التّطبيق لنفسه لدى أداة الاستكشاف مباشرةً بعد بدْء عمله، هو أولى خطوات عمل خدمة الاستكشاف؛ فيُسجّل كل المعلومات الّتي ستحتاجها بقيّة العناصر عند محاولتها الاستفادة من الخدمة الّتي يُقدِّمها.يجب على قاعدة بيانات MySQL مثلًا، تسجيلُ عنوان IP ومنفَذ Port الوصول للبرنامج؛ يُمكن أن تُضيف أيضًا اسمَ المُستخدِم واعتمادات Credentials الحساب المطلوبة لتسجيل الدّخول. أول ما يقوم به تطبيق يُريد الاستفادة من خدمةٍ مّا عند بدْء تشغيله، هوّ طلب أداة الاستكشاف لإعطائه معلومات عن نقطة اتّصال مُعرَّفة مُسبَقًا للارتباط بالخدمة. يُمكنه بعد ذلك التّفاعل مع العناصِر الّتي يحتاجها وفقًا للمعلومات الّتي يعثُر عليها. مُوزِّع الحِمل Load balancer مثالٌ جيّد، حيثُ بإمكانه - عن طريق أداة الاستكشاف - العثور على معلومات عن كل الخواديم الخلفيّّة Backend servers حتّى يُوجِّهَ إليها حركة الاتّصالات حسب إعداداتِها والمعلومات الّتي تُغذّي بها (أي الخواديم) أداةَ الاستكشاف. ينتُج عن استخدام أداة استكشاف وضعُ تفاصيل الإعداد خارجَ إطار الحاويّة. يجعل هذا الأمر الحاويّات أكثر مرونة وأقل ارتهانًا لإعدادات مُعيَّنة؛ كما أنّه يُسهِّل على عناصِر التّطبيق التفاعلَ مع نظائر جديدة من نفس الخدمة متيحًا بذلك إمكانيّة الإعداد الدّيناميكي. كيف يُؤثِّر تخزين الإعدادات؟تُعدّ القُدرة على تخزين أي نوع من بيانات الإعداد، بما فيها بياناتٌ تطلُبها أجزاء التّطبيق أثناء تنفيذها، إحدى المزايا الأساسيّة في أي نظام عمومي موزَّع لاستكشاف الخدمة. يعني هذا أنّه بالإمكان وضع بيانات إعدادٍ أكثر خارج الحاويّة، ضمن بيئة تنفيذ أوسع. يجب أن تُصمّم التّطبيقات - حتّى تعمل هذه الطّريقة بشكل فعّال - بعدد معقول من الخيّارات الافتراضيّة Defaults على أن يكون من الممكن إبدالُها بقيّم أخرى يُتَحصَّل عليها من مخزن الإعدادات أثناء التّنفيذ. تجعل هذه الطّريقة من استخدام مخزن الإعداد مُماثِلًا لاستخدام خيّارات سطر الأوامر Command line flags (أو Command line options) مع فرق أنّ استخدام مخزن إعدادات متاح للعموم يسمح بإنشاء وتشغيل نظائر أخرى من نفس العُنصر دون جهدٍ زائد. كيف يُساعِد مخزن الإعدادات في إدارة العُنقود؟لا يظهر للوهلة الأولى، العونُ الّذي يُقدّمه مخزنٌ مُوزَّع للإعدادات يستخدم صيغة مفتاح-قيمة، في حفظ وإدارة عُضويّات Membership العنقود. مخازن الإعدادات هي في الواقع البيئة المُثلى لحفظ آثار عضويّات المُستضيفات ووضعها تحت تصرّف أدوات إدارة العنقود. في ما يلي بعض معلومات المُستضيفات الّتي يُمكن حفظها على شكل مفتاح-قيمة في مخازن إعدادات مُوزَّعة: عناوين IP المُستضيفات. معلومات الاتّصال بالمُستضيفات. بيانات وصفيّة Metadata ومُلصقات Labels يُمكِن التّحكم بها من أجل اتّخاذ قرارت تتعلّق بالجدولة Scheduling. الدّور Role داخل العنقود (في حال استخدام نموذج قائد/تابِع Leader/follower model). لن تضطّر في الظّروف الاعتياديّة إلى الاهتمام بهذه التّفاصيل عند استخدام أداةٍ لاستكشاف الخدمة؛ ولكنّها وسيلة تُوفّر لأدوات الإدارة إمكانية الاستعلام أو التّعديل على معلوماتٍ تتعلّق بالعنقود. ماذا عن التّعرّف على الإخفاق Failure detection أثناء التّنفيذ؟يُمكن وضع آليّة للتّعرّف على إخفاق التّطبيقات عبر عدّة وسائل. السّؤال الّذي يجب طرحُه هنا هل ستُحدَّث خدمة الاستكشاف عند توقّف تطبيق عن العمل لتعكس حالة التّطبيق من حيثُ إنه لم يعُد يعمل؟ هذا النّوع من المعلومات حيوي للتّقليل من إخفاق الخدمة. تُتيح العديدمن أدوات استكشاف الخدمة تعيينَ قيّم مع مهلة زمنيّة يُمكِن ضبطُها Configurable Timeout. في هذه الحالة يضبُط العنصُر قيمةً ويُرفق معها مهلة زمنيّة، ثم يُعلِم أداة الاستكشاف بانتِظام بوجوده وفي نفس الوقت يُعيد تعيين المُهلة. يُعتبر العُنصُر خارج الخدمة وتُسحب معلوماته من مخزن الإعدادات عند بلوغ المُهلة الزّمنيّة المُحدَّدَة دون أن يتّصل بأداة الاستكشاف لإعلامها بوجوده وإعادة تعيين المُهلة. يتغيَّر طول المُهلة حسب التّطبيق والمُدّة الّتي يحتاجها للتّعامل مع إخفاق أحد العناصِر المُكوّنة له. توجد طريقة أخرى تعتمد على إنشاء حاويّة مُساعدة مع كل عنصُر، تقتصر مهمّة الحاويّة المُساعِدة على التّحقق من سلامة العنصُر دورِيًّا ثمّ تحديث السّجل في حال توقّف العنصُر عن العمل. نقطة ضعف هذه الطّريقة هي الحاويّة المُساعدة الّتي يُمكن أن تتوقّف عن العمل وهو ما قد ينتُج عنه معلومات خاطئة في مخزن الإعدادات. تتغلّب بعض النُّظُم على هذه المسألة عن طريق إضافة إمكانيّة التحقّق من سلامة الحاويّة إلى أداة الاستكشاف. يُمكن لخدمة الاستكشاف بهذه الطّريقة فحصُ العناصِر المُسجَّلة لديها دوريًّا للتّأكد من حالتها. ماذا عن إعادة ضبط الخدمة عند التّعديل على بيانات الإعدادات؟تُمثّل إعادة الضّبط ديناميكيًّا إحدى التّحسينات الأساسيّة على نموذج استكشاف الخدمة الأصلي. تعني إعادةُ الضّبط ديناميكيًّا قدرةَ أداة الاستكشاف على التّفاعل مع التّغييرات في مخزن الإعداد وضبط عناصِر التّطبيق حسب التّعديلات الجديدة؛ عكسَ النّموذج الأصلي الذي يقتصِر تأثيره على الإعداد الابتدائي للعُنصُر(عند بدْء تشغيله). على سبيل المثال، حينَ يفحص مُوزِّع حِمل الخواديمَ الخلفية ويجد أنّ أحدها توقّف عن العمل؛ فإنّه سيحتاج لأخذ ذلك بالحُسبان من أجل تعديل إعداداتِه لتُناسِب الوضعيّة الجديدة. توجد عدّة مشاريع تُركِّز على موزّع الحِمل نظرًا لكونه أحد التّطبيقات الأكثر احتيّاجًا لهذه الخاصيّة. يتميّز HAProxy بأنّه أحد أكثر هذه المشاريع شُهرةً لما يتمتّع به من شعبيّة بين المُهتمّين بآليّات توزيع الحِمل، في حين أنّ مشاريع أخرى تتمتّع بمرونة أكبر حيثُ بالإمكان استخدامُها لإحداث تغييرات في كل أنواع البرامج. تستعلم هذه الأدوات بانتظام خدمةَ الاستكشاف بحثًا عن تغييرات، وفي حال وجودها تستخدم نظام قوالب لتوليد ملفّاتِ إعداد جديدةً تُدمِج القيّم الّتي أرسلتها خدمة الاستكشاف. في الأخير يُعاد تشغيل التّطبيق لأخذ التّغييرات الجديدة في الحسبان. يحتاج هذا النّوع من الإعداد الدّيناميكي إلى تخطيط أكبر أثناء عمليّة بناء التّطبيق إذ أنّ كل هذه الآليّات يجب أن تتواجد في الحاويّة الّتي تُمثّل العُنصر، وهو ما يجعل من الحاويّة مسؤولةً عن تعديل إعداداتِها. يُمثِّل استخراج القيّم المطلوبِ كتابتُها في سجلّ استكشاف الخدمة، وتصميم بنية بيانات Data structure تسهُل الاستفادة منها تحدِّيًا آخر في بناء نظام إعداد ديناميكي. مع ذلك يُمكن لهذا النّظام أن يُقدّم مرونةً كبيرةً في الإعداد. ماذا عن الأمان؟يطرح كثيرٌ من المبتدئين مسألة الأمان عند الحديث عن مخازن الإعدادات المتاحة للعموم. هل من المُناسِب حقًّا حفظُ بيانات الاتّصال في أماكن يُتاح الوصول إليها للعموم؟ تختلف الإجابة على هذا السؤال كثيرًا حسب ما تُريد حفظَه في مخزن الإعدادات وحسب عدد طبقات الأمان الّتي ترى أنّها مناسِبة لتأمين بياناتك. تسمح أغلب أدوات استكشاف الخدمة بتعميّة Encryption الاتّصالات عن طريق SSL/TLS. يكفي وضعُ بعض أدوات الاستكشاف الّتي لا تهتم كثيرًا بالخصوصيّة Privacy في شبكة خاصّة، لكن وجود تأمين إضافي سيُفيد على الأرجح الكثير من التّطبيقات. يكمُن أحد الحلول الأمنيّة في إتاحة الوصول العموميّ إلى أداة الاستكشاف ولكن تُعمَّى (تُشَفَّر) البيانات المكتوبة ضمن سجل الأداة بحيثُ يتوجَّب على أي تطبيق يُريد الاستفادة من معلومة متاحة في السّجلّ امتلاكُ المفتاح السّري الخاص بهذه المعلومة حتّى يستطيعَ فكّ تعميّة Decrypty البيانات. تلجأ أدوات أخرى إلى مُقاربة مختفلة أساسُها إدخال قوائم تحكّم في الوصول Access control lists (أو ACL اختصارًا) لتقسيم فضاء المفاتيح إلى عدّة مناطِق، تُعرّف كل واحدة منها مُتطلّبات مُحدَّدة ويُعتَمَد عليها لإدارة مُلكيّة وإمكانيّة الوصول إلى المعلومات. تُؤسّس هذه المُقاربة لطريقة بسيطة تُوفّر لبعض الأطراف إمكانيّة الحصول على معلومات بينما تُبقيها خارج مُتناوَل أطراف أخرى. يُمكن ضبط كل عنصُر ليُتاح له الوصول إلى المعلومات الّتي يحتاجها فقط. ما هيّ أدوات استكشاف الخدمة الأكثر انتِشارًا؟نعرِض في الفقرات التّاليّة لبعض المشاريع الّتي تعمل على تنفيذ المبادئ العامّة المذكورة في الفقرات السّابقة. من أكثر هذه المشاريع رواجًا: etcd: أنشأها مطوّرو توزيعة CoreOS لتوفير أداة استكشاف خدمة وإعداد عموميّ مُوزَّع لكل من الحاويّات والأنظمة المُستضيفة. تمتلك هذه الأداة واجهةَ تطبيقات برمجيّة API يُتوَصَّل إليها عن طريق Http إضافةً إلى سطر أوامر على كل مُستضيف. consul: تتميّز هذه الأداة بالخصائص المتقدّمة الّتي توفّرها، مثل التحقّق من صلاحيّة الإعداد، قوائم التّحكّم في الوصول ACL، إعداد HAProxy، ...إلخ zookeeper: وهيّ أداة أقدم من السّابقتيْن. تتميّز بمنصّة أكثر ثباتًا، وذلك على حساب نقص بعض الوظائف الحديثة. المشاريع التّاليّة تعمل على تمديد وظيفة الأداة القاعديّة لاستكشاف الخدمة: Crypt: يُعطي التّطبيقات إمكانيّة تعميّة المعلومات التّي تحتفِظ بها في مخزن الإعدادات عن طريق مفتاح تعميّة عمومي Public key. يُمكِن للتّطبيقات الّتي لديها مفتاح فك التّعميّة Decryption key فقط قراءةُ هذه المعلومات. Confd: ويهدِف إلى إضافة قابليّة إعادة الضّبط ديناميكيًّا والتّحكّم في التّطبيقات حسب التّغييرات في خدمة الاستكشاف. يتضمّن هذا المشروع عدّة وظائف أهمّها مراقبَة مخزن الإعدادات بحثًا عن تعديلات، ونظامًا للقوالب يُستخدم لإنشاء ملفّات إعداد جديدة اعتمادًا على المعلومات المُمجمَّعة وقابليّة إعادة تحميل التّطبيقات عند تغيير إعداداتِها. vulcand: يعمل Vulcand كموزِّع حِمل بين مجموعات من العناصِر. يتعرّف هذا المشروع على أداة etcd ويُمكنه العمل وفقًا للتّغيرات في مخزن الإعدادات. marathon: وهو في الأساس مُجدوِل Scheduler (المقال الأخير من هذه السّلسلة يتناول المُجدوِلات)، ولكنّه يُضمّن آليّة بسيطة لإعادة تحميل HAProxy عند التّغيير على خدمات يجب توزيع الحِمل بينها. frontrunner: يُلحق بmarathon لتقديم آليّة متقدّمة لتحديث HAProxy. synapse: يُضمِّن HAProxy لتوجيه تدفّق البيانات بين مختلف عناصِر التّطبيق. nerve: يُستخدَم بالتّوازي مع synapse للتحقّق من صلاحيّة الإعداد لكل واحد من نظائر العُنصُر. عند توقّف أحد العناصِر عن العمل يُعلِم nerve أداة synapse لأخذ ذلك بالحسبان. خاتمةيسمح استكشاف الخدمة والمخازن العموميّة للإعدادات لحاويّات Docker بالتكيّف مع البيئة المُحيطَة وتغيير سلوك العناصِر الموجودة فيها، وهي مُتطلَّبات أساسيّة لتوفير قابليّة التوسّع والانتشار بسهولة ودون تدخّل يديوي.   ترجمة -وبتصرّف- للمقال The Docker Ecosystem: Service Discovery and Distributed Configuration Stores

مقدِّمةتوجد دائمًا العديدُ من العوائق التي تقِف في طريقك أثناء الانتقال بين مختلف مراحل دورة التّطوير حتى الوصول إلى مرحلة الإنتاج. فإضافة إلى التّأكّد من سلامة عمل التّطبيق في بيئات مختلفة، فقد تُواجهك مشاكلَ مع تتبّع الاعتماديّات Dependencies، التوسّع Scaling، وتحديث كل واحد من العناصر المكوِّنة للتّطبيق دون أن يُؤثِّر ذلك على التطبيق ككلّ. يُحاول Docker التغلّب على العديد من هذه المشاكل عن طريق الحاويّات Containers وأسلوب التّصميم خَدَميّ التّوجّه Service-oriented الّذي يعتمده. تُقسَّم التّطبيقات إلى عناصِر وظيفيّة، تُحَزَّم منفردةً مع كامل اعتماديّاتها، يُمكن إدارتُها ونشرُها بسهولة على مِعماريّات Architectures مُتباينة. تمنح هذه الطّريقة أيضًا سهولةً أكبر أثناء التّوسّع أو التّحديث. نستعرِض في هذا المقال فوائدَ استخدام الحاويّات، وكيفَ يُساعد Docker في حلّ بعض المشاكل المذكورة أعلاه. Docker هو العنصر المركزي في النّشر المُوزَّع للحاويّات، حيثُ يوفِّر سهولةً في الإدارة وقابليةً للتّوسّع. تاريخ مُختصَر لإعداد الحاويّات على Linuxتدعمُ بعض أنظمة التّشغيل الشّبيهة بيونيكس Unix-like OS تقنيّات إعداد الحاويّات منذُ أكثر من عقد من الزّمن، فمفهومَا الحاويّة Container والعزل Isolation ليسَا جديديْن في عالم الحواسيب. على سبيل المثال، أُضيفَت بيئة LXC، التّي شكّلت قاعدةً لتقنيات تاليّة في إعداد الحاويّات، إلى النّواة Kernel في العام 2008. مَزَجت LXC بين استخدام مجموعات التّحكم Control groups (تسمح بعزل وتتبّع استخدام موارد الجهاز، يُشار إليها بـ cgroups اختصارًا) الموجودة في النّواة وفضاءات الأسماء Namespaces (عزل المجموعات بحيثُ لا تشعُر كل مجموعة بوجود أخرى) لإجراء عمليّة عزل بسيطة. قُدِّم Docker في ما بعد بوصفه طريقةً لتبسيط الأدوات المطلوبة لإنشاء وإدارة الحاويّات، فاستخدَم أوّلًا LXC كتعريف Driver للتّنفيذ، قبل أن ينتقل إلى استخدام مكتبة Library تُدعَى libcontainer أُعدَّت خصّيصًا لهذا الغرض. لم يُضِف Docker العديد من الأفكار غير الموجودة أصلًا، إلّا أنّه جعل إنجازَ هذه الأفكار متاحًا لشريحة أكبر من المُطوِّرين ومديري الأنظمة عن طريق تبسيط العمليّة وتوحيدها عبر نفس الواجهة وهوّ ما أدّى إلى تحفيز الاهتمام بإعداد الحاويّات على Linux بين المطوِّرين. تجدُر الإشارة إلى أنّه رغم تركيزنا هنا على حاويّات Docker التّي أوصلتْها شعبيّتُها المتناميّة إلى مرتبة المعيار Standard، إلّا أنّ بعضَ ما سنذكُره ينطبِق على الحاويّات بشكل عامّ. ما الّذي تُضيفه الحاويّات؟تأتي الحاويّات بالعديد من الفوائد الّتي تجذِب إليها كلًّا من المطوِّرين، مديري الأنظِمة، وفِرق العمليّات. في ما يلي بعضٌ من هذه الفوائد. 1- عزل نظام التّشغيل المُستضيف عن التّطبيق الموجود في الحاويّةتهدِف الحاويّات إلى أن تكون معياريّةً بالكامل؛ يعني هذا أنّ الحاويّة تتّصل بالمستضيف وبكل ما يوجد خارج الحاويّة عن طريق واجهات مُعرَّفة. يجب ألّا ينشغل تطبيقٌ يعمل عبر حاويّة بمعرفة تفاصيل موارد المُستضيف أو معماريّته. يُسهِّل هذا الأمر من افتراضات المطوِّر عن بيئة عمل التّطبيق. بالمثل، يتعامل المُستضيف مع كلّ حاويّة على أنّها صندوق أسود؛ فلا يهتمّ بتفاصيل التّطبيق الموجود بداخلها. 2- سهولة التّوسّعوهوّ أحد فوائد عزل المُستضيف عن التّطبيق. يُصبِح التوسّع سهلًا للغاية عند استخدام أسلوب تصميم جيّد أثناء تطوير التّطبيق. يُشكّل التّصميم خدميّ-التّوجّه (سنناقشه لاحقًا) عند دمجه بإعداد الحاويّات؛ اللّبنة الأساسيّة لسهولة التّوسّع . يُمكن -مثلًا - لنظام مُكوَّن من عدّة حاويّات أنشأه مطوّر على حاسوبه الشّخصي أن يتوسَّع أفقيًّا ضمن منطقة الإدراج Staging أو الاختبار Testing، وعند نقل الحاويّات إلى بيئة الإنتاج يستمرّ في التّوسّع مجدّدًا. ملحوظة: المقصود بالتّوسّع الأفقي Horizontal scaling هو استعمال عدّة خواديم وتشغليها بحيث تظهر وكأنّها خادوم واحد، أما التّوسّع العمودي Vertical scaling فيُقصَد به إضافة موارد جديدة لنفس الجهاز (زيادة حجم ذاكرة الوصول العشوائي RAM على سبيل المثال). لا يحتاج التّوسّع الأفقي في الغالب لإعادة تشغيل الجهاز أو الخادوم. 3- إدارة سهلة لاعتماديّات وإصدارات التّطبيقتُمكِّن الحاويّات المُبرمجين من تجميع تطبيق - أو عنصُر منه - مع كامل اعتماديّاته والتّعامل معه كوحدة مستقلّة. لا يهتمّ النّظام المُستضيف بالاعتماديّات الخاصّة بتطبيق معيَّن، فكل المطلوب منه هوّ أن تكون لديه القدرة على تشغيل حاويّات Docker. تجعل هذه الطّريقة من إدارة الاعتماديّات أمرًا سهلًا؛ كما أنّها تُسهّل من إدارة إصدارات البرنامج Versions، فالأنظمة المُستضيفة وفرق العمليّات ليست مسؤولة عن إدارة الاعتماديّات المطلوبة من طرف التّطبيق، فكل ما يحتاجه التّطبيق - إذا استثنينا علاقته بالحاويّات الأخرى - موجود داخل الحاويّة. 4- بيئات تنفيذ Execution معزولة وخفيفة جدَّاعلى الرّغم من أن الحاويّات لا توفّر نفس المستوى من العزل الّذي توفّره الحوسبة التّخيّلية Virtualization إلّا أنّها تفضُلُها من ناحية خفّة بيئة التّنفيذ. تُعزَل الحاويّات على مستوى العمليّات Process Level وتشترك في نواة المُستضيف. يعني هذا أنّ الحاويّة لا تتضّمّن نظامَ تشغيل كاملًا وهو ما يؤدّي إلى بدْء تشغيل يكاد يكون لحظيًا. يُمكن للمطوّرين تشغيل مئات الحاويّات على حواسيبهم الشّخصيّة دون أيّة مشاكل. 5- طبقات مُشتركة Shared layeringجانب آخر تتجلّى فيه خفة الحاويّات هو تقاسمُها لنفس الطّبقات الأساسيّة. يعني اشتراكُ عدّة حاويّات في نفس الطّبقة، الحدَّ من الاستنساخ/التّضاعف Duplication؛ أي استخدامًا أقلّ لمساحة القرص الصّلب والموارِد بشكل عامّ عند إنشاء حاويّات جديدة. 6- قابليّة التّجميع والتّنبّؤ Composability and Predictabilityتُعرِّف ملفّات Docker بالضّبط الإجراءاتِ المطلوبةَ لإنشاء صورة جديدة من حاويّة، وهو ما يُمكِّن من كتابة بيئة التّنفيذ كما لو كنتَ تكتب أسطُرًا برمجية وحفظها عن طريق نظام لإدارة الإصدارات Version Control System (أو VSC اختصارًا) إذا رغبتَ في ذلك. يُنتِج نفس ملف Docker عند إنشائه في نفس البيئة، يُنتِج دائمًا صورةً لنفس الحاويّة. استخدام ملفّات Dockerfiles لعمليّات البناء المُتكرّرة المُتماثِلةيُمكن بناء صوّر Images من حاويّات Docker بطريقة تفاعليّة ولكن من الأفضل غالبًا وضع خطوات الإعداد بعد الانتهاء من تحديدها في ملف Dockerfiles. ملفّات Dockerfiles هيّ ملفّات بناء بسيطة تُعرِّف آليةَ بناء حاويّة انطلاقًا من نقطة بدْء معروفة. استخدام هذه الملفّات بسيطٌ جدًّا ولديها العديد من الفوائد، نذكر منها: سهولة إدارة الإصدارات: يُمكِن حفظ ملفّات Dockerfiles ضمن برنامج لإدارة الإصدارات لتتبّع التّغييرات والتّراجع عن أي أخطاء عند اكتشافها. قابليّة التّنبّؤ: بناء الحاويّات انطلاقًا من ملفات Dockerfiles يُساعِد في التّقليل من الأخطاء البشريّة أثناء عمليّة إنشاء الحاويّات. قابليّة المُحاسبة Accountability: من الجيّد عند التّخطيط لمشاركة صوّر الحاويّات، توفيرُ ملف Dockerfile المُستخدَم لإنشاء الحاويّة لاستخدامه كوسيلة للتّدقيق في عمليّة البناء، حيثُ يُمكن النّظر إليه باعتباره سجِلًّا للأوامر التي نُفِّذَت لإنشاء الحاويّة. المرونة Flexibility: يسمح إنشاءُ حاويّات انطلاقًا من ملفّات Dockerfiles بتجاوز الخيّارات الافتراضيّة المُعطاة في عمليّات البناء التّفاعليّة. يعني هذا أنّك عند استخدام Dockerfiles لن تحتاج لتغيير كل الإعدادت الافتراضيّة الّتي لا تُناسِب احتيّاجاتِك. من هذا المُنطَلَق فإن ملفّات Dockerfiles أداة رائعة لأتمتة Automate إنشاء الحاويّات والتّأسيس للعمليّات المتكرّرة. بُنية التّطبيقات الّتي تعمل عبر الحاويّاتبُنية التّطبيق هيّ أحد أهم المشاغِل الّتي يجب أخذها بالاعتبار عند تصميم تطبيقات مُعدّة للنّشر عبر حاويّات.عمومًا، تعمل الّطبيقات المنشورة عبر حاويّات بشكل أفضل عند تنفيذ تصميم خَدَمي التّوجّه. تُقسِّم التّطبيقات الّتي تتبع تصميمًا خَدَمي التّوجّه وظيفتَها بين عدّة عناصر متمايِزة تتواصَل في ما بينها عبر واجهات مُعرَّفة جيّدًا. تُشجّع تقنيّة الحاويّات بذاتها هذا النّوع من التّصميم إذ أنّه يسمح لكلّ عنصُر بالتّوسّع والتّرقية بشكل منفصل عن بقيّة العناصِر. يجب أن تتوفّر الخصائص التّاليّة في التّطبيقات الّتي تتبع طريقة التّصميم خَدَمي التّوجّه: لا تعتمد على أي وظيفة خاصّة بنظام تشغيل مُستضيف مُحدّد. يُوفّر كل عنصُر واجهة تطبيقات برمجيّة API مُتجانِسة يُمكن للزّبائن عبرها الاتّصال بالخدمة. يجب أن تأخذ الخدمةُ متغيّراتِ البيئة Environmental variables الّتي تعمل بها أثناء الإعداد الابتدائي. يجب أن تُحفَظ بيانات التّطبيق خارج الحاويّة في تجزئات مُرَكَّبة Mounted volumes على النّظام أو في حاويّات خاصّة بالبيانات. تُمكِّن هذه الإستراتيجيّات من استبدال أي عنصُر أو تحديثه بشكلٍ مستقل شرطَ الحفاظ على واجهته البرمجيّة، كما أنّها تُساعد في التّركيز على التّوسّع الأفقي حيثُ يُوَّسَّع العنصُر الذي يُعرقل أداء التّطبيق (نقطة ضعف).يُمكن لكل عنصر تعريفُ قيّم افتراضيّة يُمكن الإقلاع باستخدامها في فترة معقولة، بدلًا من برمجة قيّم خاصّة مباشرَةً في التّطبيق. يُمكن للعنصُر استخدامُ هذه القيّم في الحالات الطّارئة مع تفضيل قيّم يُمكن الحصول عليها عن طريق بيئة العمل. يُتَحصَّل على قيّم من بيئة العمل عادةً عن طريق أدوات مُساعدة على استكشاف الخدمة، يستطيع العُنصر إرسال استعلامات إليها أثناء بدْء التّشغيل. يُسهِّل إخراج بيانات الإعداد من الحاويّة ووضعُها في بيئة العمل من إجراء تعديلات على سلوك التّطبيق دون الحاجة لإعادة بناء الحاويّة، إضافةً إلى إمكانيّة التّأثير على نماذج عدّة من نفس العُنصُر عن طريق إعداد واحد. على العموم فإنّ أسلوب التّصميم خَدَمي التّوجّه يندمج جيّدًا مع إستراتيجيّات الإعداد عن طريق بيئة العمل، فكلّ منهما يسمح بعمليّات نشر مرنة وتوسّع أكثر مباشرة. استخدام سجلّ Docker Registry لإدارة الحاويّاتتحدّثنا عن الخطوة الأولى المُتمثِّلة في تقسيم التّطبيق إلى عناصر وظيفية مُعدَّة للتّواصل بشكل صحيح مع بقيّة الحاويات وقيّم الإعداد الموجودة في بيئة العمل. نأتي الآن للخطوة الثّانية وهي جعل صوّر الحاويّات مُتاحة عبر سجل. رفع صوّر الحاويّات إلى سجل يُعطي مستضيفات Docker إمكانيّة تنزيل هذه الصوّر بمجرَّد معرفة أسمائها ثم إنشاء حاويّات مُماثلة لها بعد ذلك (نظائر Instances). توجد العديد من سجلّات Docker متوفّرة لهذا الغرض؛ بعضُها عمومي يُمكن للجميع عرض واستخدام الصّوّر الموجودة فيها، والآخر خاص. يُمكن أيضًا إضافة وسوم Tags لتسهيل الوصول إلى وتحديث الحاويّات. خاتمةيضع Docker القواعدَ الأساسيّة اللّازمة للنّشر الموزَّع للحاويّات. يجعل عزل عناصر التّطبيق في حاويّات خاصّة بها من التّوسّع الأفقي عمليّةً سهلة تقتصِر على إطلاق نظائر جديدة لنفس العُنصُر أو إيقاف أخرى. يُوفِّر Docker الأدوات المطلوبة ليس فقط لبناء حاويّات بل أيضًا لإدارتها وتشاركها مع مستخدمين أو مُستضيفين جُدُد. في المقال التّالي من هذه السّلسلة سنتطرّق للكيفيّة الّتي تُساهِم بها استكشاف الخدمة ومخازن الإعداد المُوزَّعة عمومًا في نشر الحاويّات عبر عنقود من المُستضيفات. ترجمة -وبتصرّف- للمقال The Docker Ecosystem: An Overview of Containerization