المحتوى عن 'دوكر'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

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

تمّ العثور على 2 نتائج

  1. docker ecosystem

    يُوفِّر 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 لمعرفة معلومات عن علاقات التّبعيّة بين الحاويّات. خلاصةتُمثِّل إدارة العناقيد والجدولة جزأين مهمَّيْن من إعداد وتنفيذ خدمات تعتمد على الحاويّات في بيئة مُوزَّعة مُكوَّنة من عدّة مُستضيفات، إذ تُوفِّران الوظائف الأساسيّة من أجل بدْء تشغيل الخدمات والتّحكّم فيها. يُمكِن عبر استخدام المُجدوِلات بفعاليّة إحداثُ تغييرات كبيرة على عمل التّطبيقات، بالقليل من الجُهد.
  2. docker ecosystem

    مقدّمةيكتسي التّواصل 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 المبنيّة على هذا الأساس بهدف إدارة عنقود حاويّات.