أنا أستخدم n8n كخادم ذاتي على صورة Docker في منتج هندسة البرمجيات. كلما احتجت للانتقال من بيئة التطوير إلى بيئة الاختبار المتكاملة (SIT)، هل هناك طريقة بدلاً من تشغيل صورة Docker جديدة ونسخ جميع سير العمل من بيئة إلى أخرى في كل مرة؟ عدد سير العمل كبير جداً
@Mohamed8 لا تنسخها يدويًا، استخدم أمر n8n CLI للتصدير والاستيراد، فهو ينقل مكتبتك بالكامل مرة واحدة. على حاوية التطوير، صدّر جميع سير العمل إلى مجلد، انسخ هذا المجلد إلى صندوق SIT، ثم استورد:
# على التطوير
docker exec -u node <dev-container> n8n export:workflow --backup --output=/tmp/wf/
# انسخ /tmp/wf عبره، ثم على SIT
docker exec -u node <sit-container> n8n import:workflow --separate --input=/tmp/wf/
هناك زوج مطابق export:credentials / import:credentials إذا كنت بحاجة إلى نقل بيانات الاعتماد أيضًا. أفضل من إطلاق صورة جديدة ونسخ في كل مرة.
شكراً. أنا أستخدم المصادقة الأساسية في مسارات العمل، أضفتها في بيانات الاعتماد واخترت المناسبة منها لكل طلب HTTP. عند نسخ المسار، يتم إعادة تعيينه واختيار أول مصادقة أساسية لجميع عقد HTTP افتراضياً وأحتاج إلى إصلاحها.
هل سأواجه نفس المشكلة مع هذا الأسلوب؟
@Mohamed8 إعادة التعيين تحدث لأن العُقد تُشير إلى بيانات الاعتماد بواسطة معرّف فريد (ID) والنسخة البسيطة لا تحمل هذه المعرّفات، لذا تعود إلى أول واحد متطابق. واجهة سطر الأوامر تتجنب هذه المشكلة طالما تنقل بيانات الاعتماد أيضاً، وليس فقط سير العمل: export:credentials --backup على بيئة التطوير، ثم import:credentials على بيئة الاختبار. هذا الاستيراد ينفذ عملية upsert حسب المعرّف لذا تحتفظ كل بيانات اعتماد بمعرّفها الأصلي وتُحل مراجع سير العمل تلقائياً إلى المصادقة الأساسية الصحيحة.
رائع! هل لديك أي فكرة عن كيفية الوصول إلى مفتاح التشفير هذا؟ وهل يمكن تصديره أيضًا أم لا؟
@Mohamed8 لم يتم تصديره مع سير العمل. إنه إما متغير البيئة N8N_ENCRYPTION_KEY إذا قمت بتعيينه، أو إذا لم تقم به، فإن n8n يولده تلقائيًا وحفظه في ملف الإعدادات. اقرأه في dev باستخدام:
docker exec -u node <dev-container> cat /home/node/.n8n/config
ستجد قيمة encryptionKey هناك. أسهل طريقة هي تعيين نفس القيمة كـ N8N_ENCRYPTION_KEY على SIT (في بيئة compose/run الخاصة بك)، ثم يشترك كلاهما في المفتاح وتُفك تشفير بيانات الاعتماد المستوردة. تعيينها صراحةً على كلا الجانبين أفضل من الاعتماد على الملف المولد تلقائيًا على أي حال.
مرحباً @Mohamed8، طريقة @achamm في استخدام CLI هي الحل الصحيح لما لديك الآن. هناك شيء واحد يستحق النظر فيه على المدى الطويل، بما أن هذا يبدو أنه ترقية متكررة من dev إلى SIT في خط أنابيب منتج حقيقي، فإن n8n يدعم التحكم في الإصدارات عبر Git (Settings → Source Control، متاح في خطط معينة) الذي يحول هذا إلى تدفق بأسلوب CI/CD مناسب: ادفع سير العمل من dev إلى مستودع Git، ثم اسحب/انشر إلى SIT تلقائياً. كما أنه ينسخ سير العمل الخاص بك بشكل صحيح، لذا تحصل على diffs والعودة للإصدار السابق مجاناً بدلاً من الاستيراد/التصدير اليدوي في كل مرة.
إذا لم يكن التحكم في الإصدارات المستند إلى Git متاحاً في خطتك/إصدارك، فإن استيراد/تصدير CLI من @achamm هو المعادل اليدوي الصحيح، لكن من المفيد معرفة أن الخيار المؤتمت موجود إذا أصبحت هذه خطوة متكررة في خط الأنابيب بدلاً من مجرد هجرة لمرة واحدة.
أواجه مشكلة عندما أحاول استيراد سير العمل الخاص بي إلى بيئتي الجديدة.
أتلقى رسالة خطأ
Active version not found for workflow
Error: Active version not found for workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:248:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Could not remove webhooks of workflow "0YdMxcy7MAjVkwy2" because of error: "Active version not found for workflow"
Could not find workflow
Error: Could not find workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:244:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
نظراً لأن سير العمل الخاص بي يحتوي على مشغلات webhook وبعضها نشط وإصدار n8n الخاص بي هو 2.1.4
هل لديك أي فكرة؟
@ShawnWilliams @achamm
@Mohamed8 هذا هو الاستيراد الذي يحاول إدارة حالة النشاط للسير العملية، الإصدار الأحدث من n8n يتتبع السير العملية النشطة بواسطة معرّف الإصدار، واستيراد سير عملية نشطة التي سجل الإصدار النشط فيها غير موجود بعد على SIT يجعل clearWebhooks يفشل مع ذلك. الحل الأنظف هو إحضارها غير نشطة، إلغاء تنشيط السير العملية على dev قبل التصدير حتى تُستورد كـ active:false، ثم تنشيطها على SIT بعد تحميلها. وإذا ترك التشغيل الفاشل نسخاً نصفية مستوردة عالقة نشطة على SIT، ألغِ تنشيطها أو احذفها أولاً حتى لا يحاول الاستيراد التالي مسح webhooks لها.
هل هناك طريقة لتفعيلها/تعطيلها باستخدام سطر الأوامر؟
@Mohamed8 نعم، أمر n8n update:workflow يفعل ذلك:
docker exec -u node <container> n8n update:workflow --all --active=false
غيّر --active=true لتفعيل، أو استخدم --id= بدلاً من --all للاستهداف على واحد. إذاً سيرتك تصبح: إلغاء التفعيل على dev، ثم تصدير، ثم استيراد إلى SIT، ثم تشغيله باستخدام --active=true على SIT. إذا كنت لا تريد أن يذهب dev بلا اتصال، فقط قم بإلغاء تفعيل النسخ العالقة على SIT باستخدام --all --active=false، ثم أعد الاستيراد، ثم أعد تفعيلها هناك.
شكراً لك كثيراً على مساعدتك. @achamm
عندما أحاول نشر واحداً تلو الآخر، يظهر لي خطأ
Publishing workflow with ID: Error tracking disabled because this release is older than 6 weeks. (current version)
Error updating database. See log messages for details.
GOT ERROR
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Error: Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
at WorkflowRepository.publishVersion (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/
+db@file+packages+
+db_@opentelemetry+api@1.9.0_@opentelemetry+sdk-trace-base@1._ab22bba05a964211b9fe14bf4b841570/node_modules/
/db/src/repositories/workflow.repository.ts:894:11)
at PublishWorkflowCommand.run (/usr/local/lib/node_modules/n8n/src/commands/publish/workflow.ts:43:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Publishing 0YdMxcy7MAjVkwy2
Error tracking disabled because this release is older than 6 weeks.
Publishing workflow with ID: 0YdMxcy7MAjVkwy2 (current version)
Error updating database. See log messages for details.
وأيضاً عندما أحاول نشره من الواجهة، يقول لم يتم نشر سير العمل:
الإصدار غير موجود
@Mohamed8 لا تفعل ذلك واحداً تلو الآخر، مشكلة النشر حسب المعرّف هي التي تسبب الاختناق، معرّف سير العمل لا يتم حله لذا n8n لا يستطيع إيجاده. فقط قم بتشغيل تفعيل المجموعة:
docker exec -u node <container> n8n update:workflow --all --active=true
هذا يفعلها جميعاً في مرة واحدة دون الحاجة لتمرير معرّفات فردية. إذا حتى --all أعطى خطأ، فمن المحتمل أن يكون هناك خصوصية في الإصدار الذي أنت عليه (هذا السطر “6 أسابيع” يعني أنه إصدار أقدم)، وتحديث إصدار n8n الحالي يستحق المحاولة.
نصيحة تصدير/استيراد واجهة سطر الأوامر هي الأساس الصحيح. إذا كان لديك الكثير من سير العمل، فسأتعامل أيضاً مع dev → SIT كعملية إصدار بدلاً من عملية نسخ بسيطة.
النقاط التي أود إضافتها:
- احتفظ بالتصديرات في نظام التحكم بالإصدارات حتى تعرف ما تغيّر بين الترقيات.
- افصل هيكل سير العمل عن القيم الخاصة بالبيئة.
- لا تنقل بشكل أعمى بيانات اعتماد الإنتاج ما لم يكن لديك نموذج ملكية بيانات اعتماد واضح.
- قم بتشغيل فحوصات الدخان بعد الاستيراد لسير العمل الذي يهمك.
- سجّل سير العمل الذي تم ترقيته وما فشل وما يحتاج إلى متابعة يدوية.
- احتفظ بمسار استرجاع، حتى لو كان مجرد إعادة استيراد آخر تصدير معروف صحيح.
خطوة النسخ عادة ليست ما يسبب المشاكل لاحقاً. الجزء المؤلم هو عندما لا يعرف أحد أي بيئة تحتوي على أي إصدار، أو ما إذا تم اختبار SIT فعلاً، أو أي سير عمل انقطع بعد النقل. يصبح سجل الترقية مهماً جداً بمجرد أن يصبح سير العمل موجهاً للعملاء.
@achamm لكن في كل مرة أستخدم
docker exec -u node n8n update:workflow --all --active=true
يظهر
⚠️ WARNING: The "update:workflow" command is deprecated.
Workflow publishing via "update:workflow --all" is no longer supported.
Please publish workflows individually using: publish:workflow --id=<workflow-id>
@Mohamed8 نعم --all تم إيقاف دعمه والآلية الجديدة publish:workflow هي حيث واجهت خطأ الإصدار سابقًا، لذا تخطَّ CLI publish واستخدم REST API العام بدلاً منه، فلديه نقطة نهاية activate مخصصة تتجاوز إدارة الإصدارات بالكامل:
POST /api/v1/workflows/{id}/activate
أنشئ مفتاح API في Settings > n8n API، اسرد مسارات العمل لديك باستخدام GET /api/v1/workflows للحصول على المعرّفات، ثم كرّر استدعاء activate على كل منها. هذا هو الجعل بدفعة واحدة دون لمس أمر publish المعطّل.
@achamm هل يمكن الاستعلام عن معرّفات workflow من sqlite ثم حلقة عليها كبديل؟
@Mohamed8 أيه، قراءة المعرفات من sqlite تعمل بشكل ممتاز، الجدول هو workflow_entity لذلك SELECT id FROM workflow_entity تحصل على القائمة (API /api/v1/workflows تفعل نفس الشيء وليست مرتبطة بمخطط الـ db، لكن كلاهما يعمل). فقط اجعلها للقراءة فقط، ما تفعلش تفعيل بكتابة active=1 مباشرة في sqlite، لأن ده بيتجاوز الـ trigger/webhook registration اللي n8n بتعمله عند التفعيل وده بالضبط اللي بيخلي الـ workflows في الحالة active-version المكسورة دي. اسحب المعرفات بأي طريقة تشوفها مناسبة، بس شغّل التفعيل الفعلي من خلال API endpoint بتاعة حتى n8n تربط الـ triggers بشكل صحيح.
شكراً على مساعدتك @achamm. هل تعتقد أن نسخ مجلد n8n من DEV للاستخدام في SIT سيحافظ على معرّفات بيانات الاعتماد والعُقد بشكل صحيح؟
أرى أن جميع التفاصيل مخزنة في SQLite والذي يوجد في مجلد n8n.
@Mohamed8 أيوه، استنساخ الحجم كاملاً يشتغل وهو الأنظف للحفاظ على كل حاجة متصلة — إنه نسخة بايت-بايت من نفس قاعدة بيانات sqlite، فرقم بيانات الاعتماد والمعرّفات والمراجع بتاعة الـ nodes كلها تقعد متطابقة، ما في حاجة تحتاج إعادة ربط. مفتاح التشفير بيروح معاك كمان لأنه بداخل .n8n/config جوّة الحجم بتاعك، فبيانات الاعتماد تتفكك على الـ SIT، بس بلاش تحط N8N_ENCRYPTION_KEY env var مختلف على الـ SIT لأنه بتحصل تضارب.
فيه حاجتين محرجتين بس: إنه overwrite كامل، بيشيل كل حاجة على الـ SIT ويشيل معاه الإعدادات الخاصة بالـ DEV (الـ urls، webhook base، قيم بيانات الاعتماد بتاعة dev-vs-prod)، فهو تمام التمام لو الـ SIT مفروض يكون نسخة من الـ DEV، أقل كويس لو الـ SIT محتاج إعدادات خاصة به. وقف الـ n8n قبل ما تنسخ ملف sqlite، النسخ وهو شغال بيمكن يعطبه، أو استخدم .backup بتاع sqlite علشان تحصل على snapshot نظيف. لو الـ SIT محتاج إعدادات خاصة، الـ export/import الانتقائي بتاعه بيقعد الخيار الأحسن.