السؤال الحقيقي ليس السعر
مقارنة فاتورة VPS باشتراك منصّة تجيب عن السؤال الخطأ. فكل الخيارات قادرة على تشغيل حاويتك؛ وما يختلف هو مقدار الانتباه الذي يظل كل خيار يطلبه منك بعد أول عملية نشر.
الحاوية في الإنتاج تحتاج إلى نطاق وشهادة تجدّد نفسها، وطريقة لإعادة التشغيل عند الانهيار، ومكان تذهب إليه السجلات، وخطة للتحديث دون توقف، وقاعدة بيانات لها نسخ احتياطي. لا شيء من ذلك من مهام Docker. ومن يتولّى ذلك هو ما تختار بينه فعليًا — والمقارنة الصادقة تسعّر ساعاتك أنت، لا الخادم وحده.
الخيار 1 — VPS تديره بنفسك
استأجر آلة افتراضية، وثبّت Docker، وشغّل حاويتك. إنه المسار الأكثر مباشرة وهو ينجح فعلًا، مع صلاحية جذر كاملة ودون أي تجريد بينك وبين الآلة.
ثم يبدأ العمل الدائم: تحديثات أمان نظام التشغيل، ووكيل عكسي في المقدمة، وشهادات لا بد أن تُجدَّد، وسياسة إعادة تشغيل حين تموت الحاوية الرابعة فجرًا، وقرص يمتلئ بالسجلات والصور التي لم يقلّمها أحد، ونسخ احتياطي تضبطه — والأهم — تختبره. أما النشر فسكربت من تأليفك، والطرح دون توقف شيء تبنيه بنفسك.
اختر هذا حين تريد صلاحية الجذر، أو حين تتعلّم كيف تتراكب القطع، أو حين تكون تدير خوادم أصلًا فيصبح خادم إضافي أمرًا هامشيًا. وتجنّبه حين يكون منتجك هو التطبيق لا البنية التحتية تحته.
الخيار 2 — Kubernetes
يحلّ Kubernetes مشكلات حقيقية: خدمات كثيرة، وعمليات نشر متدرّجة، وشفاء ذاتي، وتوسّع تلقائي. فإن كنت تشغّل عشرات الخدمات عبر فريق، فهو يستحق تعقيده.
أما دون ذلك النطاق فتنقلب النسبة. إذ تصير تصون عنقودًا وترقياته وواجهة الدخول فيه وشهاداته وملفات YAML الخاصة به لتشغّل حفنة حاويات — ويصبح العنقود نفسه نظامًا يحتاج إلى خبرة مستقلة. وKubernetes المُدار يزيل بعض ذلك، لا الثقل المفاهيمي.
اختره حين يفرضه نطاقك أو فريقك بالفعل. ولا تختره لأنه ما تستخدمه الشركات الجادة؛ فالجدّية في مطابقة الأداة لحجم المشكلة.
الخيار 3 — منصّة حاويات مُدارة
هنا تسلّم الحاوية وتشغّلها المنصّة: نطاق مع HTTPS تلقائي، وإعادة تشغيل، وسجلات، وطرح محكوم بفحص الصحة، وPostgres أو Redis مُدار أو تخزين متوافق مع S3 يُربَط عند الحاجة.
على cdn.com.tr تبدأ عملية النشر بتشغيل الحاوية الجديدة، وتنتظر مسار فحص الصحة لديك ليبلّغ عن الجاهزية، ثم تحوّل الزيارات وتحيل القديمة إلى التقاعد — فالبناء المعطوب لا يُسقط الخدمة أبدًا، لأن الزيارات تبقى ببساطة على النسخة التي ما زالت تعمل. وتقف شبكة CDN الحافّية أمامها مع WAF وحماية DDoS مشمولين.
والمقايضة حقيقية وتستحق التصريح: لا صلاحية جذر على المضيف، ولا تثبيت حزم على مستوى نظام التشغيل، والوصول العام عبر HTTP(S) لا عبر منافذ TCP اعتباطية. فإن كان تطبيقك يحتاج شيئًا لا تتيحه المنصّة، فالـVPS هو الجواب الصادق.
ثلاث طرق للدخول، بحسب ما لديك
الطريق الصحيح يعتمد على مصدر صورتك.
إن كنت تبني الصور وتدفعها إلى سجلّ بالفعل، فاستخدم Container Apps: أعطِها مرجع الصورة والمنفذ، وستنشرها. ولا يتغيّر أي شيء آخر في خط إنتاجك.
وإن أردت النشر بالدفع من الشيفرة المصدرية، فاستخدم GitHub Deploy. فهو يتولى خطوة البناء عنك — يُبنى ملف Dockerfile لديك في بانٍ معزول ويُدفَع إلى سجلّنا الخاص، فلا تحتاج إلى حساب سجلّ خاص بك. ادفع إلى فرعك وستُطرَح النسخة الجديدة خلف فحص الصحة.
وإن كان تطبيقك عدة خدمات، فاستخدم Docker Compose Instant Deploy. فالخدمات التي فيها قسم `build:` تُبنى من ملف Dockerfile الخاص بها؛ والخدمات التي تشير إلى `image:` عامة (قواعد بيانات، ذاكرات تخزين مؤقت، طوابير) تُوصَّل كإضافات مُدارة أو كتطبيقات. والبناءات متعددة المراحل و`target:` و`build.args` مدعومة. عايِن الخطة قبل إنشاء أي شيء، ثم طبّقها.
عايِن ما سيصير إليه ملف compose، ثم طبّقه
# see the plan first — nothing is created
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply it when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.ymlما ينبغي التحقق منه قبل أن تلتزم
أيًّا كان الطريق الذي تسلكه، فالأسئلة التي تستحق الطرح واحدة. كيف يجري طرح النشر — هل يُسقط بناءٌ فاشل الموقعَ، أم تبقى الزيارات على آخر نسخة سليمة؟ إلى أين تذهب السجلات، وهل يمكنك قراءتها دون SSH؟ وماذا يحدث لبياناتك: هل قاعدة البيانات مُدارة وذات نسخ احتياطي، أم أنها حاوية على قرص أنت المسؤول عنه؟ وهل يمكنك الخروج — هل صورتك قابلة للنقل، أم أنك أُعِدت كتابتك داخل شيء احتكاري؟
هذا السؤال الأخير هو ما يتخطّاه الناس ثم يندمون. فصورة Docker المبنية من ملف Dockerfile الخاص بك قابلة للنقل بحكم تكوينها: تعمل بالطريقة نفسها على VPS، وعلى Kubernetes، وعلى منصّة مُدارة. والحفاظ عليها كذلك هو ما يجعل الاختيار قابلًا للتراجع.
الأسئلة الشائعة
هل عليّ بناء الصورة بنفسي؟
فقط إن أردت ذلك. فـContainer Apps ينشر صورة جاهزة تدفعها إلى سجلّ. أما GitHub Deploy وDocker Compose Instant Deploy فيبنيان من ملف Dockerfile الخاص بك داخل بانٍ معزول ويدفعان إلى سجلّنا الخاص، فلا تحتاج إلى حساب سجلّ.
هل يمكنني تشغيل قاعدة بيانات في حاوية هنا؟
يمكنك، لكن لأي شيء يهمّك استخدم إضافات Postgres أو Redis المُدارة بدلًا من ذلك — فهي تُشغَّل ويُؤخَذ لها نسخ احتياطي نيابةً عنك. أما قاعدة بيانات في حاوية عادية فهي قرص أنت مسؤول عنه شخصيًا، وهذا هو الجزء الذي يؤلم لاحقًا.
ماذا لو احتاج تطبيقي إلى SSH أو حزمة نظام مخصّصة؟
ضع حزم النظام في ملف Dockerfile لديك — فهذا بالضبط ما وُجدت الصور من أجله. أما إن احتجت إلى SSH داخل المضيف، أو تثبيتات على مستوى نظام التشغيل أثناء التشغيل، أو منافذ TCP عامة خام، فالمنصّة المُدارة ليست الخيار المناسب والـVPS هو الجواب الصادق.
هل المنصّة المُدارة أبطأ من خادمي الخاص؟
ليست كذلك بطبيعتها، وعادةً ما تنتهي أسرع عمليًا لأن الحافة العالمية تخزّن مؤقتًا أمامها. والحاوية نفسها تعمل على النوع نفسه من العتاد؛ وما تفقده هو صلاحية الجذر، لا السرعة.