Containerization

Container hóa là phương pháp đóng gói phần mềm, trong đó ứng dụng cùng mọi thành phần cần thiết để chạy, bao gồm môi trường chạy, thư viện, gói hệ thống và cấu hình, được gộp vào một image chạy dưới dạng tiến trình cô lập gọi là container. Mỗi container có hệ thống tệp, cây tiến trình và giao diện mạng riêng, trong khi tất cả container trên một máy chủ dùng chung kernel hệ điều hành của máy chủ đó; nhờ vậy, container nhẹ hơn nhiều so với máy ảo. Trong machine learning (ML), container hóa loại bỏ xung đột giữa các dự án cần phiên bản Python, CUDA hoặc PyTorch khác nhau, đồng thời cho phép model được huấn luyện trên máy trạm chạy nguyên trạng trên máy chủ, cụm máy hoặc thiết bị điện toán biên.

Cách container hoạt động#

Container Linux chủ yếu được xây dựng dựa trên hai tính năng của kernel. Namespace kiểm soát những gì một tiến trình có thể nhìn thấy, cấp cho tiến trình ID tiến trình, network stack, điểm gắn kết và người dùng riêng; còn cgroup (nhóm điều khiển) kiểm soát những gì tiến trình có thể sử dụng bằng cách giới hạn CPU, bộ nhớ và I/O. Ý tưởng này bắt nguồn từ chroot năm 1979 và jail của FreeBSD năm 2000; cgroup được đưa vào kernel Linux năm 2008, còn Docker giúp container trở nên phổ biến vào năm 2013. Sáng kiến Container Mở (OCI), thành lập năm 2015, đã chuẩn hóa định dạng image và runtime, nhờ đó image được xây dựng bằng một công cụ có thể chạy bằng công cụ khác.

Runtime container đảm nhiệm công việc thực thi. Runtime cấp cao như containerd và CRI-O tải image và quản lý vòng đời container; runtime OCI cấp thấp như runc tạo namespace và cgroup rồi khởi chạy tiến trình. Vì container Linux cần kernel Linux, macOS và Windows chạy container bên trong một máy ảo Linux nhỏ.

Image, lớp và registry#

Image là một chồng các lớp chỉ đọc cùng cấu hình chỉ định lệnh cần chạy. Khi khởi động, runtime hợp nhất các lớp thành một hệ thống tệp, thường bằng OverlayFS, rồi thêm một lớp ghi mỏng cho container đó; nhờ vậy, nhiều container có thể dùng chung một bản sao image trên đĩa. Registry như Docker Hub, GitHub Container Registry và registry của từng nhà cung cấp đám mây lưu image theo tag như latest và theo digest nội dung, tức mã băm SHA-256 luôn định danh cùng một chuỗi byte. Quá trình build tái sử dụng các lớp không thay đổi; đó là lý do Dockerfile cài đặt dependency trước khi sao chép code thường xuyên được chỉnh sửa:

Container hóa trong quy trình ML#

Trong pipeline MLOps, container đưa project từ thử nghiệm đến production. Các image framework như image trong NVIDIA NGC Catalog cố định phiên bản CUDA, cuDNN và framework, để mọi node trong một job huấn luyện phân tán chạy cùng phần mềm; máy chủ chỉ cung cấp driver GPU, được NVIDIA Container Toolkit đưa vào container. Các bài kiểm thử tích hợp liên tục chạy bên trong chính image sẽ được phát hành sau đó; inference server cho phục vụ model chạy dưới dạng image để Kubernetes nhân bản và mở rộng theo lưu lượng; còn thiết bị AI edge như bo mạch NVIDIA Jetson cập nhật model bằng cách tải tag image mới.

Tích hợp tại chỗ của Ultralytics Platform dành cho workspace Enterprise sẽ cài Docker nếu cần và chạy một container worker từ image Ultralytics chính thức phù hợp với phần cứng ARM64, CPU hoặc GPU NVIDIA của máy chủ. Worker gắn thư mục bộ dữ liệu ở chế độ chỉ đọc, nhờ đó ảnh nguồn vẫn nằm trên máy tính đó, còn các chỉ số huấn luyện và checkpoint tốt nhất của mỗi lượt chạy YOLO26 được gửi lên Platform.

Container và máy ảo#

Máy ảo chạy một hệ điều hành khách hoàn chỉnh với kernel riêng trên hypervisor, vì vậy mỗi VM chứa image hệ điều hành có dung lượng vài gigabyte và khởi động như một máy tính riêng. Container là một tiến trình thông thường trên kernel dùng chung của máy chủ, nên khởi chạy nhanh như ứng dụng và chỉ bổ sung các tệp riêng. Việc dùng chung kernel cũng đồng nghĩa lỗ hổng kernel có thể làm lộ mọi container trên máy chủ; vì vậy, hai công nghệ này thường được kết hợp: đám mây công cộng chạy container của khách hàng bên trong VM, còn runtime sandbox bổ sung một lớp ranh giới cho code không đáng tin cậy, chẳng hạn code do tác tử AI viết và chạy trong sandbox tác tử. gVisor của Google chặn các system call của container bằng kernel riêng trong không gian người dùng. Kata Containers chạy từng container bên trong một máy ảo gọn nhẹ, còn AWS xây dựng microVM Firecracker để cô lập các hàm AWS Lambda theo cách tương tự.