لماذا تستضيف Windmill ذاتيًا على خادم VPS
على خلاف الأدوات القائمة على الـ no-code بحتًا، يستهدف Windmill الفرق التي تريد كتابة شيفرة حقيقية لكن دون إعادة اختراع التنسيق وإدارة الأسرار والجدولة والواجهات. تُودِع دالة Python أو TypeScript، فيستنتج Windmill منها تلقائيًا نموذج إدخال، ويعرضها كواجهة API، ويضيفها إلى الكتالوج. للاستضافة الذاتية على خادم VPS قيمة خاصة هنا: كثيرًا ما تتعامل نصوصك البرمجية مع قواعد بيانات داخلية وأسرار حسّاسة وشبكات خاصة. وبإبقاء Windmill على بنيتك التحتية، تُنفَّذ هذه النصوص أقرب ما يكون إلى مواردك، دون كشف بيانات اعتمادك لطرف ثالث. المحرّك مكتوب بلغة Rust، لذا فهو سريع وخفيف، والمشروع مُصمَّم للاستضافة الذاتية منذ البداية.
الفوائد الملموسة للاستضافة الذاتية
- شيفرة أصلية بلغات Python/TypeScript/Go/Bash مُدارة بالإصدارات في Git، دون منطق محبوس داخل واجهة مملوكة.
- إدارة أسرار ومتغيرات مشفّرة، لا يمكن الوصول إليها إلا من خادمك.
- توليد تلقائي للواجهات وواجهات API انطلاقًا من دوالّك، دون واجهة أمامية تكتبها.
- workers قابلة للتوسّع: أضف حاويات worker لاستيعاب مزيد من المهام بالتوازي.
- تنفيذ أقرب ما يكون إلى قواعد بياناتك الداخلية، بأدنى زمن استجابة ومع احترام الشبكة الخاصة.
- لا حدود على عمليات التنفيذ يفرضها ناشر SaaS.
المتطلبات التقنية
يعتمد Windmill على PostgreSQL وعلى worker واحد أو أكثر. لنسخة إنتاجية خفيفة، خصّص 2 vCPU و4 غيغابايت RAM؛ فمحرّك Rust مقتصد، لكن كل worker يشغّل شيفرة المستخدم وقد يستهلك ذاكرة أحيانًا بحسب نصوصك. احسب 4 vCPU / 8 غيغابايت إن كنت تخطّط لعدة workers ومهام Python ثقيلة (بيانات، pandas). القرص: من 20 إلى 40 غيغابايت بحسب ذاكرة التخزين المؤقت للتبعيات. تحتاج إلى Docker وDocker Compose، ونطاق (windmill.yourdomain.com)، والمنفذين 80/443 مفتوحين. وPostgreSQL مُضمَّن في ملف compose الرسمي.
نشر Windmill باستخدام Docker Compose
تهيئة الخادم
على الخادم VPS، ثبّت Docker (curl -fsSL https://get.docker.com | sh)، وأنشئ /opt/windmill وانتقل إليه. تحقّق من الذاكرة المتاحة باستخدام free -h قبل المتابعة.
تنزيل ملف compose وملف .env
احصل على الملف المرجعي: curl -O https://raw.githubusercontent.com/windmill-labs/windmill/main/docker-compose.yml وملف .env المرافق له. يعرّف ملف compose الخادمَ والـ workers وPostgreSQL.
ضبط قاعدة البيانات وعنوان URL الأساسي
في ملف .env، اضبط DATABASE_URL بكلمة مرور قوية وBASE_URL=https://windmill.yourdomain.com. عدّل NUM_WORKERS بحسب عدد vCPU لديك (ابدأ بـ 2). واترك الـ worker من نوع native للمهام الخفيفة.
تشغيل الحزمة
شغّل docker compose up -d. يطبّق Windmill تلقائيًا عمليات ترحيل PostgreSQL عند أول تشغيل. راقب باستخدام docker compose logs -f windmill_server حتى ظهور رسالة الاستماع.
الوكيل العكسي وHTTPS
غالبًا ما يتضمّن ملف compose خدمة Caddy. وإلا، أضف Caddy الخاص بك: windmill.yourdomain.com { reverse_proxy windmill_server:8000 }. يتولّى Caddy شهادة Let's Encrypt دون إعداد إضافي.
أول تسجيل دخول واختبار نص برمجي
سجّل الدخول ببيانات الاعتماد الافتراضية ([email protected] / changeme)، وغيّر كلمة المرور فورًا، وأنشئ workspace، ثم اكتب نص Python def main(name: str): return f'Hello {name}' للتحقق من التوليد التلقائي للواجهة والتنفيذ على أحد الـ workers.
بالنسبة لنصوص Python الثقيلة، أنشئ workers مخصّصة لوسم معيّن (worker_tags=gpu أو heavy)، ووجّه المهام كثيفة الاستهلاك إلى هذه الـ workers عبر الحقل tag في النص البرمجي. بذلك تتفادى أن تستحوذ مهمة pandas على كل الـ workers وتعطّل الأتمتة السريعة. كما يخزّن Windmill تبعيات pip/npm مؤقتًا في وحدة تخزين (volume): ثبّتها على قرص سريع لتسريع أول عمليات تشغيل المهام تسريعًا كبيرًا.
