Vercel تتيح تشغيل أي Dockerfile على منصة Fluid compute

أضافت Vercel إلى منصتها دعم الحاويات العشوائية: بات بإمكان المطورين نشر أي خدمة تعتمد على Dockerfile، من خدمة مكتوبة بلغة Go إلى تطبيق على Rails أو Spring Boot، بمجرد إضافة الملف Dockerfile.vercel إلى جذر المشروع. وتتولى المنصة بناء الصورة ونشرها على بنية Fluid compute التحتية.

كيف تعمل هذه الميزة

الآلية بسيطة للغاية: يكفي وجود الخادم نفسه وملف Dockerfile.vercel ليصبح المشروع جاهزًا للنشر. وتعرض Vercel مثالًا بلغة Go: خادم HTTP يستمع إلى المنفذ المحدد في المتغير $PORT (الافتراضي 80)، ويُبنى عبر Dockerfile من مرحلتين. في المرحلة الأولى تُجمّع الصورة golang:1.24-alpine الملف التنفيذي، ثم يُنسخ إلى صورة alpine:3.20 الخفيفة التي تعمل في بيئة الإنتاج.

يبني الأمر `vercel deploy` من واجهة سطر الأوامر (CLI) الصورة ويحفظها في سجل المشروع وينشرها على Fluid compute، ثم يعيد رابط URL لبيئة الإنتاج. ويعيد كل git push بناء الصورة تلقائيًا وينشئ نشرًا معاينًا (preview) مستقلًا برابط URL غير قابل للتغيير. ويمكن فتح هذا الرابط أو إرساله إلى الزملاء أو استخدامه للعودة إلى النسخة السابقة.

• الشرط الوحيد المفروض على الخادم هو الاستماع إلى منفذ HTTP المحدد في المتغير $PORT
• المثال الوارد في المدونة مبني على الجمع بين golang:1.24-alpine وalpine:3.20 في عملية بناء من مرحلتين
• يُطلق النشر بأمر واحد هو `vercel deploy` من CLI، أو تلقائيًا عند كل git push
• تُدعم Rails وSpring Boot وExpress وLaravel وASP.NET وFastAPI والخدمات العاملة خلف nginx

ما اللغات والأطر المدعومة

تؤكد Vercel أن الحزمة التقنية المستخدمة لا تهم، إذ تعمل أي خدمة قادرة على التخاطب عبر HTTP والاستماع إلى منفذ. وقد وردت في القائمة صراحةً Rails وSpring Boot وExpress وLaravel وASP.NET وFastAPI وخوادم الويب العاملة خلف nginx، بما فيها Java وPHP، وهي منصات ارتبطت سابقًا باستضافة الخوادم التقليدية أكثر من ارتباطها ببنية Vercel الخالية من الخوادم (serverless).

ماذا يكسب المطورون

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

تقوم التسعيرة على نموذج Active CPU: تحاسب Fluid compute فقط على الوقت الذي تنفَّذ فيه شيفرة الخدمة فعليًا، لا على كامل عمر النسخة. وهذا يعني أن الخادم المتوقف عن العمل، العالق بانتظار استعلام بطيء إلى قاعدة البيانات، لا يكلّف الفريق أكثر من خادم يعمل بنشاط.

ما دلالة ذلك

تمحو ميزة Dockerfile.vercel الحدود بين منصات serverless مثل Vercel والسحابات التقليدية القائمة على الحاويات: بات من الممكن الآن نشر أي خدمة بلغة Java أو PHP أو Ruby دون إعداد سجل صور خاص أو daemon أو عنقود (cluster)، مع الحصول افتراضيًا على التوسّع التلقائي والنشر المعاين (preview).

أسئلة شائعة

ما المتطلبات المفروضة على الخادم لنشره؟

الشرط الوحيد هو أن يستمع الخادم إلى HTTP على المنفذ المحدد في متغير البيئة $PORT (الافتراضي 80). وإذا كانت الخدمة تردّ على طلبات HTTP، فيمكن تغليفها في Dockerfile.vercel ونشرها.

ماذا يحدث عند كل commit؟

يعيد كل git push بناء الصورة وينشئ رابط معاينة (preview) مستقلًا، يمكن فتحه أو إرساله إلى آخرين أو استخدامه للعودة إلى النسخة السابقة من المشروع.

على أي أطر يعمل ذلك؟

Rails وSpring Boot وExpress وLaravel وASP.NET وFastAPI والخدمات العاملة خلف nginx. أما المثال الوارد في مدونة Vercel فيستخدم الجمع بين golang:1.24-alpine وalpine:3.20 في بناء من مرحلتين.