ระบบ init แบบเบาใหม่ที่ชื่อ Nitro ได้จุดประกายการอภิปรายในชุมชนนักพัฒนา ไม่เพียงแค่เรื่องคุณสมบัติทางเทคนิคเท่านั้น แต่ยังรวมถึงปัญหาชื่อซ้ำและการถกเถียงเกี่ยวกับรูปแบบการใช้งาน container ที่เหมาะสม
Nitro วางตำแหน่งตัวเองเป็น process supervisor ขนาดเล็กแต่ยืดหยุ่นที่สามารถทำหน้าที่เป็น PID 1 บนระบบ Linux ซึ่งสร้างโดย Leah Neukirchen โดยได้รับแรงบันดาลใจจากระบบที่มีอยู่แล้วอย่าง runit, daemontools และ s6 โดยเสนอแนวทางไบนารีเดียวแบบครบครันสำหรับการจัดการ process
คุณสมบัติหลักของ Nitro :
- ไฟล์ปฏิบัติการเดียวที่ครบครันในตัวเอง (พร้อมไฟล์ควบคุมเสริมที่เป็นตัวเลือก)
- ไม่มีการจัดสรรหน่วยความจำระหว่างการทำงาน
- การทำงานแบบขับเคลื่อนด้วยเหตุการณ์ ปราศจากการสำรวจข้อมูล
- ทำงานได้บนระบบไฟล์รากที่อ่านได้อย่างเดียว
- รองรับบริการที่มีพารามิเตอร์ด้วยไวยากรณ์
@ - เข้ากันได้กับ Linux , FreeBSD และสภาพแวดล้อมคอนเทนเนอร์
ความกังวลเรื่องชื่อซ้ำเริ่มปรากฏขึ้น
ชุมชนได้แสดงความกังวลอย่างมากเกี่ยวกับการเลือกชื่อของ Nitro ซึ่งขัดแย้งกับเทคโนโลยีที่มีอยู่หลายตัว AWS Nitro Enclaves ซึ่งเป็นเทคโนโลยี virtualization ที่เน้นความปลอดภัยใช้ชื่อเดียวกัน ทำให้เกิดความสับสนที่อาจเกิดขึ้นสำหรับผู้ใช้ที่ทำงานในสภาพแวดล้อม cloud นอกจากนี้ยังมี Node.js server engine ยอดนิยมที่ชื่อ Nitro อยู่แล้วที่ nitro.build
นักพัฒนาคนหนึ่งได้เน้นย้ำถึงผลกระทบในทางปฏิบัติของการซ้ำซ้อนนี้ โดยระบุว่าพวกเขาใช้ระบบ init ขนาดเล็กภายใน AWS Nitro Enclaves เป็นประจำ ทำให้การใช้ชื่อร่วมกันเป็นปัญหาเป็นพิเศษ ชุมชนแนะนำว่าชื่อที่เป็นเอกลักษณ์และออกเสียงได้อย่าง systemd, runit หรือ s6 ทำงานได้ดีกว่าสำหรับการค้นหาและหลีกเลี่ยงความสับสน
ความขัดแย้งในการตั้งชื่อ:
- AWS Nitro : แพลตฟอร์มเสมือนจริงและความปลอดภัยสำหรับ cloud computing
- Nitro.js : เครื่องมือ server สำหรับแอปพลิเคชัน Node.js (nitro.build)
- Nitro นี้: ระบบ init และตัวควบคุมกระบวนการของ Linux
ความแตกแยกทางปรัชญาของระบบ Init ใน Container
การประกาศนี้ได้จุดประกายการถกเถียงเกี่ยวกับการรันระบบ init ภายใน container ขึ้นมาใหม่ แม้ว่า Nitro จะรองรับการใช้งานใน container อย่างชัดเจน แต่นักพัฒนายังคงแบ่งแยกในแนวทางนี้ บางคนโต้แย้งว่า container ควรปฏิบัติตามปรัชญา Unix และทำสิ่งหนึ่งให้ดี โดยตั้งคำถามว่าการตั้งค่า multi-process ที่ซับซ้อนควรอยู่ใน container เดียวหรือไม่
อย่างไรก็ตาม ข้อพิจารณาเชิงปฏิบัติมักจะเหนือกว่าความบริสุทธิ์ทางทฤษฎี ในสถานการณ์ robotics และการย้าย legacy system นักพัฒนามักต้องการ containerize แอปพลิเคชัน multi-process ที่มีอยู่ซึ่งไม่ได้ออกแบบมาสำหรับสถาปัตยกรรม cloud-native สถานการณ์เหล่านี้สร้างความต้องการระบบ init แบบเบาที่สามารถจัดการ process หลายตัวภายใน container เดียว
จากประสบการณ์ของฉันในด้าน robotics container หลายตัวเริ่มต้นชีวิตจากสิ่งที่เคยเป็น bare metal แล้วเราย้ายมันเข้าไปใน container และด้วย unstructured RPC จำนวนมากที่เกิดขึ้นระหว่าง process จึงมีประโยชน์เพียงเล็กน้อยในการแยก process ออกเป็น container แยกกัน
การเปรียบเทียบทางเทคนิคกับโซลูชันที่มีอยู่
สมาชิกชุมชนกำลังเปรียบเทียบ Nitro กับทางเลือกที่มีอยู่แล้วอย่าง runit, s6 และ dinit อย่างแข็งขัน Nitro มีความคล้ายคลึงกับ runit หลายประการ รวมถึงการกำหนดค่าแบบ directory-based และการจัดการบริการแบบ script-driven อย่างไรก็ตาม มันได้แนะนำคุณสมบัติเฉพาะบางอย่างเช่น parametrized services ซึ่งอนุญาตให้ process ที่คล้ายกันหลายตัวถูกควบคุมโดย service directory เดียว
จุดแตกต่างหลักดูเหมือนจะเป็นแนวทางไบนารีเดียวของ Nitro ซึ่งตรงข้ามกับ utilities หลายตัวของ runit นักพัฒนาบางคนชื่นชมความเรียบง่ายนี้ ในขณะที่คนอื่นตั้งคำถามว่ามันให้ข้อได้เปรียบเพียงพอเหนือระบบที่มีชื่อเสียงแล้วอย่าง runit ซึ่งถูกใช้งานสำเร็จแล้วใน distribution อย่าง Void Linux
การอภิปรายเผยให้เห็นความสนใจอย่างต่อเนื่องในระบบ init แบบเบา โดยเฉพาะสำหรับการใช้งาน embedded, container และเฉพาะทาง อย่างไรก็ตาม ความขัดแย้งด้านชื่อและการถกเถียงทางปรัชญาชี้ให้เห็นว่าการยอมรับอาจเผชิญอุปสรรคนอกเหนือจากคุณค่าทางเทคนิค ขณะที่ระบบนิเวศ container ยังคงพัฒนาต่อไป ความสมดุลระหว่างความเรียบง่ายและการแยกสถาปัตยกรรมที่เหมาะสมยังคงเป็นหัวข้อที่ถกเถียงกันในหมู่นักพัฒนา
อ้างอิง: nitro, a tiny but flexible init system and process supervisor