لا تستطيع بعض الفرق إرسال حركة مرور API إلى السحابة. قد يمنع جدار الحماية المكالمات الصادرة إلى خدمات الطرف الثالث، أو تفرض متطلبات الامتثال بقاء بيانات الطلب والاستجابة داخل البنية التحتية التي تتحكم بها، أو تكون البيئة معزولة هوائيًا بالكامل. في هذه الحالات، لا يكون استخدام عنوان وهمي مستضاف لدى طرف ثالث خيارًا، حتى لو كانت البيانات الوهمية نفسها غير حقيقية.
يعالج Apidog ذلك عبر برنامج تشغيل مستضاف ذاتيًا (Self-hosted Runner). بدل إرسال الطلبات إلى وهم Apidog السحابي، تشغّل برنامجًا صغيرًا على خادم تملكه ليعيد الاستجابات الوهمية من داخل شبكتك. يبقى تصميم API والوهم داخل مشروع Apidog، لكن عملية تقديم الاستجابات تنتقل إلى بنيتك التحتية. إذا كنت تحتاج إلى السياق الأوسع، راجع دليل خوادم وهم API المستضافة ذاتيًا ومواصفات OpenAPI التي تُبنى عليها هذه الأوهام.
ما هو برنامج التشغيل المستضاف ذاتيًا؟
برنامج تشغيل Apidog المستضاف ذاتيًا هو برنامج آلي تشغّله على خادم مستقل. يُسمى رسميًا برنامج التشغيل العام (General Runner)، ويمكنه:
- تشغيل الاختبارات الآلية المجدولة.
- استيراد وثائق API.
- إرجاع الاستجابات الوهمية.
يركز هذا الدليل على المهمة الثالثة: تقديم استجابات وهمية من داخل شبكتك.
بعد نشر برنامج تشغيل عام وتحديد مضيفه، يضيف Apidog تلقائيًا بيئة باسم Runner Mock إلى مشروعك. عند إرسال طلب من خلال هذه البيئة، يعيد برنامج التشغيل المستضاف ذاتيًا الاستجابة الوهمية بدلًا من خدمة Apidog السحابية.
استخدم هذا النهج عندما ينطبق أحد السيناريوهات التالية:
- حركة المرور الصادرة إلى المضيفين الخارجيين محظورة أو تخضع لتدقيق صارم.
- تتطلب سياسة الامتثال بقاء بيانات الطلبات داخل البنية التحتية الداخلية.
- البيئة معزولة هوائيًا ولا يمكنها الوصول إلى نقطة نهاية سحابية.
- تريد قياس زمن استجابة الوهم داخل الشبكة المحلية بدل الإنترنت العام.
أما إذا كان فريقك يستطيع استخدام الإنترنت ولا توجد قيود على البيانات، فإن وهم Apidog السحابي أبسط لأنه لا يتطلب خادمًا أو حاوية Docker إضافية.
تحتاج إلى صلاحية مسؤول الفريق أو المشروع لإعداد برنامج التشغيل، لأن النشر يتم من قسم موارد الفريق (Team Resources). إذا لم تظهر لك لوحة الموارد، فتحقق من أذوناتك.
ما تحتاجه قبل البدء
برنامج التشغيل يُشحن كحاوية Docker. ثبّت Docker بإصدار 20.10.0 على الأقل، ويُوصى بالإصدار 20.10.13 أو أحدث.
تحقق من الإصدار:
docker --version
ستحتاج كذلك إلى:
- خادم Linux أو macOS أو Windows.
- عنوان IP ثابت أو اسم مضيف يمكن الوصول إليه داخل الشبكة.
- وصول إداري إلى فريق Apidog.
- اتصال يسمح لعملاء Apidog وخدمة Apidog بالتواصل مع برنامج التشغيل وفق إعداد شبكتك.
نشر برنامج التشغيل العام
لا تكتب أمر النشر يدويًا. أنشئه من واجهة Apidog، لأنه يتضمن رمزًا مميزًا خاصًا بفريقك.
1. إنشاء أمر النشر
من صفحة Apidog:
- اختر فريقك.
- افتح الموارد (Resources) من الشريط الجانبي.
- اختر نشر برنامج التشغيل العام (Deploy General Runner).
- اضبط الخيارات التالية:
| الخيار | الاستخدام |
|---|---|
| نظام تشغيل الخادم | اختر Linux أو macOS أو Windows لتوليد أمر مناسب للمضيف. |
| صورة Docker | اختر General أو Slim أو Custom. |
| المنفذ المكشوف | يُمرر عبر -p، مثل -p 80:4524. |
| دليل البيانات المثبت | يُمرر عبر -v للحفاظ على البيانات بعد إعادة التشغيل. |
تتضمن صور Docker المتاحة:
- General: تحتوي مسبقًا على Node.js 18 وJava 21 وPython 3 وPHP 8.
- Slim: تحتوي على Node.js 18 فقط، وتناسب الحالات التي تحتاج فيها إلى صورة أصغر.
-
Custom: تتيح لك توفير
Dockerfileخاص بك عند الحاجة إلى أوقات تشغيل إضافية لبرامج الاختبار النصية.
انسخ الأمر فور ظهوره. يعرضه Apidog مرة واحدة فقط لأنه يتضمن الرمز المميز الخاص بك. إذا فقدته، أنشئ رمزًا جديدًا بدل محاولة استعادته.
2. تشغيل الحاوية على الخادم
الصق الأمر المولّد في طرفية الخادم. سيشبه التالي، مع اختلاف الرمز المميز والمسارات حسب إعدادك:
docker run -d \
--name apidog-runner \
-p 80:4524 \
-v /opt/apidog-runner/data:/app/data \
apidog/runner:latest \
--token <YOUR_GENERATED_TOKEN>
تحقق من عمل الحاوية:
docker ps
يجب أن تظهر حاوية برنامج التشغيل مع تعيين المنافذ الخاص بها.
3. تأكيد تسجيل برنامج التشغيل
ارجع إلى Apidog ثم:
- افتح موارد الفريق (Team Resources).
- اختر برنامج التشغيل العام (General Runner).
- انقر زر التحديث.
يجب أن يظهر البرنامج بحالة بدأ (Started).
تعني الحالات الرئيسية:
- بدأ (Started): البرنامج متصل بـ Apidog وجاهز لمعالجة المهام.
- متوقف (Stopped): تم إيقافه يدويًا من Apidog.
- غير متصل (Offline): فقد الاتصال بـ Apidog؛ تحقق من الحاوية وإعدادات الشبكة.
تشغيل Runner Mock
نشر الحاوية وحده لا يوجّه طلبات الوهم إليها. يجب تحديد عنوان الخادم.
من موارد الفريق > برنامج التشغيل العام:
- ابحث عن حقل مضيف الخادم (Server Host).
- أدخل عنوان برنامج التشغيل الذي يمكن الوصول إليه.
أمثلة:
http://127.0.0.1:80
للتشغيل المحلي، أو:
http://runner.internal.example.com:80
لخادم مشترك في الشبكة الداخلية، أو:
https://runner.example.com:443
عند استخدام وكيل عكسي ينهي TLS.
بعد حفظ مضيف الخادم، ينشئ Apidog بيئة Runner Mock تلقائيًا داخل المشروع. للتحقق:
- افتح المشروع.
- انتقل إلى إدارة البيئة (Environment Management).
- تأكد من ظهور
Runner Mockفي قائمة البيئات.
إرسال طلب عبر الوهم المستضاف ذاتيًا
افترض أن مشروعك يتضمن نقطة النهاية التالية:
GET /orders/{orderId}
لتجربتها:
- افتح نقطة النهاية في Apidog.
- اختر بيئة Runner Mock من قائمة البيئات.
- أرسل الطلب.
يمكنك أيضًا اختبار نقطة النهاية مباشرةً:
curl http://runner.internal.example.com:80/orders/10583
قد تحصل على استجابة مثل:
{
"orderId": 10583,
"customerEmail": "amelia.turner@example.com",
"status": "shipped",
"total": 148.5,
"currency": "USD",
"createdAt": "2026-07-14T09:32:11Z"
}
يولّد Apidog البيانات الوهمية اعتمادًا على المخطط وتعريفات الحقول. على سبيل المثال، يمكن لحقل باسم customerEmail أن ينتج قيمة بريد إلكتروني واقعية. راجع دليل التوليد التلقائي لبيانات وهمية واقعية باستخدام الوهم الذكي لمزيد من التفاصيل.
إذا احتجت إلى استجابة محددة لطلب معين، أضف توقعًا وهميًا (Mock Expectation) إلى نقطة النهاية. سيقدمه برنامج التشغيل بالطريقة نفسها التي يقدم بها وهم السحابة. تبقى مفاهيم الوهم API نفسها؛ الاختلاف الوحيد هو مكان استضافة الخدمة.
HTTPS، تركيبات البيانات، والترقيات
HTTPS يحتاج إلى وكيل عكسي
لا يدير برنامج التشغيل شهادات HTTPS تلقائيًا ولا يوفر دعم TLS مدمجًا. إذا احتجت إلى عنوان https://، ضع وكيلًا عكسيًا مثل Nginx أمام برنامج التشغيل.
مثال لإعداد Nginx ينهي TLS ويوجه الطلبات إلى برنامج التشغيل على المنفذ 4524:
server {
listen 443 ssl;
server_name runner.example.com;
ssl_certificate /etc/ssl/certs/runner.example.com.pem;
ssl_certificate_key /etc/ssl/private/runner.example.com.key;
location / {
proxy_pass http://127.0.0.1:4524;
proxy_set_header Host $host;
}
}
بعد ذلك، استخدم العنوان التالي في حقل مضيف الخادم:
https://runner.example.com:443
بدون وكيل عكسي، استخدم:
http://host:port
راجع دليل MDN لـ HTTPS إذا كان إعداد TLS جديدًا على فريقك.
تركيبات الملفات خاصة بالمسار
إذا احتاج الوهم أو الاختبارات إلى ملفات إضافية، ركّبها في المسارات التي يتوقعها برنامج التشغيل داخل الحاوية:
| النوع | المسار داخل الحاوية |
|---|---|
| البرامج الخارجية | /app/external-programs/ |
| إعدادات اتصال قاعدة البيانات | /app/database/database-connections.json |
| شهادات عميل SSL | /app/ssl/ssl-client-cert-list.json |
استخدم تركيبات Docker عبر -v لضمان بقاء هذه الملفات بعد إعادة تشغيل الحاوية.
إعادة النشر والترقية
عند توفر إصدار جديد، ستظهر خيارات:
- ترقية (Upgrade)
- إعادة النشر (Redeploy)
كلتا العمليتين توقفان الحاوية الحالية مؤقتًا ثم تشغّلان حاوية جديدة. لا تتأثر المهام المجدولة الموجودة في عميل Apidog، لكن قد يحدث انقطاع قصير في تقديم الاستجابات الوهمية أثناء إعادة تشغيل الحاوية.
أتمتة سير العمل باستخدام Apidog CLI
لا تخلط بين برنامج التشغيل وواجهة سطر الأوامر:
- برنامج التشغيل العام: خدمة طويلة الأمد تقدم الأوهام وتشغّل المهام المجدولة.
- Apidog CLI: أداة لتشغيل الاختبارات في CI وإدارة بيانات توقعات الوهم.
لا يستطيع CLI استضافة خادم وهمي أو تقديم طلبات الوهم. لا توجد أوامر مثل:
apidog run mock
أو:
apidog mock serve
يستخدم CLI الأمر apidog run لتنفيذ السيناريوهات ومجموعات الاختبار، بينما تُستخدم أوامر mock لإدارة توقعات الوهم كبيانات فقط.
بعد استخدام الوهم المستضاف ذاتيًا لتسهيل عمل الواجهة الأمامية، شغّل اختبارات العقد مقابل الواجهة الخلفية الحقيقية في CI:
apidog run -t <scenario_id> -e <env_id> -r html,cli
يشغّل الأمر السيناريو المحدد ويُنتج تقريرًا بصيغة HTML بالإضافة إلى مخرجات CLI.
لتثبيت CLI:
npm install -g apidog-cli
يتطلب ذلك Node.js v16 أو أحدث. راجع دليل تثبيت Apidog CLI لإعداد apidog login والرمز المميز، ثم اربطه بخط الأنابيب باستخدام دليل Apidog CLI CI/CD. يشرح دليل وهم APIs من CLI سبب إدارة CLI لتعريفات الوهم دون استضافتها.
الأسئلة الشائعة
هل أحتاج إلى برنامج تشغيل مستضاف ذاتيًا إذا كان فريقي يستطيع الوصول إلى الإنترنت؟
غالبًا لا. الوهم السحابي أبسط لأنه لا يحتاج إلى خادم أو Docker. اختر برنامج التشغيل عندما تكون حركة المرور الصادرة محظورة أو مدققة، أو عندما تفرض متطلبات الامتثال بقاء البيانات داخليًا، أو عندما تكون البيئة معزولة هوائيًا. للمقارنة، راجع دليل وهم Apidog السحابي.
هل يمكن لـ Apidog CLI تشغيل خادم وهمي مستضاف ذاتيًا؟
لا. ينفذ CLI الاختبارات عبر apidog run ويدير توقعات الوهم كبيانات. يقدم برنامج التشغيل العام أو وهم السحابة حركة المرور الوهمية، وليس CLI.
هل يدعم برنامج التشغيل HTTPS مباشرةً؟
لا. ضع وكيلًا عكسيًا مثل Nginx أمامه لإنهاء TLS، ثم استخدم عنوان الوكيل الذي يبدأ بـ https:// كمضيف للخادم. بدون وكيل، استخدم http://host:port.
لماذا لا يظهر برنامج التشغيل بعد تشغيل أمر Docker؟
اتبع هذا التسلسل:
- تحقق من الحاوية:
docker ps
- افتح موارد الفريق > برنامج التشغيل العام.
- انقر زر التحديث.
- تحقق من إمكانية الوصول الشبكي بين برنامج التشغيل وApidog.
تعني حالة غير متصل (Offline) أن الاتصال انقطع، بينما تعني بدأ (Started) أن الإعداد يعمل.
هل يمكن لفرق متعددة مشاركة برنامج تشغيل واحد؟
يسجل برنامج التشغيل ضمن الفريق الذي نُشر فيه، وتظهر بيئة Runner Mock لمشاريع هذا الفريق. إذا كنت تدير فرقًا موزعة، راجع دليل مشاركة بيئات الوهم عبر الفرق العالمية لتحديد عدد برامج التشغيل ومواقع نشرها.
الخلاصة
يحافظ الوهم المستضاف ذاتيًا باستخدام برنامج التشغيل العام على بيانات الطلبات داخل البنية التحتية التي تتحكم بها، بينما يبقى تصميم API والوهم في مشروع Apidog.
خطوات الإعداد العملية هي:
- ثبّت Docker على خادم داخلي.
- أنشئ أمر النشر من موارد الفريق.
- شغّل حاوية برنامج التشغيل.
- تحقق من ظهور حالة بدأ.
- اضبط مضيف الخادم.
- اختر بيئة Runner Mock وأرسل طلبك.
استخدم هذا الخيار عندما تمنع الشبكة أو متطلبات الامتثال استخدام السحابة، والتزم بالوهم السحابي عندما لا توجد هذه القيود. نزّل Apidog، وانشر برنامج تشغيل، وقدّم أول استجابة وهمية من داخل شبكتك.

Top comments (0)