Nix: ตัวสร้างอิมเมจ Docker ที่เหนือกว่าตัวสร้างอิมเมจของ Docker

 (xeiaso.net)
4 คะแนน โดย GN⁺ 2024-03-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

Nix ดีกว่าตัวสร้างอิมเมจของ Docker

  • Nix มีอยู่สามมิติ: เป็นตัวจัดการแพ็กเกจ ภาษา และระบบปฏิบัติการ
  • การใช้ Nix เพื่อสร้างอิมเมจ Docker มีข้อดีกว่าการใช้ตัวสร้างอิมเมจของ Docker เอง
  • Nix ทำให้รู้ล่วงหน้าได้ว่ากระบวนการบิลด์ต้องใช้ dependency อะไรบ้าง และสามารถบิลด์ได้แม้ไม่มีการเชื่อมต่ออินเทอร์เน็ต

ข้อดีของ Nix

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

ตัวอย่างบริการคำคมของ Douglas Adams

  • อธิบายกระบวนการแพ็กเกจโปรแกรม Go ด้วย Nix และแปลงเป็นอิมเมจ Docker
  • สามารถสร้างอิมเมจแบบ layered ได้ด้วยฟังก์ชัน dockerTools.buildLayeredImage
  • ผลลัพธ์คือได้ container image ทั่วไปที่สามารถนำไป deploy ได้ทุกที่

ความเห็นของ GN⁺

  • การใช้ Nix เป็นวิธีที่ช่วยยกระดับการจัดการ dependency และความสามารถในการทำซ้ำของการบิลด์ในกระบวนการพัฒนาซอฟต์แวร์ได้อย่างมาก
  • เมื่อเทียบกับ Docker แล้ว Nix สามารถประหยัดเวลาและทรัพยากรได้ในระยะยาว เพราะการบิลด์มีความเป็น deterministic
  • อย่างไรก็ตาม แนวคิดและวิธีใช้งานแบบใหม่ของ Nix อาจค่อนข้างยากสำหรับผู้เริ่มต้น และอาจมีความท้าทายในการผสานเข้ากับ CI/CD pipeline เดิม
  • เมื่อนำเทคโนโลยีนี้มาใช้ ควรคำนึงถึงการฝึกอบรมภายในทีม ช่วงเวลาปรับตัว และความเข้ากันได้กับโครงสร้างพื้นฐานเดิม
  • เครื่องมืออื่นที่มีความสามารถคล้ายกับ Nix คือ Guix ซึ่งก็ให้การจัดการแพ็กเกจและการบิลด์แบบ deterministic เช่นกัน

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

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

 
GN⁺ 2024-03-17
ความคิดเห็นบน Hacker News

  • พยายามจะชอบ Nix อยู่หลายครั้ง แต่ตอนนี้คิดว่าถึงเวลาต้องยอมแพ้แล้ว

    • มีอยู่สองระบบที่ใช้ Nix แต่ก็กลัวเกินกว่าจะไปแตะต้องมัน
    • ในทางทฤษฎี Nix เป็นแบบ idempotent และ deterministic แต่ถ้าไม่เข้าใจรายละเอียดของส่วน dependency ทั้งหมดอย่างถ่องแท้ ก็อาจเจอผลลัพธ์แปลก ๆ และข้อความ error ที่ไม่ช่วยอะไร
    • เอกสารแย่มาก และ tutorial ก็ช่วยได้แค่บางส่วน
    • จุดแข็งของ Docker อยู่ที่ความโกลาหลของมันเอง เพราะแค่เข้าใจพื้นฐานของ shell กับ package manager ก็สร้างแทบทุกอย่างได้ง่าย ๆ

  • Nix และ NixOS ตอนนี้มีสภาพคล้ายกับ git ก่อนยุค GitHub

    • แนวคิดพื้นฐานตั้งอยู่บน computer science ที่จริงจังกว่า SVN หรือ Docker ในปัจจุบัน
    • การเปิดตัวของ flox อาจทำให้สถานการณ์เปลี่ยนไป และ flox ก็ใช้งานง่าย
    • ถ้าไม่มี flakes และ nix-command แล้ว Nix ก็แทบไม่มีความหมาย แต่ทั้งสองอย่างยังเป็น experimental และปิดไว้เป็นค่าเริ่มต้น
    • Nix/NixOS หรือสิ่งที่คล้ายกันจะทำให้ Docker ไปอยู่ในสถานะเดียวกัน แต่คงยังไม่เกิดขึ้นจนกว่าจะถึงช่วงเวลาแบบ GitHub moment

  • ใช้เวลา 2-3 วันไปกับการ build Docker image บน Darwin และบทความนี้เหมือนกำลังเยาะเย้ยฉัน

    • Nix เป็นเครื่องมือที่ดีที่สุดสำหรับการทำสิ่งที่ต้องการให้สำเร็จ แต่บางครั้งก็มีมุมมืดที่คอยสูบวิญญาณ

  • บล็อกโพสต์นี้ไม่ได้อธิบายว่าทำไม shared Docker layers ถึงมีประโยชน์

    • มันมีประโยชน์เพราะ caching ยิ่งมี image จำนวนมากที่แชร์ layer เดียวกันได้มากเท่าไร caching ก็ยิ่งทำงานได้ดีขึ้น
    • Nix เก็บ dependency ผ่าน hash อยู่แล้ว ดังนั้น layer จึงเหมือนเดิมเสมอทั้งในแง่เวอร์ชันและคอนฟิก

  • ประสบการณ์การ build Docker image สำหรับ Java application ด้วย Nix ไม่ค่อยน่าพอใจนัก

    • หลังจากที่ gradle2nix ถูกยกเลิกไป ก็ไม่มีวิธีทดแทนที่ชัดเจนสำหรับการ build Docker image ของ Java application ที่ใช้ Gradle

  • มีประโยชน์ถ้าใช้ Nix อยู่แล้ว และหวังว่าโซลูชันจัดการแพ็กเกจแบบ declarative มากขึ้นอย่าง Nix หรือ Guix จะได้รับความนิยมในวงกว้าง

    • ถ้าอยากค่อย ๆ นำ Nix มาใช้ขณะยังใช้ Docker อยู่ ก็มีแนวทางทางเลือกคือ build คอนฟิก Nix โดยยังคงรักษา Dockerfile เอาไว้

  • ในฐานะ platform engineer ก็อยากจะชอบ Nix แต่ก็ไม่ใช่เรื่องง่ายสำหรับทุกคน

    • ตัวอย่างเช่น ชอบการเพิ่มแพ็กเกจแบบ devbox add python@3.11 มากกว่า

  • Nix ไม่ค่อยเข้ากันได้กับ upstream มากนัก จนต้องใช้ความพยายามในการทำแพ็กเกจให้ไลบรารีส่วนใหญ่พอสมควร

    • สำหรับไลบรารี C หรือ C++ ที่ซับซ้อน การห่อทุกอย่างให้ใช้กับ Nix ได้กลายเป็นส่วนงานที่ใหญ่พอสมควร

  • ไม่นานมานี้ลอง build CI base image ด้วย Nix แต่ image ใหญ่เกินไป และบางงานก็ทำงานได้ไม่ถูกต้องเพราะปัญหาเรื่อง linking

    • ถ้าจะ build multi-architecture image มันพยายามจะรันบนสถาปัตยกรรมอื่นจริง ๆ ซึ่งรองรับได้แค่ hardware virtualization ผ่าน qemu

  • กำลังใช้ Dagger อยู่ และมันเป็นความพยายามครั้งที่สองของผู้สร้าง Docker ที่แก้ปัญหาส่วนใหญ่ได้

    • สามารถเขียน pipeline ด้วยภาษาที่ใช้อยู่แล้ว และใช้ประโยชน์จากฟีเจอร์ขั้นสูงของ BuildKit อย่าง layer graph และ advanced caching ได้