لماذا تستضيف Temporal ذاتيًا على خادم VPS
يحلّ Temporal مشكلة قلّما تعالجها الأدوات فعلًا: ديمومة التنفيذ. يمكن أن يستمر سير عمل Temporal ثوانيَ أو أشهرًا، وأن ينتظر حدثًا بشريًا، وأن يعيد تلقائيًا محاولة خطوة فاشلة، وأن يستأنف من حيث توقّف تمامًا حتى وإن أُعيد تشغيل الخادم في الأثناء. إنه ليس أداة no-code: تكتب شيفرة سير العمل في SDK، ويضمن Temporal إعادة تنفيذها بشكل حتمي. تكون الاستضافة الذاتية على خادم VPS ملائمة عندما تقود سير عملك عمليات حرجة (مدفوعات، توفير موارد، تنسيق خدمات مصغّرة) وتريد تجنّب التبعية وتكلفة سحابة Temporal المُدارة. يمنحك الخادم ذاتي الاستضافة المحرّك نفسه، تحت سيطرتك، مع اتفاقيات مستوى الخدمة (SLA) الخاصة بك. انتبه: Temporal أكثر تطلّبًا من بقية أدوات هذه السلسلة، فهو بنية تحتية قائمة بذاتها.
الفوائد الملموسة للاستضافة الذاتية
- ديمومة أصلية: تصمد حالة سير العمل أمام الأعطال وإعادة التشغيل.
- إعادات محاولة ومُهل زمنية تلقائية على كل نشاط، دون شيفرة سباكة (plumbing).
- سير عمل مكتوب بلغتك: Go أو Java أو Python أو TypeScript.
- Web UI كاملة لفحص سجل التنفيذ خطوةً بخطوة.
- استقلالية عن السحابة المُدارة: بياناتك واتفاقيات مستوى الخدمة (SLA) لديك.
- مثالي للـ sagas وتوفير الموارد وتنسيق الخدمات المصغّرة.
المتطلبات التقنية
يتكوّن Temporal من عدة خدمات (frontend، history، matching، worker) إضافةً إلى قاعدة بيانات. لبيئة تطوير أو إنتاج صغير، يعمل docker-compose الرسمي مع PostgreSQL على 2 vCPU و4 غيغابايت RAM، لكن استهدف 4 vCPU / 8 غيغابايت لإنتاج جدّي، لأن خدمات Temporal وقاعدة البيانات تستهلك معًا. وللأحجام الحقيقية، يوصي Temporal بـ Cassandra ومحرّك بحث (Elasticsearch) لاستعلامات Visibility المتقدمة، وهو ما يتطلّب موارد أكبر. جهّز Docker وDocker Compose ونطاقًا (temporal.yourdomain.com)، وافتح المنفذ 7233 (gRPC) على جهة الشبكة الداخلية، والمنفذ 8080 للـ Web UI.
نشر Temporal باستخدام Docker Compose
استنساخ مستودع docker-compose
يوفّر Temporal مستودعًا مخصّصًا: git clone https://github.com/temporalio/docker-compose.git /opt/temporal && cd /opt/temporal. يحتوي على عدة صيغ (PostgreSQL، Cassandra، مع أو بدون Elasticsearch).
اختيار صيغة PostgreSQL
للبدء بشكل معقول، استخدم docker-compose-postgres.yml. ينشر PostgreSQL وخادم Temporal متعدّد الخدمات والـ Web UI. عدّل كلمة مرور قاعدة البيانات والموارد المخصّصة.
تشغيل خادم Temporal
ابدأ بالأمر docker compose -f docker-compose-postgres.yml up -d. يطبّق الخادم المخطط تلقائيًا (auto-setup). تحقّق من السلامة باستخدام docker compose logs -f temporal ثم اختبر واجهة سطر الأوامر: tctl --address temporal:7233 cluster health.
تأمين الـ Web UI خلف وكيل
لا تتولّى الـ Web UI (المنفذ 8080) المصادقة بشكل افتراضي. ضعها خلف Caddy مع HTTPS وحماية (basic auth أو SSO): temporal.yourdomain.com { basicauth { ... } reverse_proxy localhost:8080 }. لا تكشف المنفذ 7233 gRPC علنًا أبدًا.
ضبط namespace
أنشئ namespace تطبيقيًا مخصّصًا بدلًا من استخدام default: tctl --namespace prod namespace register --retention 72h. تحدّد مدة الاحتفاظ (retention) الفترةَ التي يبقى فيها سجل سير العمل قابلًا للاطّلاع.
ربط worker اختباري
من تطبيقك (SDK بلغة Python مثلًا)، اربط worker بـ temporal.yourdomain.com:7233، وسجّل سير عمل بسيطًا ونشاطًا، وأطلق عملية تنفيذ. تحقّق من سجله خطوةً بخطوة في الـ Web UI.
في الاستضافة الذاتية، راقب عن كثب مدة الاحتفاظ وحجم قاعدة البيانات: يُحفَظ كل حدث من كل سير عمل، وقد يؤدّي سجل طويل جدًا أو ملايين عمليات التنفيذ إلى تضخّم PostgreSQL بسرعة. حدّد مدة احتفاظ معقولة للـ namespace (مثلًا من 72 ساعة إلى 7 أيام) وفعّل الأرشفة إن كنت بحاجة إلى الاحتفاظ بالسجل بعد ذلك. وللإنتاج، افصل workers التطبيق (شيفرتك) عن خادم Temporal في حاويات منفصلة، بل حتى خوادم VPS منفصلة، حتى لا يُدهور worker مُثقَل عنقود التنسيق أبدًا.
