ทำให้เอเจนต์เป็นบริการ ไม่ใช่เทอร์มินัลที่ถูกลืม

แพ็กเกจเวิร์กเกอร์

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

บันทึกความคืบหน้าก่อนการดำเนินการสำคัญ

ใช้คิวหรือฐานข้อมูลที่ทนทานสำหรับงาน กำหนดตัวระบุการดำเนินการที่ไม่ซ้ำ บันทึกคำขอภายนอก และกระทบยอดผลลัพธ์ที่ไม่แน่ชัด การรีสตาร์ทไม่ควรส่งอีเมลซ้ำ สร้างคำสั่งซื้อซ้ำ หรือเรียกเก็บเงินซ้ำ

เพิ่มความสามารถในการสังเกตที่มีประโยชน์

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

กำหนดเพดานที่ชัดเจน

จำกัดการใช้จ่ายของโมเดล การทำงานพร้อมกันของเบราว์เซอร์ เวลารัน และจำนวนครั้งที่ลองใหม่ มีสวิตช์หยุดชั่วคราวที่ใช้งานง่ายและเส้นทางการตรวจสอบโดยมนุษย์สำหรับการกระทำที่มีผลสำคัญ เวิร์กเกอร์ขนาดเล็กที่ถูกสังเกตอย่างดีนั้นน่าเชื่อถือได้ง่ายกว่าตัวที่ไม่จำกัด

ใช้ตัวควบคุมและกำหนดการที่ตั้งใจไว้

Systemd และ Docker เป็นวิธีทั่วไปที่ทำให้โปรเซสอยู่รอดเมื่อตัดการเชื่อมต่อเทอร์มินัล สำหรับบริการ systemd การใช้ Type=exec สามารถรายงานความล้มเหลวในการทำงานได้โดยตรงกว่าการเปิดใช้งานเบื้องหลังแบบง่าย และ Restart=on-failure สามารถรีสตาร์ทเมื่อล้มเหลวด้วยนโยบายที่มีขอบเขต งานตามกำหนดเวลาควรหลีกเลี่ยงการทำงานทับซ้อน กำหนดไดเรกทอรีทำงาน ผู้ใช้บริการ และสภาพแวดล้อมอย่างชัดเจน ตัวอย่างนี้ถือว่ามีผู้ใช้ koala-agent สภาพแวดล้อมเสมือน โมดูลเวิร์กเกอร์ และไฟล์สภาพแวดล้อมส่วนตัวอยู่แล้ว ปรับแต่งก่อนติดตั้งยูนิต

• ใช้บัญชีบริการเฉพาะ
• กำหนดความล่าช้าในการรีสตาร์ทและเพดานความล้มเหลว
• ตรวจสอบสถานะงานก่อนหน้า before เริ่มการรันตามกำหนดการ

[Unit]
Description=Example agent worker
After=network-online.target

[Service]
Type=exec
User=koala-agent
WorkingDirectory=/opt/koala-agent
EnvironmentFile=/etc/koala-agent.env
ExecStart=/opt/koala-agent/.venv/bin/python -m worker
Restart=on-failure
RestartSec=10
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

เอกสารอย่างเป็นทางการ: ความหมายของบริการ Systemd

กำหนดงบประมาณรายวันและขอบเขตการทำซ้ำ

กำหนดจำนวนคำขอสูงสุด วงเงินใช้จ่าย และเวลาหมดอายุการทำงานให้กับเวิร์กเกอร์ ใช้บันทึก idempotency แบบคงทนสำหรับการกระทำที่ส่งผลต่อโลกภายนอก การคลิกเบราว์เซอร์ที่สำเร็จอาจเกิดขึ้นก่อนที่โปรเซสจะได้รับคำตอบ ตรวจสอบสถานะภายนอกก่อนลองอีกครั้ง การเมานต์ความลับของ Docker Compose สามารถเก็บความลับออกจากอิมเมจได้ แต่สิทธิ์การเข้าถึงและแอปพลิเคชันที่ใช้งานยังต้องได้รับการตรวจสอบ

เอกสารอย่างเป็นทางการ: ความลับของ Docker Compose

กำหนดนโยบายการตามให้ทันอย่างชัดเจนให้กับงานตามกำหนดเวลา

ใช้บริการที่ทำงานต่อเนื่องสำหรับ worker คิวแบบถาวร และบริการ oneshot ที่กระตุ้นด้วยตัวจับเวลาสำหรับงานตามกำหนดที่มีขอบเขต ด้วยตัวจับเวลาปฏิทินของ systemd การตั้งค่า Persistent=true สามารถกระตุ้นหนึ่งครั้งที่พลาดไปหลังระบบหยุดทำงาน แต่ไม่ได้สร้างงานค้างทั้งหมดขึ้นมาใหม่ ตัดสินใจว่าการตามเก็บนั้นเป็นที่ต้องการหรือไม่ RandomizedDelaySec สามารถกระจายเวลาเริ่มต้น ขณะที่ lease ระดับแอปพลิเคชันป้องกันไม่ให้สองรีพลิกาประมวลผลงานตามกำหนดเดียวกัน

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

# Read-only checks after creating your own matching units.
systemctl list-timers --all
systemctl status koala-agent.service
journalctl -u koala-agent.service --since today --no-pager

เอกสารอย่างเป็นทางการ: systemd: การจัดตารางเวลาแบบ timer

แยกแยะ crash loop ออกจาก worker ที่หยุดชะงัก

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

• กำหนดงบประมาณผู้ให้บริการและเวลาหมดอายุคำขอในแอปพลิเคชัน รวมถึงขอบเขต CPU/หน่วยความจำบนรันไทม์
• คอนเทนเนอร์ Docker ไม่ได้มีขีดจำกัดหน่วยความจำเฉพาะงานที่มีประโยชน์เพียงเพราะเป็นคอนเทนเนอร์ กำหนดและทดสอบขีดจำกัดอย่างตั้งใจ
• จัดเก็บข้อมูลลับไว้นอกอิมเมจและทรีสาธารณะ จากนั้นทดสอบว่าบันทึกการขัดข้องและข้อมูลวินิจฉัยได้ปิดบังข้อมูลนั้นไว้
• มีเส้นทางการหยุดด้วยตนเองและกำหนดให้มีการตรวจสอบอย่างเหมาะสมสำหรับการใช้จ่าย การเขียนข้อมูลในระบบโปรดักชัน หรือข้อความภายนอก

เอกสารอย่างเป็นทางการ: systemd: การกำกับดูแลบริการ · Docker: ข้อจำกัดทรัพยากรของคอนเทนเนอร์