I don’t like the UI for setting up apps on TrueNAS. I also don’t like the one for custom apps. So I thought, can I just use Docker directly? After all, it seems like that’s basically what the Apps tab is doing under the hood, as apparently it isn’t even using Kubernetes anymore, but just Docker directly?
I found a video by a person named Capt Stux about Jailmaker, but the GitHub page says it’s unmaintained. Apparently it’s in TrueNAS directly now using Incus though, which seems to be the Containers tab, but I found a Reddit thread mentioning that the feature is going to be removed again in the next release.
I’d like to make sure that I don’t do anything stupid, so I’d like to ask beforehand - can I just set up some docker containers inside a dataset that I set up in the UI, and then treat and use them like I would on any regular linux installation, without any sort of jail, just with the default containerization? And then simply interact with them normally via the docker command line and with docker compose? Or are there any problems with that idea?
I’ve been using docker directly for a while and haven’t encountered any issues. I also haven’t found any TrueNAS specific quirks.
On the command line, docker and docker compose works. I’ve also been running portainer for some time which also works. Other users have reported using dockge instead.
Note that docker containers will not show in the TrueNAS Web-UI. But that might be a feature that is added in future versions.
Of course there’s always a possibility that a future update will break things, but that is can always be the case with any system.
Docker is running directly on TrueNAS. TrueNAS is really just Debian Linux with OpenZFS added on and made the main filesystem, and then a web-based UI frontend is provided to simplify management for users. Just like regular Debian, TrueNAS also runs Docker.
You’re right, the catalog apps and custom apps are absolutely terrible, so it’s perfectly understandable you’d want to avoid them. But they’re just really a front-end to actual Docker. The easiest and I think most popular way to manage Docker without these is to install Dockge or Portainer, and then manage the rest of your apps in those with regular docker-compose yaml scripts. I use Dockge personally. You can install it from the catalog apps easily; it’s the only catalog app I use (other than Scrutiny, which is now being recommended by TN). Then you can just use that, through its web UI, and install everything else you like with docker-compose.
Incus is not Docker, it’s a virtual machine, so that’s something entirely different.
So nothing odd about datasets and such? I still don’t entirely understand them, so I was wondering if it’d be preferable to have all containers in one dataset with different folders, a dataset with different sub-datasets, or if it would even be fine to have media storage in an entirely different dataset from where the rest of something like Jellyfin is located?
When it comes to important data that a container needs to read/write you have to bind mount a suitable location that you need to manually provision.
You do not have to keep everything on the same dataset. You don’t even have to keep everything on the same pool. If you have a SSD and a HDD pool you can put database data on the SSD and media data on the HDD pool.
When it comes to provisioning storage there are a lot of different factors to consider. Like what is the storage used for? Is it a cache, a database, a network share? How important is the data, what backup/snapshot strategy? Do you need encryption? There are many more things you can configure. All these things do influence on how to provision the storage, and on whether different datasets should be used. Of course, personal preference and experience matter as well.
As a “rule of thumb” - if the storage requirements are different then they should be in different datasets. ZFS snapshots, replication and properties are defined on a per-dataset basis.
If you want an example of jellyfin on my home system (jellyfin is behind traefik reverse proxy):
tank/appdata/jellyfin is it’s own dataset (with tank/appdata as parent). Also the entirety of tank/appdata has no ACL because it doesn’t contain shared data. tank/entertainment is another dataset (network-share). I might make sense separate cache and config, but I don’t consider jellyfin as an important service.
