Docker Compose في المختبر المنزلي: التنظيم، والملفات الشخصية، وأفضل الممارسات

إنفورماتيك ديجيتال » موارد » Docker Compose في المختبر المنزلي: التنظيم، والملفات الشخصية، وأفضل الممارسات

أصبح إنشاء مختبر منزلي حديث باستخدام الحاويات هواية مفضلة لدى العديد من التقنيين. ويُعدّ Docker Compose في صميم هذا الإعداد في أغلب الأحيان : حيث يمكنك تعريف خدماتك باستخدام YAML، والتحكم في إصداراتها باستخدام Git، وتشغيل بيئتك بالكامل بأمر واحد.

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

أساليب عملية لإعداد Docker Compose في مختبر منزلي

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

من جهة، هناك من بدأوا باستخدام أوامر Docker Run المستقلة، ثم انتقلوا إلى Portainer، وأخيراً إلى Docker Compose . هذا سيناريو شائع: يوفر Portainer رؤية ممتازة، وواجهة سهلة الاستخدام، وقوالب، وما إلى ذلك، ولكن في النهاية، يصبح تعديل المعلمات المعقدة أو نقل الإعدادات أمراً شاقاً إذا لم تكن لديك أي ملفات.

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

في هذه الأثناء، يلتزم العديد من المستخدمين بنهج مختلط: عدة ملفات docker-compose.yml صغيرة مجمعة حسب السياق (على سبيل المثال، الوسائط، البنية التحتية، الإنتاجية، المراقبة)، وكلها موجودة في نفس المستودع وعادة ما تشترك في متغيرات البيئة العامة.

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

الملفات الشخصية، والتصنيف حسب الوظيفة، والمختبرات المنزلية الكبيرة

عندما يقترب عدد خدمات مختبرك المنزلي من 30 أو 40 أو 50 خدمة (بما في ذلك خدمات النسخ الاحتياطي مثل قواعد البيانات، وذاكرة التخزين المؤقت، والفهارس)، يصبح من الضروري تنظيمها. وهنا تبرز أهمية كل من تجميع الخدمات حسب وظيفتها واستخدام ملفات تعريف Docker Compose.

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

• الملف الشخصي الأساسي: homelab core، مع Traefik كوكيل عكسي وموفر هوية (مثل OAuth أو Authentik) لمصادقة جميع التطبيقات ضمن نفس المجال باستخدام HTTPS.
• ملف إعلاميخدمات مثل Plex و Sonarr و Radarr و Ombi و SABnzbd أو qBittorrent، المسؤولة عن تنظيم وتنزيل وتقديم محتوى الوسائط المتعددة.
• نبذة عن المرافقأدوات مثل Portainer و Watchtower (إذا تم استخدامها) و Diun و dockcheck أو ما شابه ذلك لإدارة ومراقبة الحاويات والتحديثات.
• ملف تعريف البنية التحتية/المراقبةTraefik و cAdvisor و Prometheus و Grafana و Uptime Kuma و Dozzle وكل ما يتعلق بالمراقبة والتسجيل.
• الملفات التجريبية أو LLM: مجموعات محددة لأنظمة إدارة التعلم أو التطبيقات الغريبة (ChatGPT Next Web local، LibreOffice Online، إلخ) والتي عادة ما تكون معطلة افتراضيًا.

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

في المستودعات المصممة جيدًا، يوجد عادةً ملف "رئيسي" docker-compose.yml في الجذر، يستخدم الأمر include لدفع الملفات الفردية إلى مجلد apps/ أو services/ . بالإضافة إلى ذلك، يتم تكوين جميع الخدمات تقريبًا عبر ملف .env عام واحد، ويتم تخزين بعض البيانات السرية في دليل secrets/ ، مما يبسط الإعداد الأولي بشكل كبير.

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

ملف واحد ضخم من نوع docker-compose مقابل عدة ملفات صغيرة

هذا هو النقاش الأزلي: هل يكفي ملف docker-compose.yml واحد يحتوي على كل شيء، أم ملفات متعددة لكل خدمة/مجموعة؟ الإجابة الحقيقية عادةً هي "يعتمد الأمر على ما تريد إعطاءه الأولوية: سهولة الترحيل أم وضوح كل خدمة".

أولئك الذين يؤيدون استخدام ملف رئيسي واحد عادةً ما يسلطون الضوء على العديد من المزايا:

• ترحيل المضيفين سهل للغايةتقوم باستنساخ المستودع، ونسخ ملف .env والبيانات السرية، وربط وحدات التخزين، وتشغيل الأمر `docker compose up -d`. لا حاجة لتصفح كل مجلد على حدة.
• البنية التحتية كرمز للحقيقة: إن البنية الكاملة للمختبر المنزلي (الخدمات، والشبكات، ووحدات التخزين، والتبعيات) موجودة في مكان واحد.
• التحديثات المركزية: أنت تقوم بتغيير إصدار الصورة، أو سياسة إعادة التشغيل، أو بعض عمليات التسجيل، وأنت تعرف بالضبط أين يجب عليك التعديل.

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

أما النهج الآخر فهو إنشاء ملف docker-compose.yml لكل تطبيق أو لكل مجموعة منطقية ، ضمن بنية كهذه:

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

وبهذا، يتم تسمية كل حاوية بشيء مثل bookstack-app-1 أو traefik-reverse-proxy-1 ، مما يساعدك على تحديد المشاكل بسرعة: إذا تعطلت حاوية bookstack-app-1، فأنت تعرف بالضبط المجلد الذي يجب البحث فيه.

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

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

أفضل الممارسات المتعلقة بملفات .env، والتعديلات، والتحكم في الإصدارات

إحدى الحيل التي لا تحظى بالتقدير الكافي هي مركزة الإعدادات في ملفات .env . بدلاً من ملء ملف docker-compose.yml بمتغيرات البيئة، يمكنك تعريف شيء كهذا:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

ثم في ملف YAML، تتم الإشارة إليها كـ ${DB_USERNAME} أو ${DB_PASSWORD} . هذا يجعل Compose سهل القراءة بنظرة سريعة، ويسمح لك بمشاركة المتغيرات بين خدمات متعددة ، والأهم من ذلك، أنه يخزن كلمات المرور في ملف منفصل (والذي يمكنك استبعاده من Git).

في بيئات العمل المختلفة (الإنتاج، الاختبار، التطوير)، يُعدّ استخدام ملف docker-compose.override.yml مفيدًا للغاية . الفكرة هي وجود ملف docker-compose.yml أساسي، وفي ملف override، يتم تعديل العناصر المتغيرة فقط: المنافذ، المسارات، علامات التصحيح، إلخ.

على سبيل المثال، في مرحلة التطوير، يمكنك تحميل ملف بديل حيث تعرض منفذًا مختلفًا، وتُفعّل وضع التصحيح، وتُثبّت شفرة المصدر المحلية . أنت لا تُغيّر ملف YAML الرئيسي، ولكنك تُكيّف البنية مع بيئة التشغيل.

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

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

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

الشبكات، ترايفيك، والتعرض الآمن للخدمات

في معظم المختبرات المنزلية متوسطة التطور، يظهر نفس المزيج: Traefik كخادم وكيل عكسي ومزود هوية مركزي (Auth أو Authentik) . يتيح ذلك عرض العديد من التطبيقات ضمن نطاقات فرعية باستخدام HTTPS وSSO.

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

إذا كنت تستخدم Traefik وتفصل خدماتك في مثيلات Docker Compose مختلفة، فأنت بحاجة إلى تحديد شبكة خارجية مشتركة . شيء من هذا القبيل:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

هنا، يتم إنشاء شبكة traefik_default بواسطة حزمة Traefik، وتُضاف إليها الخدمات الأخرى عبر شبكة خارجية تُسمى traefik-net. تُحدد التصنيفات لـ Traefik الشبكة التي يجب استخدامها لتوجيه حركة البيانات.

عندما تتضمن حزمة واحدة خدمات خلفية (على سبيل المثال، حاوية ويب وقاعدة بياناتها)، يمكنك ربطها بشبكة افتراضية مشتركة، ومنح حاوية الويب فقط حق الوصول إلى شبكة Traefik . سيتم تعيين تسمية لقاعدة البيانات إلى `traefik.enable=false` بحيث يتجاهلها Traefik.

يوفر هذا النوع من الإعداد فائدتين رئيسيتين: العزل بين الخدمات والتحكم في الوصول . فقط الحاويات التي تضع عليها علامات Traefik والتي توجد على شبكة الوكيل تصبح قابلة للوصول من الخارج.

استمرارية البيانات، ووحدات التخزين، وبنية القرص

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

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

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

الفكرة هي أن برامج التنزيل (qBittorrent، SABnzbd، إلخ) ترى مجلد التنزيلات فقط ، بينما تتمتع برامج الإدارة مثل Radarr/Sonarr بإمكانية الوصول إلى كل من التنزيلات والوسائط (لنقل/إنشاء روابط ثابتة)، ولا ترى الخوادم مثل Plex أو Jellyfin سوى مجلد الوسائط.

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

يُستخدم مجلد srv عادةً لتخزين إعدادات التطبيق (على سبيل المثال، /srv/jellyfin/config، /srv/traefik، /srv/paperless، إلخ). ويتم عادةً حفظ إصدارات جزئية منه (القوالب، Caddyfile، إلخ)، مع استبعاد أي شيء بالغ الأهمية أو يستهلك موارد كثيرة.

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

أتمتة عمليات النشر باستخدام GitHub Actions والمشغلات المحلية

إذا كنت ترغب في الارتقاء بالأمور إلى مستوى أعلى، يمكنك أتمتة تحديثات المختبر المنزلي باستخدام التكامل المستمر/التسليم المستمر (CI/CD) . وقد استبدل العديد من المستخدمين Jenkins والأدوات المشابهة بسير عمل يعتمد على GitHub Actions وبرنامج تشغيل مُستضاف ذاتيًا داخل المختبر المنزلي نفسه.

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

تتضمن عملية سير العمل النموذجية خطوات مثل:

• ماسح ضوئي سري على غرار جيت ليكس: في حال قمت بتحميل كلمات المرور أو الرموز المميزة إلى المستودع عن طريق الخطأ.
• الوبر من YAML أو كود البنية التحتية، للحفاظ على تنسيق قابل للقراءة ومتسق.
• تحديث المستودع داخل المختبر المنزلي نفسه: git pull على الخادم المستهدف.
• إعادة إنشاء الحاويات بشكل مُتحكم فيهأوقف العمليات القديمة، وشغّل العمليات الجديدة، وتحقق من الحالة.

المزايا: أمان مُعزز (تتحكم في تسريبات البيانات السرية)، جودة برمجية أفضل، وإمكانية نشر متكررة بضغطة زر واحدة . وبما أنك تستخدم مُشغّلاً محلياً، فإن الصور ووحدات التخزين لا تغادر شبكتك؛ ما عليك سوى الاستفادة من واجهة GitHub لعرض مسارات العمل.

لماذا يجعل Docker Compose الحياة أسهل بكثير في المختبر المنزلي

أمضى الكثيرون سنوات يعتمدون على Docker Run وPortainer، إلى أن اضطروا، بعد حادثة ما أو عملية نقل، إلى إعادة تقييم نهجهم. فعند فقدان مضيف أو نقل الخدمات إلى جهاز آخر، يُعدّ الاعتماد على أوامر أو إعدادات معزولة داخل Portainer فقط فخًا.

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

لم يعد تعديل الخدمة يتطلب "إعادة بناء حاوية يدويًا"؛ بل أصبح الآن مجرد تعديل سطر في ملف، وحفظه، وتشغيل الأمر `docker compose up -d` . لستَ مضطرًا لتذكر الأمر الأصلي أو التنقل بين شاشات Portainer المتعددة.

علاوة على ذلك، إذا كنت تعمل مع عدة خوادم (أجهزة كمبيوتر صغيرة، ووحدات تخزين شبكية، وأجهزة كمبيوتر مكتبية)، فسيكون من المريح للغاية نسخ ملف Compose نفسه إلى جهاز آخر، وتعديل أربعة مسارات، وتشغيل نفس الحزمة على أجهزة مختلفة . في الواقع، يُقرّ الكثيرون بأن Compose قد وفّر عليهم الكثير من الوقت في الأحداث اللاحقة، بعد مواجهة مخاوف تتعلق بفقدان البيانات أو عمليات نقل البيانات غير المنظمة.

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

التحسين: سياق البناء، وعمليات البناء متعددة المراحل، والموارد

على الرغم من أن العديد من حاويات Homelab تأتي من صور عامة، إلا أنك في بعض الحالات ستقوم بتجميعها بنفسك. في هذه الحالات، من المهم إدارة سياق البناء : لا تقم بتحميل المستودع بأكمله دون تصفية، بل اقتصر على مجلد مشروعك (باستخدام توجيه `.dockerignore` قوي) لضمان عمليات بناء سريعة وخفيفة.

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

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

لا تنس سياسات إعادة التشغيل (إعادة التشغيل: دائمًا، ما لم يتم إيقافها، عند الفشل): من خلالها تضمن إعادة تشغيل الخدمات الحيوية (الوكيل العكسي، VPN، قواعد البيانات الرئيسية) تلقائيًا بعد إعادة التشغيل أو الفشل لمرة واحدة.

وأخيرًا، يُنصح بجدولة مهام التنظيف الدورية باستخدام أوامر مثل docker image prune و docker container prune و docker volume prune لإزالة بقايا الإصدارات القديمة أو الحاويات المتوقفة أو وحدات التخزين اليتيمة وبالتالي استعادة مساحة القرص.

الخدمات الصحية، والتسجيل والمراقبة

لتجنب تحول مختبرك المنزلي إلى صندوق أسود، من المهم التركيز على ثلاثة جوانب رئيسية: فحوصات السلامة، والتسجيل المُتحكم به، والمراقبة . يتيح لك Docker Compose تحديد فحوصات السلامة لكل خدمة (باستخدام أوامر مثل `curl -f http://localhost` أو نصوص برمجية محددة) لتحديد ما إذا كانت الحاوية سليمة.

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

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

بالنسبة للمقاييس والمراقبة المستمرة، فإن التركيبة الكلاسيكية هي cAdvisor + Prometheus + Grafana . يعرض cAdvisor إحصائيات استخدام وحدة المعالجة المركزية والذاكرة والقرص والشبكة لكل حاوية؛ ويقوم Prometheus بجمعها بشكل دوري، ويعرضها Grafana في لوحات معلومات جذابة، مع تنبيهات في حالة حدوث أي ارتفاعات مفاجئة.

عادةً ما يشتمل مختبر منزلي مُجهز جيدًا على برنامج Uptime Kuma لإجراء فحوصات التوافر (HTTP، ICMP، TCP، إلخ) ونظام نسخ احتياطي آلي مثل Duplicati لنسخ البيانات الهامة إلى أقراص أخرى أو إلى السحابة. بهذه الطريقة، ستكون على دراية بما يحدث، وإذا حدث خطأ ما، فلن تفقد بياناتك المهمة.

الأمن والوصول عن بعد إلى المختبر المنزلي

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

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

يلجأ البعض ممن لا يرغبون بإدارة شبكات VPN الخاصة بهم إلى خدمات مثل Cloudflare Tunnel أو Tailscale للوصول إلى مختبراتهم المنزلية دون الحاجة إلى فتح منافذ. تُعدّ هذه بدائل ملائمة، ولكن إذا كانت الخصوصية هي أولويتك القصوى، فعليك مراعاة البيانات الوصفية التي قد تجمعها هذه الجهات الخارجية.

من الممارسات الجيدة الأخرى تشفير الخادم وأقراص التخزين الشبكي ، وتطبيق التحديثات الأمنية بانتظام، والحد من التحديثات التلقائية (يتجنب الكثيرون استخدام برنامج Watchtower ويفضلون التحديثات اليدوية المُتحكَّم بها). من الأفضل أن تكون متأخرًا قليلًا ولكن مع التحكم الكامل، بدلًا من تعطيل نصف مختبرك المنزلي بسبب تحديث لم تتحقق منه.

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

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