systemd-nspawn: Giải pháp container nhẹ thay thế Docker và máy ảo

systemd-nspawn là công nghệ container dựa trên Linux namespaces, thường được ví như "chroot phiên bản nâng cấp". Khác với Docker tập trung vào quản lý image và phân phối image chỉ đọc, systemd-nspawn dùng hệ thống tệp gốc có thể ghi, vận hành gần giống một máy ảo hơn.

Bài viết dưới đây sẽ hướng dẫn cách thiết lập container systemd-nspawn, từ tạo rootfs, cấu hình mạng đến chia sẻ GPU và giới hạn tài nguyên — những kiến thức hữu ích cho quản trị viên hệ thống và lập trình viên muốn khai thác tối đa công cụ này.

Khi nào nên dùng systemd-nspawn?

Công cụ này đặc biệt hữu ích trong các tình huống sau:

• Cần chạy phần mềm với mức độ cô lập nhất định trên VPS, nơi không thể tạo máy ảo đầy đủ do không hỗ trợ ảo hóa lồng nhau
• Cần chia sẻ quyền truy cập phần cứng, chẳng hạn GPU — đây cũng là lý do tác giả chạy các mô hình LLM trong systemd-nspawn
• Không muốn gánh thêm chi phí vận hành của ảo hóa
• Muốn truy cập trực tiếp một số tệp trên máy chủ mà không cần đến virtiofs
• Thường dùng Docker nhưng không thể hoặc không muốn dùng

Bắt đầu với một chroot

Giống mọi công nghệ container, systemd-nspawn cần một rootfs riêng trong một thư mục. Theo quy ước phổ biến, các rootfs này được đặt tại /var/lib/machines/[tên_host]. Mỗi bản phân phối Linux có cách tạo rootfs riêng:

• Debian/Ubuntu: dùng debootstrap, cài thêm các gói như systemd, dbus, locales, bash-completion và curl
• Fedora/RHEL: dùng dnf với tùy chọn --installroot trỏ tới thư mục đích
• Alpine Linux: dùng alpine-chroot-install hoặc script alpine-nspawn-install do chính tác giả phát triển để loại bỏ những hành vi nguy hiểm của công cụ gốc

Đáng chú ý, dung lượng rootfs chênh lệch rất lớn: Debian khoảng 338 MB, Fedora 507 MB, còn Alpine chỉ vỏn vẹn 16 MB — nhỏ hơn cả một bậc so với hai bản còn lại.

Khởi động container lần đầu

Sau khi cài gói systemd-container, có thể vào shell root của container bằng lệnh:

sudo systemd-nspawn -D /var/lib/machines/[name] -M [name] --private-users=pick --private-users-ownership=chown

Trong đó:

• -D chỉ định thư mục rootfs
• -M đặt tên máy, đồng thời là hostname bên trong container
• --private-users=pick bật namespace UID/GID, tự chọn một dải 65536 UID/GID chưa dùng trên máy chủ
• --private-users-ownership=chown chuyển quyền sở hữu rootfs sang dải UID/GID đã chọn

Lưu ý rằng đây chỉ là shell root tạm thời, chưa có tiến trình init thực sự. Để vận hành lâu dài, cần tạo tệp cấu hình /etc/systemd/nspawn/[tên].nspawn và quản lý bằng machinectl start, machinectl login, machinectl enable...

Cấu hình mạng cho container

systemd-nspawn cung cấp nhiều phương án mạng, phù hợp với từng nhu cầu cô lập và hạ tầng thực tế.

Dùng chung mạng với máy chủ

Đây là tùy chọn mặc định khi gọi trực tiếp systemd-nspawn: container dùng chung mạng với máy chủ, không có cô lập. Cách này dễ thiết lập nhất nhưng không phù hợp nếu cần cô lập. Bật bằng VirtualEthernet=no.

Dùng cầu nối (bridge)

Sơ đồ cầu nối mạng cho container

Cầu nối Linux về bản chất là một switch ethernet ảo. Nếu chạy máy tính sau router tại nhà hoặc có nhiều IP từ nhà cung cấp, có thể gắn giao diện hiện tại (ví dụ eth0) vào bridge, sau đó chuyển cấu hình IP sang giao diện bridge.

Trong tệp .nspawn, dùng Bridge=br_test để nối giao diện ảo host0 bên trong container vào bridge, rồi cấu hình mạng bên trong container tương ứng (tĩnh, DHCP hoặc SLAAC).

Dùng NAT

Sơ đồ NAT mạng cho container

Với VPS chỉ có một địa chỉ IP, có thể tạo bridge với mạng riêng rồi định tuyến qua NAT. Tác giả khuyến nghị cấp một dải /24 ngẫu nhiên trong dải RFC 1918 cho IPv4, và yêu cầu nhà cung cấp cấp một khối /64 cho IPv6.

Sau đó cần bật net.ipv4.ip_forward=1 và net.ipv6.conf.all.forwarding=1, đồng thời thêm quy tắc iptables MASQUERADE hoặc SNAT.

Gắn tệp và thư mục từ máy chủ

Phần [Files] trong tệp .nspawn cho phép gắn tệp hoặc thư mục từ máy chủ vào container:

[Files]
Bind=/srv/example
BindReadOnly=/srv/example:/data
Bind=/srv/example:/test:norbind

Có thể kết hợp các tùy chọn ánh xạ UID như noidmap, idmap, rootidmap và owneridmap để kiểm soát quyền truy cập chính xác. Với POSIX ACL, việc cấp quyền cho một UID cụ thể trong container trở nên đơn giản, ví dụ setfacl -Rm u:13333337:rwX /srv/example.

Chia sẻ GPU với container

Khác với VFIO passthrough trên máy ảo KVM, GPU có thể được chia sẻ giữa máy chủ và nhiều container cùng lúc bằng cách gắn các tệp thiết bị:

• GPU Nvidia: gắn /dev/nvidia0, /dev/nvidiactl, /dev/nvidia-modeset, /dev/nvidia-uvm, /dev/nvidia-uvm-tools, đồng thời cấu hình DeviceAllow trong unit systemd
• GPU Intel và AMD: chỉ cần gắn /dev/dri

Đây chính là cách tác giả cô lập các mô hình LLM chạy trong Ollama và Open WebUI.

Giới hạn tài nguyên

Có thể giới hạn CPU, bộ nhớ và băng thông I/O thông qua cơ chế chuẩn của systemd:

[Service]
CPUQuota=200%
MemoryMax=1G
MemorySwapMax=512M
IOReadBandwidthMax=100M
IOWriteBandwidthMax=100M

Ngoài ra, có thể ghim CPU bằng CPUAffinity trong phần [Exec] của tệp .nspawn.

Kết luận

systemd-nspawn mang lại sự tự do cấu hình gần như một máy ảo, nhưng không kèm chi phí vận hành của ảo hóa. Sau khi xác định được tên và cách cấp phát địa chỉ IP, quản trị viên chỉ cần chạy vài lệnh để chuẩn bị image trong lần khởi động đầu tiên, mọi thứ còn lại gói gọn trong việc chỉnh sửa tệp .nspawn.

Với systemd-nspawn, bạn được tự do thiết lập theo cách mình muốn với toàn quyền kiểm soát. Suy cho cùng, nó giống hệt một máy ảo — bạn có thể làm bất cứ điều gì mình thích.

Đối với đội ngũ DevOps tại Việt Nam đang vận hành VPS hoặc máy chủ tự quản lý, đây là lựa chọn đáng cân nhắc khi Docker không phù hợp và ảo hóa đầy đủ là quá tay.