Thời gian qua có khá nhiều thay đổi ở Ivy nhưng do lười viết nên không có những cập nhật cụ thể. Tiện đây đang rảnh rang một chút trước khi bận rộn và vừa có thay đổi toàn bộ nên có Post này.

Có một dạo các CT Podman trong Ivy chuyển sang sử dụng rootful mode, tất nhiên ít lằng nhằng hơn rootless mode và cho kết quả rất tốt. Tuy nhiên dự trù cho tình huống xấu về bảo mật xảy ra nên toàn bộ CT Podman trong Ivy một lần nữa chuyển sang rootless mode. Ngoài ra có thêm vài CT dành cho từng mục đích sử dụng cụ thể hơn và toàn bộ Ivy được nâng cấp lên phiên bản mới nhất.

Podman
– Podman 5.6.0, sử dụng crun thay cho runc vì tốn ít tài nguyên hơn mà hiệu năng lại tốt hơn
– Không còn sử dụng Portainer cho tất cả các CT Podman. Tương lai quy về 1 CT duy nhất Ivy-Monitor
– Sử dụng `slirp4netns` thay vì `pasta` mặc định do `slirp4netns` cho Network Performance tốt hơn

L-Ivy
– Proxmox 9, sử dụng Debian 13 `trixie`

Ivy-Build
– Nâng cấp lên Debian 13 `trixie`
– Sử dụng để Build podman

Ivy-NAS
– Nâng cấp lên Debian 13 `trixie`
– Podman: qBittorrent, VueTorrent, Flood
– SMB Service
– Riêng Ivy-NAS sử dụng `slirp4netns` với tùy chọn `port_handler=slirp4netns`, đảm bảo “Preserved source IP address”

Ivy-Service [read-only mode]
– Nâng cấp lên Debian 13 `trixie`
– Podman: Jellyfin, Plex, Roon, Lyrion, DSM
– SMB Service

Ivy-Library
– Nâng cấp lên Debian 13 `trixie`
– Podman: Immich

Ivy-Web
– Hiện tại vẫn ở Debian 12 `bookworm`
– Di chuyển TTV, 4Teen sang Ivy-WebArchive
– Sẽ nâng cấp lên Debian 13 `trixie` trong thời gian tới
– Dự kiến sử dụng Podman thay vì các package tự Build

Ivy-WebArchive
– Nâng cấp lên Debian 13 `trixie`
– Apache, MariaDB 11.4 LTS, PHP 5.6
– Sử dụng cho Web yêu cầu PHP bản cũ như TTV, 4Teen

Ivy-WebNS
– Đang tạm ngưng hoạt động, cân nhắc trong thời gian tới

Ivy-Dashboard
– Nâng cấp lên Debian 13 `trixie`
– Podman: Heimdall, Homepage, Grafana, Prometheus, Prometheus Proxmox VE Exporter

Ivy-Monitor
– Dự kiến khởi tạo trong thời gian tới
– Sử dụng để Monitoring cho Proxmox cũng như các CT và các Podman

Ban đầu CT Ivy-Service không sử dụng Container bên trong mà chạy trực tiếp Jellyfin và Plex trên đó. Cách này có ưu điểm là các Service này có thể sử dụng phần cứng Host pass vào CT một cách dễ dàng. Ưu điểm này không còn là ưu điểm nếu sử dụng Docker hay Podman ở rootful mode, nhưng vì sử dụng Podman ở rootless mode nên việc pass phần cứng từ Host vào LXC rồi lại vào rootless Container không phải lúc nào cũng suôn sẻ. Đặc biệt trong thư viện với quá nhiều Container, sẽ có Container hiệu chỉnh permission đúng và việc Container đó sử dụng phần cứng pass từ LXC mà không phải chỉnh sửa gì rất dễ dàng, còn lại hầu hết là không chạy do khi build nhà phát hành chỉ hỗ trợ trường hợp pass phần cứng từ Host mà thôi.

Đơn cử Jellyfin và Plex, Container Jellyfin rất dễ dàng pass GPU vào và transcode bằng GPU chỉ với việc thêm ‘–group-add keep-groups’ vào ‘podman run’ nhưng Plex thì không. Giải pháp cho Plex hiện tại gần như chỉ có chỉnh Permission ‘/dev/dri’ ở Host từ 660 sang 666.

Nhưng thực tế hơn một chút, tuy Jellyfin và Plex đều stream transcoding “On the Fly” nhưng trong quá trình đó transcoded media sẽ lưu ở temp, với 4K thì mỗi file temp có thể lên tới cả trăm GB với maximum quality. Điều này quá tốn Life Cycle của SSD, còn sử dụng HDD thì chưa chắc HDD đã đáp ứng được tác vụ ghi và đọc cùng lúc như vậy. Tốn tài nguyên hệ thống, tốn Life Cycle thậm chí có thể càng tệ hơn nếu có nhiều người xem cùng lúc. Tắt transcode là điều đúng đắn nhất.

Trình bày dài dòng như trên, Jellyfin và Plex chạy trực tiếp trên LXC là tốt hơn, nhưng cũng không nhất thiết và chỉ có ưu điểm khi muốn sử dụng phần cứng từ Host như GPU để transcode mà thôi. Nhược điểm là trường hợp cài lại Ivy-Service thì cài lại Jellyfin / Plex vất vả hơn hẳn. Vì vậy mình sẽ đổi phương án cho CT Ivy-Service sử dụng Podman và cài Jellyfin với Plex vào Podman thay vì chạy trực tiếp. Tương lai các Service khác cũng sẽ cài vào Container luôn.

Để việc triển khai Podman ở nhiều CT thuận tiện, không tốn dung lượng lưu trữ và tốn công Build nhiều lần, CT Ivy-Build được tạo để chuyên Build Podman from Source và có thể là Build nhiều package khác nữa. Binary sau khi Build sẽ được các CT khác copy về và sử dụng, khỏi phải cài đống Library thừa thãi chỉ dành cho quá trình Build.

Cuối cùng là CT Ivy-Library để làm kho lưu trữ ảnh sử dụng Immich cũng sẽ chuyển sang sử dụng Podman thay cho Docker Engine.

Tiến độ: hoàn thành vào 04/07/2024

Việc xây dựng lại Ivy-NAS chạy ở CT LXC thay vì VM đã hoàn thành. Tiến độ công việc chậm chạp tận 1 tuần mới xong do có nhiều phương án triển khai mà lại có quá ít thời gian để nghiên cứu và giải quyết các khó khăn về mặt kỹ thuật.

Ban đầu việc cài đặt CT của Ivy-NAS dự định vẫn sử dụng Desktop Environment để có thể dễ thao tác trong môi trường Desktop với Docker Desktop do các câu lệnh của Docker rất lằng nhằng và rất gây lú. Tuy nhiên Docker Desktop gặp rất nhiều trở ngại khi chạy trong CT.
Phương án sử dụng VM cùng với Docker Desktop thì chắc chắn khả thi không cần thắc mắc, tuy nhiên tính ưu tiên thấp do mình vẫn muốn sử dụng CT hơn.
Phương án sử dụng CT cùng GNOME, không sử dụng Docker thì qBittorrent mới chỉ tới 4.5.2 do đặc tính của Debian stable.
Phương án sử dụng CT cùng GNOME, sử dụng Docker Engine cùng CLI thay vì Docker Desktop thì việc cài Desktop Environment cho CT khá vô nghĩa. Lý do cài Desktop Environment để tiện sử dụng qBittorrent và quản lý Docker mà giờ cả 2 đều sử dụng WebUI thì cài Desktop Environment làm gì? Mọi thứ râu ria trên Ivy-NAS đã chuyển sang Ivy-Service rồi.

Vậy là mình đi tới quyết định Ivy-NAS sẽ sử dụng CT mà không cài Desktop Environment nữa, nhờ vậy Ivy-NAS đỡ hao tài nguyên hơn kha khá cho GNOME.

Việc quản lý Container trong Ivy-NAS chuyển sang sử dụng Podman thay vì Docker Engine do đặc tính có thể chạy Rootless từ khâu design ban đầu. Tất nhiên Docker cũng có thể chạy ở Rootless mode, hay K3s cũng có Rootless nhưng K3s phù hợp hơn cho Cluster và Rootless ở K3s đang ở giai đoạn rất sơ khai, nên tính năng này Podman làm tốt nhất. Đang trong quá trình setup Docker Engine lại chợt nhớ ra Podman nên việc cài đặt Ivy-NAS lại cộng thêm vài ngày.
Nếu chỉ cài Podman ở Host hay VM, và sử dụng Podman ở Debian Repository thì không mất nhiều thời gian. Nhưng Podman ở Debian Repository hiện chỉ đang ở bản 4.3.1, trong khi bản Stable hiện tại đang là 5.1.1 rồi. Vụ này Docker làm tốt hơn hẳn khi Docker có Repository riêng. Thế là mình phải Build Podman từ Source, sau đó là cài Portainer để sử dụng Podman từ WebUI thay vì CLI.

Hiện tại CT Ivy-NAS chỉ có 2 Container là Portainer và qBittorrent.

Còn ở CT Ivy-Service việc thêm 1 lớp Container cho Plex và Jellyfin là vô nghĩa. Mọi Service đều được cài trực tiếp lên Ivy-Service.

Ngoài ra Host Ivy có thêm mergerfs để gom Array đống HC550.

Tới đây vụ Ivy Reconstruction có thể coi là hoàn thành.

Trong quá khứ, Ivy từng được xây dựng lại với tiêu chí sử dụng hoàn toàn Container LXC thay thế cho VM. Tuy nhiên sự cố tràn RAM (Memory Leak) ở qBittorrent không chỉ gây crash chính qBittorrent mà còn làm Memory đầy ở Ivy gây crash các CT/VM khác dẫn tới Ivy cần phải Reboot sau vài ngày sử dụng nên Ivy-NAS bắt buộc phải chạy trong VM. Hiện tượng Memory Leak vẫn còn, tuy nhiên sẽ chỉ gói gọn ở trong VM thôi, và VM Ivy-NAS chỉ đơn giản là Reboot vài ngày một lần mà không ảnh hưởng tới các CT/VM khác trong Ivy.

May mắn là thời gian gần đây mình đã phát hiện ra nguyên ngân qBittorrent dễ tràn RAM và crash sau thời gian dài là do tham số File pool size quá cao, ở mức 5000. Và bằng cách giảm xuống 1000 hay 500 thì hiện tượng này không còn nên có thể coi như vấn đề đã được khắc phục. Với tiêu chí cái gì có thể nhét trong CT thì sử dụng CT, mình sẽ thử nghiệm chạy Ivy-NAS trong CT trở lại trong vài ngày tới.
Việc chạy ở CT thay vì VM có ưu điểm là CT ít overhead hơn VM và ngốn ít tài nguyên hơn, đồng thời resources chia sẻ trực tiếp với OS thay vì qua một cấp virtualization. Đồng thời với NAS thì việc sử dụng Bind mount point để chia sẻ thư mục từ Host tới CT đơn giản hơn rất nhiều so với VM khi VM cần giải pháp phức tạp hơn là sử dụng VirtioFS / Virtio9p / NFS / SMB. Ưu điểm của VM so với CT chỉ ở khi sử dụng Backup / Restore, khi VM có thể Online trong khi CT cần Stop để thực hiện những thao tác này.

Tiện với việc setup CT Library, các thành phần thuộc về Service ở trong Ivy-NAS như Plex, Jellyfin, DAV, SMB,… sẽ được tách ra một CT riêng để các Service này luôn thường trực mà không phụ thuộc vào trạng thái của Ivy-NAS.

Lần setup lại Ivy-NAS dạng CT này, phương án chạy Docker dành cho qBittorrent trong Ivy-NAS hoàn toàn khả thi do LXC đã hỗ trợ Feature keyctl để có thể chạy ảo hóa trong CT thay vì chỉ có lựa chọn chạy trong VM như trước đây. Ngoài ra phương án chạy Ivy-NAS ở VM rồi cài Docker cho qBittorrent cũng được suy xét.

Do nhu cầu lưu trữ ảnh thời gian gần đây rất nhiều quá cả dung lượng Free từ Google Photos, thêm nữa Google Photos có nhiều bất tiện và bất cập trong việc quản lý ảnh nên mình sẽ tự setup một server ảnh riêng để sử dụng theo dạng Self-host. Sau khi dùng thử và đắn đo giữa NextCloud hay Immich thì mình quyết định sẽ sử dụng Immich bởi lý do NextCloud quá nhiều thứ gây nặng nề và mình quá ngán ngẩm với timeout của PHP. Việc setup, chạy và Up/Down của NextCloud đều sử dụng PHP nên nếu kết nối chậm dẫn tới quá trình trao đổi dữ liệu quá timeout của PHP thì sẽ xảy ra nhiều thứ không hay. Riêng quá trình setup NextCloud đã gây quá nhiều phiền toái rồi.

Library chạy trên một máy ảo LXC riêng sử dụng Debian 12 Bookworm, setup Docker và Portainer. Dữ liệu ảnh được chứa trong WD Ultrastar® DC SN640 U.2 7680GB sử dụng filesystem ZFS với compression lz4.

Do vật giá leo thang và chi phí để truy trì domain cũng ngày càng tăng theo, việc duy trì domain giotdang.net trở nên lãng phí không cần thiết nên mình sẽ chuyển sang sử dụng domain miễn phí giotdang.eu.org

Các Sub-Domain đi theo giotdang.net cũng sẽ chuyển sang sử dụng giotdang.eu.org, kéo theo đó TTV cũng không duy trì domain .net nữa mà chuyển sang .eu.org luôn

Việc chuyển đổi khá đơn giản nên đã xong xuôi và có hiệu quả tức thì

Nâng cấp phiên bản cho các thành phần của Webserver cùng với các thư viện liên quan

HAProxy
Upgrade: 3.0.1 LTS

PHP
Upgrade: 8.1.29, 8.2.20, 8.3.8

Redis
Upgrade: 7.2.5

MariaDB
Upgrade: 11.4.2 LTS

Nâng cấp phiên bản cho các thành phần của Webserver cùng với các thư viện liên quan

Apache
Upgrade: 2.4.59

HAProxy
Upgrade: 2.8.9

PHP
Upgrade: 8.1.27, 8.2.17
New: 8.3.4

Redis
Upgrade: 7.2.4

MariaDB
Wait for 11.4.2 LTS

Thêm một Cluster nữa được thêm vào cùng với Ivy, do nền tảng phần cứng chạy trên J6413 với Codename Elkhart Lake nên Project được đặt tên là Elkhart… một cái tên không hay cho lắm.

Ban đầu Elkhart dự tính chỉ sử dụng với mục địch là một Router chạy pfSense, do dư thừa tài nguyên phần cứng nên Elkhart sẽ triển khai thêm phần SSL Termination, và HAProxy sẽ được chuyển từ Ivy tới Elkhart. Từ đó Elkhart hỗ trợ SSL Termination không chỉ cho Giọt Đắng mà còn cho các máy ảo khác trong toàn bộ Cluster. Hiện tại phần này đã hoàn thành và Elkhart triển khai 2 máy ảo: 1 máy ảo SSL Container và 1 máy ảo pfSense VM do pfSense bắt buộc phải sử dụng VM.

Cùng với việc Offload SSL từ Ivy qua Elkhart, Ivy cũng đang được nghiên cứu lại để chuyển toàn bộ hệ thống VM sang sử dụng Container. Cùng với đó là việc sử dụng ZFS ở một số tình huống thay cho ext4.

Việc Rework Ivy không hẹn ngày hoàn thiện.