لماذا تستضيف Kestra ذاتيًا على خادم VPS
يتميّز Kestra بنهجه التصريحي: سير العمل (flow) هو ملف YAML قابل للإدارة بالإصدارات، يضمّ مهامًا متسلسلة وشروطًا وحلقات ومُطلِقات. يجذب هذا النهج القائم على Everything-as-Code فرقَ البيانات التي تريد Git ومراجعة الشيفرة وقابلية إعادة الإنتاج، دون عناء كتابة DAG بلغة Python. تُصبح الاستضافة الذاتية لـ Kestra على خادم VPS منطقية تمامًا للأنابيب التي تقرأ من قواعد بياناتك وتكتب إليها: تُنفَّذ عمليات المعالجة حيث تعيش بياناتك، دون مرور خارجي. يستطيع Kestra أيضًا إطلاق المهام في حاويات Docker معزولة، ما يجعل خادم VPS الذي يتوفّر فيه Docker daemon مناسبًا بشكل خاص. تقدّم واجهة الويب محرّر flows وعرضًا طوبولوجيًا وتتبّعًا كاملًا للتنفيذ.
الفوائد الملموسة للاستضافة الذاتية
- سير عمل بصيغة YAML مُدار بالإصدارات في Git، مراجعة للشيفرة وقابلية كاملة لإعادة الإنتاج.
- إضافات غنية: قواعد بيانات SQL، وS3، ونصوص Python/Bash، وحاويات Docker، وطلبات HTTP.
- مُطلِقات متنوّعة: cron، حدث، webhook، اكتشاف ملف.
- تنفيذ أقرب ما يكون إلى قواعد البيانات الداخلية، دون مرور خارجي.
- واجهة ويب مع محرّر مرئي وعرض طوبولوجي وسجلات تنفيذ مفصّلة.
- لا تكلفة لكل عملية تنفيذ: خادم VPS وحده هو ما يحدّ من حجم عمليات المعالجة.
المتطلبات التقنية
يحتاج Kestra إلى PostgreSQL كـ backend (في أبسط إصدار، يستخدم قاعدة داخلية، لكن يُوصى بـ PostgreSQL في الإنتاج). خصّص 2 vCPU و4 غيغابايت RAM كحد أدنى، لأن JVM الخاصة بـ Kestra تستهلك الذاكرة؛ واستهدف 8 غيغابايت إن كانت flows لديك تُطلق مهام Docker أو نصوص بيانات ثقيلة. جهّز 30 غيغابايت من القرص، وDocker وDocker Compose، ونطاقًا (orchestrator.yourdomain.com). نقطة مهمة: لكي يُطلق Kestra مهامًا داخل حاويات، ثبّت مقبس Docker (/var/run/docker.sock) داخل حاوية Kestra.
نشر Kestra باستخدام Docker Compose
تحضير الخادم VPS
ثبّت Docker (curl -fsSL https://get.docker.com | sh) وأنشئ /opt/kestra. تحقّق من الذاكرة المتاحة: تحبّ JVM الذاكرة، فخصّص 4 غيغابايت على الأقل حرّة فعليًا باستخدام free -h.
كتابة ملف docker-compose
احصل على ملف compose الرسمي لـ Kestra الذي يتضمّن PostgreSQL. عرّف الخدمة kestra مع الصورة kestra/kestra:latest، والأمر server standalone، وثبّت /var/run/docker.sock:/var/run/docker.sock لتفعيل المهام المُحوّاة.
ضبط الـ backend من PostgreSQL
في قسم configuration من ملف compose، وجّه kestra.datasources إلى PostgreSQL مع عنوان JDBC URL والمستخدم وكلمة المرور. واضبط أيضًا kestra.url: https://orchestrator.yourdomain.com/ للحصول على روابط صحيحة في الواجهة.
تشغيل Kestra
شغّل docker compose up -d. عند أول تشغيل، يُنشئ Kestra مخططه في PostgreSQL. راقب docker compose logs -f kestra حتى ظهور الرسالة التي تشير إلى جاهزية الخادم على المنفذ 8080.
الوكيل العكسي وHTTPS
ضع Caddy أمامه: orchestrator.yourdomain.com { reverse_proxy localhost:8080 }. يحمي HTTPS الوصول إلى محرّر flows وسجلات التنفيذ، التي قد تحتوي على بيانات حسّاسة.
إنشاء أول flow بصيغة YAML
في الواجهة، أنشئ flow اختبار مع مهمة io.kestra.plugin.core.log.Log ثم أضف مُطلِق cron من نوع schedule. تحقّق من أن عملية تنفيذ مجدولة تنطلق وتظهر في الخط الزمني. ثم أدرِج هذا الـ YAML بالإصدارات في Git.
اضبط ذاكرة JVM صراحةً لتفادي المفاجآت على خادم VPS: مرّر JAVA_OPTS=-Xmx2g (أو نصف ذاكرتك RAM) في بيئة حاوية Kestra. من دون هذا الحد، قد تحاول JVM حجز قدر كبير من الـ heap وتُطلق OOM kill من نواة Linux. بالنسبة لأنابيب البيانات، استخدم نوع المهمة Docker بدلًا من Process: تعمل كل عملية معالجة في حاويتها الخاصة مع تبعياتها، ما يتفادى تلويث خادم VPS ويضمن قابلية إعادة الإنتاج.
