تعلمت 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 بناء الصورة تلقائياً وينشئ نشر معاينة منفصل برابط 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.

ما يحصل عليه المطورون

تصبح الحاوية على Vercel مواطناً كاملاً في المنصة: فهي تعمل على نفس البنية التحتية التي يعمل عليها الواجهة الأمامية والخدمات الأخرى للمشروع. يحصل كل التزام على نشر معاينة خاص به برابط URL منفصل، ويحدث التحجيم تلقائياً في كلا الاتجاهين — عندما يزداد حجم المرور، تضيف المنصة مثيلات؛ عندما ينخفض حجم المرور، تقلصها، مما يحرر الفريق من الحاجة إلى حساب حجم الأسطول أو حدود الانتقال يدوياً.

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

ما المقصود بهذا

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

الأسئلة الشائعة

ما متطلبات الخادم للنشر؟

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

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

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

على أي أطر يعمل هذا؟

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