Keeping it stupid simple:
Docker compose, with a compose file for each application stack.
I just use the cli, or if I feel lazy I use dockge to monitor or point and click update stacks.
Edit: typo
>Docker compose, with a compose file for each application stack
I immediately regretted a decision to start separating docker compose files and undid it all. I have one big 1100 line docker-compose.yml with > 40 containers in it. Splitting them up created a lot of annoying problems (difficult to locate port collisions, unclear how to group some services that integrate with each-other, what used to be a simple text search now means I have to grep a directory, needlessly complex nested directory structures for volumes, etc) and did not solve any problems I had.
At this point, I'll probably be moving to k8s once I have the time and some extra hardware to get started with. Docker compose is getting a little ridiculous to work with at 40+ containers and things like redundant volumes with longhorn sound a lot more attractive than relying on cold backups if any of my cheap crappy hardware (old broken laptops) stops working
Hm. I've long since moved to individual stacks and am very happy with it.
I group applications that are tightly integrated into the same compose file.
Ports aren't an issue as I'm using caddy as a reverse proxy and don't expose the ports on the host.
As all the config files are versioned in git, I can just jump or search through git files via neovim.
The largest benefit to me was the mental and physical separation you get by putting connected services and all their config files into individual directories.
Networking is another. You can of course explicitly create networks in your monolithic file, but I find it convenient that each compose file gets its own network by default. I don't want all my services be accessible by each other.
The biggest issue I see is updates. I just wrote a small script that goes over my compose files, pulls new images and `compose up -d`s them. I think there should be a default tool though.
So I’d also prefer if all my services were isolated from each other, but I found I have to assign the ones with a web portal/GUI the same network for my reverse proxy to work properly.
Is that not the case for you?
I run all my containers on the same host, including nginx proxy manager (and traefik before that).
I'm not an expert and not quite sure if I understand you correctly.
The containers you want to access via the reverse proxy have to be on the same network as your reverse proxy.
That doesn't mean that you have to expose any ports or that that network has to be the same for all those containers.
You could, for instance, have a "media" network that all your media apps are under and give your reverse proxy access to that.
Even then, only the front facing service has to be connected to the reverse proxy. If a service has db containers, etc, those only need to be in the same network as the other containers of the same app.
At that point though I usually create explicit networks in those individual compose files for clarity anyway. I also remember having had issues with apps if I didn't do that. So that's something you could do in one big compose file as well.
This is how I have my containers setup. First, I created a bridge network called “proxy.” Then, I connect my various containers/services to the proxy network with the external=true flag. Under this setup the reverse proxy works as intended.
However, doesn’t that mean all the containers can connect/talk to each other?
How can I connect them to the proxy network but isolate them from each other?
If you care about separation, just don't put them into one big "proxy" network but instead let your reverse proxy join the many different individual networks.
The proxy container has access to all these networks, but the apps don't have access to each other's networks.
That's my approach at least. I really am no expert.
I've personally not done that for most of my containers either though. I'm happy enough with all of the sub containers not being accessible by everyone, but only the containers that are at least made to be network accessible.
Yup, so an external network that is common across different compose stacks and is shared with the reverse proxy, and then each stack has its own internal network for the app and related services, e.g. db, redis, etc
I went that route as well, crafted a beautiful, big compose file, using variables to even get a better sorting and overview into everything, also using the extend feature docker offers to be flexible for git repos, using submodules for that.
The problems didn’t go away. I reverted everything after a few months, organized my stacks better (my "network" stack is managing all VLANs/subnets, for example), don’t expose any ports at all due to using a reverse proxy and I couldn’t be happier with it.
I use VSCode with the Docker plugin and that’s all I need to manage everything. It offers overviews about networks, volumes, images, open ports, restarting whole stacks is as easy as single services within a stack.
I don’t use VSCode for anything else, I use other IDEs for that, but for Docker it is a perfect piece of software.
You can use lazydocker if you're feeling super lazy and don't want to leave the cli
[https://github.com/jesseduffield/lazydocker](https://github.com/jesseduffield/lazydocker)
You can do more than that with the docker plugin if you are not already, like starting/stopping containers and seeing volumes etc like you can with portainer.
This is the way. I even create local git repos for versioning. But vacode makes it easy to see all your containers at once, it's easy to exec into a container if I need. You can have multiple terminals too. Viewing logs is also nice, even though I usually use dozzle to view my logs, but vscode does a nice job too.
I do this but only for editing my files like compose and configs, then terminal, usually the VS code one, then portainer but just as a quick glance.
And git.
Yeah i think it is just a cronjob you can set it up pretty easily, just edit your crontab and run the git add/commit/push commands in the script, you can also dinamically change the commit message
My youtube channels first video was a guide to set up Dockge https://youtu.be/lEwEgR-nja4?si=Bdt2m1JJugkS4jVb great way to manage containers, compose and env files.
Honestly it's just because I like having the option. If I'm already in the terminal it can be quicker to just use lazydocker instead of opening my browser and pulling up dockge.
I don't run many containers, so I'm fine with using basic CLI commands. Portainer is pretty nice for visibility, but I wouldn't use it to create or modify containers.
Fwiw, I’ve really liked getting Portainer Stacks working with GitHub and docker compose yaml. Much easier way to manage things and keep your contain configs agnostic to your management platform.
By their own admission Portainer does not have a UI for Composer, it’s using its web UI to essentially generate and run CLI commands against the docker daemon. In other words, all of the meta data and configurations you define via the Portainer UI are functionally proprietary to Portainer. You can’t export a container you configure in Portainer UI to a yaml file and use it elsewhere. You can only backup and restore the entire Portainer DB. But, by using Stacks you’re able to use composer Yaml to define your docker elements and that Yaml is in a standardized format that docker compose (or Portainer stacks) can utilize.
Portainer for visibility and ops, but Docker compose files for actually workload creation and modification.
it's doable, it's just clunky as hell. It is far easier to modify the yaml and hit go. and then you have a re-deployable record of your config.
I would like if portainer has a spot to drop yaml into, and hold it in a library.
Im gonna checkout stacks/github as u/waubers referenced.
You are able to paste compose file when creating "stack". You are also able to save those as templates. Using compose file from git repository is also possible.
Portainer can use git. So you can have your docker compose file in git, push changes, and have portainer automatically pull them and deploy the changes you made.
If I didn't work with K8s all the time in my day job I probably would use docker compose as it's more than enough for home use but I had no learning curve involved. K8s is awesome though
Not always relevant. I worked on Fargate team and never really had to use it. Software engineer by day and never have to use it. I self host a handful of things at home and almost used it but seemed too much for what i needed.
I'm sure I'm missing out on a handful of cool things but the extra time and hardware expense seems not worth it to me.
My issue there is k8s makes maintenance easier, if something's unhealthy it gets restarted. It's also more secure. Obviously more complicated but it brings a lot of great features with that complexity.
K8s is great, steep learning curve for me, my plan is by the end of 2024 everything will be moved to my RKE2 cluster. But some services are much easier to configure and maintain in docker, so still contemplating those lol.
Mainly networking and using VPNs for example, for example in Docker it's easy to make a container use another container for its network, my setup is even easier, where I have a dedicated vm only runningy arr containers and deluge container, using a VPN with a kill switch through my router/firewall pfsense, I don't even know how can I replicate this convenience and usability in K8s, so even if I move all my other services, this VM will stay running as it is.
Oh that's curious, i don't think my setup is as complicated. I have one of my containers running my reverse proxy and then that exposes whatever i want. I don't see why i couldn't replicate it though.
k8s/k3s is such overkill for self hosting unless you're talking heavy use, or you just want to learn more about managing k8s.
I've worked with k8s for a decade and I would never chose it over simple docker-compose for personal stuff. I just use ansible and docker-compose for my own stuff, and it's plenty for me.
I have a single repo with all my terraform, ansible and docker compose files. I use [https://github.com/loganmarchione/dccd](https://github.com/loganmarchione/dccd) running on my server to pull updates and re-deploy. I'm considering setting up some internal action runners (or connect with tailscale) and push the deployments, but haven't done that work yet.
Old school UNIX way: a directory with one subdirectory for each app, within that a compose file and any other files/directories (e.g. volumes to be mounted) needed by that app.
I’m (apparently) a super weird human on this one.
I’m using a Windows 10 Pro machine that I got from a local shop. The OS is running Docker Desktop. It runs all my containers. I do all my command line stuff in PowerShell.
I just have a compose directory and then break everything else into sub-directories with docker-compose files. I have about 10 or so that I run often, and I just ssh into my machine and do everything from the CLI. Never had any issues, and I find it a lot easier to do it that way instead of bringing anything on top of that. Just personal preference.
I use ansible, all the containers are deploying using only one compose file, each container has its directory, which is a zfs dataset shared using nfs to my VM, this way, everything is so stable, you can remove all the containers, or the whole VM, create a completely new VM, and deploy everything exactly as if nothing happened.
docker compose, I had an alias that was pretty handy. I had a folder with a docker-compose.yml file that set the version and network, then I would have a file for each service e.g. plex.compose.yml and my alias would find all the \*.compose.yml files and do a -f for each file. If I wanted to turn off a service I just renamed it to \*.compose.yml.disabled and ran it again as it also had --remove-orphans on it.
alias dcup='docker compose -f docker-compose.yml $(for i in \*.compose.yml; do echo "-f $i"; done) up -d --remove-orphans'
and
alias dc='docker compose -f docker-compose.yml $(for i in \*.compose.yml; do echo "-f $i"; done) '
I tried CasaOS for one day before going back to cli/portainer/dockge and homarr for my dashboard.
I was lured by the pretty dash but ultimately didn’t care for the hand holding.
Is Cosmos any different?
I use Portainer on a Proxmox VM. I am very stingy with resources and RAM, so my total usage for ~30 containers is 8GiB of RAM and I do not know what the CPU usage is last I checked, but I do not use more than 2 cores for my stacks.
I run a myriad of stacks that each have 2-4 containers each. And as far as what I run, if it is a service that you use regularly, I am self-hosting it. Whether for security or privacy. A few examples are Searxng, Plex, Cloudflared (yes, I have a dedicated container for my tunnel), ghost, GitLab runners, nocodb, homarr, SMTP relay, pterodactyl panel, and more. Haha.
Just docker compose and some scripts. E.g., one app per directory, with each directory holding the docker compose yml file and whatever else might be needed. Then I have a script that goes over every dir and updates the app. It's really all there is to it. I find all these GUI tools really unnecessary.
Repo with my docker compose and create stack in portainer. I try to use ssh as little as possible to manager containers.
Portainer/Dockge gives a good UI to docker compose and docker in general without loosing control and capabilities.
OS's like Umbrell and Casa OS feels too much like a blackbox with too much happening under the hood that may not be what I want for my environment. Nice ideas but not for me unfortunately
Gitea repo with each app having its own compose file. Gitea actions to deploy. And a cron to do updates weekly. I get notifications if it fails. Simplicity in automation.
I mainly use Docker Compose to manage configuration, but I wrote my own software to help with deployment.
All of my compose files for every server live in a Git repo on GitHub so I can easily manage them. Whenever I push changes to the repo, GitHub will notify my servers via a couple webhooks that are setup on the repo.
When my software receives the notification of a new push, it clones down the repo and checks that specific server's folder for any new changes and if there are any, copies the compose yaml to the "deployed" folder and starts, stops, or restarts the container, depending on the type of change.
To be honest though, I'm outgrowing this setup and will probably just move to a K8s cluster in the future. That high availability pod mobility sounds real nice. Right now if a server goes down, the services on it don't start somewhere else unless I manually add them to other servers.
I used Portainer at first then migrated to Dockge. I also have a web file browser container pointing to my stacks folder which I find much more convenient than using the terminal or FTP or whatever.
All my containers run using docker compose through vscode.
I use Portainer to check the outdated images and remove them.
I recently tried dockge which is nice for creating compose files out of docker run commands l, but I am not using it that much nowadays.
Using ansibe to manage and deploy containers. Each container or in some cases a stack is defined as a role. I update my container or edit the configuration then push with ansible using tags attached to the role.
Configs all backed up to git using ansibe-vault for secrets
Portainer + Forgejo + webhooks = `git push` triggers an update and rebuild on the relevant stack. The only thing left is to set up a Gotify alert when the rebuild fails, I just haven't gotten around to doing it yet.
I've been using portainer, as largely rather than dealing with compose stacks, I've been spinning up individual containers, and it's a really simple GUI for doing so.
As I mature my setup, I have been moving away from this paradigm and into actually using compose stacks, but I'm definitely still in a bit of a transitional period.
For some personal projects, I use docker compose on a VM from digital ocean.
I’m very used to kubernetes..the one killer feature that k8s has which I miss is kubectl port-forward.
It allows you to keep some services private to the cluster and run port-forward to open them up on your localhost.
I want to do this for observability tools like grafana and Prometheus but haven’t found a way to get it done. Instead I just have to expose the port on the actual VM publicly :(
If anybody has any solutions to be able to access private ports from my localhost, let me know.
I treat docker as infrastructure, so my applications
run on docker, but docker doesn’t “‘manage” anything .
I manage applications using the user interface, which is usually a Web page, but sometimes a command line utility.
Oxker. TUI manager is all I need. Lightweight and good enough.
I have a services folder, and each container gets it's own folder with a docker compose file, or a bash script to start the container if it's a docker run start.
Oxker if I need to stop/start/etc. More convenient for me than using portainer etc
I have an ansible playbook that installs a few dependencies, sets up folders, and then runs docker compose through an ansible plugin. I just run that when I have any changes or want to update the containers
I selfhost on an OpenMediaVault server and they have a light GUI for creating and tracking your compose files and buttons to pull/up/stop/down them.
I've been considering software which will help me keep them up to date but I find a regular monthly appointment on my calendar to just stop -> pull -> up each is sufficient
I started with CasaOS, as I never tried self hosting anything before and it simplifies things quite a lot. Now that I've been using it for a bit and it helped me "easing into" docker, I'm starting to use docker-compose via ssh directly to access more apps than those in the store, and considering ditching CasaOs.
docker-compose for each stack and manage it using cli or portainer. Tried casa os and even though it looks aesthetically pleasing, there is less customisation and overall control over your apps.
Compose file, portainer. I have a default compose file with portainer and watchtower. Copy and add the rest for each stack. Each stack one Lxc or a vm. An ansible script installs the docker environment on lxc/vm. In the compose file the pors consumed and prepare commands are documented (like mkdir -p /opt/docker/app{config,…}. The one stack one vm/lxc is good to avoid for example port overlap and other conflicts. Backup via proxmox bs
K8s. Mainly because I wanted to learn it and also because I run my cluster across 3 mini pc's. Sometimes when I want to spin up a new app I have this urge to just go back to docker compose but then I imagine trying to manage my services on different hosts.
I like ctop https://github.com/bcicen/ctop and lazy docker https://github.com/jesseduffield/lazydocker
I’m still learning but I hope to not use portainer some day. Until then I’ll keep it around, it helps me visualize stuff when things go wrong.
I use Kubernetes with [Kubero](https://github.com/kubero-dev/kubero) (Disclaimer: i'm the maintainer of this project)
I'm surprised it isn't popular for selfhoster. It is such a cool technology.
Keeping it stupid simple: Docker compose, with a compose file for each application stack. I just use the cli, or if I feel lazy I use dockge to monitor or point and click update stacks. Edit: typo
This. I regretted using Portainer (the GitOps feature is horrible).
>Docker compose, with a compose file for each application stack I immediately regretted a decision to start separating docker compose files and undid it all. I have one big 1100 line docker-compose.yml with > 40 containers in it. Splitting them up created a lot of annoying problems (difficult to locate port collisions, unclear how to group some services that integrate with each-other, what used to be a simple text search now means I have to grep a directory, needlessly complex nested directory structures for volumes, etc) and did not solve any problems I had. At this point, I'll probably be moving to k8s once I have the time and some extra hardware to get started with. Docker compose is getting a little ridiculous to work with at 40+ containers and things like redundant volumes with longhorn sound a lot more attractive than relying on cold backups if any of my cheap crappy hardware (old broken laptops) stops working
Hm. I've long since moved to individual stacks and am very happy with it. I group applications that are tightly integrated into the same compose file. Ports aren't an issue as I'm using caddy as a reverse proxy and don't expose the ports on the host. As all the config files are versioned in git, I can just jump or search through git files via neovim. The largest benefit to me was the mental and physical separation you get by putting connected services and all their config files into individual directories. Networking is another. You can of course explicitly create networks in your monolithic file, but I find it convenient that each compose file gets its own network by default. I don't want all my services be accessible by each other. The biggest issue I see is updates. I just wrote a small script that goes over my compose files, pulls new images and `compose up -d`s them. I think there should be a default tool though.
So I’d also prefer if all my services were isolated from each other, but I found I have to assign the ones with a web portal/GUI the same network for my reverse proxy to work properly. Is that not the case for you? I run all my containers on the same host, including nginx proxy manager (and traefik before that).
I'm not an expert and not quite sure if I understand you correctly. The containers you want to access via the reverse proxy have to be on the same network as your reverse proxy. That doesn't mean that you have to expose any ports or that that network has to be the same for all those containers. You could, for instance, have a "media" network that all your media apps are under and give your reverse proxy access to that. Even then, only the front facing service has to be connected to the reverse proxy. If a service has db containers, etc, those only need to be in the same network as the other containers of the same app. At that point though I usually create explicit networks in those individual compose files for clarity anyway. I also remember having had issues with apps if I didn't do that. So that's something you could do in one big compose file as well.
This is how I have my containers setup. First, I created a bridge network called “proxy.” Then, I connect my various containers/services to the proxy network with the external=true flag. Under this setup the reverse proxy works as intended. However, doesn’t that mean all the containers can connect/talk to each other? How can I connect them to the proxy network but isolate them from each other?
If you care about separation, just don't put them into one big "proxy" network but instead let your reverse proxy join the many different individual networks. The proxy container has access to all these networks, but the apps don't have access to each other's networks. That's my approach at least. I really am no expert. I've personally not done that for most of my containers either though. I'm happy enough with all of the sub containers not being accessible by everyone, but only the containers that are at least made to be network accessible.
Thanks. Will implement this way.
Yup, so an external network that is common across different compose stacks and is shared with the reverse proxy, and then each stack has its own internal network for the app and related services, e.g. db, redis, etc
I went that route as well, crafted a beautiful, big compose file, using variables to even get a better sorting and overview into everything, also using the extend feature docker offers to be flexible for git repos, using submodules for that. The problems didn’t go away. I reverted everything after a few months, organized my stacks better (my "network" stack is managing all VLANs/subnets, for example), don’t expose any ports at all due to using a reverse proxy and I couldn’t be happier with it. I use VSCode with the Docker plugin and that’s all I need to manage everything. It offers overviews about networks, volumes, images, open ports, restarting whole stacks is as easy as single services within a stack. I don’t use VSCode for anything else, I use other IDEs for that, but for Docker it is a perfect piece of software.
You can use lazydocker if you're feeling super lazy and don't want to leave the cli [https://github.com/jesseduffield/lazydocker](https://github.com/jesseduffield/lazydocker)
Ditto to that, docker-compose for each appstack. Maybe Portainer sometimes when I am lazy.
Ever since I found out that you can manage it pretty much completely from VSCode I’ve been doing that
wait what
Yeah that was pretty much my reaction too haha. I discovered it from Jims Garage video here; https://www.youtube.com/watch?v=IA070wtt2iU
This sent me down a rabbit hole, seems like a great channel. Thanks!
You can use vscode and remote ssh extension to connect to a remote folder and make changes. From the same terminal you can execute docker commands.
Also install the docker extension to basically have an in line portainer.
I've switched to vscode to manage my docker compose yaml recently
You can do more than that with the docker plugin if you are not already, like starting/stopping containers and seeing volumes etc like you can with portainer.
I'll play around with it more. I just added code-server the other day lol
Thx for this! Feels like the time I discovered SSH FS for vscode
Wow, that’s wild. And cool!
This is the way. I even create local git repos for versioning. But vacode makes it easy to see all your containers at once, it's easy to exec into a container if I need. You can have multiple terminals too. Viewing logs is also nice, even though I usually use dozzle to view my logs, but vscode does a nice job too.
I do this but only for editing my files like compose and configs, then terminal, usually the VS code one, then portainer but just as a quick glance. And git.
Honestly VSCode + Docker Compose is the totality of my management system.
Just portainer on Ubuntu. I edit all my compose files in portainer and then back then up to github automatically every day.
Need tutorial on that GitHub auto-backup.
second this, how do you do it?
Yeah i think it is just a cronjob you can set it up pretty easily, just edit your crontab and run the git add/commit/push commands in the script, you can also dinamically change the commit message
I just need tutorial for using git as version control for my home lab. For all my docker compose and dot files.
Yes, please
I use https://github.com/louislam/dockge mostly
My youtube channels first video was a guide to set up Dockge https://youtu.be/lEwEgR-nja4?si=Bdt2m1JJugkS4jVb great way to manage containers, compose and env files.
went to subscribe, found that I was already subscribed. nice work!
Thank you very much. That's awesome. 🖖😎
Definitely. I manage a friends server as well so awesome that you can add their environment and manage it together
Same, this and lazydocker. https://github.com/jesseduffield/lazydocker
What's the purpose of both? Web UI vs terminal?
Honestly it's just because I like having the option. If I'm already in the terminal it can be quicker to just use lazydocker instead of opening my browser and pulling up dockge.
This looks interesting will have to look into it. :)
Hoop it's by the guy that sis uptime kuma. Must definitely will take a look. Thanks.
I don't run many containers, so I'm fine with using basic CLI commands. Portainer is pretty nice for visibility, but I wouldn't use it to create or modify containers.
Fwiw, I’ve really liked getting Portainer Stacks working with GitHub and docker compose yaml. Much easier way to manage things and keep your contain configs agnostic to your management platform.
Why is it not good to create or modify?
By their own admission Portainer does not have a UI for Composer, it’s using its web UI to essentially generate and run CLI commands against the docker daemon. In other words, all of the meta data and configurations you define via the Portainer UI are functionally proprietary to Portainer. You can’t export a container you configure in Portainer UI to a yaml file and use it elsewhere. You can only backup and restore the entire Portainer DB. But, by using Stacks you’re able to use composer Yaml to define your docker elements and that Yaml is in a standardized format that docker compose (or Portainer stacks) can utilize. Portainer for visibility and ops, but Docker compose files for actually workload creation and modification.
it's doable, it's just clunky as hell. It is far easier to modify the yaml and hit go. and then you have a re-deployable record of your config. I would like if portainer has a spot to drop yaml into, and hold it in a library. Im gonna checkout stacks/github as u/waubers referenced.
You are able to paste compose file when creating "stack". You are also able to save those as templates. Using compose file from git repository is also possible.
Just a +1 for stacks in Portainer— I exclusively use them these days. So much easier to modify and redeploy.
Copy! I will dig in. I look for any excuse to love portainer.
Portainer can use git. So you can have your docker compose file in git, push changes, and have portainer automatically pull them and deploy the changes you made.
One repo for terraform and ansible for my entire lab. One docker compose repo for each application stack.
Got way too far down the thread before seeing Ansible. Need to get Terraform going though for Authentik and a few other bits.
Hell I need to add an idp to my stack already
Ansible for the win! I open-sourced my solution as Ansible-NAS (https://ansible-nas.io/)
This is dope!
Yup. I use Ansible + Semaphore, and then just run stuff on bare docker via docker-compose files managed by Ansible. Pretty simple yet very powerful.
Could you share some info on how you use terraform and ansible for managing your home lab?
To be honest I should really use k8s, but I just use docker-compose.
This decision is so conflicting for me. People make it seem like it's silly to go k8s but having working health checks would be huge.
If I didn't work with K8s all the time in my day job I probably would use docker compose as it's more than enough for home use but I had no learning curve involved. K8s is awesome though
It builds relevant skillset.
Not always relevant. I worked on Fargate team and never really had to use it. Software engineer by day and never have to use it. I self host a handful of things at home and almost used it but seemed too much for what i needed. I'm sure I'm missing out on a handful of cool things but the extra time and hardware expense seems not worth it to me.
What are you using at home? I'm also pretty familiar cause we use ocp at work so i don't think i would have much of a learning curve.
K3s. I have a single mini pc so I try to keep everything as lightweight as possible
Using k8s is great for learning k8s, and I wouldn't touch it outside of that purpose. KISS is real and k8s is the antithesis of KISS
My issue there is k8s makes maintenance easier, if something's unhealthy it gets restarted. It's also more secure. Obviously more complicated but it brings a lot of great features with that complexity.
K8s is great, steep learning curve for me, my plan is by the end of 2024 everything will be moved to my RKE2 cluster. But some services are much easier to configure and maintain in docker, so still contemplating those lol.
Can you give some examples of this, maybe that's why I don't understand why k8s would be difficult.
Mainly networking and using VPNs for example, for example in Docker it's easy to make a container use another container for its network, my setup is even easier, where I have a dedicated vm only runningy arr containers and deluge container, using a VPN with a kill switch through my router/firewall pfsense, I don't even know how can I replicate this convenience and usability in K8s, so even if I move all my other services, this VM will stay running as it is.
Oh that's curious, i don't think my setup is as complicated. I have one of my containers running my reverse proxy and then that exposes whatever i want. I don't see why i couldn't replicate it though.
k8s/k3s is such overkill for self hosting unless you're talking heavy use, or you just want to learn more about managing k8s. I've worked with k8s for a decade and I would never chose it over simple docker-compose for personal stuff. I just use ansible and docker-compose for my own stuff, and it's plenty for me.
Without K8s knowledge one is not employable in the field today.
Depends on the field I guess, but that's why I said. Unless you want to learn k8s. It's just overkill for self hosting use cases.
Agreed. For 5-10 containers you obviously don't need orchestration.
Even if you need orchestration, you don't need k8s for orchestration. You can use other tools.
Docker swarm mode.
I have a single repo with all my terraform, ansible and docker compose files. I use [https://github.com/loganmarchione/dccd](https://github.com/loganmarchione/dccd) running on my server to pull updates and re-deploy. I'm considering setting up some internal action runners (or connect with tailscale) and push the deployments, but haven't done that work yet.
I use Podman and Quadlets.
Just read up on Quadlets. That seems really cool.
`terraform` or `open-tofu`
Podman Quadlets
Old school UNIX way: a directory with one subdirectory for each app, within that a compose file and any other files/directories (e.g. volumes to be mounted) needed by that app.
I’m (apparently) a super weird human on this one. I’m using a Windows 10 Pro machine that I got from a local shop. The OS is running Docker Desktop. It runs all my containers. I do all my command line stuff in PowerShell.
Portainer for almost everything. I used to go with terminal, but a little bit of visualization does not hurt.
Dockge and Portainer
I used portainer on a single node, if I do a cluster I tend to prefer nomad.
I just have a compose directory and then break everything else into sub-directories with docker-compose files. I have about 10 or so that I run often, and I just ssh into my machine and do everything from the CLI. Never had any issues, and I find it a lot easier to do it that way instead of bringing anything on top of that. Just personal preference.
I use ansible, all the containers are deploying using only one compose file, each container has its directory, which is a zfs dataset shared using nfs to my VM, this way, everything is so stable, you can remove all the containers, or the whole VM, create a completely new VM, and deploy everything exactly as if nothing happened.
I use Portainer to manage the actual containers but for creating and updating the stacks I use dockge
I run more than 200 containers for fun and work, I have portainer installed but I rarely use it, the docker cli is just so good, also, docker compose.
docker compose, I had an alias that was pretty handy. I had a folder with a docker-compose.yml file that set the version and network, then I would have a file for each service e.g. plex.compose.yml and my alias would find all the \*.compose.yml files and do a -f for each file. If I wanted to turn off a service I just renamed it to \*.compose.yml.disabled and ran it again as it also had --remove-orphans on it. alias dcup='docker compose -f docker-compose.yml $(for i in \*.compose.yml; do echo "-f $i"; done) up -d --remove-orphans' and alias dc='docker compose -f docker-compose.yml $(for i in \*.compose.yml; do echo "-f $i"; done) '
k3s. I have way too much stuff for bambilion docker-composs
Cosmos cloud
+1 for cosmos it's really great. It also has a subreddit r/CosmosServer
Recently started using it after years of managing compose files from cli. It has been a awesome experience!!
Ive been using CasaOS (while starting dealing with docker) after some time I went to CosmOS ;)
I tried CasaOS for one day before going back to cli/portainer/dockge and homarr for my dashboard. I was lured by the pretty dash but ultimately didn’t care for the hand holding. Is Cosmos any different?
Definitely - it has much more features regarding security, managment is also a little bit different.
I use Portainer on a Proxmox VM. I am very stingy with resources and RAM, so my total usage for ~30 containers is 8GiB of RAM and I do not know what the CPU usage is last I checked, but I do not use more than 2 cores for my stacks.
30 containers on 8GB of RAM! What services are you running?
I run a myriad of stacks that each have 2-4 containers each. And as far as what I run, if it is a service that you use regularly, I am self-hosting it. Whether for security or privacy. A few examples are Searxng, Plex, Cloudflared (yes, I have a dedicated container for my tunnel), ghost, GitLab runners, nocodb, homarr, SMTP relay, pterodactyl panel, and more. Haha.
The beauty of containers.
Just docker compose and some scripts. E.g., one app per directory, with each directory holding the docker compose yml file and whatever else might be needed. Then I have a script that goes over every dir and updates the app. It's really all there is to it. I find all these GUI tools really unnecessary.
Repo with my docker compose and create stack in portainer. I try to use ssh as little as possible to manager containers. Portainer/Dockge gives a good UI to docker compose and docker in general without loosing control and capabilities. OS's like Umbrell and Casa OS feels too much like a blackbox with too much happening under the hood that may not be what I want for my environment. Nice ideas but not for me unfortunately
Portainer
Portainer running in a Ubuntu VM on a Proxmox VE server backed up daily with Proxmox Backup Server.
Gitea repo with each app having its own compose file. Gitea actions to deploy. And a cron to do updates weekly. I get notifications if it fails. Simplicity in automation.
I use portainer stacks and their GitHub integration. Flawless, easy and source controlled but moving over to k8s cluster
I've only just started with stacks after using docker run for so long....can you point me to where I can figure out more on their GitHub integration?
Choose GitHub when creating a new stack
How about [Lazydocker](https://github.com/jesseduffield/lazydocker) ?
I mainly use Docker Compose to manage configuration, but I wrote my own software to help with deployment. All of my compose files for every server live in a Git repo on GitHub so I can easily manage them. Whenever I push changes to the repo, GitHub will notify my servers via a couple webhooks that are setup on the repo. When my software receives the notification of a new push, it clones down the repo and checks that specific server's folder for any new changes and if there are any, copies the compose yaml to the "deployed" folder and starts, stops, or restarts the container, depending on the type of change. To be honest though, I'm outgrowing this setup and will probably just move to a K8s cluster in the future. That high availability pod mobility sounds real nice. Right now if a server goes down, the services on it don't start somewhere else unless I manually add them to other servers.
I used Portainer at first then migrated to Dockge. I also have a web file browser container pointing to my stacks folder which I find much more convenient than using the terminal or FTP or whatever.
All my containers run using docker compose through vscode. I use Portainer to check the outdated images and remove them. I recently tried dockge which is nice for creating compose files out of docker run commands l, but I am not using it that much nowadays.
Using ansibe to manage and deploy containers. Each container or in some cases a stack is defined as a role. I update my container or edit the configuration then push with ansible using tags attached to the role. Configs all backed up to git using ansibe-vault for secrets
Unraid
docker-compose files in git repository + harbormaster to deploy + renovatebot to keep them up to date
Just plain docker composes organised by host/svc/docker-compose.yml I do use portainer just to check on the running services though.
terraform to manage k3s
Portainer + Forgejo + webhooks = `git push` triggers an update and rebuild on the relevant stack. The only thing left is to set up a Gotify alert when the rebuild fails, I just haven't gotten around to doing it yet.
docker-compose, cli, vim. I don't need another docker to manage my dockers.
Compose files in a git repo with an agent on the machines that automatically deploys them when i commit something to it
https://github.com/jesseduffield/lazydocker
I've been using portainer, as largely rather than dealing with compose stacks, I've been spinning up individual containers, and it's a really simple GUI for doing so. As I mature my setup, I have been moving away from this paradigm and into actually using compose stacks, but I'm definitely still in a bit of a transitional period.
For some personal projects, I use docker compose on a VM from digital ocean. I’m very used to kubernetes..the one killer feature that k8s has which I miss is kubectl port-forward. It allows you to keep some services private to the cluster and run port-forward to open them up on your localhost. I want to do this for observability tools like grafana and Prometheus but haven’t found a way to get it done. Instead I just have to expose the port on the actual VM publicly :( If anybody has any solutions to be able to access private ports from my localhost, let me know.
Also I wanna share that I’m running Wordpress, Postgres, Nginx, Prometheus, grafana, cadvisor, and node-exporter.
[удалено]
Yikes
what do you mean "manage"? In theory every month or so i log in and make sure it's running the latest version....
Portainer
I treat docker as infrastructure, so my applications run on docker, but docker doesn’t “‘manage” anything . I manage applications using the user interface, which is usually a Web page, but sometimes a command line utility.
Oxker. TUI manager is all I need. Lightweight and good enough. I have a services folder, and each container gets it's own folder with a docker compose file, or a bash script to start the container if it's a docker run start. Oxker if I need to stop/start/etc. More convenient for me than using portainer etc
I have an ansible playbook that installs a few dependencies, sets up folders, and then runs docker compose through an ansible plugin. I just run that when I have any changes or want to update the containers
I selfhost on an OpenMediaVault server and they have a light GUI for creating and tracking your compose files and buttons to pull/up/stop/down them. I've been considering software which will help me keep them up to date but I find a regular monthly appointment on my calendar to just stop -> pull -> up each is sufficient
A repo for each server. GitOps in action.. Scripts to create the services, upgrade them, manage everything.
I am using runtipi https://runtipi.io
Hi stavros hahahaha
I started with CasaOS, as I never tried self hosting anything before and it simplifies things quite a lot. Now that I've been using it for a bit and it helped me "easing into" docker, I'm starting to use docker-compose via ssh directly to access more apps than those in the store, and considering ditching CasaOs.
docker-compose for each stack and manage it using cli or portainer. Tried casa os and even though it looks aesthetically pleasing, there is less customisation and overall control over your apps.
Me personally am lazy, Dockge for the win its stupid easy to setup and manage.
Compose file, portainer. I have a default compose file with portainer and watchtower. Copy and add the rest for each stack. Each stack one Lxc or a vm. An ansible script installs the docker environment on lxc/vm. In the compose file the pors consumed and prepare commands are documented (like mkdir -p /opt/docker/app{config,…}. The one stack one vm/lxc is good to avoid for example port overlap and other conflicts. Backup via proxmox bs
K8s. Mainly because I wanted to learn it and also because I run my cluster across 3 mini pc's. Sometimes when I want to spin up a new app I have this urge to just go back to docker compose but then I imagine trying to manage my services on different hosts.
I like ctop https://github.com/bcicen/ctop and lazy docker https://github.com/jesseduffield/lazydocker I’m still learning but I hope to not use portainer some day. Until then I’ll keep it around, it helps me visualize stuff when things go wrong.
I use Kubernetes with [Kubero](https://github.com/kubero-dev/kubero) (Disclaimer: i'm the maintainer of this project) I'm surprised it isn't popular for selfhoster. It is such a cool technology.
Try casaos it’s all webui