إذا كنت تعمل مع الحاويات، فستصل عاجلاً أم آجلاً إلى الجزء الأقل جاذبية: انشر حاوية Docker على خادم بعيد دون أن يتحول الأمر برمته إلى فوضى عارمة من الأوامر والمنافذ والشهادات والبرامج النصية. والخبر السار هو أن نظام Docker البيئي (Plesk، ومحرك Docker عن بُعد، وDocker Desktop مع WSL2، وPortainer، وGitHub Actions، إلخ) قد حلّ بالفعل معظم المشاكل الشائعة؛ كل ما عليك فعله هو دمجها معًا بذكاء.
ستتعرف في هذه المقالة، بتفصيل كبير، على كيفية عملها. السيناريوهات المختلفة لاستخدام Docker عن بُعدبدءًا من استخدام خادم Linux أو Windows كـ"جهاز بناء" أو عقدة تشغيل، وصولًا إلى إدارته من خلال Plesk أو VS Code، أو حتى أتمتة عمليات النشر باستخدام Docker Compose و CI/CD. الفكرة هي أنه يمكنك تكرار سير العمل بالكامل: البناء، والتحميل، والتشغيل، وكشف المنافذ، وإدارة وحدات التخزين، والتحكم في الحاويات، دون الحاجة إلى تشغيل Docker مباشرةً على جهازك الرئيسي.
متطلبات وتوافق استخدام Docker على الخوادم البعيدة
قبل نشر أي شيء، يجب أن تكون واضحًا حيث يمكن تشغيل Docker بطريقة مدعومة وما هي القيود؟ ففي بيئات من نوع Plesk، على سبيل المثال، توجد متطلبات محددة للغاية لنظام التشغيل والبنية.
يدعم Plesk برنامج Docker على قائمة مختارة من أنظمة Linux الحديثة: CentOS 7، Red Hat Enterprise Linux 7، Debian 10/11/12، Ubuntu 18.04/20.04/22.04/24.04، AlmaLinux 8.x/9.x، Rocky Linux 8.x وكذلك في بيئات Virtuozzo 7 بدءًا من التحديث 1 Hotfix 1 (7.0.1-686). نقطة مهمة: يعمل Docker في Plesk فقط في أنظمة x64لذا إذا كنت تتعامل مع بنى معمارية نادرة أو 32 بت، فانسَ الأمر.
هناك تفصيل مهم غالباً ما يمر دون أن يلاحظه أحد: لا يمكن استخدام Docker إذا تم نشر Plesk داخل حاوية Docker.بمعنى آخر، يجب تشغيل Plesk على مضيف "حقيقي" (فعلي أو افتراضي) لإدارة الحاويات، وليس العكس. علاوة على ذلك، في Virtuozzo 7، تأتي الحاويات المبنية على CentOS 7 مزودة بجدار حماية مُفعّل افتراضيًا، مما يُجبر مسؤول Plesk على تكوين قواعد جدار الحماية يدويًا لفتح المنافذ التي يحتاجها Plesk وتلك التي ستستخدمها الحاويات.
في عالم ويندوز، الأمور مختلفة. مع بليسك لنظام ويندوز، يمكنك باستخدام Docker المثبت على جهاز بعيدبدون تثبيت Docker على الخادم الذي يعمل عليه Plesk. وللقيام بذلك، عليك استخدام خدمات Docker عن بُعد، والأهم من ذلك، الحصول على ترخيص إضافي (يتم تضمين Docker عن بعد في حزم مثل Hosting Pack أو Power Pack أو Developer Pack، أو يمكن شراؤه بشكل منفصل.) يتيح لك هذا الحفاظ على نظام Windows "نظيفًا" وتمركز الحاويات على عقدة أخرى.
نقطة أخيرة بخصوص التوافق: لا يمكن ترحيل أو استنساخ حاويات Docker المُدارة من Plesk بشكل مباشرمع ذلك، يمكنك نسخ البيانات التي يستخدمونها احتياطيًا عبر وحدات التخزين أو اللقطات. لذا، فإن الاستراتيجية المعتادة هي: حفظ البيانات بشكل دائم باستخدام وحدات التخزين، وإنشاء صورة قابلة للتكرار، وإذا لزم الأمر، إنشاء لقطات لحالات محددة.
تثبيت ونشر خادم Docker جاهز للعمل عن بُعد
أساس أي عملية نشر عن بعد هو امتلاك خادم مثبت عليه Docker ومُهيأ بشكل صحيحيمكنك اتباع المسار الكلاسيكي (تثبيت Docker CE على Ubuntu، Debian، إلخ) أو استخدام الحلول التي تأتي مع Docker بشكل مسبق.
على منصات مثل Cloudbuilder، على سبيل المثال، إنشاء الخادم مع تثبيت Docker مسبقًا، تصبح العملية بسيطة في لوحة التحكم: ما عليك سوى اختيار واحد صورة الخادم التي تتضمن بالفعل Docker في علامة التبويب "التطبيقات"، حددها في معالج الإعداد، وفي غضون دقائق قليلة، سيكون لديك مضيف جاهز لاستقبال الحاويات. إذا لم يظهر في المرة الأولى، يمكنك ابحث عن كلمة "Docker" في محرك البحث عن الصور ثم اختر التطبيق.
إذا كنت ترغب في سيناريو أكثر تقدماً، خاصة عند العمل مع حاويات خادم ويندوز وكوبرنيتيس (AKS/EKS/GKE)يمكنك إعداد "جهاز بناء" عن بُعد خاص بك باستخدام Docker Engine. في نظام التشغيل Windows Server 2019، على سبيل المثال، يتضمن النظام نفسه ترخيص Docker. Docker Engine Enterpriseيمكنك تثبيته عبر PowerShell باستخدام DockerMsftProvider وميزة الحاويات. يُعد هذا الأسلوب مثاليًا إذا كان جهاز الكمبيوتر المحمول الخاص بك يعاني من نقص في الموارد أو إذا كنت بحاجة إلى عزل العمليات بدلاً من عزل Hyper-Vهذا أمر شائع عندما تريد أن تتطابق صورك مع عقد Windows الخاصة بـ Kubernetes.
سيكون التسلسل العام كالتالي: تبدأ تشغيل خادم Windows Server 2019 بالإصدار المناسب (ويفضل أن يكون في وضع Server Core لتوفير الموارد)، ثم تقوم بتثبيت Docker Engine Enterprise، وبعد ذلك... يمكنك تهيئته لقبول الاتصالات البعيدة الآمنة عبر بروتوكول TLSبحيث يمكنك إنشاء الصور وتشغيل الحاويات من جهازك المحلي أو من خط أنابيب، دون لمس هذا الخادم مباشرة باستثناء التكوين الأولي.
البحث عن الصور واختيارها وإدارتها في Docker (محليًا وعن بُعد)
بمجرد حصولك على مضيف Docker، فإن الخطوة التالية هي إدارة الصور التي ستستخدمها لحاوياتكوهذا يشمل كلاً من المستودع المحلي للمضيف وDocker Hub أو سجلات أخرى.
في واجهات مثل Plesk، يمكنك استخدام مربع البحث للعثور على الصوريبحث النظام في المستودعات المُفعّلة، والتي عادةً ما تكون مستودع محلي (الصور التي تم تنزيلها وتخزينها مسبقًا على الخادم باستخدام Docker) و دوكر هابإذا كانت الصورة مخزنة محليًا بالفعل، فسترى مؤشرات مثل "(محلي)" بجوار الإصدار؛ وإلا فسيتم تنزيلها من السجل البعيد.
من الشائع أن يحتوي تطبيق واحد على إصدارات متعددة تحمل علاماتلتشغيل إصدار معين، ما عليك سوى تحديد التصنيف المناسب عند تشغيل الحاوية. من Plesk، عند اختيار صورة، يمكنك تحديد "نسخة الصورة" يمكنك الوصول إلى أحدث إصدار من خلال قائمة منسدلة، أو ببساطة اختر أحدث إصدار إذا كنت تفضل ذلك. كما يمكنك الوصول إلى الوثائق والوصف على Docker Hub من بطاقة الصورة (باستثناء الصور المحلية، حيث لا ينطبق هذا).
بمرور الوقت، يصبح المستودع المحلي بمثابة مستودع شامل، لذا فهو مهم تنظيف الصور القديمةعلى سبيل المثال، من Plesk يمكنك الانتقال إلى قسم Docker > الصور، والبحث عن صورة معينة، أو النقر على الرابط الموجود أسفل اسم المنتج لعرضها. جميع العلامات المحلية والمساحة التي تشغلها. ومن ثمّ، يمكنك تحديد الملفات التي لم تعد بحاجة إليها وحذفها، مما يحرر مساحة على القرص المضيف.
إنشاء وتكوين الحاويات بشكل مفصل على مضيف بعيد
عند تشغيل حاوية على خادم بعيد، من الأفضل ألا تقتصر على البساطة فقط تشغيل عامل ميناءبل بالأحرى للتحكم بشكل صحيح في تكوينه: الذاكرة، والمنافذ، ووحدات التخزين، ومتغيرات البيئة، وسياسات التمهيد.
في لوحة تحكم مثل Plesk، تتمثل عملية سير العمل النموذجية في تسجيل الدخول دوكر > الحاويات > تشغيل الحاويةابحث عن الصورة، وحدد الإصدار، ثم في الخطوة التالية، اضبط إعداداتها. هنا يمكنك تحديد، على سبيل المثال، متغيرات البيئةالمنافذ التي سيكشفها ووحدات التخزين التي سيقوم بتثبيتها. عند النقر على "تشغيل"، سيتم إنشاء الحاوية وإدراجها في علامة تبويب "الحاويات"؛ ومن هناك يمكنك فتح سجلات وحدة التحكم الخاصة بها للتحقق من أنها تعمل بشكل صحيح.
هناك العديد من الخيارات المتقدمة التي تستحق المتابعة:
- حدود الذاكرةبشكل افتراضي، يمكن لحاويات Docker استخدام جميع ذاكرة الوصول العشوائي (RAM) المتاحة على المضيف. إذا كنت لا ترغب في أن تُحمّل الحاوية الخادم فوق طاقته، فقم بتفعيل خيار حد الذاكرة وحدد قيمة مناسبة بالميغابايت لحملها.
- بدء تلقائيإذا قمت بتعطيل "التشغيل التلقائي بعد إعادة تشغيل النظام"، فلن تبدأ حاوياتك تلقائيًا عند إعادة تشغيل المضيف، ولن تبدأ المواقع التي تعتمد عليها تلقائيًا. ستبقى ساقطة حتى تقوم بالتقاطها يدويًا.في بيئات الإنتاج، عادة ما يكون من المستحسن إبقاء خاصية التشغيل التلقائي مفعلة.
- تخصيص الموانئبشكل افتراضي، يقوم خيار تعيين المنفذ التلقائي بربط المنفذ الداخلي للحاوية بمنفذ عشوائي على المضيف (على سبيل المثال، 32768). إذا كنت ترغب في التحكم في هذا المنفذ، فقم بتعطيل التعيين التلقائي وقم بتكوين "التعيين اليدوي"إذا لم يظهر هذا الخيار، فهذا يعني عادةً أن الصورة لا تعرض المنافذ.
- أمن الموانئعند استخدام التعيين اليدوي، يقوم Docker عادةً بربط هذا المنفذ افتراضيًا فقط بـ 127.0.0.1 (المضيف المحلي)، مما يجعل الخدمة غير متاحة من الإنترنت. هذا مثالي إذا كنت ستضع خادم وكيل عكسي أمامها أو كنت تحتاج فقط إلى الوصول الداخلي. إذا قمت بإلغاء تحديد الخيار الذي يحظر الوصول الخارجي، فسيتم ربط المنفذ بجميع الواجهات وسيتم حظر التطبيق. يمكن الوصول إليه من الخارج باستخدام عنوان IP الخاص بالمضيف بالإضافة إلى المنفذ المحدد.
تتيح لك علامة تبويب إعدادات الحاوية أيضًا تنفيذ إجراءات مثل قم بتغيير اسم الحاوية، قم بتعديل متغيرات البيئة أو تعيينات وحدات التخزين، وراجع السجلات واستهلاك الموارد، وأعد إنشاء الحاوية باستخدام إصدار صورة آخر، واحفظ التكوين الحالي كصورة جديدة، وقم بتنزيل لقطة، أو قم بإزالة الحاوية تمامًا.
إدارة البيانات الدائمة: وحدات التخزين والنسخ الاحتياطية
إحدى النقاط الحاسمة عند نشر Docker عن بُعد هي كيفية استمرار البيانات دون ربطها بدورة حياة الحاوية. وهنا يأتي دور وحدات تخزين Docker، حيث تعمل كمجلدات مضيفة مثبتة داخل الحاوية.
المجلد ليس أكثر من دليل الخادم المضيف المثبت على نظام ملفات الحاويةيضمن هذا بقاء بياناتك (قواعد البيانات، والملفات التي يرفعها المستخدمون، والسجلات المهمة، وما إلى ذلك) حتى في حال إيقاف الحاوية أو حذفها. وبهذه الطريقة، إذا احتجت إلى إعادة إنشاء الحاوية أو تغيير إصدار الصورة، فستبقى بياناتك سليمة.
عند تكوين وحدة تخزين، يجب عليك تحديد، من ناحية، المسار المطلق على المضيف مكان تخزين البيانات (حقل المضيف)، ومن جهة أخرى، المسار المطلق داخل الحاوية المكان الذي يتوقع التطبيق العثور عليها فيه (حقل الحاوية). إذا كنت بحاجة إلى أكثر من وحدة تخزين، فأضف إدخالات جديدة. يُنصح أيضًا بمراجعة وثائق Docker الرسمية لفهم الاختلافات بين وحدات التخزين المُدارة بواسطة Docker ووحدات التخزين المُرتبطة بمسارات النظام.
ضع في اعتبارك أنه على الرغم من أن Plesk أو الأدوات الأخرى قد لا تسمح لك "بترحيل" الحاوية على هذا النحو، يمكن نسخ المجلدات أو إنشاء نسخ احتياطية منها. مثل أي مجلد على الخادم، أو حتى باستخدام لقطات على مستوى نظام الملفات. هذا يحوّل تركيز استراتيجية النسخ الاحتياطي إلى وحدات التخزين بدلاً من الحاوية نفسها، مما يسهل إعادة بنائها بشكل كبير.
تكوين الشبكة والوكيل العكسي للحاويات البعيدة
لكي يكون تطبيق Docker المنشور على خادم بعيد قابلاً للوصول إليه من الخارج، لا يكفي مجرد كشف المنافذ في الحاوية: بل من الضروري أن تنسيق منافذ المضيف، وجدار الحماية، وفي كثير من الحالات، خادم وكيل عكسي مثل Nginx أو Apache.
في البيئات التي تستخدم فيها، على سبيل المثال، Cloudbuilder، إذا كان تطبيقك يستمع على المنفذ 3030 وكان لديك تعيين 3030:3030 في docker-compose، فستحتاج إلى افتح هذا المنفذ في سياسة جدار الحماية الخاصة بالخادميتم ذلك عن طريق إنشاء قاعدة مخصصة وربطها بالخادم. بمجرد فتح التطبيق، يمكنك الوصول إليه من متصفحك باستخدام عنوان URL كالتالي: https://IP_DEL_SERVIDOR:3030.
إذا كنت تعمل مع Plesk و Nginx، فمن الشائع جدًا تهيئتهما قواعد الوكيل العكسي لتوجيه حركة مرور HTTP القياسية (المنفذ 80 أو 443) إلى المنفذ الداخلي الذي يستمع إليه الحاوية. تُطبَّق هذه القواعد في تكوين خادم الويب الخاص بالنطاق، على سبيل المثال في /var/www/vhosts/system/$domain/conf/nginx.confبهذه الطريقة يمكنك عرض موقع ويب موجود في Docker كما لو كان مجرد موقع آخر على الخادم، مع نطاقه وشهادة TLS وما إلى ذلك، بينما يستمع الحاوية على منفذ داخلي غير مكشوف مباشرة للإنترنت.
عادةً ما تعمل هذه التكوينات بشكل جيد حتى لو كان الخادم خلف NATبشرط أن تكون منافذ جدار الحماية وتعيينات الشبكة مُهيأة بشكل متسق. في الحالات المعقدة (حاويات متعددة، مضيفات متعددة، إلخ)، من الشائع استخدام وكيل عكسي عام يعمل كموجه HTTP ويتواصل داخليًا مع خدمات Docker المختلفة عبر منافذها الداخلية أو شبكة Docker مخصصة.
استخدام Docker Compose لتنسيق عمليات النشر على الخوادم البعيدة
عندما تبدأ تطبيقاتك في استخدام أكثر من خدمة واحدة (واجهة أمامية، واجهة خلفية، قاعدة بيانات، ذاكرة تخزين مؤقت، إلخ)، فإن العمل فقط مع تشغيل عامل ميناء يصبح الأمر محرجًا. وهنا يأتي دور Docker Compose، الذي يسمح لك بـ قم بتعريف مجموعة خدمات كاملة في ملف واحد وقم بإعداده على الفور على الخادم البعيد.
مثال بسيط ونموذجي هو تطبيق NodeJS باستخدام Express. أولاً، تقوم بإنشاء مشروعك (على سبيل المثال، في مجلد "app")، ثم تقوم بتهيئته باستخدام npm init، تقوم بتثبيت التعبير مع npm install express وتكتب index.js ابدأ تشغيل الخادم على المنفذ 3030. بمجرد تشغيل التطبيق محليًا باستخدام node indexلقد حان الوقت لاستخدام تقنية دوكر.
للقيام بذلك، عليك إنشاء Dockerfileعلى سبيل المثال في "app/Dockerfile"، حيث تحدد الأساس (على سبيل المثال FROM node:12)، و عملتنسخ الكود، ثم تشغله npm install وأنت تعرض المنفذ 3030. من المستحسن إضافة .dockerignore لتجنب تحميل مجلدات كبيرة مثل node_modules إلى سياق البناء.
ثم تقوم بتحديد ملف عامل ميناء-compose.yml في جذر المشروع، حيث تصف الخدمات. في تطبيق بسيط، قد يكون لديك خدمة مثل "express" تقوم بـ قم بالبناء على ./appيقوم هذا البرنامج بربط المنفذ 3030:3030 وتحديد أمر بدء التشغيل. في المشاريع الأكثر جدية، تُضاف الحاويات أيضًا لـ الواجهة الأمامية، و الخلفية، وقاعدة البيانات (على سبيل المثال MongoDB) وأي مكون آخر، كل منها بتكوينه الخاص من وحدات التخزين والشبكات والمتغيرات.
لنشر هذه الحزمة على خادم بعيد، يكون الإجراء المعتاد كما يلي:
- اتصل بالخادم عبر SSH هذا النظام مثبت عليه برنامج Docker بالفعل.
- قم باستنساخ المستودع الذي يحتوي على المشروع (أو قم بتحميل الملفات عبر SCP، على الرغم من أن git عادة ما يكون أكثر ملاءمة).
- تأكد من أن الملف الثنائي عامل ميناء-يؤلف هو مُثبّتٌ بالفعل، إذ لا يأتي مُثبّتًا مُسبقًا مع Docker في العديد من التوزيعات. على سبيل المثال، في نظام Linux، يمكنك تنزيله من GitHub باستخدام
curlاحفظه في/usr/local/bin/docker-composeقم بتحديده كملف قابل للتنفيذ. يُنصح بمراجعة صفحة "تثبيت Docker Compose" الرسمية لمعرفة الإصدار الموصى به. - من المجلد الذي يحتوي على
docker-compose.yml، تنفيذ عامل ميناء يؤلف (ربما في الوضع)-d(بحيث يعمل في الخلفية). سيستغرق التنفيذ الأول وقتًا أطول، لأنه سيتعين عليه تنزيل الصور وحل التبعيات؛ أما عمليات التنفيذ اللاحقة فستكون أسرع بكثير.
يمكنك أيضًا استخدام لوحات تحكم مثل Plesk نشر حزم Docker Compose دون استخدام SSH مباشرةً. من Docker > Stacks > Add Stack، يمكنك تسمية المشروع واختيار طريقة التحميل: إما لصق محتويات ملف Compose في محرر نصوص، أو تحميله من جهازك، أو اختيار ملف موجود مسبقًا في مساحة الويب الخاصة بالموقع. سيتولى النظام تعريف وإنشاء حاويات مخصصة، وسيتم تخزين ملفاتها في الدليل الرئيسي للموقع.
عمليات نشر عن بُعد مؤتمتة باستخدام GitHub Actions و docker-compose
إذا كنت تعمل باستخدام CI/CD، فمن المنطقي أن ترغب في أتمتة نشر حاوياتك على خادم بعيد في كل مرة تقوم فيها بالدفع إلى فروع معينة (على سبيل المثال، التطوير أو الرئيسي)، يتناسب Docker Compose بشكل جيد للغاية مع هذا النوع من سير العمل.
من الأساليب الشائعة ربط سير عمل GitHub Actions بخادم Ubuntu البعيد عبر SSH. حتى الآن، يتبع الكثيرون أسلوبًا مشابهًا لما يلي: قم بتنزيل الصور من Docker Hub، وأوقف الحاويات قيد التشغيل واحذفها، ثم قم بتشغيل الأمر docker run لكل منها.من خلال الانتقال إلى docker-compose، يمكن تبسيط سير العمل بشكل كبير.
أبسط طريقة هي أنه بمجرد إنشاء اتصال SSH، يجب أن تقوم المهمة بـ انتقل إلى المستودع على الخادم (أو إلى الدليل الذي يحتوي على ملفاتك) docker-compose.yml) وقم بتشغيل أوامر docker-compose التي تحتاجها، على سبيل المثال docker-compose pull لتحديث الصور و docker-compose up -d --remove-orphans لإعادة إنشاء الخدمات وفقًا للتغييرات في ملف Compose.
إنها استراتيجية صحيحة تماماً، وبالنسبة للعديد من المشاريع، أكثر من كافٍ ومتين للغايةيكمن الحل في التأكد من تثبيت ملفات Docker الثنائية وdocker-compose بشكل صحيح على الخادم البعيد، وأن المستخدم المتصل عبر SSH لديه صلاحيات تنفيذ هذه الأوامر (عادةً ما يكون ذلك من خلال عضويته في مجموعة docker أو مجموعة sudoers المُهيأة بشكل صحيح). من منظور GitHub Actions، فإن الباقي يقتصر على استخدام إجراء SSH موثوق وإدارة بياناتك السرية (عنوان IP للخادم، اسم المستخدم، المفتاح الخاص، إلخ) باستخدام بيانات المستودع السرية.
تشغيل Docker عن بُعد من نظام Windows بدون Hyper-V: WSL2، ومحرك Docker عن بُعد، وPortainer
إذا كنت تستخدم نظام التشغيل ويندوز ولا يمكنك أو لا ترغب في تمكين Hyper-V (على سبيل المثال، لأنه يتعارض مع أدوات المحاكاة الافتراضية الأخرى)، فلديك عدة طرق لـ استخدم الحاويات المستضافة على خادم آخر كما لو كانت محلية، على غرار ما تقدمه LXD.
أحد الخيارات هو الاعتماد على Docker Desktop مع واجهة خلفية WSL2إذا كنت تستطيع استخدام WSL2 (نظام ويندوز الفرعي لنظام لينكس الإصدار الثاني) ولكن ليس لديك Hyper-V التقليدي، فإن Docker Desktop يتيح لك إعداد بيئة تطوير قائمة على نظام لينكس حيث تعمل الحاويات على توزيعة WSL2 (أوبونتو، على سبيل المثال)، وتتحكم أنت من خلال نظام ويندوز. ويكون سير العمل النموذجي كالتالي:
- قم بتثبيت WSL2 وتوزيعة لينكس (Ubuntu 22.04، 24.04، إلخ).
- قم بتثبيت Docker Desktop، وفي الإعدادات، قم بتمكين محرك يعتمد على WSL2 في القسم العام.
- في قسم "تكامل WSL"، اختر توزيعات WSL2 التي تريد دمج Docker معها.
- من التوزيعة، تحقق
docker --versionوجرّب معdocker run hello-world.
ومن هناك يمكنك العمل مع قانون VS استخدام WSL و Dev Containers و Docker extensions للتطوير مباشرة في الحاويات البعيدة (المستضافة فعليًا على WSL2)، وفتح المجلدات في الحاوية، وتصحيح الأخطاء، وما إلى ذلك. إنه أمر مريح للغاية للتطوير، على الرغم من أنه ليس تمامًا مثل الإشارة إلى خادم بعيد خارجي.
إذا كنت تريد استخدام محرك Docker عن بعد حقيقييمكنك استضافة النظام على خادم آخر (لينكس أو ويندوز سيرفر)، وتهيئته لقبول اتصالات TLS عبر TCP (عادةً على المنفذ 2376). وللقيام بذلك، عليك إنشاء شهادات X.509 (شهادة المرجع المصدق، وشهادة الخادم، وشهادة العميل)، ثم تهيئة... ملف daemon.json الخاص بالخادم لتفعيل بروتوكول TLS، حدد مسارات الشهادات وافتح مضيف TCP الذي سيستمع إليه البرنامج الخفي. ثم، على جهاز العميل، قم بتثبيت الشهادات في ~/.docker (أو في ملف تعريف مستخدم ويندوز) وتكوين متغيرات البيئة مثل DOCKER_HOST y DOCKER_TLS_VERIFY أو، في الإصدارات الأحدث، يمكنك إنشاء سياق Docker يشير إلى ذلك المضيف البعيد. بمجرد تفعيل هذا السياق، يمكن تنفيذ أي أمر docker التي تقوم بتشغيلها على جهازك المحلي يتم تشغيله فعلياً على الخادم البعيد..
أداة أخرى مفيدة للغاية في هذا السيناريو هي حماليوفر Portainer واجهة ويب لإدارة حاويات Docker على خادم واحد أو أكثر. لتثبيته، عليك أولاً إنشاء وحدة تخزين بيانات لـ Portainer، ثم تشغيل حاويته، وتعيين المنفذين 8000 و9000، وربطها بـ /var/run/docker.sock يُمكّنك هذا من التواصل مع خادم Docker الخاص بالمضيف. ومن هناك، يمكنك الوصول إليه عبر المنفذ 9000 (تذكر فتحه في جدار الحماية الخاص بك)، وإنشاء مستخدم مسؤول، وتكوين الاتصالات المحلية والبعيدة. يستطيع Portainer التواصل مع عُقد Docker الأخرى باستخدام واجهة برمجة تطبيقات Docker أو وكيل Portainer، مما يسمح لك بـ إدارة عدة مضيفات Docker من وحدة تحكم ويب واحدة.
تكوين متقدم لمحرك Docker البعيد باستخدام TLS والسياقات
عندما تريد أن يستخدم جهاز التطوير الخاص بك خادمًا بعيدًا كمحرك Docker رئيسي، يُنصح قم بحماية هذا الاتصال باستخدام بروتوكول TLS وعدم ترك البرنامج يعمل بشكل عشوائي عبر بروتوكول TCP. يتضمن ذلك العمل مع شهادات X.509 وضبطها بدقة على كل من الخادم والعميل.
على سبيل المثال، في خادم يعمل بنظام Windows Server مع محرك Docker، يمكنك أتمتة عملية إنشاء الشهادات باستخدام برنامج PowerShell النصي الذي يقوم بتثبيت openssl، وإنشاء مرجع مصدق، وإصدار شهادة خادم باستخدام اسم الموضوع البديل الذي يتضمن نظام أسماء النطاقات وعناوين IP اللازمة (العامة، والداخلية، والمحلية)، كما يقوم بإنشاء شهادات العميل للمصادقة المتبادلة. الملفات الناتجة (عادةً ca.pem, server-cert.pem, server-key.pem, cert.pem y key.pemيتم وضعها في مجلد يسهل الوصول إليه، على سبيل المثال C:\ProgramData\docker\config\.
في الملف daemon.json يمكنك من خلال الخادم تكوين مفاتيح مثل "tls": صحيح، "tlsverify": صحيح، "tlscacert"، "tlscert"، "tlskey" وقائمة المضيفين، بما في ذلك tcp://0.0.0.0:2376 بالإضافة إلى قناة الاتصال المسماة الأصلية في نظام ويندوز. أعد تشغيل خدمة Docker وتأكد من أن كل شيء يعمل بشكل صحيح. تذكر أن المنفذ المشفر القياسي هو 2376، بينما المنفذ 2375 مخصص للاتصالات غير المشفرة (وهو أمر غير مستحسن بشدة للوصول إلى الإنترنت).
وأخيرًا، على جهاز العميل، انسخ الشهادات إلى دليل Docker الخاص بك (~/.docker أو ما شابه) وقم بتكوين إما متغيرات البيئة (DOCKER_HOST، DOCKER_TLS_VERIFY) أو سياق مع docker context createحيث تحدد المضيف، وهيئة التصديق، والشهادة، والمفتاح. بمجرد تفعيل السياق البعيد، عند تشغيل docker version ستلاحظ أن العميل والخادم لهما إصدارات وبنى مختلفة (على سبيل المثال، عميل Linux/amd64 وخادم Windows/amd64 مع Docker Engine Enterprise)، ولكن يتم تطبيق أوامرك على المضيف البعيد كما لو كانت محلية..
إذا كنت قد استخدمت سابقًا إصدارات Docker التجريبية لنظام WSL، فقد يكون لديك سياقات قديمة مثل "wsl" لم تعد مستخدمة. يمكنك التحقق من ذلك باستخدام docker context ls وإذا لزم الأمر، قم بإزالة السياقات القديمة باستخدام docker context rm لتجنب أخطاء الاتصال مع الأنابيب القديمة.
بشكل عام، تتيح لك هذه المجموعة الكاملة من المكونات (Plesk، ومحرك Docker عن بُعد، وDocker Desktop مع WSL2، وdocker-compose، وPortainer، وGitHub Actions) إعداد سير العمل الذي تقوم ببناء ونشر الحاويات على الخوادم البعيدة بطريقة آمنة وقابلة للتكرار ومريحة نسبياً.فصل موارد التطوير، وعقد التنفيذ، ولوحات الإدارة، والمنسقين وفقًا لما يناسب احتياجاتك في كل حالة. شارك الدليل وسيتعرف المزيد من المستخدمين على حاوية Docker.