บางทีมไม่สามารถส่งทราฟฟิกไปยังคลาวด์ได้ เช่น อยู่หลังไฟร์วอลล์องค์กรที่บล็อกบริการภายนอก มีข้อกำหนดให้ข้อมูลคำขอและการตอบกลับอยู่ในโครงสร้างพื้นฐานภายใน หรือทำงานในสภาพแวดล้อมแบบ air-gapped ที่ตัดขาดจากอินเทอร์เน็ตทั้งหมด ในกรณีนี้ Mock URL ที่โฮสต์บนโครงสร้างพื้นฐานของบุคคลอื่นใช้งานไม่ได้ แม้ข้อมูล Mock จะเป็นข้อมูลปลอมก็ตาม
Apidog แก้ปัญหานี้ด้วย Self-hosted Runner: ติดตั้งโปรแกรมขนาดเล็กบนเซิร์ฟเวอร์ที่คุณควบคุม แล้วให้โปรแกรมส่ง Mock response จากภายในเครือข่ายของคุณเอง การออกแบบ API และ Mock ยังคงอยู่ในโปรเจกต์ Apidog แต่จุดที่ให้บริการย้ายมาอยู่บนฮาร์ดแวร์ของคุณ
หากต้องการดูภาพรวมของกรณีใช้งาน โปรดอ่านคู่มือ เซิร์ฟเวอร์ Mock API ที่โฮสต์ด้วยตนเอง และดูรายละเอียดมาตรฐาน API ได้จาก OpenAPI Initiative
รันเนอร์ที่โฮสต์ด้วยตนเองคืออะไร
Apidog Self-hosted Runner หรือชื่ออย่างเป็นทางการว่า General Runner คือโปรแกรมที่โฮสต์บนเซิร์ฟเวอร์แบบสแตนด์อโลน โดยรองรับงานหลัก 3 แบบ:
- รันการทดสอบอัตโนมัติตามกำหนดเวลา
- นำเข้าเอกสาร API
- ส่งคืน Mock response
บทความนี้เน้นการใช้งานข้อที่ 3
หลังติดตั้ง General Runner และตั้งค่า Server Host แล้ว Apidog จะสร้าง Environment ชื่อ Runner Mock ให้กับโปรเจกต์โดยอัตโนมัติ คำขอที่ส่งผ่าน Environment นี้จะได้รับ Mock response จากรันเนอร์ในเครือข่ายของคุณ แทนที่จะเป็น Cloud Mock ของ Apidog
Mock definition และข้อมูลที่สร้างขึ้นยังเหมือนเดิม ความแตกต่างคือเครื่องที่ให้บริการ response เท่านั้น
เลือกใช้ Self-hosted Runner เมื่อ:
- ทราฟฟิกขาออกไปยังโฮสต์ภายนอกถูกบล็อกหรือถูกตรวจสอบอย่างเข้มงวด
- นโยบาย compliance กำหนดให้ข้อมูลคำขออยู่ในโครงสร้างพื้นฐานภายใน
- สภาพแวดล้อมเป็นแบบ air-gapped และเข้าถึง Cloud endpoint ไม่ได้
- ต้องการวัด latency ของ Mock ภายใน LAN แทนอินเทอร์เน็ตสาธารณะ
หากทีมเข้าถึงอินเทอร์เน็ตได้และไม่มีข้อจำกัดเหล่านี้ Cloud Mock ของ Apidog จะติดตั้งง่ายกว่า เพราะไม่ต้องดูแล Docker host เพิ่มเติม
การตั้งค่า General Runner ต้องใช้สิทธิ์ผู้ดูแลระบบระดับทีมหรือโปรเจกต์ เนื่องจากขั้นตอนติดตั้งอยู่ในส่วน Team Resources หากไม่เห็นเมนู Resources ให้ตรวจสอบสิทธิ์ก่อน
สิ่งที่ต้องเตรียม
General Runner ทำงานเป็น Docker container ดังนั้นโฮสต์ต้องติดตั้ง Docker เวอร์ชันอย่างน้อย 20.10.0 และแนะนำ 20.10.13 ขึ้นไป
ตรวจสอบเวอร์ชัน Docker:
docker --version
คุณต้องมี:
- Docker host บน Linux, macOS หรือ Windows
- IP หรือ hostname ที่เสถียรสำหรับโฮสต์ โดยเฉพาะกรณีใช้งานในอินทราเน็ต
- สิทธิ์ผู้ดูแลระบบใน Apidog Team หรือ Project
การตั้งค่าที่เหลือทำผ่าน Apidog
ติดตั้ง General Runner
1. สร้างคำสั่งติดตั้งจาก Apidog
ใน Apidog ให้เปิด Home แล้วเลือกทีมของคุณ จากนั้นไปที่:
Resources → Deploy General Runner
ในหน้าต่างตั้งค่า ให้กำหนดค่าต่อไปนี้:
Server OS
เลือก Linux, macOS หรือ Windows เพื่อให้ Apidog สร้างคำสั่งที่ตรงกับโฮสต์-
Docker Image
-
General: มี Node.js 18, Java 21, Python 3 และ PHP 8 -
Slim: มี Node.js 18 สำหรับอิมเมจที่เล็กกว่า -
Custom: ใช้ Dockerfile ของคุณเอง หากต้องมี runtime เพิ่มเติมสำหรับ test script
-
Exposed Port
กำหนดด้วย-pเช่น:
-p 80:4524
ตัวอย่างนี้แมปพอร์ต 80 ของโฮสต์ไปยังพอร์ต 4524 ภายใน Runner
-
Mounted Data Directory
กำหนดด้วย
-vเพื่อเก็บข้อมูล Runner ไว้บนโฮสต์และคงอยู่หลัง container restart
คัดลอกคำสั่งที่ Apidog สร้างให้ทันที เพราะคำสั่งมี token ฝังอยู่และจะแสดงเพียงครั้งเดียว หากทำหาย ต้องสร้างคำสั่งใหม่
2. รัน Container บนเซิร์ฟเวอร์
วางคำสั่งที่สร้างขึ้นใน terminal ของเซิร์ฟเวอร์ ตัวอย่างรูปแบบคำสั่ง:
docker run -d \
--name apidog-runner \
-p 80:4524 \
-v /opt/apidog-runner/data:/app/data \
apidog/runner:latest \
--token <YOUR_GENERATED_TOKEN>
ใช้ token ที่ Apidog สร้างให้จริง อย่าใช้ค่า placeholder ในตัวอย่าง
ตรวจสอบว่า container กำลังทำงาน:
docker ps
คุณควรเห็น container ของ Runner พร้อม port mapping ที่กำหนดไว้
3. ยืนยันการลงทะเบียนใน Apidog
กลับไปที่:
Team Resources → General Runner
กดปุ่มรีเฟรช แล้วตรวจสอบสถานะ Runner
สถานะที่ควรรู้:
| สถานะ | ความหมาย |
|---|---|
| Started | Runner ทำงาน เชื่อมต่อกับ Apidog และพร้อมประมวลผลงาน |
| Stopped | Runner ยังติดตั้งอยู่ แต่ถูกหยุดจาก Apidog และไม่ประมวลผลงาน |
| Offline | Runner สูญเสียการเชื่อมต่อกับ Apidog ให้ตรวจสอบ container และเส้นทางเครือข่าย |
หาก Runner ยังไม่แสดงทันที ให้รอสักครู่แล้วกดรีเฟรชอีกครั้ง
เปิดใช้งาน Runner Mock
การติดตั้ง Runner เพียงอย่างเดียวทำให้คุณมี agent แล้ว ขั้นตอนถัดไปคือกำหนดให้ Mock traffic วิ่งผ่าน agent นี้
ในหน้า Team Resources → General Runner ให้ค้นหาช่อง Server Host แล้วป้อน URL ที่เข้าถึง Runner ได้ เช่น:
http://127.0.0.1:80
สำหรับการทดสอบในเครื่อง หรือ:
http://runner.internal.example.com:80
สำหรับโฮสต์ที่แชร์ในอินทราเน็ต
หากใช้ reverse proxy ที่ terminate TLS แล้ว:
https://runner.example.com:443
หลังตั้งค่า Server Host แล้ว Apidog จะสร้าง Environment ชื่อ Runner Mock ในโปรเจกต์โดยอัตโนมัติ
ตรวจสอบได้ที่:
Project → Environment Management
คุณไม่ต้องสร้าง Environment นี้เอง
ส่งคำขอผ่าน Self-hosted Mock
สมมติว่าโปรเจกต์มี endpoint ดังนี้:
GET /orders/{orderId}
ให้เปิด endpoint ใน Apidog แล้วเลือก Environment เป็น Runner Mock จากนั้นส่งคำขอได้ตามปกติ
คุณยังทดสอบผ่าน curl ได้:
curl http://runner.internal.example.com:80/orders/10583
ตัวอย่าง Mock response:
{
"orderId": 10583,
"customerEmail": "amelia.turner@example.com",
"status": "shipped",
"total": 148.5,
"currency": "USD",
"createdAt": "2026-07-14T09:32:11Z"
}
ข้อมูล JSON นี้ถูกสร้างจาก Schema ของ endpoint และให้บริการจาก Runner ภายในเครือข่ายของคุณเอง
เพื่อให้ผลลัพธ์มีคุณภาพ ให้กำหนด Schema ให้ชัดเจน เช่น ระบุชนิดข้อมูลและชื่อฟิลด์อย่าง customerEmail, status หรือ createdAt Apidog ใช้ข้อมูลเหล่านี้เพื่อสร้าง Mock data ที่สอดคล้องกับฟิลด์
อ่านเพิ่มเติมเกี่ยวกับ:
หากต้องการกำหนด response สำหรับคำขอเฉพาะ ให้เพิ่ม Mock expectation บน endpoint นั้น Runner จะให้บริการ expectation เดียวกับ Cloud Mock
HTTPS, การเมาท์ข้อมูล และการใช้งานจริง
HTTPS ต้องใช้ Reverse Proxy
Runner ไม่มีระบบจัดการใบรับรอง HTTPS ในตัว และไม่ออกใบรับรอง TLS ให้อัตโนมัติ หากต้องการใช้ https:// ให้ terminate TLS ผ่าน reverse proxy เช่น Nginx
ตัวอย่าง Nginx ที่รับ HTTPS บนพอร์ต 443 และส่งต่อไปยัง Runner บนพอร์ต 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
หากไม่มี reverse proxy ให้ใช้:
http://host:port
ไม่ควรตั้งค่า Server Host เป็น https:// แล้วคาดหวังให้ Runner จัดการ TLS โดยตรง ดูพื้นฐานเพิ่มเติมได้จาก คู่มือ HTTPS ของ MDN
เมาท์ไฟล์ตามเส้นทางที่ Runner คาดหวัง
หาก Mock หรือ test ต้องใช้ไฟล์เพิ่มเติม ให้เมาท์ไฟล์ไปยังตำแหน่งที่กำหนดภายใน container:
| ประเภทไฟล์ | Path ภายใน Container |
|---|---|
| โปรแกรมภายนอก | /app/external-programs/ |
| การตั้งค่าการเชื่อมต่อฐานข้อมูล | /app/database/database-connections.json |
| ใบรับรอง SSL client | /app/ssl/ssl-client-cert-list.json |
ตัวอย่างการใช้ volume mount:
docker run -d \
--name apidog-runner \
-p 80:4524 \
-v /opt/apidog-runner/data:/app/data \
-v /opt/apidog-runner/external-programs:/app/external-programs \
apidog/runner:latest \
--token <YOUR_GENERATED_TOKEN>
การใช้ -v ช่วยให้ข้อมูลยังคงอยู่หลัง restart หรือ redeploy container
การอัปเกรดและ Redeploy
เมื่อมี Runner เวอร์ชันใหม่ Apidog จะแสดงตัวเลือก Upgrade และเมนู More Actions → Redeploy
ทั้งสองกระบวนการจะหยุด container เดิมชั่วคราวขณะที่ container ใหม่เริ่มทำงาน ดังนั้น Mock service อาจหยุดชั่วครู่ระหว่าง restart
อย่างไรก็ตาม งานตามกำหนดเวลาที่ตั้งค่าไว้ใน Apidog client จะไม่ได้รับผลกระทบ และการตั้งค่าจะไม่สูญหาย
ใช้ Apidog CLI ใน CI/CD อย่างถูกต้อง
จุดที่มักสับสนคือ General Runner ไม่ใช่ Apidog CLI
- General Runner เป็น agent ที่ทำงานต่อเนื่อง ใช้ให้บริการ Mock และรันงานตามกำหนดเวลา
- Apidog CLI เป็นเครื่องมือสำหรับรันทดสอบแบบครั้งเดียวใน CI/CD
CLI ไม่สามารถเริ่มหรือโฮสต์ Mock server ได้ ไม่มีคำสั่งเหล่านี้:
apidog run mock
apidog mock serve
คำสั่ง apidog run ใช้รัน Test Scenario, โฟลเดอร์ Test Scenario และ Test Suites ส่วนกลุ่มคำสั่ง mock ใช้จัดการ Mock expectations ในฐานะข้อมูล ไม่ใช่ให้บริการ Mock traffic
ตัวอย่างการรัน Test Scenario ใน CI:
apidog run -t <scenario_id> -e <env_id> -r html,cli
คำสั่งนี้จะรัน Scenario กับ backend ที่ใช้งานจริง และสร้างรายงานทั้ง HTML และ CLI
ติดตั้ง CLI:
npm install -g apidog-cli
CLI ต้องใช้ Node.js v16 หรือใหม่กว่า ดูรายละเอียดได้ที่:
CLI และ AI coding agents เช่น Cursor, Claude Code และ Codex สามารถช่วยสร้างหรืออัปเดต endpoint และ schema ในโปรเจกต์ได้ จากนั้น General Runner จะใช้ schema เหล่านั้นเพื่อให้บริการ Mock ภายในเครือข่าย ขณะที่ CLI ใช้ตรวจสอบ backend จริงใน pipeline
คำถามที่พบบ่อย
จำเป็นต้องใช้ Self-hosted Runner หากทีมเข้าถึงอินเทอร์เน็ตได้หรือไม่
ส่วนใหญ่ไม่จำเป็น Cloud Mock ไม่ต้องติดตั้งหรือดูแล Docker host เพิ่มเติม เลือกใช้ Self-hosted Runner เมื่อมีข้อจำกัดด้านเครือข่าย compliance หรือสภาพแวดล้อมแบบ air-gapped
หากต้องการเปรียบเทียบกับ Cloud Mock โปรดดู การใช้งาน Apidog Cloud Mock
Apidog CLI เริ่ม Self-hosted Mock server ได้หรือไม่
ไม่ได้ CLI ใช้รันทดสอบด้วย apidog run และจัดการ Mock expectations ผ่านคำสั่ง mock แต่ไม่สามารถเปิดพอร์ตเพื่อให้บริการ Mock ได้ งานนี้เป็นของ General Runner หรือ Cloud Mock
Runner รองรับ HTTPS ด้วยตัวเองหรือไม่
ไม่ Runner ไม่มีใบรับรองและไม่จัดเตรียม TLS certificate อัตโนมัติ ใช้ reverse proxy เช่น Nginx เพื่อ terminate TLS แล้วตั้งค่า Server Host เป็น URL https:// ของ proxy
ทำไม Runner ไม่แสดงหลังรันคำสั่ง
ตรวจสอบตามลำดับนี้:
- เปิด Team Resources → General Runner
- กดรีเฟรช
- ตรวจสอบ container:
docker ps
- ตรวจสอบว่าโฮสต์เชื่อมต่อกับ Apidog ได้
หากสถานะเป็น Offline แปลว่าการเชื่อมต่อหลุด ส่วนสถานะที่ต้องการคือ Started
หลายทีมแชร์ Runner เดียวสำหรับ Mock ได้หรือไม่
Runner จะลงทะเบียนกับทีมที่ใช้ติดตั้ง และ Environment ของ Runner Mock จะแสดงตามโปรเจกต์ในทีมนั้น หากต้องแชร์ Mock environment ระหว่างทีมที่กระจายอยู่หลายพื้นที่ โปรดดู การแชร์สภาพแวดล้อม Mock ทั่วทั้งทีมทั่วโลก
สรุป
Self-hosted Mock ด้วย General Runner ช่วยให้ข้อมูลคำขอและการตอบกลับอยู่ในโครงสร้างพื้นฐานที่คุณควบคุมได้ โดยยังใช้ Mock design เดิมจากโปรเจกต์ Apidog
ขั้นตอนหลักมีเพียง:
- ติดตั้ง Docker container ของ General Runner
- ตั้งค่า Server Host
- เลือก Environment เป็น Runner Mock
- ส่งคำขอ Mock ผ่านเครือข่ายภายใน
ใช้ Runner เมื่อ Cloud endpoint เข้าถึงไม่ได้หรือไม่เป็นไปตามนโยบายองค์กร และใช้ Cloud Mock เมื่อไม่มีข้อจำกัดเหล่านั้น
พร้อมเริ่มใช้งานหรือไม่? ดาวน์โหลด Apidog ติดตั้ง Runner และให้บริการ Mock response แรกภายในอินทราเน็ตของคุณ

Top comments (0)