إصدار المجتمع، إصدارات محددة، المصادقة متعددة العوامل معفلة، بيانات الاعتماد مخزنة في متجر التشفير الخاص بـ n8n، مفتاح التشفير مخزن بشكل منفصل عن نسخ احتياطية من قاعدة البيانات
القيد الذي يقود كل شيء: يتم التعامل مع أي مسار داخلي كسطح هجوم جديد يحتاج إلى مراجعته الخاصة. الإجابة الافتراضية هي “عدم الدخول”. المحرر متاح للاستخدام الداخلي فقط، المستخدمون النهائيون يتلقون المخرجات فقط (بريد إلكتروني وما إلى ذلك).
خطتي للمشغلات:
معظم ما نبنيه ليس في الوقت الفعلي. الكمون المقبول هو بالدقائق، وليس بالثواني. لذا أنا أستبدل webhooks بالاستطلاع المجدول للدفعة الأولى من سير العمل (Graph و Zoom recordings و mailbox checks). لا حاجة للدخول الداخلي، والاتصالات الخارجة تناسب قائمة سماح صغيرة لفريق الشبكة.
للوصول إلى المحرر بدون DNS أنا أخطط لإدخالات ملف hosts على الأجهزة التي تحتاجها، مع قبول شهادة Caddy ذاتية التوقيع مرة واحدة لكل جهاز. لا شيء يتم نشره في أي مكان.
الأشياء التي قررت بالفعل تجنبها حتى لا نذهب إلى هناك:
Cloudflare Tunnel / Tailscale Funnel — TLS ينتهي عند المزود، لا يعمل بالنسبة لنا
سجل A عام يشير إلى IP خاص — يعمل لكنه يكشف اسم المضيف والعنونة الداخلية إلى الأبد (سجلات CT). سأفعل هذا فقط إذا فشلت الخيارات الأبسط
ما أود الحصول عليه رأي حوله:
هل يوجد أي شخص يقوم بتشغيل n8n الإنتاج الخارج فقط؟ ما الذي عضك الذي ربما لا أراه؟
تكرار الاستطلاع في الممارسة — كيف تتعامل مع EXECUTIONS_DATA_PRUNE وانتفاخ قاعدة البيانات عندما تجد معظم الأشغال لا شيء؟
النبض / المراقبة — “النجاح” على مستوى سير العمل مضلل عندما تكون تستطلع (استطلاع معطل يبدو مثل يوم هادئ). على ماذا تنبه فعلاً؟
بالنسبة لأي شيء قد يحتاج في النهاية إلى دفع، أين رسمت الخط وأي نمط وصلت إليه؟ WAF + IP allowlist أو عكس الأنفق أو قائمة الانتظار بين الرسائل؟
أي أخطاء متعلقة بـ N8N_HOST / WEBHOOK_URL عندما لا يملك المثيل اسم عام؟
عقد المجتمع — تعمل بإمكانية وصول كاملة للبيانات. كيف تتحقق من الجهات الخارجية قبل التثبيت؟
يسعدني الكتابة بما ينتهي بنا. شكراً
أهلاً وسهلاً @Olu!
بخصوص DB bloat مع polling: اضبط EXECUTIONS_DATA_PRUNE=true بالإضافة إلى EXECUTIONS_DATA_MAX_AGE (hours) و EXECUTIONS_DATA_PRUNE_MAX_COUNT معاً، حد العدد أهم من العمر عندما تعمل الاستطلاعات كل دقائق قليلة وغالباً لا تجد شيء. بخصوص المراقبة، لا تنبه على نجاح سير العمل، بل انبه على “لم يتم تسجيل أي تنفيذ في آخر X دقائق” عبر Uptime Kuma التي تصل إلى نقطة نهاية خفيفة يقرعها سير العمل للاستطلاع عند كل تشغيل، هذا يمسك الاستطلاع الصامت الميت الذي تخفيه علامة صحيحة خضراء. بخصوص N8N_HOST/WEBHOOK_URL بدون اسم عام، اضبط WEBHOOK_URL صراحة على عنوان Caddy الداخلي الخاص بك، وإلا يعود n8n للتخمين من الطلب وكسر أي عقدة تولد عناوين callback (مثل عقد Wait/Form). بخصوص العقد المجتمعية، شغلها في عامل queue-mode معزول أولاً مع حساب خدمة ذو نطاق محدود قبل الترويج لمثيلك الرئيسي، هذا يحد من نطاق الانفجار إذا تبين أن أحدها يتصرف بشكل سيء.
أقدّر هذا حقاً؛ جميع النقاط الأربع ذاهبة مباشرة إلى الإعدادات. خاصة نقطة PRUNE_MAX_COUNT.
كنت أخطط لاستخدام العمر فقط وكنت سأراقب الجدول وهو ينمو. نمط Uptime Kuma للدفع أنظف بكثير مما فكرت فيه.
لا تزال لديّ فضول إذا كان أحد قد توصل إلى نمط محدد لعندما تحتاج فعلاً إلى الدفع (السؤال 4) - WAF + قائمة السماح بـ IP هي ما أعمل عليه لذلك اليوم، لكنني مهتم بما جرّبه الآخرون.
مرحباً @Olu
من بين خياراتك الثلاثة، قائمة الانتظار هي الخيار الذي يحافظ على n8n بحيث تكون الاتصالات الصادرة فقط. محفزات AMQP و RabbitMQ و MQTT ليست مستمعي HTTP، بل العقدة تتصل بالوسيط بنفسها، لذا لا شيء يربط منفذاً لها و TLS ينتهي عند الوسيط الخاص بك. بيانات اعتماد RabbitMQ تتطلب شهادة CA بالإضافة إلى شهادة عميل ومفتاح، لذا يمكنك استخدام mTLS لهذا الجزء بدلاً من الثقة بمزود.
يعيد تحديد موقع الدخول بدلاً من إزالته. Graph و Zoom يجب أن ينشرا في مكان ما، لذا جهاز استقبال صغير في DMZ يتحقق من توقيع البائع وينشر إلى قائمة الانتظار. هذا نقطة نهاية بغرض واحد يمكن لفريق الشبكة الخاص بك مراجعتها بشكل صحيح، على عكس محرر n8n و REST API اللذين يقعان خلف WAF وقائمة IP بيضاء يجب عليك إعادة التحقق منها في كل مرة يدور فيها البائع النطاقات.
مرحبا!
سأكون موجزًا وقد أضيف شيئًا إلى النقاط ذات الصلة.
بالإضافة إلى ما قاله مساعدو المجتمع الآخرون و@Anshul_Namdev، إذا التزمت بـ pooling، يمكنك أيضًا تفعيل حفظ عمليات التنفيذ الفاشلة فقط من خلال إعدادات سير العمل.
إضافة عقدة IF للتحقق من البيانات الزائدة والتوقف (أو بدء سير عمل فرعي) سيوفر أيضًا عدم تشغيل سير العمل بالكامل.
في نهاية التنفيذ الناجح، سأرسل ping برقم معرّف سير العمل وأنشئ منطقًا إضافيًا، مثل… إذا لم يكن هناك ping من هذا المعرّف في الوقت X، فهناك خطأ ما.
أنا أستخدم nginx وأستطيع أن أقول أنني ببساطة أعيّن بعض كتل الموقع الغريبة (لذا أنشئ مسارًا داخليًا مزيفًا [لكن احذر من oauth’s] وألعب بعد ذلك مع متغيرات البيئة الخاصة بـ n8n.
العقد المتحققة منها يتم التحقق منها بواسطة بعض الأشخاص الرائعين، ويضمنون لها… عقد المجتمع يتم بناؤها والتحقق منها بواسطة “صدّقني” (ما لم تعرف ما تفعله والتأثير الذي قد يكون له)…
ملخصي إن كان يستحق الفلس.
إذا لم أجب على نقاط أخرى، فهذا يعني أنها قابلة للتنفيذ (1. جهاز localhost الخاص بي هو “الإنتاج” الخاص بي في هذه الحالة المقيدة ربما. 2. tunnel)…
تحياتي! اقتُرح تلقائيًا بواسطة 3 أكواب قهوة. إنه مشروع تجريبي لأنني تم وسمي بواسطة @n8n
بخصوص سؤال المراقبة تحديداً — مشغل الاستقصاء الذي لا يعيد شيئاً يبدو متطابقاً مع مشغل استقصاء معطوب، ولا يظهر أي منهما تحت التنفيذات الفاشلة. الإصلاح الأرخص هو سير عمل جدول منفصل يتحقق من طابع زمن آخر تنفيذ ناجح لكل سير عمل تم استقصاؤه ويصدر تنبيهاً عندما يصبح قديماً. فحص واحد يكتشف مشغلاً معطوباً، أو بيانات اعتماد منتهية الصلاحية، وسير عمل قام شخص ما بإلغاء تفعيله بهدوء.
بالنسبة للانتفاخ، اضبط ‘حفظ تنفيذات الإنتاج الناجحة’ على ‘عدم الحفظ’ لكل سير عمل على أجهزة الاستقصاء عالية التردد بدلاً من إيقاف تشغيله عالمياً. تحتفظ بسجل كامل حيث قد تريده فعلاً أثناء حادثة ما وتوقف الكتابات حيث تأتي منها.
