كيفية تشغيل سيرفر وهمي ذاتي الاستضافة على شبكتك الداخلية باستخدام Apidog

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

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

زر

ما هو برنامج التشغيل المستضاف ذاتيًا

إن برنامج تشغيل Apidog المستضاف ذاتيًا هو برنامج آلي تستضيفه على خادم مستقل. يُطلق عليه رسميًا "برنامج التشغيل العام"، ويقوم بثلاث مهام: تشغيل الاختبارات الآلية المجدولة، واستيراد وثائق API، وإرجاع الاستجابات الوهمية. هذه المهمة الثالثة هي محور هذا المقال.

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

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

حركة المرور الصادرة إلى المضيفين الخارجيين محظورة أو تخضع لتدقيق شديد.
تتطلب سياسة الامتثال بقاء بيانات الطلب على البنية التحتية الداخلية.
البيئة معزولة هوائيًا ولا يمكنها الوصول إلى نقطة نهاية سحابية على الإطلاق.
تريد قياس زمن انتقال الوهم على شبكتك المحلية (LAN)، وليس عبر الإنترنت العام.

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

ملاحظة حول الخطط والأذونات. لا تذكر وثائق Apidog بوابة صريحة بين المجاني والمدفوع لبرنامج التشغيل العام أو للوهم المستضاف ذاتيًا، ولا تسرد أي أرقام تسعير له، لذلك لن يخترع هذا الدليل أيًا منها. ما يتطلبه الإعداد هو إذن مسؤول الفريق أو المشروع، لأن نشر برنامج التشغيل يحدث داخل "موارد الفريق" (Team Resources)، ويمكن للمسؤولين فقط فتح تلك الإعدادات. إذا لم تتمكن من رؤية لوحة الموارد (Resources)، فهذا هو السبب.

ما تحتاجه قبل البدء

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

docker --version

تحتاج أيضًا إلى مكان لتشغيله: جهاز يعمل بنظام Linux أو macOS أو Windows يمكن لعملاء Apidog لفريقك وخدمة Apidog الوصول إليه. في الشبكة الداخلية، يعني هذا عادةً خادمًا داخليًا بعنوان IP ثابت أو اسم مضيف. هذه هي قائمة المتطلبات الأساسية بأكملها: Docker، مضيف، وحقوق المسؤول على الفريق. كل شيء آخر تقوم بتكوينه داخل Apidog نفسه.

نشر برنامج التشغيل العام

يتم إنشاء أمر النشر لك من داخل Apidog، ويحمل رمزًا مميزًا، لذلك لا تكتبه يدويًا. إليك سير العمل.

إنشاء الأمر

افتح صفحة Apidog الرئيسية، حدد فريقك، ثم انقر على "الموارد" (Resources) في الشريط الجانبي الأيمن واختر "نشر برنامج التشغيل العام" (Deploy General Runner). تظهر نافذة منبثقة حيث تقوم بتعيين بعض الأشياء:

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

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

تشغيله على الخادم

الصق الأمر في طرفية الخادم الخاص بك. يبدأ التثبيت تلقائيًا ويسحب الصورة. يبدو الأمر النهائي تقريبًا كالتالي (سيختلف الأمر الخاص بك، وسيتضمن الرمز المميز الحقيقي):

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

يجب أن ترى حاوية برنامج التشغيل مدرجة مع تعيين المنفذ الخاص بها. يعرض عميل Docker مثل Docker Desktop نفس الشيء إذا كنت تفضل استخدام واجهة المستخدم الرسومية.

تأكيد تسجيله

بالعودة إلى Apidog، انتقل إلى "موارد الفريق" (Team Resources) وافتح "برنامج التشغيل العام" (General Runner). انقر على زر التحديث. يجب أن يظهر برنامج التشغيل الآن على أنه منشور بحالة "بدأ" (Started). إذا لم يظهر في البداية، فإن زر التحديث هو الحل؛ امنحه لحظة وانقر مرة أخرى.

تتضمن حالة برنامج التشغيل ثلاث حالات تستحق المعرفة:

بدأ (Started): ممكّن، يتواصل مع Apidog، يتعامل مع المهام. هذه هي الحالة التي تريدها.
متوقف (Stopped): قام شخص ما بإيقافه يدويًا في Apidog. يبقى منشورًا ولكنه لن يعالج المهام.
غير متصل (Offline): فقد اتصاله بـ Apidog، لذلك لا يمكنه معالجة أي شيء. تحقق من الحاوية ومسار الشبكة.

تشغيل Runner Mock

نشر برنامج التشغيل يمنحك الوكيل. خطوة أخرى توجه حركة مرور الوهم الخاصة بك إليه.

في "موارد الفريق" (Team Resources)، افتح "برنامج التشغيل العام" (General Runner) وابحث عن حقل "مضيف الخادم" (Server Host). أدخل العنوان حيث يمكن الوصول إلى برنامج التشغيل الخاص بك. في إعداد HTTP عادي، يكون هذا هو المضيف والمنفذ الذي كشفته، مثل http://127.0.0.1:80 لاختبار محلي أو http://runner.internal.example.com:80 لمضيف شبكة داخلية مشتركة. خلف وكيل إنهاء TLS، يبدو مثل https://runner.example.com:443. المزيد عن HTTPS بعد قليل.

بمجرد تعيين "مضيف الخادم" (Server Host)، يقوم Apidog بتوصيل بيئة Runner Mock لمشروعك تلقائيًا. تحقق من ذلك: افتح المشروع، انتقل إلى "إدارة البيئة" (Environment Management)، وتأكد من أن Runner Mock يظهر الآن في قائمة البيئات. لم تقم بإنشائه يدويًا؛ تعيين "مضيف الخادم" (Server Host) هو ما جعله يظهر.

إرسال طلب عبر الوهم المستضاف ذاتيًا

الآن استخدمه. لنفترض أن لديك نقطة نهاية GET /orders/{orderId} في مشروع لواجهة برمجة تطبيقات لإدارة الطلبات الداخلية. افتح نقطة النهاية هذه، ثم في القائمة المنسدلة للبيئة في الأعلى، حدد Runner Mock بدلاً من البيئة السحابية. أرسل الطلب.

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

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"
}

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

HTTPS، تركيبات البيانات، وتفاصيل أخرى واقعية

تشغيل اختبار على http://127.0.0.1 سهل. يحتوي النشر المشترك على الشبكة الداخلية على بعض الجوانب الحادة التي تستحق المعرفة قبل طرحه للفريق.

HTTPS يحتاج إلى وكيل عكسي

لا يحتوي برنامج التشغيل على دعم مدمج لشهادات HTTPS ولا يوفر شهادات تلقائيًا. لن يقوم بجلب أو إدارة شهادة TLS لك. إذا كنت بحاجة إلى https://، قم بإنهاء TLS عند وكيل عكسي أمام برنامج التشغيل، على سبيل المثال Nginx الذي يحمل شهادتك، ثم وجه "مضيف الخادم" (Server Host) إلى عنوان URL الخاص بالوكيل بـ HTTPS. بدون وكيل، التزم بـ http://host:port. لا تعين "مضيف الخادم" (Server Host) إلى https:// وتتوقع من برنامج التشغيل الإجابة على TLS مباشرة؛ لا يمكنه ذلك.

تُظهر كتلة Nginx الدنيا التي تعمل أمام برنامج تشغيل على المنفذ 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;
    }
}

ثم يصبح "مضيف الخادم" (Server Host) https://runner.example.com:443. يعد دليل MDN لـ HTTPS مرجعًا جيدًا إذا كان إنهاء TLS جديدًا على فريقك.

تركيبات الملفات خاصة بالمسار

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

تذهب البرامج الخارجية إلى /app/external-programs/.
تذهب تهيئة اتصال قاعدة البيانات إلى /app/database/database-connections.json.
تذهب شهادات عميل SSL إلى /app/ssl/ssl-client-cert-list.json.

قم بتوصيل هذه عبر تركيبات -v بحيث تبقى بعد إعادة التشغيل.

سلوك إعادة النشر والترقية

عندما يتم شحن إصدار جديد من برنامج التشغيل، سترى خيار "ترقية" (Upgrade)، وتحت "المزيد من الإجراءات" (More Actions) يمكنك "إعادة النشر" (Redeploy). كلاهما يوقف الحاوية قيد التشغيل بينما يتم تشغيل الحاوية الجديدة. الجزء المطمئن: لا تتأثر المهام المجدولة الحالية في عميل Apidog بإعادة النشر أو الترقية، لذا فإنك تقاطع الخدمة المباشرة فقط لحظة إعادة تشغيل الحاوية، ولا تفقد التكوين.

أتمتة سير العمل باستخدام Apidog CLI

إليك الفرق الذي يجنب الارتباك: برنامج التشغيل هو وكيل طويل الأمد يمكنه تقديم الأوهام وتشغيل المهام المجدولة، بينما Apidog CLI هو برنامج تشغيل اختبار أحادي الغرض لـ CI. إنهما أدوات مختلفة. لا يمكن لـ CLI تقديم، بدء، أو استضافة خادم وهمي. لا يوجد أمر apidog run mock ولا apidog mock serve. يقوم أمر apidog run الخاص بـ CLI بتنفيذ سيناريوهات الاختبار، مجلدات سيناريوهات الاختبار، ومجموعات الاختبار، ومجموعة أوامر mock الخاصة به تقوم فقط بعمليات CRUD على توقعات الوهم كبيانات. تقديم الوهم هو وظيفة برنامج التشغيل، وليس وظيفة CLI أبدًا.

لذلك، يتناسب الاثنان معًا على النحو التالي: يمكن لـ CLI ووكلاء ترميز الذكاء الاصطناعي مثل Cursor و Claude Code و Codex إنشاء وتحديث نقاط النهاية والمخططات في مشروعك، مما يحافظ على دقة إخراج الوهم مع تطور المواصفات. بمجرد أن يفتح الوهم المستضاف ذاتيًا العمل الأمامي، يتم تشغيل سيناريوهات الاختبار لنفس المشروع بشكل تلقائي في CI بأمر واحد، مما يؤكد صحة الواجهة الخلفية الحقيقية مقابل العقد الذي وصفه الوهم:

apidog run -t <scenario_id> -e <env_id> -r html,cli

يقوم هذا الأمر الواحد بتشغيل سيناريوهاتك مقابل الواجهة الخلفية المباشرة ويكتب تقريرًا بتنسيق HTML بالإضافة إلى تقرير CLI. يتم التثبيت عن طريق npm install -g apidog-cli على Node.js v16 أو أحدث؛ يغطي دليل تثبيت Apidog CLI إعداد apidog login والرمز المميز. لجعل هذا الاختبار يعمل عند كل عملية دفع (push)، قم بتوصيله بخط الأنابيب الخاص بك باستخدام دليل Apidog CLI CI/CD. يشرح المقال حول وهم APIs من CLI بالضبط لماذا تدير الطرفية تعريفات الوهم ولكنها لا تستضيفها.

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

هل أحتاج إلى برنامج التشغيل المستضاف ذاتيًا إذا كان فريقي يستطيع الوصول إلى الإنترنت؟

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

هل يمكن لـ Apidog CLI بدء خادم وهمي مستضاف ذاتيًا؟

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

هل يدعم برنامج التشغيل HTTPS من تلقاء نفسه؟

لا يشحن شهادات أو يوفرها تلقائيًا. ضع وكيلًا عكسيًا مثل Nginx أمامه لإنهاء TLS، ثم وجه "مضيف الخادم" (Server Host) إلى عنوان URL الخاص بالوكيل بـ https://. بدون وكيل، استخدم http://host:port.

لماذا لا يظهر برنامج التشغيل الخاص بي بعد تشغيل الأمر؟

افتح "موارد الفريق" (Team Resources)، وانتقل إلى "برنامج التشغيل العام" (General Runner)، وانقر على زر التحديث. قد يتأخر التسجيل للحظة. إذا لم يظهر بعد، تأكد من أن الحاوية قيد التشغيل باستخدام docker ps وأن المضيف يمكن الوصول إليه من Apidog. تعني حالة "غير متصل" (Offline) أن الاتصال قد انقطع؛ "بدأ" (Started) هي الحالة التي تريدها.

هل يمكن لفرق متعددة مشاركة برنامج تشغيل واحد لخدمة وهمية عالمية؟

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

الخلاصة

يحافظ الوهم المستضاف ذاتيًا باستخدام برنامج التشغيل العام على بيانات طلباتك على البنية التحتية التي تتحكم فيها بينما يظل تصميم الوهم الخاص بك في مكانه دائمًا، في مشروع Apidog الخاص بك. تقوم بنشر حاوية Docker واحدة، وتعيين "مضيف الخادم" (Server Host)، وتقوم بيئة Runner Mock بالباقي. استخدمه عندما تكون السحابة محظورة، والتزم بوهم السحابة عندما لا تكون كذلك. هل أنت مستعد لتشغيل الأوهام على شبكتك الخاصة؟ قم بتنزيل Apidog، انشر برنامج تشغيل، وقدم أول استجابة Runner Mock دون أن تغادر حزمة واحدة شبكتك الداخلية.