เครื่องมือบรรทัดคำสั่งใหม่ที่ชื่อ attempt ได้ดึงดูดความสนใจของนักพัฒนาที่กำลังมองหาวิธีที่ดีกว่าในการจัดการกับคำสั่งและบริการที่ไม่เสถียร เครื่องมือนี้ช่วยให้ผู้ใช้สามารถลองใหม่โดยอัตโนมัติเมื่อคำสั่งล้มเหลว พร้อมกลยุทธ์ backoff หลากหลายรูปแบบ ซึ่งตอบสนองต่อปัญหาที่พบบ่อยในการดูแลระบบและการเขียนสคริปต์
คุณสมบัติหลัก
- เรียบง่าย: ชุดฟีเจอร์ขนาดเล็กที่ครอบคลุมกรณีการใช้งานส่วนใหญ่ พร้อมโค้ดเบสที่ตรวจสอบได้
- แข็งแกร่ง: รวมถึงการหมดเวลา การสุ่มหน่วงเวลา และการหน่วงแบบเลขชี้กำลังพร้อมชุดทดสอบที่ครอบคลุม
- ฟรีตลอดไป: ใบอนุญาตสาธารณสมบัติสำหรับทุกเวอร์ชัน
- การจับคู่รูปแบบบน stdout/stderr สำหรับการลองใหม่แบบมีเงื่อนไข
ชุมชนค้นพบโซลูชันทางเลือก
การเปิดตัวครั้งนี้ได้จุดประกายการอภิปรายที่น่าสนใจเกี่ยวกับเครื่องมือที่มีอยู่แล้วในพื้นที่นี้ ผู้ใช้ได้ชี้ให้เห็นทางเลือกหลายตัวอย่างรวดเร็ว โดยมีนักพัฒนาคนหนึ่งกล่าวว่าเขาเพิ่งเลือกใช้ recur เนื่องจากมีความสามารถในการจัดการ input/output ที่เหนือกว่า ทางเลือกยอดนิยมอีกตัวที่เกิดขึ้นในการสนทนาคือเครื่องมือ retry ที่หาได้ง่าย ซึ่งสามารถพบได้ในตัวจัดการแพ็กเกจหลักอย่าง Homebrew และ Debian repositories สิ่งนี้แสดงให้เห็นว่าแม้ปัญหาในพื้นที่นี้จะไม่ใหม่ แต่ยังมีพื้นที่สำหรับนวัตกรรมและแนวทางที่แตกต่างกัน
เครื่องมือทางเลือกที่ได้รับการกล่าวถึง
- recur: มาพร้อมกับ Starlark DSL และการจัดการ stdin/stdout ที่ดีกว่า
- retry: เป็นที่รู้จักอย่างแพร่หลายที่สุด พร้อมใช้งานใน package managers หลัก ( Homebrew , Debian )
- expect: เครื่องมือแบบดั้งเดิมสำหรับการทำงานอัตโนมัติของคำสั่งแบบโต้ตอบ
- โซลูชัน shell แบบกำหนดเองเช่น "wait-for-it.sh" สำหรับ Docker Compose
การอภิปรายเรื่องปรัชญาการออกแบบ
การออกแบบอินเทอร์เฟซของเครื่องมือนี้ได้สร้างการอภิปรายที่มีเหตุผลเกี่ยวกับแบบแผนบรรทัดคำสั่ง Unix บางผู้ใช้ตั้งคำถามว่าทำไมฟีเจอร์ exponential backoff ถึงใช้แนวทาง subcommand แทนที่จะเป็น flag แบบ double-hyphen ตามแบบดั้งเดิม ผู้เขียนอธิบายการเลือกนี้โดยเปรียบเทียบกับโครงสร้าง subcommand ของ Git โดยมองกลยุทธ์ backoff ที่แตกต่างกันเป็นโหมดที่แยกจากกันมากกว่าตัวเลือกธรรมดา การตัดสินใจในการออกแบบนี้สะท้อนคำถามที่ลึกซึ้งกว่าเกี่ยวกับวิธีที่เครื่องมือ CLI สมัยใหม่ควรสร้างสมดุลระหว่างความคุ้นเคยกับฟังก์ชันการทำงาน
การติดตั้งและการใช้งานเบื้องต้น
- ติดตั้งผ่าน:
cargo install attempt-cli - รูปแบบคำสั่งพื้นฐาน:
attempt [BACKOFF] [OPTIONS] [COMMAND]... - ตัวอย่าง:
attempt --retry-if-contains "server not ready" sqlx migrate - รองรับ exponential backoff:
attempt exponential --retry-if-contains "server not ready" sqlx migrate
การแก้ไขปัญหาในโลกจริง
การตอบสนองของชุมชนเผยให้เห็นว่าปัญหาตรรกะการลองใหม่มีความพบเห็นได้ทั่วไปในงานพัฒนาประจำวัน ผู้ใช้แบ่งปันโซลูชันของตนเอง ตั้งแต่ฟังก์ชัน shell แบบกำหนดเองสำหรับการเชื่อมต่อ SSH ไปจนถึงวิธีแก้ปัญหาต่างๆ สำหรับการพึ่งพาบริการ Docker Compose การอภิปรายเน้นย้ำความหงุดหงิดในวงกว้างกับเครื่องมือ orchestration สมัยใหม่ โดยมีผู้ใช้คนหนึ่งสังเกตว่าโครงสร้างพื้นฐานส่วนใหญ่พึ่งพาโซลูชันชั่วคราวและสคริปต์เชื่อมต่อ
ทุกครั้งที่ฉันได้ยินคนชื่นชม orchestrator เหล่านี้ ไม่ว่าจะเป็น Docker, K8, หรืออะไรก็ตาม ฉันจำได้ว่าส่วนใหญ่มันเป็นเรื่องโกหกที่สร้างด้วยกาวและไม้อย่าง wait-for-it.sh
การสนทนายังได้สัมผัสกับฟีเจอร์ที่หายไปจากระบบเก่า โดยมีนักพัฒนาคนหนึ่งรำลึกถึงความสามารถ batch และการควบคุมงานที่แข็งแกร่งที่เคยมีอยู่ในระบบอย่าง VAX VMS แสดงให้เห็นว่าระบบปฏิบัติการสมัยใหม่ยังขาดเครื่องมือความน่าเชื่อถือพื้นฐานบางอย่าง
ข้อจำกัดที่ทราบแล้ว
- สมมติว่าผลลัพธ์เป็นการเข้ารหัส UTF-8 (จะเกิดข้อผิดพลาดเมื่อ UTF-8 ไม่ถูกต้องกับ output predicates)
- ผลลัพธ์ help ไม่แสดงให้เห็นว่ากลยุทธ์ 'fixed' เป็นค่าเริ่มต้น
- ผลลัพธ์ help ที่ยาวอาจส่งผลต่อการค้นหาเอกสารประกอบ
ข้อจำกัดทางเทคนิคและการแลกเปลี่ยน
แม้จะได้รับการตอบรับเชิงบวก แต่ผู้ใช้และผู้เขียนยอมรับข้อจำกัดปัจจุบันบางประการ เครื่องมือนี้สมมติว่าเอาต์พุตเป็น UTF-8 encoded ซึ่งอาจทำให้เกิดการ crash กับโปรแกรมที่ส่งออก UTF-8 ที่ไม่ถูกต้องเมื่อใช้การจับคู่รูปแบบเอาต์พุต ระบบช่วยเหลือยังมีความแปลกประหลาดบางอย่างที่ไม่สะท้อนพฤติกรรมเริ่มต้นอย่างเต็มที่ การอภิปรายที่ตรงไปตรงมาเกี่ยวกับข้อจำกัดเหล่านี้แสดงให้เห็นถึงความชื่นชมของชุมชนต่อความโปร่งใสในการพัฒนาเครื่องมือ
การเกิดขึ้นของ attempt และการอภิปรายรอบๆ มันแสดงให้เห็นว่านักพัฒนายังคงแสวงหาโซลูชันที่ดีกว่าสำหรับปัญหาความน่าเชื่อถือพื้นฐาน แม้ในพื้นที่ที่อาจดูเหมือนได้รับการแก้ไขแล้ว ความหลากหลายของแนวทางและนวัตกรรมที่ดำเนินต่อไปแสดงให้เห็นว่ายังมีพื้นที่สำคัญสำหรับการปรับปรุงในวิธีที่เราจัดการกับระบบและคำสั่งที่ไม่เสถียร