Apptainer - คอนเทนเนอร์แอปพลิเคชันสำหรับลินุกซ์

 (github.com/apptainer)
14 คะแนน โดย xguru 2025-06-27 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • แพลตฟอร์มคอนเทนเนอร์โอเพนซอร์ส ที่ออกแบบโดยเน้น ความเรียบง่าย/ความเร็ว/ความปลอดภัย
    • เหมาะอย่างยิ่งสำหรับสภาพแวดล้อม HPC (การประมวลผลสมรรถนะสูง) และ ระบบที่ใช้งานร่วมกัน
  • มี ฟอร์แมตอิมเมจคอนเทนเนอร์แบบไฟล์เดี่ยวชนิด Immutable พร้อมรองรับ การเข้ารหัสและการลงลายเซ็น
  • มุ่งเน้น การใช้งานร่วมกับระบบอย่างกลมกลืน มากกว่าการแยกตัว ทำให้สามารถใช้ GPU, เครือข่ายความเร็วสูง, และระบบไฟล์แบบขนานได้ทันทีในสภาพแวดล้อมคลัสเตอร์/เซิร์ฟเวอร์
  • สามารถดึงคอนเทนเนอร์ทั้งหมดจากรีจิสทรี OCI (Open Containers Initiative) ได้ และ เพิ่มความเข้ากันได้กับ Docker ให้สูงสุด
    • รองรับให้สามารถ pull, run และ build คอนเทนเนอร์ส่วนใหญ่บน Docker Hub ได้โดยไม่ต้องแก้ไข
  • เปลี่ยนชื่อมาจาก Singularity และย้ายมาเป็นโครงการของ Linux Foundation
  • เป็นคอนเทนเนอร์ไฟล์เดี่ยวบนพื้นฐาน SIF (Singularity Image Format) ที่ทำให้ย้าย แจกจ่าย และแชร์ได้อย่างง่ายดาย
  • ใช้ โมเดลความปลอดภัยที่ปลอดภัย โดยสิทธิ์ผู้ใช้ภายในและภายนอกคอนเทนเนอร์เป็นสิทธิ์เดียวกัน และโดยค่าเริ่มต้นไม่สามารถยกระดับสิทธิ์เพิ่มเติมจากโฮสต์ได้
  • ใบอนุญาต BSD

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
galadbran 2025-06-27

บทความ unregistry ที่ถูกพูดถึงในความคิดเห็นบน Hacker News:
Unregistry – ส่ง docker push ไปยังเซิร์ฟเวอร์โดยตรงโดยไม่ต้องมีรีจิสทรี | GeekNews
 
GN⁺ 2025-06-27
ความคิดเห็นบน Hacker News

  • ทีมของเราเคยลองใช้ Apptainer บนคอมพิวต์คลัสเตอร์สำหรับงานออกแบบ/ตรวจสอบซิลิคอน แต่สุดท้ายก็กลับไปใช้โมดูล TCL(ย้ายไปใช้ Lua) แบบดั้งเดิม

    • เจอปัญหาหลายอย่าง
      • อย่างแรก คอนเทนเนอร์ใช้ของกันและกันไม่ได้ ตัวอย่างเช่น ถ้าเครื่องมืออย่าง Make, GCC, Git อยู่คนละ Apptainer พอเข้าไปใน Make ก็จะมองไม่เห็น GCC
      • อย่างที่สอง ถ้ามีผลลัพธ์ที่พึ่งพาสิ่งภายในคอนเทนเนอร์ มันจะทำงานได้ไม่ถูกต้อง เช่น เมื่อ build โปรแกรมด้วย GCC Apptainer ไบนารีที่ build ได้จะลิงก์กับไลบรารีภายใน Apptainer จนรันไม่ได้ และยังมีปัญหาเรื่อง C header ด้วย
      • อย่างที่สาม ค่า PATH มักจะยุ่งอยู่เรื่อย ทำให้มองไม่เห็นพาธหรือเครื่องมือที่จำเป็นนอก Apptainer ซ้ำแล้วซ้ำอีก
      • โดยรวมแล้วแนวคิดดี แต่ในแง่ การใช้งานจริง กลับมีแต่ความยุ่งยาก สุดท้ายการใช้ OS รุ่นเก่า(RHEL8) โดยตรงกลับง่ายกว่ามาก
    • ผมมองว่า Apptainer/Singularity คล้ายกับ Docker มาก (แค่ไม่มีการตั้งค่าเครือข่ายแบบเต็มรูปแบบ) ปัญหาแบบนี้ก็เกิดเหมือนกันใน Docker คอนเทนเนอร์แบบดั้งเดิม
      • ในเวิร์กโฟลว์ HPC ของผม ผมใช้ Apptainer เป็นตัวแทน Docker แบบเสียบแทนได้เลย และสำหรับงานลักษณะนี้มันเหมาะมาก
      • จุดเด่นที่สุดของ Apptainer คือเป็น คอนเทนเนอร์แบบ non-root ทำให้ทำเครือข่ายซับซ้อนไม่ได้ แต่ก็ ปลอดภัย กว่ามากในสภาพแวดล้อม multi-tenant อย่าง HPC
    • ถ้าความไม่พอใจที่ใหญ่ที่สุดจากการใช้แอปแบบคอนเทนเนอร์คือมัน ทำงานเหมือนคอนเทนเนอร์ นั่นก็เป็นธรรมชาติของคอนเทนเนอร์
    • ไม่ควรเอาชิ้นส่วนคอนเทนเนอร์มาปะปนกันใช้ เหมือนกับที่เราไม่เอาไบนารีจากลินุกซ์ดิสโทรต่างกันมาผสมกัน
      • คอนเทนเนอร์เหมาะที่สุดเมื่อใช้พัฒนาในสภาพแวดล้อมที่รวมเป็นชุดเดียว เพราะคอนเทนเนอร์คือ สภาพแวดล้อมแบบแยกขาด ดังนั้นไม่ว่าจะคอมไพล์อะไรก็ควรให้ผลลัพธ์อยู่ในคอนเทนเนอร์ของมันเอง
      • อย่างไรก็ดี สามารถสร้างหลายคอนเทนเนอร์จาก base image เดียวกันเพื่อให้ไฟล์เข้ากันได้เช่นกัน (แต่ต้องใส่ dependency ที่จำเป็นทั้งหมดไว้เท่านั้น)

  • ดีใจที่ Apptainer ได้รับความสนใจ เพราะในบางสถานการณ์มันดีกว่า Docker, Podman เป็นต้น

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

  • docker ก็แจกจ่ายแบบ ไฟล์เดียว ได้ด้วยคำสั่ง docker save และ docker load

    • แม้จะไม่รองรับเดลตา แต่ไม่นานมานี้มีลิงก์โซลูชันชื่อ "unregistry" บน HN ซึ่งทำให้ใช้ความสามารถแบบ "docker push" และ สะท้อนเดลตา ได้ โดยไม่ต้องมี Docker Registry

  • ทั้ง Apptainer และ singularity ce ถูกใช้กันทั่วไปใน HPC ทั้งสองตัวแยกสายมาจาก โครงการ Singularity เดิม แต่ไม่เหมือนกันทั้งหมด

    • เราใช้ singularity บนซูเปอร์คอมพิวเตอร์(HPC) หลายเครื่อง และนักวิจัยบางคนก็ติดตั้ง Apptainer ไว้ใช้ในเครื่องตนเอง
    • ไม่นานมานี้พบ บั๊กเขตเวลา ในโค้ด Python (matplotlib, xarray ฯลฯ) โดยมีปัญหาใน singularity ce แต่ทำงานถูกต้องใน Apptainer
    • Apptainer รุ่นใหม่ยังมีโค้ดเบสที่คล้ายกัน แต่มีการนำการแก้บั๊กเข้ามาได้เร็วกว่า ตัวอย่างเช่น singularity เคยเกิดปัญหาเพราะ เขียนทับเขตเวลาของผู้ใช้ ลงในระบบ
    • ลิงก์อ้างอิง: singularity issue #3686
    • Apptainer ไม่ใช่ fork ของโครงการ Singularity เดิม Apptainer คือโครงการหลักดั้งเดิม เพียงแค่เปลี่ยนชื่อจากการโหวตของชุมชน แล้วก็ย้ายไปอยู่ภายใต้ Linux Foundation
      • กรณีที่ Sylabs ดึงนักพัฒนาดั้งเดิมไปแล้ว fork โครงการออกมาคือ singularity ce
      • ดูเพิ่มเติม: community announcement
    • ถึงอย่างนั้น ความเข้ากันได้ของคอนเทนเนอร์ ยังรักษาไว้ ทำให้ build บน Apptainer แล้วไปรันบน Singularity ได้ (และกลับกันก็เช่นกัน)

  • Apptainer ก็คือ Singularity ในชื่อใหม่ งานวิจัยที่เกี่ยวข้องอยู่ที่นี่

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

  • Flatpak กำลังจะเปลี่ยนจาก OSTree ไปสู่แนวทางที่อิงคอนเทนเนอร์ เขาบอกว่าจุดเด่นใหญ่คือมี tooling ฝั่งคอนเทนเนอร์ที่ได้รับการดูแลรักษาอยู่เสมอ แต่ก็สงสัยว่ามันต่างจาก Apptainer อย่างไร

    • น่าจะเป็นเพราะ Flatpak มีจุดเด่นที่ ควบคุม sandbox ของแอปแต่ละตัว ได้ เช่น การแยก permission แบบละเอียด ผ่าน xdg-dbus จึงใช้งานได้ใกล้เคียงแอปเนทีฟ
      • ไม่แน่ใจว่า Apptainer แยกหรือกักกันได้สมบูรณ์ในระดับนั้นหรือไม่
      • ถ้าใช้เครื่องมืออย่าง containertoolbx ความแตกต่างของแนวทางคอนเทนเนอร์ก็แทบไม่มีความหมาย
      • พูดตามตรง ฟีเจอร์ของเครื่องมือต่าง ๆ ก็ทับซ้อนกันมาก แต่ผมคิดว่านั่นก็ไม่ใช่เรื่องเสียหาย

  • ในสภาพแวดล้อมที่ผมใช้อยู่ เป้าหมายหลักของการใช้ Apptainer ไม่ได้เกี่ยวกับการแจกจ่าย การแยก หรือความพร้อมใช้งานของซอฟต์แวร์

    • HPC คลัสเตอร์ของเรามี โควตา inode จำกัด ต่อผู้ใช้แต่ละคน ทำให้ติดตั้งซอฟต์แวร์ที่มีไฟล์จำนวนมาก (เช่น Anaconda) ได้ยาก
    • แต่ image ของ Apptainer เป็น ไฟล์เดียวบนพื้นฐาน squashfs จึงเก็บได้หลายอันโดยไม่ต้องกังวลเรื่องโควตา inode
    • โดยปกติการติดตั้งซอฟต์แวร์แบบทั่วไปอาจง่ายกว่า แต่โควตาจะหมดอย่างรวดเร็ว

  • เห็นด้วยกับความเห็นของ Havoc ข้อความมันกำกวมว่า Apptainer เป็นตัวแทน Flatpak สำหรับเดสก์ท็อป หรือเป็นของฝั่งเซิร์ฟเวอร์กันแน่

    • เป็นของฝั่งเซิร์ฟเวอร์ แต่ตัวคำถามเองก็กำกวม
      • Apptainer มีไว้สำหรับ รันแอป CLI ในคอนเทนเนอร์แบบ immutable และ rootless
      • เครื่องมือที่ใกล้เคียงที่สุดคือ Fedora Toolbx
      • การใช้งานหลักของ Apptainer คือ การแจกจ่ายและนำเครื่องมือสำหรับงานคำนวณเชิงวิทยาศาสตร์กลับมาใช้ซ้ำ ใช้ได้โดยไม่ต้องมีสิทธิ์ root, เปลี่ยน rootfs ของแต่ละคอนเทนเนอร์ไม่ได้, เมานต์ไดเรกทอรีทำงานให้อัตโนมัติ และรองรับ GPU ได้ดีด้วย (อันนี้ยังไม่ได้ทดสอบเอง)
      • อ้างอิง: Fedora Toolbx

  • ชื่อ "Apptainer" ออกเสียงแปลก และให้ความรู้สึกเหมือนมีอะไรไม่ค่อยถูกต้อง

  • ถ้าเป็นนักพัฒนา คุณอาจกำลังมองหา เครื่องมือคอนเทนเนอร์สำหรับการแยกสภาพแวดล้อม

    • ผมเคยทำเครื่องมือบนพื้นฐาน Podman เพื่อแยกแต่ละโปรเจกต์พัฒนาออกจากกัน ถ้าสนใจใช้หรือทดสอบด้านความปลอดภัย ดูได้ที่ โค้ด หรือ บทความบล็อก
    • อยากรู้ว่าทำไม toolbox ถึงยังไม่เพียงพอ
      • สำหรับผม toolbox ก็โอเค เพราะเวลาติดตั้งสภาพแวดล้อมพัฒนารายโปรเจกต์ ไม่ต้องคอยจัดการไฟล์ซิสเต็มแอบแฝงหลายชุด

  • มีประโยชน์มากบน SLURM คลัสเตอร์และเซิร์ฟเวอร์ที่ไม่มีสิทธิ์ root

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