إدارة الشبكات Docker Networks: كيف تتحدث الحاويات مع بعضها بأمان؟

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

فهم الشبكات في Docker ليس موضوعاً ثانوياً، بل جزء أساسي من هندسة التطبيقات الحديثة، خصوصاً في البيئات التي تعتمد على Microservices، التكامل مع CI/CD، والنشر المؤتمت عبر الخوادم السحابية.

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

لماذا تحتاج الحاويات إلى شبكة مدروسة وليست عشوائية؟

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

لذلك يوفّر Docker DNS الداخلي آلية تسمح للحاويات بالتخاطب عبر أسماء الخدمات بدلاً من العناوين المباشرة. هذا يجعل التطبيق أكثر ثباتاً، وأسهل في النقل بين بيئات Development وStaging وProduction.

• تقليل كشف المنافذ للعالم الخارجي.
• عزل الخدمات الحساسة مثل قواعد البيانات.
• تسهيل اكتشاف الخدمات عبر الاسم بدلاً من IP.
• دعم بنية مرنة تناسب أنظمة Pipelines والنشر الآلي.

أنواع الشبكات الأساسية في Docker

شبكة bridge

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

شبكة host

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

شبكة none

تعزل الحاوية تماماً من الشبكة. هذا الخيار مناسب لبعض مهام المعالجة غير المتصلة أو الحاويات التي لا تحتاج أي اتصال داخلي أو خارجي.

شبكة overlay

تستخدم عادة في بيئات التجميع مثل Docker Swarm لربط الحاويات عبر عدة خوادم. وهي خطوة قريبة مفاهيمياً من نماذج الشبكات في Kubernetes.

كيف يتم التواصل بين الحاويات عملياً؟

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

هذا مفيد جداً عند ربط خادم Backend بقاعدة بيانات، وهي الفكرة التي تتقاطع مباشرة مع مقال ربط حاوية خادم (Backend) بحاوية قاعدة بيانات (MySQL/PostgreSQL) آلياً.

docker network create app-net

docker run -d --name db --network app-net -e POSTGRES_PASSWORD=secret postgres

docker run -d --name api --network app-net -p 8080:8080 my-api-image

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

العزل الأمني: لا تجعل كل الحاويات ترى كل شيء

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

• شبكة أمامية بين Reverse Proxy وخدمة الويب.
• شبكة خلفية بين خدمة الويب وقاعدة البيانات.
• شبكة منفصلة لخدمات المراقبة أو السجلات عند الحاجة.

لا تقم بنشر منفذ قاعدة البيانات باستخدام -p 5432:5432 أو -p 3306:3306 إلا إذا كانت هناك حاجة تشغيلية حقيقية ومدروسة. في أغلب المشاريع، يكفي أن تبقى قاعدة البيانات متاحة داخلياً فقط عبر شبكة التطبيق.

إدارة الشبكات عبر Docker Compose

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

إذا كنت قد طبّقت ما ورد في كتابة أول ملف docker-compose.yml خطوة بخطوة، فإليك نموذجاً أكثر احترافية يعزل الطبقات الشبكية بشكل واضح.

version: "3.9"

services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    networks:
      - frontend

  api:
    image: my-api-image
    networks:
      - frontend
      - backend

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - backend

networks:
  frontend:
  backend:

volumes:
  db_data:

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

الفحص والتشخيص عند تعطل الاتصال

عندما تفشل الحاويات في التحدث مع بعضها، لا تبدأ بتخمينات عشوائية. استخدم أدوات الفحص الداخلية لتحديد مكان الخلل: هل المشكلة في الشبكة؟ في الاسم؟ في المنفذ؟ أم في التطبيق نفسه؟

docker network ls
docker network inspect app-net
docker inspect api
docker exec -it api sh

ومن داخل الحاوية يمكنك اختبار الاسم والمنفذ باستخدام أدوات مثل ping أو nc أو curl حسب ما هو متاح داخل الصورة. هنا تظهر أهمية بناء الصور بعناية كما شرحنا سابقاً في كتابة أول Dockerfile: تحويل سكربت Python إلى صورة (Image) معزولة.

أفضل الممارسات الأمنية والمعمارية

• أنشئ شبكة مخصصة لكل تطبيق أو لكل بيئة تشغيل.
• اعتمد على أسماء الخدمات بدلاً من عناوين IP الثابتة.
• لا تنشر إلا المنافذ التي يحتاجها المستخدم أو Load Balancer.
• افصل قواعد البيانات وخدمات الرسائل في شبكات خلفية غير مكشوفة.
• ادمج فحص الاتصال ضمن مهام CI/CD قبل النشر للإنتاج.

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

ما العلاقة بين شبكات Docker وهندسة السحابة الحديثة؟

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

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

الخلاصة

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

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