Apptainer เผชิญความท้าทายในโลกแห่งความเป็นจริงแม้จะได้รับความนิยมใน HPC

Apptainer ซึ่งเดิมเรียกว่า Singularity ได้กลายเป็นโซลูชันคอนเทนเนอร์ยอดนิยมในสภาพแวดล้อม high-performance computing (HPC) แม้ว่าเทคโนโลยีนี้จะสัญญาว่าจะให้คอนเทนเนอร์ที่ปลอดภัย พกพาได้ และใช้งานง่าย แต่การอภิปรายในชุมชนเมื่อเร็วๆ นี้เผยให้เห็นความท้าทายเชิงปฏิบัติที่สำคัญซึ่งผู้ใช้พบเจอในการใช้งานจริง

อินเทอร์เฟซที่จัดระเบียบแสดงผลลัพธ์คอนเทนเนอร์ Terraform ซึ่งเป็นสัญลักษณ์ของบริบทที่กว้างขึ้นของโซลูชันคอนเทนเนอร์ในสภาพแวดล้อม HPC

การแยกคอนเทนเนอร์สร้างปัญหาในขั้นตอนการพัฒนา

การออกแบบพื้นฐานของคอนเทนเนอร์ Apptainer ได้สร้างอุปสรรคที่ไม่คาดคิดสำหรับทีมพัฒนา ผู้ใช้รายงานว่าการแยกระหว่างคอนเทนเนอร์ทำให้ยากต่อการสร้างเวิร์กโฟลว์แบบโมดูลาร์ที่เครื่องมือต่างๆ ต้องทำงานร่วมกัน เมื่อเครื่องมือสร้างที่จำเป็น เช่น Make, GCC และ Git ถูกวางไว้ในคอนเทนเนอร์แยกกัน พวกมันไม่สามารถโต้ตอบกันได้อย่างมีประสิทธิภาพ สิ่งนี้บังคับให้ทีมต้องบรรจุทุกอย่างลงในคอนเทนเนอร์เดียวขนาดใหญ่ หรือละทิ้งแนวทางแบบคอนเทนเนอร์ไปเลย

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

Apptainer เปรียบเทียบกับโซลูชันคอนเทนเนอร์อื่นๆ

สภาพแวดล้อม HPC ขับเคลื่อนการใช้งานแม้จะมีข้อจำกัด

แม้จะมีความท้าทายเหล่านี้ Apptainer ยังคงถูกใช้งานอย่างแพร่หลายในคลัสเตอร์ HPC หลักๆ รวมถึง Leonardo, LUMI, Fugaku และศูนย์คอมพิวติ้งของมหาวิทยาลัยต่างๆ ความน่าสนใจของเทคโนโลยีนี้ในสภาพแวดล้อมเหล่านี้เกิดจากความสามารถในการทำงานโดยไม่ต้องมีสิทธิ์ root และความเข้ากันได้กับทรัพยากรคอมพิวติ้งที่ใช้ร่วมกัน ต่างจาก Docker หรือ Podman คอนเทนเนอร์ Apptainer สามารถอยู่ได้ทั้งหมดภายในไดเรกทอรีโฮมของผู้ใช้บนระบบไฟล์เครือข่าย หลีกเลี่ยงความจำเป็นในการใช้พื้นที่ดิสก์ในเครื่องที่มักจะจำกัดบนโหนดคอมพิวต์

บนโหนดคอมพิวต์ / อาจจะเป็น nvme 500gb นั่นคือดิสก์ทั้งหมดที่มี ผู้ใช้เมาท์ $home ของพวกเขาผ่าน nfs และได้รับโควต้าที่เรากำหนด อาจเป็นหลายร้อย tb

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

คลัสเตอร์ HPC หลักที่ใช้ Apptainer/Singularity

• Leonardo (EuroHPC)
• LUMI (EuroHPC)
• Fugaku (Japan)
• NeSI (New Zealand)
• Levante (Germany)
• ศูนย์คอมพิวติ้งของมหาวิทยาลัยต่างๆ ทั่วโลก

ความแตกต่างทางเทคนิคปรากฏระหว่าง Apptainer และ Singularity CE

ระบบนิเวศคอนเทนเนอร์ได้กลายเป็นเรื่องซับซ้อนมากขึ้นหลังจากการแยกโปรเจกต์ Singularity ต้นฉบับ Apptainer เป็นตัวแทนของการดำเนินโปรเจกต์ต้นฉบับต่อภายใต้ Linux Foundation ในขณะที่ Sylabs ดูแล Singularity CE เป็นฟอร์กแยกต่างหาก แม้ว่าทั้งสองระบบจะยังคงเข้ากันได้ส่วนใหญ่ แต่ความแตกต่างเล็กๆ น้อยๆ กำลังปรากฏขึ้นซึ่งส่งผลต่อการใช้งานจริง

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

โซลูชันทางเลือกได้รับความสนใจ

ความยากลำบากเชิงปฏิบัติกับ Apptainer ได้นำไปสู่การที่องค์กรบางแห่งสำรวจแนวทางทางเลือก ระบบโมดูลแบบดั้งเดิม เช่น TCL (ปัจจุบันคือ Lua) modules กำลังกลับมาได้รับความนิยม โดยเสนอการบูรณาการที่ดีกว่าระหว่างคอมโพเนนต์ซอฟต์แวร์ต่างๆ โดยไม่มีการลงโทษจากการแยกของคอนเทนเนอร์ ระบบเหล่านี้อนุญาตให้ผสมและจับคู่เครื่องมือและเวอร์ชันต่างๆ ในขณะที่รักษาสภาพแวดล้อมที่สามารถทำซ้ำได้

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

ความท้าทายที่ดำเนินต่อไปกับ Apptainer สะท้อนคำถามที่กว้างขึ้นเกี่ยวกับบทบาทของคอนเทนเนอร์ในสภาพแวดล้อมคอมพิวติ้งทางวิทยาศาสตร์ ที่ความต้องการในการทำซ้ำได้ต้องสมดุลกับความต้องการเชิงปฏิบัติของเวิร์กโฟลว์ที่ซับซ้อนและเชื่อมต่อกัน

อ้างอิง: EMPOWER YOUR APPLICATIONS.