Nix, trình xây dựng image Docker tốt hơn trình xây dựng image của Docker

Nix tốt hơn trình xây dựng image của Docker

• Nix có ba khía cạnh: trình quản lý gói, ngôn ngữ và hệ điều hành.
• Dùng Nix để tạo image Docker có những điểm tốt hơn trình xây dựng image của chính Docker.
• Nix cho phép biết trước mọi phụ thuộc cần thiết trong quá trình build và có thể build ngay cả khi không có kết nối Internet.

Lợi ích của Nix

• Dùng Nix có thể tạo image Docker hiệu quả hơn.
• Nix chia các phụ thuộc thành số lượng layer Docker tối thiểu để khi cập nhật chỉ phản ánh những thay đổi tối thiểu.
• Khi nhiều dịch vụ cùng nằm trong một kho lưu trữ, các Docker layer có thể được chia sẻ với nhau nên hiệu quả hơn.

Ví dụ dịch vụ trích dẫn của Douglas Adams

• Bài viết giải thích quá trình đóng gói một chương trình Go bằng Nix và chuyển nó thành image Docker.
• Có thể tạo image dạng layer bằng hàm dockerTools.buildLayeredImage.
• Kết quả là thu được một image container thông thường và có thể triển khai nó ở bất cứ đâu.

Ý kiến của GN⁺

• Sử dụng Nix là một cách có thể cải thiện đáng kể việc quản lý phụ thuộc và tính tái lập của quá trình build trong phát triển phần mềm.
• So với Docker, Nix có thể tiết kiệm thời gian và tài nguyên về lâu dài nhờ tính quyết định của quá trình build.
• Tuy nhiên, các khái niệm mới và cách sử dụng của Nix có thể hơi khó với người mới bắt đầu, và việc tích hợp vào pipeline CI/CD hiện có cũng có thể gặp khó khăn.
• Khi áp dụng công nghệ này, cần có thời gian đào tạo và thích nghi trong nhóm, đồng thời phải cân nhắc khả năng tương thích với hạ tầng hiện tại.
• Một công cụ khác cung cấp chức năng tương tự Nix là Guix, công cụ này cũng cung cấp quản lý gói và build mang tính quyết định.

[GN⁺]

Ý kiến Hacker News

• Tôi đã nhiều lần cố gắng để có thiện cảm với Nix, nhưng giờ tôi nghĩ đã đến lúc phải bỏ cuộc.

  • Tôi có hai hệ thống dùng Nix, nhưng lại sợ đụng vào chúng.
  • Về mặt lý thuyết, Nix có tính idempotent và deterministic, nhưng nếu không hiểu chính xác toàn bộ phần phụ thuộc thì bạn có thể gặp những kết quả kỳ lạ và các lỗi không hữu ích.
  • Tài liệu cực kỳ tệ, còn tutorial chỉ hữu ích được một phần.
  • Điểm mạnh của Docker nằm ở chính sự hỗn độn đó: chỉ với hiểu biết cơ bản về shell và trình quản lý gói, bạn có thể dễ dàng xây dựng gần như mọi thứ.

• Nix và NixOS đang ở trạng thái giống như git trước thời GitHub.

  • Ý tưởng cốt lõi dựa trên khoa học máy tính nghiêm túc hơn so với SVN hay Docker hiện nay.
  • Có thể mọi thứ đã thay đổi với sự ra mắt của flox, và flox thì dễ dùng.
  • Nếu không có flakes và nix-command thì Nix gần như không có ý nghĩa, nhưng chúng lại đang ở trạng thái thử nghiệm và bị tắt mặc định.
  • Nix/NixOS hoặc thứ gì đó tương tự rồi sẽ đưa Docker vào trạng thái như vậy, nhưng sẽ không xảy ra trước khi có “khoảnh khắc GitHub”.

• Tôi đã mất 2-3 ngày để build image Docker trên Darwin, và bài viết này như thể đang chế nhạo tôi.

  • Nix là công cụ tốt nhất để đạt được điều bạn muốn, nhưng đôi khi nó có những góc tối hút cạn linh hồn.

• Bài blog không giải thích vì sao các Docker layer dùng chung lại hữu ích.

  • Chúng hữu ích vì caching. Càng nhiều image chia sẻ cùng một layer thì caching càng hiệu quả.
  • Nix vốn đã lưu dependencies qua hash, nên layer sẽ luôn giống hệt nhau với cùng phiên bản và cấu hình.

• Trải nghiệm build image Docker cho ứng dụng Java bằng Nix không mấy dễ chịu.

  • Sau khi gradle2nix bị khai tử, không còn phương án thay thế rõ ràng nào để build image Docker cho ứng dụng Java dùng Gradle.

• Điều này hữu ích nếu bạn đã áp dụng Nix, và tôi hy vọng các giải pháp quản lý gói mang tính khai báo hơn như Nix hay Guix sẽ trở nên phổ biến.

  • Nếu bạn muốn dần dần áp dụng Nix trong khi vẫn dùng Docker, thì có một cách tiếp cận thay thế là giữ nguyên Dockerfile và build cấu hình Nix.

• Với tư cách là một platform engineer, tôi rất muốn thích Nix, nhưng nó không hề dễ với tất cả mọi người.

  • Ví dụ, tôi thích cách thêm gói kiểu devbox add python@3.11 hơn.

• Nix không tương thích với upstream đến mức hầu hết thư viện đều cần rất nhiều công sức để đóng gói.

  • Với các thư viện C hoặc C++ phức tạp, việc bọc mọi thứ lại cho Nix trở thành một phần công việc khá lớn.

• Gần đây tôi đã thử build base image CI bằng Nix, nhưng image quá lớn, và vì các vấn đề linking nên một số tác vụ không hoạt động đúng.

  • Để build image đa kiến trúc, bạn thực sự phải chạy trên kiến trúc khác, mà việc đó chỉ được hỗ trợ qua ảo hóa phần cứng dùng qemu.

• Tôi đang dùng Dagger, và đây là nỗ lực thứ hai của những người tạo ra Docker để giải quyết phần lớn các vấn đề đó.

  • Bạn có thể viết pipeline bằng chính ngôn ngữ mình đang dùng, đồng thời tận dụng được các tính năng nâng cao của BuildKit như đồ thị layer và caching nâng cao.