Jailmaker maybe over my head but so are all the breaking changes with TrueCharts. I upgraded to Dragonfish and broke all my TrueCharts apps trying to migrate them. Rather than getting insulted on their discord channel here I am. I installed Jailmaker and it seems to work fine
I followed the Stux video and installed dockge, which also seemed to work but dockge doesn’t respond at this IP, I did make it static on my pfsense DHCP and I am able to ping the IP from my Windows desktop.
I don’t know much about networking so I am not following the macvln discussion, my guess it has something to do with that because dockge appeared to install fine. Is there any way to confirm dockge is running in the jail?
Try telnet 192.168.55.xxx 5001 and see what you get in return? Alternative command you can use netcat with: nc -zv 192.168.55.xxx 5001. If you’re getting timeouts, then it’s something to do with firewall rules, routes, or possibly interface issues.
Sorry for the stupid question but ever since it was mentioned recently why use docker inside a jail which itself is a container it got me thinking. I’ve tried to keep things simple in my setup and don’t really care about isolation between containers. So I created one jail for a single docker compose stack with all my needed apps. Using Dockge looks cool. And I’ve seen many examples of creating separate docker compose files in a hierarchy to manage each stack separately. But what advantage does it have over just running docker compose up -d listing your individual containers or shut them down individually? Dockge UI looks sweet and I’m going to try it but I can’t think of why it would be advantageous to separate the compose files.
yikes, don’t worry, we won’t do that over here. i can’t imagine why someone would yell at someone trying to get help sheesh, that’s nasty
i myself made a big migration over qnap qts to truenas.
i see that you were previously invested into truecharts.
if you had docker containers, you could copy the docker compose and deploy them using dockge once you had setup jailmaker docker first.
from my understanding of the situation, once you have jailmaker docker installed, you should have truenas apps unmount/deactivated and don’t use that. there have been mixed reports by people they can use both jailmaker and truenas apps together fine. but i rather not find out so i left that off. VM might be ok though.
If you don’t have a docker compose from your original truecharts deploy, well you may need to start from scratch afaik. this is my assumption, so you best get a second opinion on this. You can then deploy docker compose using a new setup then set it back to how you had it before.
some apps even have their own saved config you can load from. example, my ubiquiti unifi controller you could save the config for the app and import it to recover. so even if i nuke my unifi controller docker container, i can simply redeploy a brand new one from scratch, then import that unifi config, and it will restore perfectly fine. So apps that have something similar would be much easier to restore when moving from one to the other.
just to add onto that, if before you entered the docker jail shell, you could do a jlmkr list and a jlmkr status docker *i named my jail docker, to also know the state of the jail. Example it can show whether you had set the startup on reboot or not and also the current ip for it. You should check that first when you first setup. I had to ammend it from 0 to 1, in order to flip it to run on startup.
as for the networking portion don’t worry too much. just follow the guides.
notes: this mini guide is under the assumption you want to do bridging networking mode which most people recommend.
do this first
then do the advanced networking portion. don’t forget the add static ip for the docker jail as mentioned here
then lastly, in truenas > system settings > general >
modify here e.g. web interface select only the static ip for the bridge only
for creating docker networks you can do say
Create Docker Network
jlmk shell docker docker network create proxy
then in your dockge for docker compose
for each service image within the compose you add the network for each of them same like this
networks:
- proxy
put a single entry like this at the very end
networks:
proxy:
external: true
that said i noticed this just worked as the default, though maybe not optimal. though you didn’t need to do the create proxy network in shell cmdline which i did to setup the proxy network. networks: {}
at this point for networking you are more or less done. There are still many things to learn and do but this is more or less the basics
read here the explanation why dockge exists and what it offers
personally i’ve deployed docker 3 ways.
the old school method docker compose up -d using just a compose-docker.yaml i editted with an .env file
using portainer
using dockge
they are all good, but my preference is to deploy using a UI. Why? take both portainer and dockge. When you deploy a container, it saves that compose into their own compose folder (aka stacks) . Why is that good? it keeps it saved and organized making redeploying quick and fast.
but couldn’t you do the same manually? yeah you could, but portainer/dockge just makes things simpler and convenient.
Simply put, dockge/portainer both offer quick easy management for your docker containers e.g. start, stop, redeploy with a few clicks of a button in the UI. Would you rather type all that in cmdline? dockge/portainer just makes things easier. You can at a glance see which dockers are up and running and which are not. basically it just makes managing it just more convenient. There is a good reason why people use portainer/dockge to manage their docker deployments.
Even if one day portainer or dockge up and died, those docker compose and .env files would still be there and you can just redeploy them just fine. Only thing you may need to change is a slight edit in your compose. For example for portainer, in regards to how they handle .env they use a unique stack.env so you merely just change that to a .env
just recently i started using dockge over portainer because the dev also came from a portainer background so he designed dockge to fill in something that was unsatisfying about portainer, so it’s supposedly an improvement over portainer in some aspects.
It feels more light weight (less clutter) and more intuitive with a cmdline in your face telling you what is going on as you deploy a container, whereas portainer you had to click to the cmdline tab to check that out (essentially it was off to the side and you had to go there each time or had a separate tab for it to find out what’s going on which was annoying to do)
portainer has more networking configurations in the UI versus dockges simplicity. that can be a good or bad thing, not sure just yet. but all i know is my docker containers work just fine with dockge without over complicating things
all i can say is give it a try, if you feel it doesn’t have any value for you, you can go back to your old way of doing things. Just because i and many others like it, doesn’t necessarily mean you will too. But you won’t know until you try it for yourself. that’s how i did it
Thank you @mooglestiltzkin that was a nice writeup about Dockge and I agree it looks cool and I’m going to try it. What I was referring to when I talked about separate compose files is more that people I’ve seen like to use separate .yml compose files rather than putting all applications into one compose file. This is all docker compose and not related to Dockge. I don’t see what benefit having separate compose files has over just throwing all the services into one compose file. You can administer the start and stop of individual services within that one compose file through command line so I must be missing the overall value. Hopefully that makes more sense!
But i get what you mean now. To my understanding on that,
say you are doing a database e.g. influxdb. So rather than have each docker compose have their own influxdb, instead, you point them all to that single one influx db. You have to link it properly though in the specific compose formating. But the way i was taught on this, they don’t use that much resource so you can host multiple dbs and it wouldn’t be a big deal as long as i named it to differentiate which db is for what usage specifically)
that is just one common example whether than deploying many into one single docker, that you might instead reference 1 important container e.g. a database container that may be used by multiple containers.
Usually if in that one compose they are each unique containers and not being used by anything else other than the single app it was packed together with, then for me it’s a no brainer to just deploy into as a single compose (especially if the intended purpose for these services is to provide for the app they were needed to work with e.g. say jellyfin or some app needs all these things to run because it’s dependent on them and which was why they were all included in a single docker compose to begin with to indicate as such). you click and it boots everything up together without having to do it separately (that said you can individually start stop each container regardless of if you add them all in that single compose e.g. For portainer you can launch them all same time as a single group, or do it individually manually). for regular docker commandline just ps to list the dockers, then docker with the command to start/stop/restart or whatever to the specific container
However, some containers are finicky in the order of which boots up first for it to launch without issue. There is a method for handling it. i think there is a code for dependent on specific containers, and something not launching until another container launches first (i think it’s the health check command for this function) is the gist of it.
anyway this is my own understanding. maybe there is a better approach to this. but usually i just deploy it in a single compose bundle more often then not just fine. and if i needed to start stop the specific container without doing so for the others, i can without issue. keep in mind, these bundles are usually provided by the app you are trying to deploy so they have their default recommended docker compose with all of those bundled together. i rarely if ever make up my own bundles. i just use what the app provides in their official docker compose yaml
For portainer in the UI the group of services launched in that docker compose is grouped up as a stack, so like i said when you can launch and stop the entire stack. or you can do it for each containers separately in the portainer UI.
for dockge i think it omits the separation to start/stop individual services listed together in the compose. instead it only has the stack to launch/stop all the services listed in that compose all together only. So what do you do then? i assume you go shell and docker ps, then docker stop containername for dockge. for portainer you don’t have to do that, just stop that specific service from UI.
if you just go shell docker ps or docker ps -a all the docker containers will be listed, regardless if you had deployed them as individual compose yamls or bundled together in one. and if you need to start/stop/restart a specific one, you can e.g. docker stop jellyfin
so coming back to your question. why bother deploy a bunch of them in a single compose? i think main reason is so they are in one place and related to the app they are to be used for (also you can specify dependencies), and especially if you require health checks to queue the order they boot in to make sure it starts up properly without errors. that’s my answer
A stack defines an application or service… you can stop/restart/start the stack to stop/restart/update the service.
If you don’t have other services intermingled then you don’t impact those services when you start/stop a given stack.
Having a minimum of containers in a stack as necessary to deploy the service, simplifies implementation of the stack.
Yes, you can have a monolithic compose, but you can just as easily break that into many smaller compose stacks… but a stack that contains multiple containers to create a service, for example, hosting a wordpress may require a database container, a webserver and a backup container… can be encapsulated in a single text file… and started/stopped together…
meanwhile, starting/stopping the wordpress, say to change something, doesn’t impact starting/stopping a jellyfin server, which might annoy my wife… if she’s watching her favourite show.
click/click
Now, why not just use docker run...
Well, then you need to make a text file… where you document your docker run commands in case you ever have to rebuild your stacks… of dockers…
And if your stack gets complicated… then it gets even harder…
OR you could just compose your stack with docker-compose in a yml file…
And yes, you could just have one compose file… but its simpler to just have many, then you can use other peoples recipes… probably the first party’s.
This sandboxing and jailmaker look very interesting!
I followed Stux’s video, got jailmaker installed and running, but when I try to install docker, I get the following error:
Downloading the image index
Downloading the rootfs
ERROR: Failed to download https://images.linuxcontainers.org//images/debian/bookworm/amd64/default/20240430_16:32//rootfs.tar.xz
Aborting...
When I try to wget the file, I get the following error:
wget https://images.linuxcontainers.org//images/debian/bookworm/amd64/default/20240430_16:32//rootfs.tar.xz
--2024-05-01 18:33:33-- https://images.linuxcontainers.org//images/debian/bookworm/amd64/default/20240430_16:32//rootfs.tar.xz
Resolving images.linuxcontainers.org (images.linuxcontainers.org)... 45.45.148.8, 2602:fc62:a:1::8
Connecting to images.linuxcontainers.org (images.linuxcontainers.org)|45.45.148.8|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://syd1lxdmirror01.do.letsbuildthe.cloud//images/debian/bookworm/amd64/default/20240430_16:32//rootfs.tar.xz [following]
--2024-05-01 18:33:34-- https://syd1lxdmirror01.do.letsbuildthe.cloud//images/debian/bookworm/amd64/default/20240430_16:32//rootfs.tar.xz
Resolving syd1lxdmirror01.do.letsbuildthe.cloud (syd1lxdmirror01.do.letsbuildthe.cloud)... 170.64.160.91, 2400:6180:10:200::f:9000
Connecting to syd1lxdmirror01.do.letsbuildthe.cloud (syd1lxdmirror01.do.letsbuildthe.cloud)|170.64.160.91|:443... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.
EDIT: SOLVED - same error on my desktop, so investigating further, it appears to be a problem with the Zenarmor IPS I have running on OPNsense.
@Stux I watched your YouTube video, and I’m impressed. Almost enough to go for it. But BSD still does all I need it to do and more, and I’ve grown to understand it quite well.
But again, jailmaker looks really good.
But again (BSD needs to have the last word here) BSD is awesome!
i like and use docker. kubernetes there is a use case for them
why can’t we have both? have them available then let user decide which to use. though if there were more support for jailmaker that would be great. i already documented how i applied that to my truenas usage. i’m sure there many others doing the same to host their docker containers these days.
other option is vm for docker. but why though? anyway another reason to go the jailmaker route
If only all that effort would have gone into FreeBSD jails and most of all the networking setup of those - we could have the best container platform existing.
