كيفية إعداد رانر Apidog المستضاف ذاتيًا لاختبارات API المجدولة

إن مجموعة اختبارات واجهة برمجة التطبيقات (API) الخاصة بك لا تكون مفيدة إلا إذا كانت تعمل وفق جدول زمني يمكنك الوثوق به. فالمجموعة التي تشغلها يدوياً تلتقط الأخطاء عندما تتذكر النقر. أما التشغيل الليلي على جهاز تتحكم فيه، فيلتقطها في الساعة 2 صباحاً، قبل أن يكتشفها المستخدمون. هذه هي وظيفة مشغل Apidog: خدمة ذاتية النشر، مثبتة باستخدام Docker على خادمك الخاص، والتي تنفذ سيناريوهات الاختبار المجدولة التي تبنيها في Apidog وتدفع التقارير مرة أخرى إلى مشروعك.

لقد تناولنا الطرق الثلاث لجدولة الاختبارات في Apidog في دليلنا لجدولة اختبارات API الآلية. تقارن تلك المقالة بين التنفيذ السحابي والمشغل وواجهة سطر الأوامر (CLI) على مستوى عالٍ. هذه المقالة هي الغوص العميق في مسار المشغل: متى تحتاج إليه، وكيفية نشره، وكيفية توجيه مهمة مجدولة إليه، وكيف يقارن بالبدائل.

متى تحتاج إلى مشغل اختبار مستضاف ذاتياً

يعد التنفيذ السحابي ملائماً، ولكن هناك ثلاث حالات تدفع الفرق نحو مشغل اختبار مستضاف ذاتياً.

تعيش واجهات برمجة التطبيقات (APIs) الخاصة بك على شبكة خاصة. بيئة التشغيل المرحلي على https://orders.staging.internal:8443 لا يتم حلها من الإنترنت العام. لا يمكن لأي خدمة سحابية الوصول إليها. يمكن لمشغل منتشر داخل شبكة VPC أو شبكة مكتبك أن يفعل ذلك، لأنه يرسل الطلبات من حيث يتواجد. هذا هو نفس المنطق وراء تشغيل خادم وهمي مستضاف ذاتياً على شبكتك الداخلية: يجب أن يعيش عبء العمل حيث يوجد الوصول إلى الشبكة.

الامتثال يحافظ على حركة المرور داخل الشركة. إذا كان فريق الأمان لديك يحظر إرسال حمولات الاختبار التي تحتوي على بيانات عملاء واقعية خارج البنية التحتية الخاصة بك، فإن التنفيذ السحابي يكون مستبعداً. باستخدام المشغل، تنشأ الطلبات من خادمك وتصل إلى واجهات برمجة التطبيقات الخاصة بك مباشرةً. فقط تقارير الاختبار هي التي تنتقل مرة أخرى إلى Apidog.

تريد جداول زمنية مستقرة ومستقلة عن أي كمبيوتر محمول. تتوقف الاختبارات المجدولة داخل تطبيق سطح المكتب عند إغلاق التطبيق. وتُشغل الاختبارات المربوطة بـ CI عندما يدفع أحدهم تعليمة برمجية. لا يمنحك أي منهما "كل 6 ساعات، للأبد، مهما حدث". المشغل على خادم يعمل باستمرار يفعل ذلك بالضبط.

إذا لم ينطبق أي من هذه الشروط، فمن المحتمل أنك لا تحتاج إلى مشغل. ستفي عمليات التشغيل اليدوية في التطبيق أو واجهة سطر الأوامر (CLI) ضمن CI بالغرض.

ما هو مشغل Apidog

إن المشغل المستضاف ذاتيًا هو خدمة أتمتة تنشرها على خادم مستقل. بمجرد اتصاله بفريقك، يمكنه:

• تشغيل مهام الاختبار الآلية المجدولة المبنية من سيناريوهات اختبار Apidog الخاصة بك
• استيراد توثيق API بجدول زمني متكرر
• تقديم استجابات وهمية مستضافة ذاتيًا

يأتي بنطاقين. مشغل عام على مستوى الفريق ينتمي إلى فريق واحد. يمكن مشاركة مشغل على مستوى المؤسسة عبر جميع المشاريع في فرق مؤسستك. يعمل النشر بنفس الطريقة لكليهما.

النموذج الذهني الرئيسي: المشغل هو عامل، وليس نسخة من مشروعك. تبقى سيناريوهات الاختبار والبيئات والتأكيدات الخاصة بك في Apidog. يتلقى المشغل المهام، وينفذها مقابل أي شبكة يمكنه الوصول إليها، ويرفع النتائج. لا يقوم أعضاء الفريق مطلقًا بالاتصال به عبر SSH لمعرفة ما حدث؛ بل يفتحون سجل التشغيل في التطبيق.

المتطلبات الأساسية

تحقق من هذه المتطلبات قبل النشر. تأتي مباشرة من وثائق بيئة نشر المشغل.

الأجهزة. الحد الأدنى 2 نواة معالج و 4 جيجابايت من ذاكرة الوصول العشوائي (RAM)؛ يوصى بـ 4+ نوى و 8 جيجابايت إذا كنت ستشغل مهامًا متزامنة أو كان لديك فريق أكبر. خصص 30 جيجابايت على الأقل من القرص للسجلات وملفات الاختبار، و 50 جيجابايت لتكون مرتاحًا.

Docker. يحتاج المضيف إلى Docker إصدار 20.10.0 أو أحدث، ويوصى بالإصدار 20.10.13. إذا كان الخادم جديدًا، فاتبع دليل تثبيت Docker Engine الرسمي لتوزيعك أولاً.

الشبكة. يتصل المشغل بخادم Apidog عبر HTTPS على المنفذ 443 ويحافظ على اتصال WebSocket (WSS) مفتوحًا لإرسال المهام في الوقت الفعلي. يحتاج أيضًا إلى وصول صادر إلى نطاقات AWS المستخدمة لتحميل التقارير، بالإضافة إلى، بالطبع، الوصول الشبكي إلى كل واجهة برمجة تطبيقات تستهدفها اختباراتك. لاحظ الاتجاه هنا: المشغل يجري المكالمات الصادرة. لا تحتاج إلى فتح منافذ واردة لكي يصل إليها Apidog، مما يجعل محادثات جدار الحماية مع فريق العمليات لديك قصيرة.

الأذونات والخطة. نشر المشغل هو إجراء مورد للفريق، لذا ستحتاج إلى دور الفريق المناسب. يعتمد عدد تشغيل المهام المجدولة التي تحصل عليها على مستوى اشتراكك؛ تحقق من صفحة أسعار Apidog للاطلاع على الحدود الحالية لكل خطة.

الخطوة 1: الحصول على أمر النشر من Apidog

يقوم Apidog بإنشاء أمر نشر Docker لك، مع تضمين رمز المصادقة. لا تقم بنسخ واحد من مدونة، بما في ذلك هذه؛ الرمز هو ما يربط الحاوية بفريقك.

1. افتح Apidog وانتقل إلى صفحة Apidog الرئيسية. إذا لم يكن لديك حساب بعد، قم بتنزيل Apidog مجانًا للمتابعة.
2. حدد الفريق الذي يجب أن ينتمي إليه المشغل.
3. انقر على الموارد (Resources) في الجانب الأيمن.
4. انقر على نشر المشغل العام (Deploy General Runner).

تظهر نافذة منبثقة تعرض أمر النشر الكامل. انسخه فورًا: يحتوي على رمز حساس ويُعرض مرة واحدة فقط. تعامل معه كسر CI، وليس كقصاصة لويكي فريقك.

قبل النسخ، يتيح لك مربع الحوار تخصيص الأمر:

• نظام تشغيل الخادم (Server OS): Linux أو macOS أو Windows.
• متغير الصورة (Image variant): يأتي الإصدار العام (General) مع Node.js 18 و Java 21 و Python 3 و PHP 8، بحيث تعمل نصوص المعالجة المسبقة/اللاحقة بهذه اللغات دون إعداد إضافي. يتضمن الإصدار المختصر (Slim) Node.js 18 فقط ويُسحب بشكل أسرع. يسمح لك الإصدار المخصص (Custom) بتوفير Dockerfile الخاص بك عندما تعتمد الاختبارات على شهادات CA داخلية أو مكتبات غير عادية.
• المنفذ المكشوف (Exposed port): اربط منفذًا بـ -p (على سبيل المثال -p 80:4524) إذا كنت ستستخدم المشغل أيضًا للاستجابات الوهمية المستضافة ذاتيًا.
• دليل البيانات المثبت (Mounted data directory): أضف تركيب وحدة تخزين -v إذا كانت سيناريوهات الاختبار الخاصة بك تقرأ ملفات البيانات المحلية، مثل مجموعات بيانات CSV للتشغيل المدفوع بالبيانات.

تغطي وثائق المشغل العام كل خيار بالتفصيل.

الخطوة 2: تشغيل الحاوية والتأكد من اتصالها

قم بتسجيل الدخول عبر SSH إلى الخادم المستهدف، والصق الأمر، ودع Docker يسحب الصورة ويبدأ الحاوية. ملاحظتان تشغيليتان تستحقان الضبط في اليوم الأول:

• مرر TZ كمتغير بيئة (على سبيل المثال TZ=Asia/Singapore) لكي يعني "كل يوم في الساعة 02:00" الساعة 02:00 الخاصة بك، وليس الافتراضي للحاوية.
• بدءًا من الإصدار 2.2.5 للمشغل، تتضمن الصورة مستخدمًا غير جذري runner (UID/GID 10001). إذا كانت منصتك تفرض runAsNonRoot، اضبط سياق الأمان وفقًا لذلك وقم بتكوين أذونات وحدة التخزين مسبقًا، حيث لا يمكن لنقطة الدخول تغيير ملكية الأدلة في وضع غير جذري.

بالعودة إلى Apidog، يظهر المشغل تحت "موارد فريقك" بمجرد اكتمال تأكيد اتصال WebSocket، ويمكن لأعضاء الفريق تحديده عند إنشاء المهام. إذا لم يظهر في غضون دقيقة، تحقق من سجلات الحاوية باستخدام docker logs وتأكد من أن المضيف يمكنه الوصول إلى خادم Apidog على المنفذ 443؛ غالبًا ما يكون اتصال WSS المحظور هو السبب في الشبكات الشركات المقيدة.

يمكنك نشر عدة مشغلات في فريق واحد. غالبًا ما يحتفظ الفرق بمشغل واحد داخل شبكة VPC المرحلية وآخر مع وصول قراءة إلى الإنتاج، ثم يختارون مشغلًا لكل مهمة.

الخطوة 3: إنشاء مهمة مجدولة تستهدف المشغل

مع وجود المشغل متصلاً، أصبحت الجدولة نموذجاً، وليست نصاً برمجياً.

1. في مشروعك، افتح وحدة الاختبارات (Tests) وانقر على المهام المجدولة (Scheduled Tasks). تعيش المهام في هيكل مجلدات، لذا قم بتجميعها حسب الخدمة أو البيئة مع تزايد القائمة.
2. أنشئ مهمة وأعطها اسماً سيفهمه زميلك في غضون ستة أشهر: "اختبار دخاني لخدمة الطلبات، بيئة التشغيل المرحلي، كل 6 ساعات" أفضل من "اختبار1".
3. حدد سيناريو اختبار واحدًا أو أكثر. لكل سيناريو يمكنك تعيين البيئة، بيانات الاختبار، عدد التكرارات، التأخير بين الطلبات، وما إذا كنت تريد حفظ نصوص الطلب/الاستجابة.
4. عيّن البيئة ونطاق المتغيرات. يُوصى بتطبيق المتغيرات على جميع السيناريوهات داخل المهمة كحل وسط؛ نطاق المجلدات الشامل قوي ولكنه سهل التعثر فيه.
5. قم بتعيين دورة التشغيل (Run Cycle): كل أحد في الساعة 11 مساءً، كل 6 ساعات، أيًا كان ما يتناسب مع مدى سرعة حاجتك لمعرفة ما إذا كان هناك خطأ ما.
6. تحت يعمل على (Runs on)، اختر المشغل المستضاف ذاتيًا بالاسم.
7. تكوين الإشعارات. يمكنك التنبيه بعد كل تشغيل أو عند الفشل فقط. الفشل فقط هو الافتراضي السليم؛ قناة مليئة بعلامات الصح الخضراء تدرب الجميع على تجاهلها.

احفظها. من هذه النقطة، يتم تنفيذ الجدول الزمني على خادمك سواء كان تطبيق Apidog مفتوحًا أم لا.

الخطوة 4: قراءة تقارير التشغيل في Apidog

بعد كل عملية تشغيل، يقوم المشغل بتحميل النتائج إلى خادم Apidog تلقائيًا. افتح المهام المجدولة ← سجل التشغيل (Scheduled Tasks → Run History) في التطبيق لمشاهدة كل عملية تنفيذ: حالة النجاح/الفشل، نتائج كل سيناريو، حالات فشل التأكيد، والتوقيت.

هذه هي الميزة الهادئة للمشغل مقارنةً بإعداد cron-plus-scripts محلي. يتم التنفيذ على بنيتك التحتية، ولكن التقارير تصل إلى نفس مساحة العمل المشتركة حيث يتم تعريف الاختبارات. عندما يفشل تشغيل الساعة 02:00 يوم الثلاثاء، يرى مهندس ضمان الجودة الذي يحقق أي تأكيد فشل في أي خطوة، في السياق، دون البحث في الخادم عن ملفات السجل.

قم بإقران إشعارات الفشل بسجل التشغيل ولديك حلقة مراقبة: يتم إطلاق التنبيه، وافتح التقرير، وكرر الخطوة الفاشلة يدويًا في التطبيق مقابل نفس البيئة، وقم بالإصلاح، وانتظر التشغيل الأخضر التالي.

المشغل مقابل CLI مقابل السحابة: اختيار مسار التنفيذ

يمنحك Apidog ثلاث طرق لتنفيذ الاختبارات تتجاوز النقر اليدوي في التطبيق، وهي تحل مشكلات مختلفة. لقد كتبنا شرحًا كاملاً لمسار CI في دليل Apidog CLI GitHub Actions الخاص بنا، وتوضح المقارنة أدناه مكان كل منها.

المسارات تتكامل بدلاً من أن تتنافس. إعداد شائع: يقوم CLI بحماية كل عملية نشر في خط الأنابيب، بينما يقوم المشغل بتشغيل مجموعة اختبارات دخانية (smoke suite) كل ساعة مقابل بيئة التشغيل المرحلي (staging) وتراجع كامل ليلي (nightly full regression)، للتحقق من الفشل الناجم عن انحراف البنية التحتية وانتهاء صلاحية بيانات الاعتماد بدلاً من تغييرات التعليمات البرمجية.

تحذير واحد بشأن التوقيت: وفقًا لوثائق المهام المجدولة، تم تصميم المهام المجدولة للتشغيل على مشغل مستضاف ذاتيًا، مع إمكانية اختيار Apidog Cloud عند توفرها. إذا كنت بحاجة إلى تنفيذ مجدول اليوم ولا يمكنك انتظار توفر السحابة لخطتك، فإن المشغل هو المسار الموثوق به.

الأسئلة الشائعة

هل أحتاج إلى المشغل إذا كنت أستخدم بالفعل Apidog CLI في CI؟

يجيبون على أسئلة مختلفة. يخبرك CI "هل هذا التغيير عطل واجهة برمجة التطبيقات؟" وقت الدفع. يخبرك المشغل "هل واجهة برمجة التطبيقات تعمل بشكل جيد الآن؟" في دورة ثابتة، حيث يلتقط الأعطال الناتجة عن الرموز المميزة المنتهية الصلاحية، أو التبعيات الميتة، أو انحراف البنية التحتية دون وجود تعليق مرتبط. تعتمد العديد من الفرق كليهما؛ انظر دليل إعداد اختبار API الليلي الخاص بنا للنصف المجدول بواسطة CI من النمط.

هل يمكن للمشغل الوصول إلى واجهات برمجة التطبيقات (APIs) الداخلية؟

نعم، وهذا هو السبب الرئيسي لوجوده. يقوم المشغل بتقديم الطلبات من الجهاز الذي تم نشره عليه. ضعه داخل VPC أو شبكة مكتبك، ويمكنه اختبار المضيفين *.internal التي لا يمكن لأي خدمة سحابية حلها. يحتاج فقط إلى الوصول الصادر عبر HTTPS و WebSocket إلى خادم Apidog لتلقي المهام وتحميل التقارير.

ما هي الحد الأدنى لمواصفات الخادم؟

معالج ثنائي النواة، 4 جيجابايت من ذاكرة الوصول العشوائي (RAM)، 30 جيجابايت من مساحة القرص، و Docker 20.10.0 أو أحدث. للفرق التي تشغل مهام مجدولة متزامنة، انتقل إلى 4+ نوى و 8 جيجابايت. يمكن استخدام جهاز افتراضي صغير أو صندوق احتياطي في رف المكتب؛ القيد هو وقت التشغيل، وليس قوة المعالجة.

ما هي الخطة التي أحتاجها للمهام المجدولة على مشغل مستضاف ذاتيًا؟

تختلف حصص تشغيل المهام المجدولة حسب مستوى الاشتراك، لذا تحقق من الحدود الحالية على صفحة أسعار Apidog قبل التخطيط لجدول زمني عالي التردد. إذا كنت تقوم بتقييم خيارات التنفيذ عبر الأدوات، فإن مقارنة Apidog CLI مقابل Postman CLI الخاصة بنا تنظر في ما يتضمنه جانب مشغل الاختبار لكل منصة.