كيفية نشر حاويات Docker على الخوادم البعيدة

العمل مع حاويات Docker على الخوادم البعيدة لقد أصبح هذا الأمر أساسيًا لأي شخص يرغب في نشر تطبيقات حديثة دون الوقوع في فخ التبعيات وإصدارات المكتبات والعبارة الكلاسيكية "إنه يعمل على جهازي". ومع ذلك، عندما ننتقل من تشغيل أمر بسيط docker run عند الانتقال من إعداد عملية نشر جادة محليًا على خادم Linux، باستخدام Docker Compose أو مشاركات GitHub أو Plesk أو Portainer أو حتى التطبيقات الرسومية التي يمكن الوصول إليها عبر المتصفح، تصبح الأمور أكثر تعقيدًا بعض الشيء.

إذا كان هدفك هو نشر حاويات Docker على خادم بعيد (أوبونتو، ديبيان، ويندوز مع WSL 2، خادم سحابي، بليسك، إلخ.) والقيام بذلك بطريقة قابلة للصيانة وآلية وآمنة، في هذا الدليل لديك رحلة كاملة إلى حد ما: من الاستخدام الأساسي لـ Docker Compose عن بعد، إلى بيئات التطوير باستخدام VS Code، وعمليات النشر من بليسك، والإدارة باستخدام Portainer والتنفيذ عن بعد للتطبيقات الرسومية باستخدام noVNC و Caddy.

المفاهيم الأساسية: حاويات دوكر والنشر عن بُعد

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

لنشر حاويات Docker على الخوادم البعيدة عادةً، تحتاج إلى خادم مضيف (مثل خادم أوبونتو على السحابة) مزود بـ Docker، ويمكنك اختيارياً استخدام Docker Compose، ثم ترسل إليه الشفرة أو الصور لتشغيلها. يمكنك القيام بذلك يدويًا عبر SSH، أو أتمتته باستخدام GitHub Actions، أو دمجه مع لوحات تحكم مثل Plesk أو أدوات مثل Portainer.

السيناريوهات الرئيسية التي ستواجهها في العالم الحقيقي عند الحديث عن "Docker عن بُعد"، هناك ثلاثة جوانب: التطوير المحلي مع تشغيل الحاويات على جهاز آخر (أو في WSL 2)، والنشر الآلي لخدمات الواجهة الخلفية/الواجهة الأمامية، وإدارة حاويات الإنتاج (المراقبة، والتسجيل، وإعادة التشغيل، وسياسات الشبكة، إلخ). التقنية نفسها، لكن ما يتغير هو طريقة إدارتها.

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

من docker run إلى Docker Compose على خادم بعيد

نمط شائع إلى حد ما للنشر اليدوي يتضمن ذلك وجود مستودع كود على GitHub، وخادم Ubuntu بعيد مثبت عليه Docker، وسير عمل CI/CD (على سبيل المثال، GitHub Actions) يقوم بما يلي عند الدفع إلى فرع مثل development o main:

• الاتصال بالخادم البعيد عبر SSH.
• أوقف الحاويات قيد التشغيل وأزلها.
• قم بتنزيل الصور الجديدة من Docker Hub (أو من سجل الصور الخاص بك).
• جولة docker run لكل خدمة.
• دع Nginx (أو الخادم الوكيل العكسي الذي تستخدمه) يقوم بإعادة توجيه حركة المرور إلى منافذ كل حاوية.

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

أبسط الممارسات (والأكثر شيوعًا) مع GitHub Actions ينبغي أن يقوم سير العمل بـ cd إلى دليل المشروع على الخادم البعيد (حيث docker-compose.yml) وتنفيذ أوامر مثل:

• docker compose pull لعرض أحدث الصور.
• docker compose down لإيقاف وإزالة الحاويات القديمة (اختياريًا مع --remove-orphans).
• docker compose up -d --build إذا قمت بإنشاء الصور من الخادم نفسه.

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

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

بيئة تطوير عن بُعد باستخدام Docker و WSL 2 و VS Code

في نظام التشغيل ويندوز، من الشائع جدًا التطوير باستخدام Docker باستخدام WSL 2.يوفر Docker Desktop لنظام التشغيل Windows محركًا قائمًا على WSL 2 يسمح لك بتشغيل حاويات Linux و Windows من نفس الجهاز، مع تحرير التعليمات البرمجية باستخدام VS Code والاختبار في المتصفح المحلي.

سير العمل النموذجي لإعداد بيئة تطوير باستخدام حاويات بعيدة عبر WSL 2 ما يلي:

1. قم بتثبيت WSL 2 وتوزيعة لينكس (أوبونتو، على سبيل المثال).
2. تقوم بتثبيت Docker Desktop على نظام التشغيل Windows وتمكين خيار "استخدام محرك WSL 2" في الإعدادات > عام.
3. في الإعدادات > الموارد > تكامل WSL، يمكنك تحديد توزيعات WSL التي تريد أن يعمل عليها Docker.
4. يمكنك التحقق من التثبيت باستخدام docker --version والجري docker run hello-world ضمن توزيعة WSL.

للتطوير "داخل" الحاويات ولا يقتصر الأمر على استخدام Docker كمحرك فحسب؛ فـ VS Code عنصر أساسي. باستخدام WSL وDev Containers وإضافات Docker، يمكنك القيام بأمور مثل:

• افتح مجلد مشروعك الموجود داخل WSL مباشرةً في VS Code.
• أعد فتح هذا المجلد "في حاوية تطوير" (حاوية التطوير)، باستخدام Dockerfile وعلى devcontainer.json التي تصف بيئتك المثالية (إصدار بايثون، نود، إلخ).
• قم بتصحيح أخطاء تطبيقك من خلال VS Code أثناء تشغيله في الحاوية.

مثال شائع جداً يعمل هذا مع مشروع Django أو Node.js: تقوم باستنساخ المستودع داخل WSL، ثم تفتح المجلد باستخدام code .تختار تعريف حاوية تطوير (على سبيل المثال، "Python 3")، فيقوم VS Code بإنشاء الصورة وتشغيل الحاوية مع جميع التبعيات. ومن ثم، يمكنك تشغيل الكود وتصحيحه والتحقق من أنه يعمل على نظام Linux حتى لو كان نظام التشغيل لديك هو Windows.

يُعد هذا الأسلوب مفيدًا أيضًا عندما لا يكون جهازك قويًا جدًالأنه يمكنك نقل جزء من الحمل إلى خادم بعيد باستخدام Docker والاتصال به باستخدام VS Code عبر SSH وحاويات التطوير، مما يجعله يعمل كما لو كان محليًا ولكنه يعتمد على موارد الخادم.

نشر التطبيقات على خادم سحابي باستخدام Docker و Docker Compose

قم بإعداد خادم سحابي مزود بـ Docker جاهز للنشر إنها سريعة للغاية مع معظم مزودي الخدمة: يمكنك اختيار صورة نظام مثبت عليها Docker مسبقًا، والانتظار لبضع دقائق، وسيكون جهازك جاهزًا لاستقبال الحاويات.

نمط نموذجي لنشر تطبيق Node.js بسيط سيكون الأمر كالتالي:

1. أنشئ مشروع Node.js (على سبيل المثال، مشروع "Hello world" باستخدام Express) على جهازك المحلي: مجلد المشروع، المجلد الفرعي app, npm initتثبيت التبعيات (مثل express) و أ index.js يقوم ذلك بإعداد خادم على المنفذ 3030 برسالة أساسية.
2. قم بتطبيق Docker على التطبيق باستخدام Dockerfile ذلك يحدد الصورة الأساسية (على سبيل المثال node:12)، و WORKDIRانسخ ملفات التطبيق، ثم قم بتشغيله. npm install وكشف المنفذ الداخلي.
3. أضف .dockerignore تجنب وضع أشياء مثل node_modules.
4. إنشاء عامل ميناء-compose.yml في جذر المشروع، مع تحديد الإصدار (على سبيل المثال، 3.8) وتحديد الخدمة الرئيسية، build، تعيين المنافذ (3030:3030) والأمر (node index).

بمجرد أن يصبح المشروع والتأليف جاهزينعادةً ما يتبع النشر على الخادم البعيد هذا المسار:

• تتصل بالخادم عبر SSH.
• يمكنك استنساخ المستودع أو تحميل الملفات (Git، SCP، rsync...).
• أنت تقوم بالتثبيت عامل ميناء-يؤلف إذا لم يكن موجودًا بالفعل (في العديد من التوزيعات، يجب عليك تثبيته بشكل منفصل عن Docker، على سبيل المثال عن طريق تنزيل الملف الثنائي من GitHub ومنحه أذونات التنفيذ).
• أنت تنفذ docker-compose up (o docker compose up (حسب الإصدار) بحيث يتم تنزيل الصور، وإنشاء صورة التطبيق، وبدء تشغيل الحاويات.

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

بمجرد أن يصبح التطبيق جاهزًا للتشغيل، يمكنك الوصول إليه. باستخدام عنوان IP العام للخادم والمنفذ المكشوف (على سبيل المثال، https://IP_DEL_SERVIDOR:3030), أو عن طريق إخفاء هذا المنفذ خلف وكيل عكسي مثل Nginx/Traefik الذي يستمع على المنفذ 80/443.

إدارة الحاويات البعيدة باستخدام Plesk و Docker

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

يدعم Plesk برنامج Docker على مجموعة متنوعة من أنظمة التشغيلCentOS 7، RHEL 7، Debian 10/11/12، إصدارات مختلفة من Ubuntu (18.04، 20.04، 22.04، 24.04)، AlmaLinux 8/9، Rocky Linux 8.x، و Virtuozzo 7 المحدث. في Plesk لنظام التشغيل Windows، لا يتم تشغيل Docker محليًا ولكن على جهاز بعيد يعمل كمضيف Docker.

هناك بعض القيود المهمة التي يجب مراعاتها:

• لا يمكنك استخدام ملحق Docker إذا تم نشر Plesk داخل حاوية Docker.
• لاستخدام خدمات Docker عن بعد (أي المضيفين الخارجيين)، فأنت بحاجة إلى ترخيص إضافي أو حزم محددة (حزمة الاستضافة، حزمة الطاقة، حزمة المطورين).
• لا يمكن "ترحيل" حاويات Docker التي يديرها Plesk على هذا النحو، على الرغم من أنه يمكنك نسخ البيانات التي تستخدمها احتياطيًا باستخدام وحدات التخزين أو اللقطات.

يمكنك البحث عن الصور من خلال واجهة Plesk سواء في المستودع المحلي (الصور التي تم تنزيلها مسبقًا على المضيف) أو في Docker Hub. لتشغيل حاوية، سترشدك اللوحة إلى ما يلي:

1. زيارة دوكر > الحاويات > تشغيل الحاوية.
2. ابحث عن الصورة المطلوبة واطلع على وثائقها على Docker Hub (إن وجدت).
3. يمكنك اختيارياً تحديد تصنيف/إصدار صورة معين.
4. قم بتكوين معلمات الحاوية (متغيرات البيئة، والمنافذ، ووحدات التخزين، والذاكرة، والتشغيل التلقائي، وما إلى ذلك) وانقر فوق تشغيل.

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

فيما يتعلق بجانب التنسيق عن بعديمكن لـ Plesk العمل مع "خدمات Docker البعيدة". يتضمن ذلك تكوين برنامج Docker daemon على المضيف البعيد (على سبيل المثال، باستخدام /etc/docker/daemon.json مع دعم بروتوكولات TLS و TCP، وإنشاء الشهادات .pem وقم بتسجيل هذا المضيف في Plesk من Docker > البيئات > إضافة خادمبعد ذلك يمكنك وضع علامة على عقدة Docker هذه على أنها نشطة والتبديل بين الخوادم المختلفة من نفس الواجهة.

نشر حزم Docker Compose من Plesk

إذا كنت تستخدم بالفعل Docker Compose لبنيتك التحتيةقد تكون مهتمًا بأن يتولى Plesk عملية نشر "المجموعات" من الملفات. docker-compose.yml.

سير العمل لنشر Compose في Plesk الأمر بسيط نسبياً:

1. أدخل Docker > Stacks > Add Stack.
2. قم بتعيين اسم مشروع للمجموعة.
3. اختر مصدر ملف الإنشاء: المحرر (لصق المحتوى)، أو قم بتحميل ملف من جهاز الكمبيوتر الخاص بك، أو حدد ملفًا موجودًا في مساحة الويب الخاصة بالمجال.
4. قم بتأكيد الإعدادات واسمح لـ Plesk بتعريف وإنشاء الحاويات المحددة.

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

كما يسهل برنامج Plesk إدارة الصور المحلية: من Docker > الصور يمكنك تصفية الصور، ومراجعة علامات المنتجات المختلفة، والاطلاع على المساحة المستخدمة، وحذف الصور القديمة لتحرير مساحة على القرص. وهذا أمر بالغ الأهمية في البيئات البعيدة ذات المساحة المحدودة.

إذا كنت تستخدم Nginx كخادم ويب أمامييطبق Plesk قواعد البروكسي (على سبيل المثال، في nginx.conf (من النطاق) لتوجيه حركة المرور إلى حاويات Docker الخاصة بك، حتى في الحالات التي تكون فيها الشبكة خلف جدار الحماية NAT. هذا يوفر عليك عناء التعامل اليدوي مع إعدادات الوكيل العكسي على الخوادم البعيدة.

إدارة الحاويات البعيدة باستخدام بورتينر

بورتينر عبارة عن واجهة ويب خفيفة الوزن بالنسبة لـ Docker، فهو يُسهّل العمل اليومي بشكل كبير لأولئك الذين لا يرغبون في استخدام سطر الأوامر. فهو يعمل كحاوية بحد ذاته، ويمكنه إدارة المضيف المحلي أو عدة مضيفات بعيدة (حتى مع Portainer Agent).

لتثبيت Portainer على خادمك باستخدام Docker عادةً ما تتبع هذه الخطوات الأساسية:

• أنشئ وحدة تخزين لبيانات بورتاينر: docker volume create portainer_data.
• قم بتشغيل حاوية Portainer عن طريق ربط المنفذين 8000 و9000، وتركيب مقبس Docker (/var/run/docker.sock) وحجم البيانات: docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer.

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

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

تشغيل التطبيقات الرسومية في حاويات بعيدة والوصول إليها عبر متصفح الإنترنت

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

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

تتضمن البنية الأساسية لهذا النوع من الحاويات الرسومية عادةً:

• خادم VNC/X11 خفيف الوزن (TigerVNC) يعمل كخادم عرض.
• مدير نوافذ بسيط (OpenBox) للتعامل مع النوافذ.
• نوع خادم صغير وسهل الاستخدام easy-novnc والذي يعرض VNC كـ WebSocket ويقوم بإنشاء صفحة HTML للاتصال من المتصفح.
• supervisord أو ما شابه ذلك لبدء ومراقبة جميع العمليات داخل الحاوية.
• التطبيق نفسه (Thunderbird، GIMP، إلخ) مُهيأ للعرض على الشاشة البعيدة (DISPLAY=:0).

عملياً، يتم إنشاء دليل عمل. (على سبيل المثال ، ~/thunderbird) حيث يتم وضعها:

• Un المشرف.conf والذي يحدد البرامج التي سيتم تشغيلها: TigerVNC و easy-novnc و OpenBox والتطبيق الرئيسي، مع تحديد الأولويات بحيث يبدأ خادم الرسوميات قبل التطبيق.
• Un menu.xml يقوم OpenBox بتكوين قائمة سطح المكتب (التطبيق الرئيسي، الطرفية، مراقب العمليات باستخدام htop، إلخ).
• Un ملف Dockerfile متعدد المراحل والتي تقوم في المرحلة الأولى بالتجميع easy-novnc باستخدام لغة Go، وفي الخطوة الثانية يتم إنشاء الصورة النهائية على نظام Debian، وتثبيت Openbox وTigerVNC وSupervisor وأدوات سطر الأوامر والتطبيق (Thunderbird في هذا المثال)، ونسخ الملفات الثنائية والإعدادات، وإنشاء مستخدم غير جذري، وتحديد وحدة تخزين بيانات دائمة في /data.

عادةً ما يتم تفويض الأمر الافتراضي للحاوية إلى supervisord، وتشغيله كمستخدم عادي باستخدام gosuبعد ضبط الأذونات على وحدة تخزين البيانات، عند بدء تشغيل الحاوية، يتم تشغيل VNC و noVNC ومدير النوافذ والتطبيق تلقائيًا، وكل ما عليك فعله هو الوصول إلى منفذ HTTP الذي يعرضه easy-novnc.

لجعله أكثر قوة وسهولة في الاستخدام على الإنترنتمن الجيد وضع خادم ويب مثل Caddy في المقدمة، وأيضًا في حاوية، والذي يعمل كوكيل عكسي لتطبيقك الرسومي، ويضيف مصادقة أساسية (اسم المستخدم وكلمة المرور المجزأة)، ويعرض اختياريًا WebDAV للوصول إلى الملفات. /data من جهازك المحلي.

قم بتنسيق الحل باستخدام الشبكات، ووحدات التخزين، وCaddy

للحفاظ على تنظيم هذا النوع من عمليات النشر النهج المعتاد هو إنشاء شبكة Docker خاصة بك ووحدة تخزين بيانات واحدة أو أكثر:

• الشبكة، على سبيل المثال thunderbird-net، والتي ستتم مشاركتها بين جميع الحاويات ذات الصلة.
• حجم thunderbird-data والذي سيحتوي على ملف تعريف المستخدم والبيانات الدائمة للتطبيق الرسومي.

حاوية التطبيق الرسومي يمكنك تشغيله باستخدام أمر مثل:

• سياسة --restart=always حتى يتمكن من الوقوف بمفرده.
• تجميع الحجم thunderbird-data:/data.
• إتصال شبكة thunderbird-net.
• اسم قابل للتحديد (thunderbird-app(على سبيل المثال) التي سيستخدمها Caddy للوكيل العكسي.

في دليل آخر (على سبيل المثال، ~/caddy) يتم بناء صورة كادي مع الوحدات النمطية اللازمة (مثل إضافة WebDAV) و Caddyfile والذي يُعرّف:

• خادم على المنفذ 8080.
• Un reverse_proxy إلى thunderbird-app:8080 (أو المنفذ الذي يعرضه برنامج noVNC).
• مسارات إضافية للتنقل بين الملفات (/files) ولـ WebDAV (/webdav)، وكلاهما يخدم محتوى وحدة تخزين البيانات.
• كتلة من basicauth والذي يحمي جميع المسارات باستخدام اسم مستخدم وكلمة مرور مشفرة يتم قراءتها من متغيرات البيئة.

عند إنشاء حاوية Caddyيتم تجميع نفس المجلد thunderbird-data:/dataفهو يتصل بالشبكة thunderbird-net ويتم نشر منفذها (على سبيل المثال، -p 8080:8080) على المضيف. مع هذا، ما عليك سوى الانتقال إلى متصفحك إلى http://IP_DEL_SERVIDOR:8080أدخل بيانات اعتمادك وانقر على "اتصال" لبدء استخدام التطبيق الرسومي عن بُعد.

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

مع كل هذه المكونات (Docker Compose، Plesk، Portainer، VS Code، WSL 2، Caddy، noVNC...) من الممكن إعداد كل شيء بدءًا من عمليات النشر البسيطة للواجهة الخلفية وحتى أجهزة سطح المكتب البعيدة المغلفة في حاويات والتي يمكن الوصول إليها بشكل مثالي عبر المتصفح، والاستفادة من الخوادم ذات القدرة الأكبر بكثير من جهازك مع الحفاظ على تحكم دقيق للغاية في الشبكات والأمان والتخزين والتحديثات.