With jailmaker 1.5.0, I had no automatic startup of a jail with bridge networking, after upgrading to 24.04.1, same issue as with the Tailscale jail with host networking; manually starting them after boot worked.
With jailmaker 2.0.0, all jails started automatically after upgrading to 24.04.1.
@Jip-Hop, did you change something in 2.0.0 that could account for this?
If you cloned the jailmaker repo, as per my video, then just cd into your jailmaker dataset, then run git pull
That should update your repo with the latest code
(Probably best to stop any jails first)
If you have untracked changes, or have modified things you shouldn’t have, then this SO article should cover it.
Assuming that all works it should just be a matter of restarting your jails, and if you get any errors, then editing the config so that it resembles the appropriate template in the template directory should resolve, as the templates are updated as the config options are deprecated/changed.
Thanks Stux that makes perfect sense.
I have to say Stux thanks for what you do.
Follow-up: tried one more server, and it seems that 2.0.0 has indeed fixed the jail startup issue. I’m leaving my workaround in place for now, just in case (no harm trying to start a jail that is already running)
The other option I was thinking of was running Home Assistant Supervised within its own jail (as opposed to running Home Assistant Container in my Docker jail). Home Assistant Supervised is already a poorly (comparatively) supported version of Home Assistant, running it within a jail would only compound this. I’m leaning towards leaving the HAOS VM in place as “it just works” and I have the resources on my server to spare (even if I would like to free them up).
Interesting… The startup command used to also run the install logic. But I removed it, so the startup command now really only tries to start the jails.
@ Stux, you were mentioned (not by name) at the end of the mega announcement on the major changes planned for apps in Electric Eel (The Future of Electric Eel and Apps - #109).
Gonna be an interesting time over the next few months leading up to and through 24.10’s release.
As a result, I’m not sure whether to migrate my existing 8 TrueCharts apps (an ‘arr’ suite, jellyfin, jellyseer and homarr) into jailmaker and dockge or await whatever iX is cooking up.
IMO you should absolutely migrate your TrueCharts apps into docker/Dockge in a jailmaker jail.
It basically gives you control. And it’s stable, and high performance.
If you have any IX Apps, well that’s up to you. But the benefit of migrating them is that you can then unset the apps pool and get rid of the k3s overhead now.
In the future, you can migrate back to apps, or not, at your own pace.
EDIT: here’s a good guide on the truecharts to sandbox migration
Thanks, I think that’s what I’ll do over the next few days.
Since I’ve got you…is there any way to get Dockge to autostart the containers on boot up?
Thanks to the init script method you outlined, I’ve got Jailmaker and Dockge starting up on reboot, but the nginx container I’ve set up within Dockge needs a manual start up.
Doesn’t look like it’s currently a feature: Possible to auto-start all containers on dockge first-run · louislam/dockge · Discussion #296 · GitHub
That bug report is different. It’s about starting all
stacks in a new environment (sandbox).
Docker already provides this functionality.
Make sure you specify a restart clause in your compose, either “unless-stopped” or “always”
That should mean the stack will auto start when the jail starts, if it’s been started already.
Eg:
version: "3.8"
services:
nginx:
image: nginx:latest
restart: unless-stopped
ports:
- 8080:80
networks: {}
Wow!
TrueNas reporting shows that my CPU and RAM usage is almost half as with TrueCharts. Temps also went down a couple degrees from the CPU idling.
That’s a rather good reason for about 98% of users to get rid of k3s and Helm charts.
Well, that’s Jellyfin migrated over. Not too difficult thanks to your vid, Stux!
I’m less looking forward to moving my arr suite, since there are a lot of moving parts, ports and mount points to take care of. Still, carefully wins the race, eh?
I’m not looking forward to migrating my 25 truecharts apps to jailmaker or maybe later the docker integration from truenas, especially the traefik ingress part and homepage integration is what was keeping me away from jailmaker. With truecharts the traefik setup and integration, including 2fa with authentik was pretty easy. Now i have a whole lot of reading, learning and experimenting to do…
If you’re heavily invested in TrueCharts, wait one month to see what migration path may be provided.
That’s why they call it a home lab 
Edit: I’ve now fully migrated all of my apps from k3s.
The arr + media apps + syncthing + homarr are all now dockerised (with the arr’s in a single stack), all managed by dockge, and so I’ve just unset my k3s pool. Yup - faster TrueNAS start up, for sure!
I have to say, it’s been a great learning experience, and I like the idea of having a whole bunch of compose.yaml files “ready to spin up” as and when needed.
I can see what all the fuss has been about with dockers now
Since I use haproxy as a reverse proxy (in OPNsense), I found the switch over trivial, since I just had to adjust a few real server IP addresses and ports.
I’ve never tried nginx or traefik as reverse proxies, so good luck!
Switching from k3s to docker containers looks to have saved 1-2 GB of RAM use, which is always nice.
There is a nifty thing called NestyBox / SysBox, and it was bought by Docker. It basically is similar to nspawn, but works inside Docker, as a different runtime engine (ie a runc)
ANYWAY, here is a fun VM vs bare metal containers vs system containers with containers, etc performance analysis…
Which should basically apply to Sandboxes/Jailmaker too.
An interesting point is the networking cost of the docker bridge.
If you want to avoid the cost of the internal docker bridge in your jail, then you could use host networking on the container… in the jail… even if the jail is using bridge networking to the truenas host.
Of course, the fastest performance is to use host networking on both, but then you have to ensure that you don’t have conflicting ports etc.
I’d rather just have “it work” functionality, which is what you get with bridges.
If I understand correctly the blog post:
(1) is the application in the main system
(2) is the application in a jail/sandbox (as in CORE jails)
(3) is running docker in a jail (as per some “obscure video” made by someone…)
(4) is docker in a VM.
TL;DR (1), (2) and (3) are basically similar in all metrics, except for networking where (3) takes some hit from the bridge. (4) takes a hit in all metrics—worst being memory use and provisioning time, not even networking.
That’s my takeaway too, except 3) could be the perf of 2) if you used host-networking in the compose file.
Then it comes down to if you are using bridge networking to the sandbox, or not.
Would be interesting to confirm. No, I don’t have the desire to test that.
Not to mention benchmarking macvlan vs. bridge networking…
Anyway this basically answers @winnielinnie 's question about containers in a container (sandbox): The cost is minimal. Regular users may just take the 17% hit, deploy standard containers in a sandbox and let all the work of updating said containers be done upstream.
The most concerned and/or most advanced users can make the cost essentially null by maintaining their own jails, or at least using host networking and managing their own list of used ports.