What I’m trying to sort out is a good (i.e., automated) way to sync up, at least the stacks directory, and ideally the remaining Dockge data, to a git repo. But otherwise, I think I have an overall picture of how I’m going to handle this–no doubt questions on some details will be coming.
Actually that’s a very good point. If you could share your PoC of stacks with a running Traefik working with something like Dashy or Homepage that’d basically dispel all the magic.
The other dataset (dockge) is probably just config of Dockge, might be also worth checking out.
So if you upload them let us know 
About automation, I’ve browsed for like 2 minutes and people seem to be using mostly scripting and crons.
I hope my migration from jailmaker to lxc will also be pretty straight forward.
From what i’ve seen in the podcast demos it should be, but then again i consider myself still a noob with lots of potential to f*** it up.
My sync/backup solution for my compose files is a private github repo with the compose and for e.g. nextcloud the php.config
In the future i want to play arouond with code-server which can be linked to github and a local copy of my compose files on truenas
I’m doing it with Homepage (also using labels) in my test environment, and it seems to be working just fine. Here’s a sample compose file that integrates both with Traefik and with Homepage:
version: "3.3"
services:
stirling-pdf:
image: frooodle/s-pdf:latest
volumes:
- ./trainingData:/usr/share/tessdata #Required for extra OCR languages
- ./extraConfigs:/configs
# - ./customFiles:/customFiles/
# - ./logs:/logs/
environment:
- DOCKER_ENABLE_SECURITY=false
- INSTALL_BOOK_AND_ADVANCED_HTML_OPS=true
- LANGS=en_US
labels:
- traefik.enable=true
- traefik.http.routers.stirling-pdf.rule=Host(`stirling.domain`)
- traefik.http.routers.stirling-pdf.entrypoints=https
- traefik.http.routers.stirling-pdf.tls=true
- traefik.http.services.stirling-pdf.loadbalancer.server.port=8080
- homepage.group=Media
- homepage.name=Stirling PDF
- homepage.icon=stirling-pdf
- homepage.href=http://stirling.domain/
- homepage.description=Web-based PDF editor
- docker-compose-watcher.watch=1
- docker-compose-watcher.file=/home/docker/stacks/stirling-pdf/compose.yaml
networks:
- proxy
networks:
proxy:
external: true
personally i’ve switched form labels to use the homepage service.yml to add my services to homepage. If you als setup code-server you can edit the yml in realtime and homepage will adept the changes with an automatic refresh.
That way you can also integrate the pre-build widgets from Widgets - Homepage
You can do that with labels too. See:
Oh wow, i’ve completely missed that, but again there are always many ways to reach the same goal.
One of the things I really liked about the TrueCharts apps was that I was able to set up Ingress and Homepage (as well as codeserver and some other things) in the app itself, so I’m trying to figure out how to make the Compose-based setup work as similarly as possible. Ingress is covered (unless some ports need to be exposed and not others, as with e.g. Gitea) as is Homepage, and I know I’ve seen examples for the VPN integration. Codeserver is still on my to-do list.
I’m using this compose file for code-server
---
services:
code-server:
image: lscr.io/linuxserver/code-server:latest
container_name: code-server
environment:
- PUID=0 # has to run as root, otherwise changes can't be saved
- PGID=0 # has to run as root, otherwise changes can't be saved
- TZ=Europe/Berlin
# - PASSWORD=password #optional
# - HASHED_PASSWORD= #optional
# - SUDO_PASSWORD=password #optional
# - SUDO_PASSWORD_HASH= #optional
# - PROXY_DOMAIN=code-server.my.domain #optional
# - DEFAULT_WORKSPACE=/config/workspace #optional
volumes:
- /mnt/data/code-server/config:/config
- /mnt/data/:/mnt/data
ports:
- 10443:8443
restart: unless-stopped
and since it only runs locally i refrained from setting up a password and just out-commented the lines for password and user
Thanks for the examples, they help a lot.
And the Homepage config is actually a great point, the Homepage entries being defined on the application’s config is pretty blessed.
That seems simple enough. It doesn’t have the per-app config that TrueCharts did, but would give an easy way to edit, not only the compose and .env files, but also any configs that are mounted to the apps. And presumably it’d be simple enough to put that behind Traefik as well.
Docker runs as root. Oops!
Security concerns kicking in is when you install your own Podman, or rootless Docker, in a sandbox/LXC container/VM. And forget the idea of a ready-to-use app catalog, or of easy custom install.
I tried to find more about this Docker root thing and this if what I got.
By default root inside Docker container is the same as host root. So if malware breaks out of container it has root on host.
But this can be managed by:
- Running app inside container as some other user by using
--userflag. This way it would first need to get root somehow to do harm. But some apps may require to be run as root so this may not be always usable. - Using namespaces to map root inside container to user on host. This way even if container root breaks out its still only user on host.
Another thing is not mounting Docker socket to container you dont trust. Root in container can use Docker socket to control Docker daemon which has root on host. This is used for example so containers like Dockage or Portainer can actually manage Docker. But it can also do anything on host.
It seems to me that Docker isnt that dangerous if you use it correctly.
I guess only thing left is if there is some critical vulnerability in Docker itself that would allow malware in container to take control of Docker daemon even if you didnt expose Docker socket and used namespaces. In that case only rootless Docker would save you.
Hope I didnt say anything wrong.
1 Like
Most of this comes down to “don’t expose privileged containers to the internet”
FWITW, I just read a brief on FreeBSD, Podman, and the new OCI containers where Podman has to be run as root on FreeBSD for now too (but that will change soon I’m sure).
https://people.freebsd.org/~dch/posts/2024-12-04-freebsd-containers/
1 Like
Maybe, but realistically, “use it correctly” and understanding the security stuff is beyond the heads of most users.
1 Like
Not much more to say on that topic (pretty much sums it up).
I don’t know much more about podman, or docker–besides what I just read–but from what I understand docker inherently would need the elevated privileges because it is a daemon. But from what I understand podman is not a daemon so it should allow for “unprivileged” containers out of the box (the only requirement for root is because WHERE the containers are created, essentially. Correct?).
So no doubt this was a pretty obvious idea, but it just occurred to me: I don’t have to wait to upgrade to EE to start installing apps and migrating data to them; I can instead do the Dockge-in-a-sandbox thing (yes, I know you have a video for that, though I haven’t yet watched it), and then upgrade to EE once I have everything running that way. Less disruptive and all that.
Question remaining on that course of action would be whether I can still have the “proxy” network in that scenario. Or would I need to wait on that until I’m running EE?
proxy network in the jail or on the host? I have the proxy network running in my jail, and if i were to migrate it to directly to the host, all i should have to do would be to execute “docker create network proxy” from the truenas shell to create the proxy network on the host (or do it from the portainer gui)
As I think about it a bit, if I’m running Dockge under jlmkr, that network would be in the jail, and anything running under Docker would be in that jail and thus be able to use that network. So docker network create proxy inside the jail. Whenever I “upgrade” to EE, I’d run the same command for the NAS itself.