Docker على خادم VPS: دليل عملي لنشر التطبيقات

غيّر Docker طريقة تثبيت التطبيقات على الخوادم. لم تبقَ حاجة إلى حزم نظام تتنازع فيما بينها، ولا إلى إصدارات PHP متعارضة، ولا إلى عبارة «يعمل على جهازي». على خادم VPS يعتمد NVMe، تعزل الحاوية (container) التطبيق ومكتباته، وتُستبدل بأمر واحد، وتُوصف في ملف يمكن حفظه بإصدارات. لكن الأمر يقتضي تثبيتًا نظيفًا، ومعرفة أين تسكن البيانات فعلًا، وإدراك اللحظة التي يتوقف فيها العرض الصغير عن الكفاية.

ما الذي يغيّره Docker فعليًا على خادم VPS

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

ثلاث حالات تبرّر الجهد:

• تراكم الاعتماديات. تطبيق Node وقاعدة PostgreSQL ووكيل عكسي (reverse proxy): لكل منها احتياجاتها وإيقاع تحديثها. عزل كل خدمة يمنع ترقية واحدة من إسقاط الخدمتين الأخريين.
• الحاجة إلى بيئات متطابقة. الصورة نفسها تعمل على حاسوبك وعلى الخادم، بالمكتبات والإصدارات نفسها.
• الاستعداد للمرحلة التالية. عند وصول خادم ثانٍ، يُعاد تشغيل التعريف نفسه دون تثبيت يدوي.

في المقابل، موقع تعريفي ثابت أو تطبيق PHP واحد يُدار ببساطة أكبر عبر nginx وPHP-FPM مثبّتين على النظام مباشرة. يضيف Docker خادمًا خفيًا (daemon) وطبقة شبكة وغيغابايتات من الصور؛ وهذا مبرَّر عندما تكون لديك عدة خدمات يجب فصلها، لا لمجرد الظهور بمظهر تقني.

تثبيت Docker دون إفساد النظام

المستودع الرسمي بدل حزمة التوزيعة

الحزمة التي توفرها Ubuntu أو Debian غالبًا أقدم من Compose v2. السكربت الرسمي curl -fsSL https://get.docker.com | sh يثبّت مستودع Docker والمحرك وإضافة Compose في خطوة واحدة. نزّل السكربت واقرأه قبل تنفيذه: التثبيت يحدث مرة واحدة، فمن المفيد معرفة ما يمسّه على الجهاز.

ثلاثة تحققات قبل المتابعة

تأكد بعد ذلك من أن الخدمة تعمل وأن Compose هو الإضافة وليس الملف التنفيذي القديم المكتوب بـ Python:

• systemctl is-active docker يجب أن يجيب active.
• docker compose version يجب أن يعرض إصدارًا من سلسلة 2.x.
• docker run --rm hello-world يجب أن ينتهي دون خطأ.

تفصيل مهم: إضافة مستخدم إلى مجموعة docker تعني منحه صلاحيات الجذر (root)، لأنه يستطيع تثبيت أي مجلد من المضيف داخل حاوية. على خادم يديره شخص واحد، استخدم sudo docker واترك المجموعة جانبًا.

أول حزمة خدمات: التطبيق وقاعدة البيانات والوكيل العكسي وTLS

ثلاث خدمات وشبكة داخلية واحدة

الحزمة الدنيا ثلاثة خدمات في ملف compose.yaml: وكيل عكسي ينهي اتصال TLS، والتطبيق، وقاعدة البيانات على وحدة تخزين مسماة (volume). لا يُنشر للخارج سوى المنفذين 80 و443؛ قاعدة البيانات لا تكشف شيئًا، وتتواصل الحاويات بأسماء خدماتها على شبكة مخصصة. أوامر العمل اليومي تبقى هي نفسها:

• docker compose up -d يشغّل الحزمة في الخلفية.
• docker compose ps يعرض الحالة الفعلية للخدمات ومنافذها.
• docker compose logs -f app يتابع سجلات الخدمة التي تهمك وحدها.

تجنّب نشر قاعدة البيانات على 0.0.0.0 بحجة «الاتصال من الحاسوب الشخصي». إن احتجت وصولًا عن بعد فاستخدم نفق SSH (tunnel): إعداده أسرع من شرح حادث أمني لاحقًا.

الشهادة: الدومين أولًا ثم TLS

تتحقق Let's Encrypt من أن الدومين يشير فعلًا إلى جهازك. أنشئ سجل A نحو عنوان IPv4 المخصص المشمول في كل عرض، وانتظر انتشار التحديث، ثم اطلب الشهادة. طريقتان شائعتان: certbot في وضع webroot مع وحدة تخزين مشتركة بين حاوية الوكيل ومهمة التجديد، أو وكيل يتولى ACME بنفسه مثل Caddy. في الحالتين، تأكد من أن التجديد مجدول ومُختبَر: شهادة تنتهي بعد تسعين يومًا من أكثر الأعطال التي يمكن تجنّبها.

وحدات التخزين والنسخ الاحتياطي: ما يبقى بعد حذف الحاوية

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

لكن وحدة التخزين ليست نسخة احتياطية. تشمل العروض نسخًا احتياطيًا تلقائيًا يغطي تعطل الخادم والخطأ على مستوى الجهاز، لكنه لا يعوّض تصديرًا متسقًا على مستوى التطبيق: نسخة خام من مجلد البيانات مأخوذة أثناء الكتابة قد تكون غير قابلة للاستخدام. بالنسبة إلى PostgreSQL، الأمر docker compose exec db pg_dump -U app app مع توجيه المخرجات إلى ملف على المضيف يمنحك نسخة قابلة للقراءة والضغط.

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

حدود الموارد: الحاوية التي تخنق الخادم

افتراضيًا تأخذ الحاوية كل الذاكرة المتاحة. على عرض بذاكرة 1 غيغابايت، يكفي تسرّب ذاكرة واحد لتفعيل قاتل العمليات في النواة، وهو لا يختار دائمًا الضحية التي كنت ستختارها.

• حدّد سقوفًا. mem_limit وcpus في ملف compose، أو كتلة deploy.resources.limits في Compose v2. سقف الذاكرة يجعل العطل محليًا ومتوقعًا.
• راقب الاستهلاك الحقيقي. docker stats يعرض المعالج والذاكرة والإدخال/الإخراج لكل حاوية مباشرة.
• أدر السجلات. مشغّل json-file ينمو بلا حد افتراضيًا؛ سياسة max-size وmax-file تمنع تطبيقًا ثرثارًا من ملء قرص NVMe في ثلاثة أسابيع.
• أبلغ التطبيق بالسقف. على JVM أو عملية Node أن تعرف الحد، وإلا حسبت حجم الكومة (heap) على ذاكرة المضيف فتُقتل قبل أن تتباطأ أصلًا.

راقب مساحة القرص أيضًا: الصور القديمة تتراكم مع كل نشر. docker image prune ينظّف الصور اليتيمة، لكن لا تشغّل docker system prune --volumes قبل قراءة قائمة ما سيختفي.

الأمان: خمس عادات تصنع الفرق

• لا تمنح الحاوية وصولًا إلى /var/run/docker.sock. من يتحكم في الخادم الخفي يتحكم في الجهاز كله، بما في ذلك أقراصه.
• شغّل التطبيق بصلاحيات محدودة عبر التوجيه user، واجعل نظام الملفات للقراءة فقط حيث يمكن.
• ثبّت إصدارات الصور بدل الاعتماد على latest: أنت من يقرر وقت التحديث، لا المستودع.
• انتبه للجدار الناري. يكتب Docker قواعد iptables خاصة به، فالمنفذ المنشور يتجاوز UFW. استخدم سلسلة DOCKER-USER لتصفية ما يدخل فعلًا.
• أعد البناء بانتظام. صورة لم تُحدَّث ستة أشهر تحمل ستة أشهر من الترقيعات الغائبة، بما فيها مكتبة لم تنظر إليها يومًا.

المراقبة على مدار الساعة واتفاقية مستوى الخدمة (SLA) بنسبة 99,9% تخصّان البنية التحتية: الجهاز والشبكة والطبقة الافتراضية. أما ما يجري داخل حاوياتك فيبقى مسؤوليتك، وهذا منطقي — لا يمكن لأي مزوّد جدي أن يضمن كود غيره.

أي عرض VPS يناسب حزمة Docker؟

يستهلك خادم Docker وطبقة التخزين overlay2 والصور ذاكرة وقرصًا قبل وصول أول طلب. هذا موقع العروض الخمسة، بأسعار معلنة بالدولار شهريًا وبالدرهم قبل الضريبة:

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

الأسئلة الشائعة (FAQ)

هل Docker إلزامي لاستضافة تطبيق على خادم VPS؟

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

هل يعمل Docker على خادم VPS بذاكرة 1 غيغا؟

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

هل تغطي النسخ الاحتياطي التلقائي وحدات تخزين Docker؟

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

هل أحتاج Kubernetes لبضع حاويات؟

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

الخطوة التالية

ابدأ بحزمة صغيرة جدًا، وضعها في الإنتاج، ثم أضف الخدمات كلما تأكدت الحاجة. تُسلَّم عروض VPS من Open Vista في أقل من 15 دقيقة بعد الطلب من مركز البيانات في نيويورك — ومركز بيانات الرباط مُعلن لكنه غير مفتوح بعد. اطّلع على العروض والأسعار لمقارنة الخطط، أو اقرأ صفحة VPS NVMe قبل اختيار نقطة البداية.