لماذا استضافة Temporal ذاتياً على VPS
Temporal Cloud متاح، لكن الاستضافة الذاتية تبقى وثيقة الصلة لأسباب عديدة: التكلفة المتوقعة ابتداءً من 99 درهم/شهر، وسيادة البيانات، والتحكم الكامل في الإصدار والسياسات.
حالات استخدام Temporal
يتألق Temporal حيث تظهر حدود مهام cron وقوائم الانتظار البسيطة. فيما يلي أكثر حالات الاستخدام شيوعاً في بيئات الإنتاج.
معمارية Temporal المستضاف ذاتياً
إن فهم المكونات الداخلية يساعدك على تحديد مواصفات VPS الخاص بك وتشخيص المشكلات. يتكون Temporal من أربعة خدمات رئيسية يمكن تشغيلها في نفس العملية (temporalio/auto-setup) أو نشرها بشكل منفصل على نطاق واسع.
Temporal مقابل BullMQ مقابل Celery
مرّر الجدول أفقيًا
| المعيار | Temporal | BullMQ | Celery |
|---|---|---|---|
| استدامة الحالة | سجل كامل محفوظ في قاعدة البيانات — يستأنف سير العمل المنقطع من حيث توقف تماماً | الحالة في Redis — فقدان Redis يعني فقدان المهام (قابل للتخفيف باستخدام AOF/RDB) | نتائج اختيارية في الواجهة الخلفية (Redis، قاعدة البيانات) — لا يوجد سجل تنفيذ أصلي |
| الإعادة والحتمية | إعادة تشغيل تلقائية من السجل — يجب أن يكون كود سير العمل حتمياً، وTemporal يتكفل بالباقي | لا إعادة تشغيل أصلية — إعادة محاولة بسيطة عند الفشل، دون إعادة الخطوات السابقة | إعادة المحاولة قابلة للتخصيص لكل مهمة، لا إعادة تشغيل لسير عمل متعدد الخطوات |
| واجهة المراقبة | واجهة مستخدم غنية مدمجة: قائمة سير العمل، تفاصيل كل خطوة، البحث، الإجراءات اليدوية | Bull Board كإضافة خارجية — وظيفي لكن محدود | Flower كأداة منفصلة — مقاييس أساسية، لا سجل للخطوات |
| اللغات المدعومة | Go، TypeScript/JavaScript، Python، Java، .NET، PHP (SDKs رسمية) | Node.js فقط | Python فقط (تكاملات خفيفة للغات أخرى) |
| تعقيد التثبيت | مجموعة من 4 خدمات + PostgreSQL + Worker — أثقل من Redis، مبرر لسير العمل الطويلة | نسخة Redis واحدة — سهل الانطلاق جداً | وسيط (Redis أو RabbitMQ) + واجهة خلفية اختيارية — في حده الأدنى |
| حالة الاستخدام المثالية | سير العمل الطويلة، متعددة الخطوات، مع إعادة المحاولة والتعويض — المدفوعات، الإعداد، خطوط معالجة البيانات | المهام القصيرة والمتوازية — إرسال البريد الإلكتروني، تغيير حجم الصور، الإشعارات | مهام Python الدُفعية — التعلم الآلي، الاستخراج، معالجة الملفات |
المتطلبات التقنية
نشر Temporal باستخدام Docker Compose
إنشاء دليل العمل
تنزيل ملف Docker Compose الرسمي
إنشاء ملف متغيرات البيئة
أنشئ ملف
.envلتخصيص credentials الخاصة بـPostgreSQL. لا تترك كلمات مرور افتراضية أبدًا في بيئة الإنتاج.تقييد صلاحيات ملف .env
ملف
.envيحتوي على credentials — قيّد الوصول إليه.تشغيل المكدس
التحقق من صحة الخدمات
التحقق من الاتصال بـFrontend Service
استخدم
temporalCLI للتأكد من أن الخادم يستجيب على منفذ gRPC.إنشاء namespace الإنتاج
الوصول إلى واجهة Temporal
واجهة الويب متاحة على المنفذ 8080. في الإنتاج، ضع reverse proxy nginx مع HTTPS أمام هذا المنفذ.
تهيئة التشغيل التلقائي
فعّل إعادة التشغيل التلقائية بعد إعادة تشغيل VPS.
تهيئة Worker بسيط بـGo أو TypeScript
Worker هو العملية التي تنفذ فعلياً كود الأعمال الخاص بك. يتصل بـFrontend Service، ويستطلع task queue وينفذ سير العمل والأنشطة التي يوزعها عليه Temporal. إليك مثال بسيط بأكثر لغتين استخداماً.
واجهة مستخدم Temporal — مراقبة سير العمل وتصحيحه
واجهة مستخدم Temporal (متاحة على المنفذ 8080) هي الأداة الأساسية لمراقبة سير عملك في الإنتاج. تتيح لك:
نسخ احتياطي لـ PostgreSQL والاستمرارية
تعتمد متانة Temporal كليًا على PostgreSQL. نسخة بلا نسخ احتياطي تعني خسارة كاملة لسجل سير العمل عند أي عطل في الـ VPS.
استكشاف الأخطاء — الأخطاء الشائعة
فيما يلي الأخطاء الأربعة الأكثر شيوعًا عند تثبيت Temporal على VPS وطريقة معالجتها.
الأمان: لا تعرض Frontend Service بدون مصادقة
يجب ألا يُعرَّض المنفذ 7233 (gRPC Frontend) والمنفذ 8080 (UI) مباشرةً للإنترنت دون حماية. لا يتضمن Frontend Service أي مصادقة أصلية في الإصدارات مفتوحة المصدر: كل من يستطيع الاتصال به يمكنه بدء سير العمل وإيقافها وقراءة جميع بياناتها. الإجراءات الموصى بها: (1) أغلق المنفذ 7233 في ufw وأتِح الوصول فقط لعناوين IP الخاصة بـ Workers (ufw allow from 10.0.0.0/8 to any port 7233)؛ (2) ضع الـ UI خلف proxy عكسي nginx مع مصادقة HTTP أساسية أو SSO؛ (3) استخدم VPN أو شبكة خاصة بين VPS الخاص بـ Temporal وVPS الخاصة بـ Workers. في بيئة الإنتاج، فكّر في استخدام mTLS (متاح في Temporal الإصدار 1.x) لتشفير اتصال gRPC والتحقق منه.
