วิธีติดตั้งและรัน Mock Server แบบ Self-Hosted บน Intranet ด้วย Apidog

บางทีมไม่สามารถส่งทราฟฟิกของตนไปยังคลาวด์ได้ บางทีคุณอาจอยู่หลังไฟร์วอลล์ขององค์กรที่บล็อกการโทรออกไปยังบริการของบุคคลที่สาม บางทีกฎการปฏิบัติตามข้อกำหนดระบุว่าข้อมูลคำขอและการตอบกลับจะต้องอยู่ในเครื่องที่คุณควบคุม บางทีสภาพแวดล้อมทั้งหมดถูกแยกขาดจากเครือข่ายภายนอก (air-gapped) และไม่มีอะไรออกจากอินทราเน็ตเลย ในกรณีเหล่านั้น URL จำลองที่โฮสต์บนโครงสร้างพื้นฐานของผู้อื่นจึงไม่สามารถเริ่มต้นได้ แม้ว่าข้อมูลจำลองนั้นจะเป็นของปลอมก็ตาม

Apidog จัดการปัญหานี้ด้วยรันเนอร์ที่โฮสต์ด้วยตนเอง (self-hosted runner) แทนที่จะให้คำขอของคุณส่งออกไปยัง Cloud Mock ของ Apidog คุณจะติดตั้งโปรแกรมขนาดเล็กบนเซิร์ฟเวอร์ที่คุณเป็นเจ้าของ และโปรแกรมนั้นจะส่งคืนการตอบกลับจำลองจากภายในเครือข่ายของคุณ การออกแบบจะอยู่ในโปรเจกต์ Apidog ของคุณเหมือนเดิม มีเพียงการให้บริการเท่านั้นที่ย้ายไปอยู่บนฮาร์ดแวร์ของคุณ คู่มือนี้จะอธิบายว่ารันเนอร์คืออะไร ควรเลือกใช้เมื่อใดแทน Cloud Mock วิธีตั้งค่าจากเอกสาร และความแตกต่างที่ทำให้คนสับสนคือ: รันเนอร์ไม่ใช่ CLI หากคุณต้องการภาพรวมที่กว้างขึ้นว่าทำไมทีมถึงรัน Mock บนเครื่องของตนเอง คู่มือเกี่ยวกับ เซิร์ฟเวอร์ Mock API ที่โฮสต์ด้วยตนเอง จะครอบคลุมกรณีทั่วไป และ OpenAPI Initiative จะอธิบายสเปกที่ใช้สร้าง Mock เหล่านี้ ต้องการทำตามใช่หรือไม่ ดาวน์โหลด Apidog ก่อน

รันเนอร์ที่โฮสต์ด้วยตนเองคืออะไร

Apidog Self-hosted Runner คือโปรแกรมอัตโนมัติที่คุณโฮสต์บนเซิร์ฟเวอร์แบบสแตนด์อโลน ชื่ออย่างเป็นทางการคือ General Runner และมันมีหน้าที่สามอย่าง: รันการทดสอบอัตโนมัติแบบกำหนดเวลา, นำเข้าเอกสาร API และส่งคืนการตอบกลับจำลอง งานที่สามนี้คือสิ่งที่เราจะพูดถึงในบทความนี้

นี่คือแนวคิดหลัก: เมื่อคุณติดตั้ง General Runner และตั้งค่า Server Host แล้ว สภาพแวดล้อมใหม่ที่เรียกว่า Runner Mock จะปรากฏขึ้นโดยอัตโนมัติในโปรเจกต์ของคุณ คำขอใดๆ ที่คุณส่งผ่านสภาพแวดล้อมนั้นจะได้รับการตอบกลับจำลองจากรันเนอร์ที่โฮสต์ด้วยตนเองของคุณ แทนที่จะเป็น Cloud Mock ของ Apidog การออกแบบ Mock เหมือนกัน ข้อมูลที่สร้างขึ้นเหมือนกัน แต่เครื่องที่ให้บริการแตกต่างกัน ทราฟฟิกของคุณจะไม่มีวันออกจากเครือข่ายของคุณ

นี่คือทางเลือกแบบ Self-hosted สำหรับ Cloud Mock หากทีมของคุณสามารถเข้าถึงอินเทอร์เน็ตได้และไม่มีข้อห้ามใดๆ Cloud Mock ของ Apidog นั้นง่ายกว่าเพราะไม่ต้องมีการติดตั้งใดๆ ให้ใช้งานรันเนอร์เมื่อเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้:

• ทราฟฟิกขาออกไปยังโฮสต์ภายนอกถูกบล็อกหรือถูกตรวจสอบอย่างเข้มงวด
• นโยบายการปฏิบัติตามข้อกำหนดต้องการให้ข้อมูลคำขออยู่ในโครงสร้างพื้นฐานภายใน
• สภาพแวดล้อมเป็นแบบ Air-gapped และไม่สามารถเข้าถึง Cloud Endpoint ได้เลย
• คุณต้องการวัดเวลาแฝงของ Mock บน LAN ของคุณเอง ไม่ใช่ผ่านอินเทอร์เน็ตสาธารณะ

หากไม่มีข้อใดข้างต้นที่ตรงกับความต้องการของคุณ Docker host เพิ่มเติมก็เป็นค่าใช้จ่ายที่ไม่จำเป็น จงซื่อสัตย์กับตัวเองว่าคุณอยู่ในกลุ่มใดก่อนที่จะจัดเตรียมเซิร์ฟเวอร์

ข้อควรทราบเกี่ยวกับแผนและสิทธิ์: เอกสาร Apidog ไม่ได้ระบุเกณฑ์ที่ชัดเจนระหว่างฟรีกับแบบชำระเงินสำหรับ General Runner หรือสำหรับ Self-hosted Mock และไม่มีตัวเลขราคาสำหรับสิ่งนี้ ดังนั้นคู่มือนี้จะไม่อ้างอิงถึง หากต้องการตั้งค่าสิ่งนี้ จำเป็นต้องมีสิทธิ์ผู้ดูแลระบบของทีมหรือโปรเจกต์ เนื่องจากกระบวนการติดตั้งรันเนอร์เกิดขึ้นภายใน Team Resources และมีเพียงผู้ดูแลระบบเท่านั้นที่สามารถเปิดการตั้งค่าเหล่านั้นได้ หากคุณไม่เห็นแผง Resources นั่นคือสาเหตุ

สิ่งที่คุณต้องมีก่อนเริ่มต้น

รันเนอร์มาในรูปแบบ Docker container ดังนั้นเซิร์ฟเวอร์ที่โฮสต์จะต้องติดตั้ง Docker เอกสารระบุเวอร์ชันขั้นต่ำที่ 20.10.0 และแนะนำ 20.10.13 หรือใหม่กว่า ตรวจสอบสิ่งที่คุณมี:

docker --version

คุณยังต้องการสถานที่สำหรับรันมัน: เครื่อง Linux, macOS หรือ Windows ที่ทั้ง Apidog client ของทีมคุณและ Apidog service สามารถเข้าถึงได้ ในอินทราเน็ตนั่นมักจะหมายถึงเซิร์ฟเวอร์ภายในที่มี IP หรือชื่อโฮสต์ที่เสถียร นั่นคือรายการข้อกำหนดเบื้องต้นทั้งหมด: Docker, โฮสต์ และสิทธิ์ผู้ดูแลระบบในทีม ทุกอย่างอื่นที่คุณกำหนดค่าอยู่ภายใน Apidog เอง

ติดตั้ง General Runner

คำสั่งการติดตั้งจะถูกสร้างให้คุณจากภายใน Apidog และมีโทเค็นอยู่ ดังนั้นคุณไม่จำเป็นต้องพิมพ์เอง นี่คือขั้นตอน

สร้างคำสั่ง

เปิด Apidog Home เลือกทีมของคุณ จากนั้นคลิก 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 จะแสดงสิ่งเดียวกันนี้หากคุณต้องการดูที่ UI

ยืนยันว่าได้ลงทะเบียนแล้ว

กลับไปที่ Apidog ไปที่ Team Resources และเปิด General Runner คลิกปุ่มรีเฟรช รันเนอร์ควรจะแสดงเป็น deployed พร้อมสถานะ Started หากไม่ปรากฏในตอนแรก ปุ่มรีเฟรชคือวิธีแก้ไขของคุณ ให้รอสักครู่แล้วคลิกอีกครั้ง

สถานะของรันเนอร์มีสามสถานะที่ควรรู้:

• Started (เริ่มต้นแล้ว): เปิดใช้งาน, กำลังสื่อสารกับ Apidog, จัดการงานต่างๆ นี่คือสถานะที่คุณต้องการ
• Stopped (หยุดแล้ว): มีคนหยุดด้วยตนเองใน Apidog มันยังคงถูกติดตั้งแต่จะไม่ประมวลผลงาน
• Offline (ออฟไลน์): สูญเสียการเชื่อมต่อกับ Apidog ดังนั้นจึงไม่สามารถประมวลผลอะไรได้ ตรวจสอบคอนเทนเนอร์และเส้นทางเครือข่าย

เปิดใช้งาน Runner Mock

การติดตั้งรันเนอร์จะทำให้คุณได้ตัวแทน (agent) อีกหนึ่งขั้นตอนคือการกำหนดทราฟฟิก Mock ของคุณไปยังมัน

ใน Team Resources ให้เปิด General Runner และค้นหาช่อง Server Host ป้อนที่อยู่ที่รันเนอร์ของคุณสามารถเข้าถึงได้ ในการตั้งค่า HTTP ธรรมดา นั่นคือโฮสต์และพอร์ตที่คุณเปิดเผย เช่น http://127.0.0.1:80 สำหรับการทดสอบภายใน หรือ http://runner.internal.example.com:80 สำหรับโฮสต์อินทราเน็ตที่ใช้ร่วมกัน หลัง TLS-terminating proxy จะมีลักษณะเหมือน https://runner.example.com:443 รายละเอียดเพิ่มเติมเกี่ยวกับ HTTPS จะตามมาในไม่ช้า

เมื่อตั้งค่า Server Host แล้ว Apidog จะเชื่อมต่อสภาพแวดล้อม Runner Mock สำหรับโปรเจกต์ของคุณโดยอัตโนมัติ ตรวจสอบได้โดย: เปิดโปรเจกต์ ไปที่ Environment Management และยืนยันว่า Runner Mock แสดงอยู่ในรายการสภาพแวดล้อมแล้ว คุณไม่ได้สร้างมันด้วยตนเอง การตั้งค่า Server Host คือสิ่งที่ทำให้มันปรากฏขึ้น

ส่งคำขอผ่าน Mock ที่โฮสต์ด้วยตนเอง

ตอนนี้ใช้งานได้เลย สมมติว่าคุณมี endpoint GET /orders/{orderId} ในโปรเจกต์สำหรับ API การจัดการคำสั่งซื้อภายใน เปิด endpoint นั้น จากนั้นในเมนูดร็อปดาวน์สภาพแวดล้อมที่ด้านบน ให้เลือก Runner Mock แทนสภาพแวดล้อม Cloud ส่งคำขอ

การตอบกลับจะมาจากรันเนอร์ของคุณ เนื่องจาก Apidog สร้างข้อมูล Mock จาก Schema ของคุณ Schema Order ที่กำหนดไว้อย่างดีจะส่งคืนค่าที่สมจริงแทนที่จะเป็นค่า Placeholder ที่ว่างเปล่า:

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 นั้นไม่เคยแตะอินเทอร์เน็ตสาธารณะเลย รันเนอร์สร้างมันขึ้นจาก Schema ของ Endpoint ของคุณและให้บริการจากภายในเครือข่ายของคุณ การสร้างข้อมูลที่รู้จักฟิลด์ เช่น ค่า customerEmail ด้านบน มาจากการที่ Apidog อ่านประเภทและชื่อฟิลด์ของ Schema ของคุณ ซึ่งเป็นเอนจินเดียวกันกับที่กล่าวถึงในบทความที่เกี่ยวข้องกับการ สร้างข้อมูล Mock ที่สมจริงโดยอัตโนมัติด้วย Smart Mock หากคุณต้องการควบคุมสิ่งที่คำขอที่กำหนดส่งคืนอย่างแม่นยำ คุณสามารถเพิ่ม Mock expectation บน Endpoint และรันเนอร์จะให้บริการ expectation นั้นในลักษณะเดียวกับ Cloud Mock กลไกในการสร้าง Mock response ที่ดีจะเหมือนกันไม่ว่าเซิร์ฟเวอร์จะเป็นของ Apidog หรือของคุณเอง มีเพียงโฮสต์เท่านั้นที่เปลี่ยนไป แนวคิดทั่วไปเบื้องหลัง การทำ Mock API ยังคงไม่เปลี่ยนแปลง

HTTPS, การเมาท์ข้อมูล และรายละเอียดอื่นๆ ในโลกจริง

การทดสอบบน http://127.0.0.1 นั้นง่าย การใช้งานบนอินทราเน็ตที่ใช้ร่วมกันมีบางจุดที่ซับซ้อนที่คุณควรรู้ก่อนที่จะนำไปใช้กับทีม

HTTPS ต้องใช้ Reverse Proxy

รันเนอร์ไม่มีการรองรับใบรับรอง HTTPS ในตัว และไม่มีการจัดเตรียมใบรับรองอัตโนมัติ มันจะไม่ดึงหรือจัดการใบรับรอง TLS ให้คุณ หากคุณต้องการ https:// ให้ยุติ TLS ที่ Reverse Proxy ด้านหน้ารันเนอร์ ตัวอย่างเช่น 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 คู่มือ HTTPS ของ MDN เป็นแหล่งข้อมูลที่ดีหากการยุติ TLS เป็นเรื่องใหม่สำหรับทีมของคุณ

การเมาท์ไฟล์นั้นเป็นแบบระบุเส้นทาง

หาก Mock หรือการทดสอบของคุณต้องการไฟล์เพิ่มเติม รันเนอร์จะคาดหวังว่าไฟล์เหล่านั้นจะอยู่ในเส้นทางที่กำหนดภายในคอนเทนเนอร์ ดังนั้นให้เมาท์ไฟล์เหล่านั้นที่นั่น:

• โปรแกรมภายนอกจะอยู่ใน /app/external-programs/
• การกำหนดค่าการเชื่อมต่อฐานข้อมูลจะอยู่ใน /app/database/database-connections.json
• ใบรับรองไคลเอ็นต์ SSL จะอยู่ใน /app/ssl/ssl-client-cert-list.json

เชื่อมโยงสิ่งเหล่านี้ผ่านการเมาท์ -v ของคุณเพื่อให้พวกมันอยู่รอดการรีสตาร์ท

พฤติกรรมการติดตั้งใหม่และการอัปเกรด

เมื่อรันเนอร์เวอร์ชันใหม่เผยแพร่ คุณจะเห็นตัวเลือก Upgrade และภายใต้ More Actions คุณสามารถเลือก Redeploy ได้ ทั้งสองตัวเลือกนี้จะหยุดคอนเทนเนอร์ที่กำลังทำงานอยู่ขณะที่คอนเทนเนอร์ใหม่กำลังทำงานขึ้นมา ส่วนที่น่าสบายใจคือ: งานที่กำหนดเวลาไว้ใน Apidog client จะไม่ได้รับผลกระทบจากการติดตั้งใหม่หรือการอัปเกรด ดังนั้นคุณจะขัดจังหวะการให้บริการสดในช่วงที่คอนเทนเนอร์รีสตาร์ทเท่านั้น ไม่ได้สูญเสียการกำหนดค่าใดๆ

ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI

นี่คือความแตกต่างที่ช่วยลดความสับสน: รันเนอร์เป็นเอเจนต์ที่มีอายุการใช้งานยาวนานที่สามารถให้บริการ Mock และรันงานที่กำหนดเวลาไว้ได้ ในขณะที่ Apidog CLI เป็นตัวรันการทดสอบแบบครั้งเดียวสำหรับ CI ทั้งสองเป็นเครื่องมือที่แตกต่างกัน CLI ไม่สามารถให้บริการ เริ่มต้น หรือโฮสต์ Mock server ได้ ไม่มีคำสั่ง apidog run mock และไม่มี apidog mock serve คำสั่ง apidog run ของ CLI จะดำเนินการ Test Scenarios, โฟลเดอร์ Test Scenario และ Test Suites และกลุ่มคำสั่ง mock ของมันจะทำแค่ CRUD บน Mock expectations เป็นข้อมูล การให้บริการ Mock เป็นงานของรันเนอร์ ไม่ใช่ของ CLI

ดังนั้นทั้งสองจึงทำงานร่วมกันดังนี้: CLI และ AI coding agents เช่น Cursor, Claude Code และ Codex สามารถสร้างและอัปเดต Endpoint และ Schema ในโปรเจกต์ของคุณ ซึ่งช่วยให้ผลลัพธ์ Mock ของคุณถูกต้องเมื่อสเปกมีการพัฒนา เมื่อ Mock ที่โฮสต์ด้วยตนเองได้ปลดบล็อกงานฟรอนต์เอนด์แล้ว Test Scenario ของโปรเจกต์เดียวกันจะทำงานแบบ Headless ใน CI ด้วยคำสั่งเดียว เพื่อตรวจสอบ Backend จริงเทียบกับสัญญาที่ Mock อธิบายไว้:

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

คำสั่งเดียวนี้จะรัน Scenario ของคุณเทียบกับ Backend ที่ใช้งานจริง และสร้างรายงาน HTML และ CLI การติดตั้งคือ npm install -g apidog-cli บน Node.js v16 หรือใหม่กว่า; คู่มือการติดตั้ง Apidog CLI ครอบคลุมการตั้งค่า apidog login และโทเค็น หากต้องการให้การทดสอบนั้นเกิดขึ้นทุกครั้งที่มีการ Push ให้เชื่อมโยงเข้ากับ Pipeline ของคุณด้วย คู่มือ Apidog CLI CI/CD บทความเกี่ยวกับการ Mock API จาก CLI อธิบายว่าทำไมเทอร์มินัลถึงจัดการ Mock Definitions แต่ไม่โฮสต์พวกมัน

คำถามที่พบบ่อย

ฉันจำเป็นต้องใช้ Self-hosted runner หรือไม่หากทีมของฉันสามารถเข้าถึงอินเทอร์เน็ตได้?

อาจจะไม่ Cloud Mock ไม่จำเป็นต้องติดตั้งอะไรและเป็นเส้นทางที่ง่ายกว่า เลือกใช้รันเนอร์เมื่อทราฟฟิกขาออกถูกบล็อกหรือถูกตรวจสอบ กฎการปฏิบัติตามข้อกำหนดบังคับให้ข้อมูลอยู่ในโครงสร้างพื้นฐานภายใน หรือสภาพแวดล้อมเป็นแบบ Air-gapped หากคุณกำลังเปรียบเทียบวิธีการโฮสต์กับวิธีการจัดการ คู่มือ การใช้งาน Apidog Cloud Mock เป็นคู่มือที่สมบูรณ์แบบสำหรับบทความนี้

Apidog CLI สามารถเริ่ม Mock server ที่โฮสต์ด้วยตนเองได้หรือไม่?

ไม่ได้ CLI รันการทดสอบด้วย apidog run และจัดการ Mock expectations เป็นข้อมูลด้วยกลุ่มคำสั่ง mock การให้บริการทราฟฟิก Mock ทำโดย General Runner หรือ Cloud Mock ไม่ใช่โดย CLI หากคุณหวังว่าจะพิมพ์คำสั่งในเทอร์มินัลเดียวแล้วได้ Mock ที่กำลังทำงานอยู่บนพอร์ต นั่นคืองานของรันเนอร์ ซึ่งตั้งค่าผ่าน GUI ตามที่อธิบายไว้ข้างต้น

รันเนอร์รองรับ HTTPS ด้วยตัวเองหรือไม่?

มันไม่ได้มาพร้อมกับใบรับรองหรือไม่จัดเตรียมใบรับรองโดยอัตโนมัติ ให้ติดตั้ง Reverse Proxy เช่น Nginx ไว้ด้านหน้าเพื่อยุติ TLS จากนั้นชี้ Server Host ไปยัง URL https:// ของพร็อกซี หากไม่มีพร็อกซี ให้ใช้ http://host:port

ทำไมรันเนอร์ของฉันไม่ปรากฏขึ้นหลังจากที่ฉันรันคำสั่งไปแล้ว?

เปิด Team Resources ไปที่ General Runner และคลิกปุ่มรีเฟรช การลงทะเบียนอาจล่าช้าไปสักครู่ หากยังไม่ปรากฏ ให้ยืนยันว่าคอนเทนเนอร์กำลังทำงานอยู่ด้วย docker ps และโฮสต์สามารถเข้าถึงได้จาก Apidog สถานะ Offline หมายถึงการเชื่อมต่อหลุด; Started คือสถานะที่คุณต้องการ

หลายทีมสามารถแชร์รันเนอร์เดียวสำหรับการให้บริการ Mock ทั่วโลกได้หรือไม่?

รันเนอร์จะลงทะเบียนกับทีมที่คุณติดตั้ง และสภาพแวดล้อม Runner Mock ของมันจะแสดงขึ้นตามโปรเจกต์ หากคุณรันทีมแบบกระจายที่แชร์สภาพแวดล้อม Mock รูปแบบในคู่มือเกี่ยวกับการ แชร์สภาพแวดล้อม Mock ทั่วทั้งทีมทั่วโลก จะช่วยให้คุณตัดสินใจได้ว่าจะต้องตั้งค่ารันเนอร์จำนวนเท่าใดและที่ไหน

สรุป

การทำ Mock ที่โฮสต์ด้วยตนเองด้วย General Runner ช่วยให้ข้อมูลคำขอของคุณอยู่ในโครงสร้างพื้นฐานที่คุณควบคุม ในขณะที่การออกแบบ Mock ของคุณยังคงอยู่ในโปรเจกต์ Apidog ของคุณเช่นเคย คุณติดตั้ง Docker container หนึ่งตัว ตั้งค่า Server Host และสภาพแวดล้อม Runner Mock จะจัดการส่วนที่เหลือทั้งหมด เลือกใช้เมื่อไม่สามารถเข้าถึง Cloud ได้ และใช้ Cloud Mock เมื่อสามารถเข้าถึงได้ พร้อมที่จะรัน Mock บนเครือข่ายของคุณเองแล้วหรือยัง? ดาวน์โหลด Apidog ติดตั้งรันเนอร์ และให้บริการ Runner Mock response แรกของคุณโดยไม่มีแพ็คเก็ตใดๆ ออกจากอินทราเน็ตของคุณ