Should I be using a unified Docker-Compose.yml? reddit / selfhosted ---------------------------------------------------------------------- Captain-Moroni · 2023-12-08 20:04 I've been using docker for the last 2-3 years in ubuntu, last year I moved from setting up each instance with the docker CLI to docker- compose. When I want to start up a new container, I create a new docker compose file in its own folder, add the info for the container I want, then launch it. If I need to modify any network or environmental variable I do that in portainer. Would it be better to have a single docker compose with all of the containers listed? Would it be better to have docker compose files for each set of containers that interact with each other? Would it be better to keep using a new compose file for all of my containers? ---------------------------------------------------------------------- Vyerni11 · 2023-12-08 20:26 The proper way is to have separate compose file for each project. But its up to you what you do. I personally have the one compose file, and put everything on separate docker networks unless they need to communicate to each other. ---------------------------------------------------------------------- Firm_Nothing_2223 · 2023-12-08 20:30 If you are using Portainer now you can deploy your compose.yml's using Stacks in Portainer. Me myself group similar services into different stacks. Then the compose files are stored in plain text in a compose directory under the Portainer data for backing up everything. ---------------------------------------------------------------------- dajun-la · 2023-12-08 20:39 it depends on what you are trying to do and how familiar you ware with it. I have everything in one docker-compose file because I have lot of services the communicate and are behind Nginx Proxy Manager. I don't feel like managing a bunch of networks and the fact that I can move all my services from machine to machine easily. Also I can update everything in one go vs multiple docker. you can even manage multiple networks in one DC file. Its not better, its not worse, its all about use case/experience. if you wanting to know the real difference, and nothing is critical, try it and see how it goes! ---------------------------------------------------------------------- thekrautboy · 2023-12-08 20:40 > Would it be better to have a single docker compose with all of the containers listed? No, absolutely not. Some people might comment that they have been doing this for decades, good for them. Its a terrible practice and it ruins many of the advantages compose offers. Just because something *can* be done somehow doesnt mean its a good idea to it that way. > Would it be better to have docker compose files for each set of containers that interact with each other? Yes, thats the typical setup and good practice. You have a set of containers (services) which are then called stacks all inside one compose. For example a web frontend and a database. They belong together, they are placed in their own Docker network together. No other container needs access to the database for example. No ports need to be mapped to the Docker host either, except those that are absolutely required. For example the web frontend HTTP port so you can access it. Or you use a reverse proxy, then none of those ports need to be mapped to the host at all, they only get accessed by the proxy server. > Would it be better to keep using a new compose file for all of my containers? No, see above. **This question gets asked here a lot so i am just going to copy&paste the rest of a older comment of mine:** ___ **Stuffing everything into on giant compose file is a nightmare and removes a lot of the advantages that compose actually provides. Unfortunately there must be some Youtuber or blogger out there that teaches this approach, youre not the first person to do this.** **See the end for a TL;DR** My suggestion, and i believe this is common best practice: **Use a seperate folder and one compose for each stack, as in a group of services that absolutely need to be together. Keep bind mounts like data, config, db etc folders for the services also within those folders.** #Structure As a example of folder structure: mydockerstuff/ ├── immich/ │ ├── cache/ │ ├── docker-compose.yml (contains only immich itself with its own postgres, typesense and redis) │ ├── postgres/ │ ├── upload/ │ ├── typesense/ │ ├── redis/ ├── outlinewiki/ │ ├── data/ │ ├── docker-compose.yml (contains only outline itself with its own postgres and redis) │ ├── postgres/ │ ├── redis/ ├── portainer/ │ ├── data/ │ └── docker-compose.yml (contains only portainer itself) And each stack (folder) also has their own **Docker network** defined inside the compose, so the postgres db from immich doesnt get to be in the same network as the redis from outline for example. When using a **reverse proxy**, only the frontend of a stack that requires to be proxied becomes member of the proxy network. Everything else of the stack stays **seperate**. There is no need for the db container to be part of the proxy network, and the db also doesnt need any ports mapped to the Docker host. Of course a container like Portainer as example that doesnt have any other containers to rely on doesnt *need* its own network, when its being proxied its enough to make it a member of the proxy network and thats it. #One-db-for-all or One-db-for-each? This also speaks to the question of "**one db container that all services use together**" or "**one separate db container for each service**". It might seem logical to run one central MySQL db container and then have all your services connect to that and use it, to keep it simple and save on RAM and CPU. However people who go with that approach are basically guaranteed to run into problems longterm when, especially with databases as example, different versions are required. For example you are running Postgres 14 for all your services, and it works great. Then a update for one service comes up and that update now requires a major version upgrade to Postgres 15. What do you do? You can either spend a lot of time researching if all your other services are also compatible with the higher version of the db, how to migrate each of them, run backups before hand and then risk the upgrade for everything. Or you can start up a second container, keep the old v14 and run a new v15 in addition. Over time that wont just be two containers with that approach, you will end up with a handful of Postgres containers, another handful of MySQL, some InfluxDB and etc. Soon you will realize that sticking each service with its own dedicated db is much simpler to keep track of. And when a service requires a db upgrade, you can just upgrade that one single db and everything else is not impacted by that at all. Also, especially for db containers you should pin them to a specific version in your compose files, and do not use *latest* for example. Databases are almost always finnicky with major version upgrades, so i would absolutely not recommend to have them use *latest* as tag, and even worse, auto-update them with tools like Watchtower. If you deploy a new project, and they recommend version X of a specific db, then you should stick to that and keep using that version, until the maintainers of that project recommend the next major version of the db. It may sound like a lot of extra work, but it isnt, and it will save you a lot of headache in the future. The **CPU usage** impact is near nothing by running multiple db containers, because they almost only cause load when they are being used. And then it doesnt make much difference if that load is on one single db or spread out over multiple smaller ones. The workload stays the same. There is of course some overhead, but i would claim its extremely minimal for typical homelab setups. **RAM usage** i could see more of a reason to go for a single main db instead of one-per-service, a naked MariaDB by itself uses something like 100MB, so when someone is using a host with very limited RAM available (Raspi3 with 1GB as example) i could understand that they dont want to run 3x MariaDB for a total of 300MB just for those. They would "save" 200MB by running a single db instead. Of course they would still need to face all the disadvantages i mentioned already by using a single db for multiple services. Now back to the original topic, to manage these stacks its very simple. Some examples: cd immich docker compose up -d cd .. cd portainer docker compose pull && docker compose down && docker compose up -d Or docker compose --f immich/docker-compose.yml up -d docker compose --f portainer/docker-compose.yml pull && docker compose --f portainer/docker-compose.yml down && docker compose --f portainer/docker-compose.yml up -d It helps to define some often used docker compose commands as shorter alias in `.bashrc` (or whatever you use). So `docker compose up -d` becomes just `dcupd` for example. You can also still use [Portainer](https://www.portainer.io/) to manage stacks that are deployed manually, you only miss out on a few specific features. Compare yourself and make your own choice. But imo using **only** Portainer leads to not learning actual Docker and when the time comes when Portainer cannot handle something, people end up clueless. (For those completely new to Portainer, you can grab a [free license of the Business Edition](https://www.portainer.io/take-3) for 3 nodes for free, and it offers a few extra features). #TL;DR Keep every group of services as a separate stack and folders, follow K.I.S.S, you will be thankful for it longterm ---------------------------------------------------------------------- flaming_m0e · 2023-12-08 20:42 > Then the compose files are stored in plain text in a compose directory under the Portainer data for backing up everything. TIL. Thank you kind stranger. This even stores compose yamls from remote portainer agents as well ---------------------------------------------------------------------- Firm_Nothing_2223 · 2023-12-08 20:48 TIL I have not tried using agents and deploy individual instances. My fear is my main instance goes down then I assuming I can't access the others or am I incorrect? Thank you ---------------------------------------------------------------------- flaming_m0e · 2023-12-08 20:49 I can't access my portainer instances on the remotes if the main one is down, but if I have compose ymls and a command line, I'm good. ---------------------------------------------------------------------- Firm_Nothing_2223 · 2023-12-08 20:57 I just switched to deploying via Portainer so not scared of cli. But this is just a little more convenient for a homelabber that forgets commands once in a while . Greatly appreciate your input ---------------------------------------------------------------------- ProbablePenguin · 2023-12-08 21:01 >Would it be better to have docker compose files for each set of containers that interact with each other? This is how you're supposed to do it. For example a webserver using Nginx, PHP, and a Database would be a compose stack. ---------------------------------------------------------------------- ProbablePenguin · 2023-12-08 21:04 You only need 1 manually created network for proxy communication across stacks. The problem with a single compose file is your service names are all screwy too, like normally I would have a compose stack named 'nextcloud' and the containers would be named 'db' 'app' 'redis' and the volumes 'data' 'db' Docker would automatically prepend the 'nextcloud' stack name to everything so they would become 'nextcloud_db' 'nextcloud_app' and so on. This lets you refer to services by only the internal name so for example nextclouds default config would just use the hostname 'db' to access the database. By having everything in one stack you have to manually name everything and update default configs a lot. ---------------------------------------------------------------------- SillyLilBear · 2023-12-08 21:15 this is the comment you should focus on. ---------------------------------------------------------------------- Captain-Moroni · 2023-12-08 21:45 Thank you very much for the write up! Super helpful. So with the services I've got above, like audiobookshelf, trillium and cloudflared, they all talk because cloudflared is how I serve them up outside of my local network, they would be on one single compose file, while my minecraft servers would be on a seperate one with playit.gg? ---------------------------------------------------------------------- threedaysatsea · 2023-12-08 22:05 Sticky this comment! Excellent write-up. ---------------------------------------------------------------------- FonduemangVI · 2023-12-08 22:29 The thing I'm impressed with is you managed to get Outline working, do you mind sharing your compose/setup. I've been struggling with it for a while ---------------------------------------------------------------------- thekrautboy · 2023-12-08 22:35 I would not put audiobookshelf and trillium together, they have nothing thematically to do with each other but more importantly, they simply dont need to talk to each other, so why do that at all. Instead have your cloudflared container have its own persistent Docker network, for simplicity, in its own compose file. Then each container that needs access to it you simply join that container to the cloudflared network. ---------------------------------------------------------------------- Captain-Moroni · 2023-12-08 22:47 Okay, so it isn't so much as each container that I need to talk to each other has it's own docker compose, it is each container that depends on each other. So cloudflared is by itself, but tandoor and postgres share a file ---------------------------------------------------------------------- Astorek86 · 2023-12-08 22:49 Just wanna add something, that I think is very useful: A little Shell- Script, that updates every Container on that. ``` mydockerstuff/ ├── immich/ ├── outlinewiki/ ├── portainer/ ├── update.sh ``` That `update.sh` contains the following: ``` #!/bin/bash for d in $(ls -d */ | grep -v "^old"); do cd "$d" echo --- echo $d docker compose pull docker compose down -t 30 docker compose up -d cd .. done wait echo "All done" ``` Run the Script with `bash update.sh` and it will update every Container... Every Directory that starts with `old` will be skipped. Just wanted to put that here, I thought it could be useful to some users^^. ---------------------------------------------------------------------- thekrautboy · 2023-12-08 23:15 Thanks for adding this. Sadly your formatting makes it useless ;) One large downside i see with your script is that it would take down containers even when there isnt a new update. Regardless, mass-updating containers can be risky and i would not recommend that as a general practice. Its not uncommon that software has breaking changes in a new update and blindly updating everything can break your services, leaving you to wonder wtf has happened. And the time you spend then figuring it out and fixing it is very likely much longer then the very short time you saved by updating everything at once. A good tool to do this (when it makes sense) is dockcheck. https://github.com/mag37/dockcheck ---------------------------------------------------------------------- thekrautboy · 2023-12-08 23:19 Simply put, only place containers with each other that require it technically. Sometimes you can of course make exceptions for simplicity and group things together that dont depend on each absolutely, but still belong together. Thats completely up to you of course. ---------------------------------------------------------------------- ithilelda · 2023-12-09 00:07 well, I suggest whatever fits you. There isn't ANY technical difference, the top post is factually incorrect. The only difference is maintenance. If you find having too many files makes you lose track, just combine some into one. If you find your monolith too large, just split. Do it your way. Do it however makes you efficient. ---------------------------------------------------------------------- AlteRedditor · 2023-12-09 01:05 Gosh, I can't put it into words how useful this is for beginners like me. Getting started felt kinda hard, especially for all kinds of fears and the abundance of information that is just hard to figure out, like do I need this thing or not and so on. So thank you so much!! 🏆🏆🏆 ---------------------------------------------------------------------- ijustlurkhere_ · 2023-12-09 01:32 > Keep bind mounts like data, config, db etc folders for the services also within those folders Question: whenever rebuilding a docker host and starting up services, if i point their bind points to existing folders used by the same services before - the data gets overwritten. Is there a way to make it reuse data already present in the bind points? And another question: is there any reason i wouldn't want that? Is that bad practice? ---------------------------------------------------------------------- thekrautboy · 2023-12-09 01:35 Uhm, youre welcome :) ---------------------------------------------------------------------- thekrautboy · 2023-12-09 01:36 > Question: whenever rebuilding a docker host and starting up services, if i point their bind points to existing folders used by the same services before - the data gets overwritten. That should not happen, atleast not as default with Docker. But maybe some containers have this added as a function because for that specific software it makes sense, im not sure. ---------------------------------------------------------------------- ijustlurkhere_ · 2023-12-09 01:39 Hm, good to know - i'll recheck. ---------------------------------------------------------------------- Budget-Supermarket70 · 2023-12-09 02:11 What do you loss from running things in one container. Your comment says you loose the advantage of docker compose. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 02:12 > What do you loss from running things in one container. Nobody said anything about "running things in one container". ---------------------------------------------------------------------- Budget-Supermarket70 · 2023-12-09 02:14 Define update default configs a lot. I haven't done it at all. Sure the docker compose are not default but did it once and that's it. ---------------------------------------------------------------------- ProbablePenguin · 2023-12-09 02:22 A lot of services will default to say "db" as the database hostname, if you're running everything in one compose file, your db will be named something else. ---------------------------------------------------------------------- pattymcfly · 2023-12-09 03:24 Everything is correct. Great write up. ---------------------------------------------------------------------- rmc13_ · 2023-12-09 03:39 Thank you so much for sharing this. Very helpful and comprehensive. I'll be saving this for my future homelab setup as a reference. ---------------------------------------------------------------------- JB-pixel · 2023-12-09 03:48 My approach is to have a stack per type of apps that may interact with each other, i.e Sonarr, Radarr, Prowlarr, Overserr, bazarr all in a single stack. It may depend on your use case. I also have a stack for home iot/ security ( home assistant, mqtt, frigate, whisper) ---------------------------------------------------------------------- bacitoto-san · 2023-12-09 03:56 I've done it and quickly went back to one compose for each service. Edit: I confess, I have some compose files for multiple services/containers but they are very similar in both function and form ---------------------------------------------------------------------- uberduck · 2023-12-09 04:30 No. Blast radius. Manageability. ---------------------------------------------------------------------- SEND_NUKES_PLS · 2023-12-09 06:16 Why tf would anyone have a single compose for multiple projects?? ---------------------------------------------------------------------- Apo2k7 · 2023-12-09 08:34 To add to this. I'am using gitea in my network for storing my compose.yml's. You can configure a stack in portainer to use a git repo as a source for the compse.yml, it also updates the stack if the repo changes. So you get the best of both worlds automatic deployment and also version controled storage. ---------------------------------------------------------------------- GolemancerVekk · 2023-12-09 09:40 > Or you use a reverse proxy, then none of those ports need to be mapped to the host at all, they only get accessed by the proxy server. Just wanted to point out that in that case if the proxy goes down you can't access anything anymore. So you *may* want to consider mapping to host, and using those for the proxy mapping. At your discretion. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 09:42 Do however you want in your setup but i would consider this bad practice and not great advice. ---------------------------------------------------------------------- Astorek86 · 2023-12-09 09:45 >Thanks for adding this. Sadly your formatting makes it useless ;) Useless because of the formatting? What do you mean? I don't see an error here... The Update-breaking changes are also a problem if you're using something like dockcheck and Watchtower. There's nothing to prevent such things at the moment; dockcheck and Watchtower will also do the same... I also wanted to show how simple a Script could look to easily modify that for yourself, for the Community. But the Downvotes says to me, I shouldn't do that anymore here... ---------------------------------------------------------------------- GolemancerVekk · 2023-12-09 09:46 Not creating a single point of failure *is* good practice. But, like I said, it's up to each person to weigh convenience vs other criteria. It does make it easier if you don't have to remember two sets of URLs. ---------------------------------------------------------------------- labm0nkeys · 2023-12-09 09:53 I've made an example github repository where I show how I do it. The main reason was that there are two cool docker features called extends and includes that allow you to reduce code repetition and split the stack into multiple files. It was not so easy to find a good exempt if it so I made one. Here it is https://github.com/labmonkey/docker- compose-project-example ---------------------------------------------------------------------- MiakiCho · 2023-12-09 10:32 If you don't mind learning something new, I strongly suggest ansible. You can deploy all containers in one command and at the same time update only a few in a group or just one single container with the help of tags. And you can do all that even without opening a terminal inside the server. You can also update directly from your editor, emacs, vim, VSCode etc. docker-compose, in my opinion has some serious limitations. It is hard to define dependency, order of deployment, conditions when a container requires a restart etc. With ansible it is very easy for me to specify dependency, order, conditions etc etc. ---------------------------------------------------------------------- pogky_thunder · 2023-12-09 11:29 There's also watchtower that does the same thing. ---------------------------------------------------------------------- mmcnl · 2023-12-09 11:49 A lot of words I don't necessarily agree with. A single compose file also has its advantages. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 12:40 Yes, like i mentioned: > If you are on the hunt for something to fully automatically update all your containers, tools like Watchtower exist for that. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 12:41 Fine with me if you disagree. You can stick to what you think is best and maybe 1% of Docker users do, and i stick to what probably 90+% of users do. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 12:44 The typical reasons for using a reverse proxy is to provide HTTPS for services which dont do that themselves, and/or to use much easier URLs without having to add portnumbers (and also avoiding port conflicts of course). Both of these become pointless when you say you also map ports to the host "as a backup in case the proxy goes down". That sort of like saying "i run all my secure services through LAN, but i also have a unencrypted WLAN open just in case the LAN breaks"... not exactly the same but i think you get my point. If you are worried about the proxy being a single point of failure, simply use load balancing / failover, many proxies can do that. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 12:50 > Useless because of the formatting? What do you mean? [Because this is how standard reddit displays your comment](https://imgur.com/rSUEvxe). It may look correctly formatted to you using different clients, like mobile apps, but reddit often doesnt work the same across all platforms and clients. > The Update-breaking changes are also a problem if you're using something like dockcheck and Watchtower. There's nothing to prevent such things at the moment; dockcheck and Watchtower will also do the same... I know, thats why i pointed it out. > But the Downvotes says to me, I shouldn't do that anymore here... (Sorry, but I'm a bit frustrated because that's not the first time I throw an lengthy explanation of something, and nobody says what's wrong with it, I just got downvotes without any explanation whatsoever...) If you put any value into up or downvotes youre not going to have a good time on reddit. Try to ignore them as much as you can, be yourself and stick to your comments. If people dislike it and dont bother telling you why, thats just how it is. You cannot force people to have a discussion with you. ---------------------------------------------------------------------- mmcnl · 2023-12-09 12:58 Most cars are black, doesn't mean they are better than green cars. ---------------------------------------------------------------------- thekrautboy · 2023-12-09 12:59 Wow, impressive arguments you provided for using a single compose. I give up, you converted me. Brb while i change all my setups. ---------------------------------------------------------------------- mmcnl · 2023-12-09 13:10 I literally said my point is that one is not inherently better than the other, but that you should choose the complexity you are willing to deal with it. ---------------------------------------------------------------------- arimhan · 2023-12-09 13:57 Doesn't docker create a default network per stacks ? so a single stacks means every service can talk to each other. ---------------------------------------------------------------------- ithilelda · 2023-12-09 14:32 yes, but you can always use the top level networks field to define your own. Then add a networks field to services that you want a specific network. It is all configurable. ---------------------------------------------------------------------- arimhan · 2023-12-09 14:55 Well if you have to add the network field to each service, whats the difference with mulitple stacks ? ---------------------------------------------------------------------- Captain-Moroni · 2023-12-09 15:07 You mean you define a path for a volume and that gets overwritten? That definitely should not be happening, the whole reason you use defined volumes outside of the container is so that the data persists if you take down that container ---------------------------------------------------------------------- Captain-Moroni · 2023-12-09 15:13 Another question, if I add an entry to the compose file, say I didn't have bazarr with the other four you mentioned but wanted to add it, would I restart the whole stack, or would I be able to just bring up the new one? ---------------------------------------------------------------------- ijustlurkhere_ · 2023-12-09 15:20 I'll need to test it a few times and see what i'm doing wrong as this *seems* to be exactly what's happening and the likelihood is very high that it's me doing something wrong. ---------------------------------------------------------------------- Captain-Moroni · 2023-12-09 15:21 Is there one particular image this is happening with or multiple? ---------------------------------------------------------------------- Captain-Moroni · 2023-12-09 15:23 If it is better, I'm happy to learn it! I'll check it out ---------------------------------------------------------------------- ijustlurkhere_ · 2023-12-09 15:27 PiHole specifically. i mapped it's data to a host folder to see if settings and admin password get preserved if i'm reinstalling the server and raising the services up again - and every time i tried to it had default settings and the password that was set in an env variable. I'm thinking maybe it's intentional on Pihole's part, but i honestly don't know the internal workings of docker containers well enough to figure that out. ---------------------------------------------------------------------- Captain-Moroni · 2023-12-09 15:30 The password is for sure overwritten every time I even restart the container, but other things such as adlists persist. I would guess that is a pihole specific "feature" ---------------------------------------------------------------------- ijustlurkhere_ · 2023-12-09 15:35 I can't check right now and i'm not sure if i'm gaslighting myself but i seem to recall things like dhcp settings or dhcp service being enabled not carrying over. But yes - very likely a Pi thing and that brings me to - would be nice to know proper ways to backup volumes, bound volumes, and database volumes. Or better yet - is there were a tool that did it for me. ---------------------------------------------------------------------- GenerousAccord · 2023-12-09 16:37 Agree completely. As a dev, I keep my own service's compose files in their own folders as well as other's compose files for things I selfhost, like my private docker registry. Although I recently moved my own services from docker compose to kubernetes using https://kompose.io/ and now the only thing I run with docker compose, currently, is my private docker registry but everything including in kube, are always in their own folders. ---------------------------------------------------------------------- GolemancerVekk · 2023-12-09 18:50 I try to keep things simple and to balance pros and cons. What are we using HTTPS *on the LAN* for? The only actor that could eavesdrop on these connections is my router, and that's under my control. HTTPS doesn't protect services from being accessed. If I have untrusted/hostile devices on the LAN (Chinesium cameras, guests on the WiFi etc.) that I'm worried could probe services for vulnerabilities, HTTPS won't protect against that; the answer is to isolate those devices on their own VLANs. You can control port mapping from Docker so that's not an issue. There are services that need to broadcast on the LAN (DLNA-capable services for example) which have to be host-mapped anyway. Bottom line, going through a proxy on the LAN tends to be a lot of convenience and very little actual necessity. And a luxury service should not bring all the other services down with it if it fails. Balancing proxies for selfhosting is an option but falls into an area of overkill for me personally. It goes way beyond what I'm willing to maintain at home. ---------------------------------------------------------------------- MercenaryIII · 2023-12-09 19:49 I usually prefer separate compose files myself, but what are some specific disadvantages for throwing everything in one compose file? As a starter, I know it would be overwhelming to see all that info at once (if you have many services). ---------------------------------------------------------------------- psicodelico6 · 2023-12-09 21:55 Great. Thanks . Question: when i run docker compose up.. Is it command run all services en each docker compose yml o just docker-compose.yml ? ---------------------------------------------------------------------- thekrautboy · 2023-12-09 21:56 I dont understand that sentence sorry. ---------------------------------------------------------------------- ithilelda · 2023-12-10 01:38 the reverse is also true. If there is no technical difference between the two approaches, then what's the difference? I've already stated that it is only a preference thing. ---------------------------------------------------------------------- arimhan · 2023-12-10 08:44 With multiple stacks you need to only add a networks to the external facing container, with one docker compose you need to create al those networks and add them to all the container, so much more room for security issue. ---------------------------------------------------------------------- SpongederpSquarefap · 2023-12-10 18:47 Yeah that's what I do I've always found "docker run" to be great for a one off thing I need to test, but awful for persistence I have several containers that are single containers deployed as a "compose stack" It's just easier - I can see the entire config and redeploy it easily Makes handling variables and secrets easy too - means I can share my config without risk of exposing secrets ---------------------------------------------------------------------- 10031 · 2023-12-11 14:43 You can individually bring up a service inside a stack. However, I don’t recommend a single compose file personally. ---------------------------------------------------------------------- havock · 2023-12-11 19:35 >blindly updating is not recommended This a thousand times. I've run into 2 cases where I update a docker container to the latest version only to find out that something was broken and the container no longer works. Why because I didn't bother to read the change log because I was lazy. I also totally agree with your each container get's it's own compose file post. ---------------------------------------------------------------------- thekrautboy · 2023-12-12 00:58 > What are we using HTTPS on the LAN for? The only actor that could eavesdrop on these connections is my router, and that's under my control. Plenty of other "actors", for example if another container gets compromised and you have your MariaDB listening on the host accepting unencrypted connections, its very simple to catch the user/pass and login to the db then. > HTTPS doesn't protect services from being accessed. True, but without it its extremely simple to catch passwords and abuse those services. With HTTPS you may be able to reach a login prompt but you lack the credentials. > the answer is to isolate those devices on their own VLANs. That would be ideal but thats not what were talking about here. > You can control port mapping from Docker so that's not an issue. Not sure what that is supposed to mean. You recommended to map ports to the host as a form of backup access in case the reverse proxy would go down. > There are services that need to broadcast on the LAN (DLNA-capable services for example) which have to be host-mapped anyway. True, but those are in the far minority with typical setups. > Bottom line, going through a proxy on the LAN tends to be a lot of convenience and very little actual necessity. And a luxury service should not bring all the other services down with it if it fails. I very much disagree that HTTPS for local networks is a luxury. ---------------------------------------------------------------------- GolemancerVekk · 2023-12-12 08:23 > Plenty of other "actors", for example if another container gets compromised and you have your MariaDB listening on the host accepting unencrypted connections, its very simple to catch the user/pass and login to the db then. How would a container that was given one port to listen on the host be able to intercept packets sent to another port, on another container? >> You can control port mapping from Docker so that's not an issue. > Not sure what that is supposed to mean. It means that containers don't get to open their own ports and sniff LAN traffic at will. They are under very tight control and receive only connections meant for them. Even if a container is working in network_mode=host it's not "simple" to sniff LAN traffic without elevated privileges.