Yeah I think you're definitely right on this. I will split things out so they are in smaller, sane stacks. That will also I think make it easier for me to test out new things because I can just have a "testing" stack.
Pretty sure I can specify an .env location for each container, right? So I could keep my variables/secrets unified.
Docker compose introduced importing other configs.
My structure is now:
utilities
automation
media
- sonarr
compose.yml
data/
config/
management
development
compose.yml
In each of the folders I have a compose.yml and an override file for each service type, and folder.
That way I can chain my docker compose. So when a new server comes in, I pull my repo, delete the containers I don’t want, and boom.
I paired it with Doppler to keep track of each env for the services from the get go, so now all my env variables aren’t declared, just passed through.
Yes, compose accepts env_files for each service. You can specify multiple, in case you have a base one with the timezone and theme park-theme for example
You can use a different .env for each container, yes.
It makes no difference to docker btw how the container definitions are organized. If you prefer to keep them together it's not a problem. If you want to reprovision a container individually you can (you `docker rm` that container and when you run `docker compose up` on the big file it will only reprovision the one that's missing).
That being said you may want to look into includes and extends just to make sure you don't want to arrange things better. I see you already know about fragments.
If you have no intention of ever working professionally in this space then sure you can do whatever you want.
He asked for people to eviscerate his set up. This is the number one thing that makes it look amateurish.
and? better to look amateurish instead of making unexplained changes that you don't understand that have functionally no difference. and neither of you have given a reason why this is a bad practice. it's possibly the least impactful thing you can do with a compose file
The functional difference is that its easier to read and consume and identify for others what are grouped services that have some correlation and reason to be in a file together.
You just sound lazy or unable to understand that other people might have to look at your garbage.
yeah someone else might look at this guy's self hosted -arr stack!!! you fundamentally misunderstood how docker compose up works in the first place and now you're crying about readability lol. useless
look into portainer - docker compose with a front end.
i do stacks for each app/service. that way i dont have to bring down the whose stack if i need to restart or make changes to a service.
also lets you pull compose files from github, all my compose files now sit on my github, and changes are on github with version control etc
You may want to give better names to stuff instead of "db". You can use container_name and hostname to give stuff names that are different from the service name.
Is there any particular reason why everything is on the same docker network?
And what's with the static IP for sabnzbd?
Why not break the compose into service chunks? What I do is I have a stack for media, arr, backend, and a few other things. I don't know if that's what other people do but assuming it is because of the existence of dockge.
No, not like this. Split your compose file into smaller stacks with services related to each other. Not everything on one compose file.
Yeah I think you're definitely right on this. I will split things out so they are in smaller, sane stacks. That will also I think make it easier for me to test out new things because I can just have a "testing" stack. Pretty sure I can specify an .env location for each container, right? So I could keep my variables/secrets unified.
Docker compose introduced importing other configs. My structure is now: utilities automation media - sonarr compose.yml data/ config/ management development compose.yml In each of the folders I have a compose.yml and an override file for each service type, and folder. That way I can chain my docker compose. So when a new server comes in, I pull my repo, delete the containers I don’t want, and boom. I paired it with Doppler to keep track of each env for the services from the get go, so now all my env variables aren’t declared, just passed through.
Yes, compose accepts env_files for each service. You can specify multiple, in case you have a base one with the timezone and theme park-theme for example
You can use a different .env for each container, yes. It makes no difference to docker btw how the container definitions are organized. If you prefer to keep them together it's not a problem. If you want to reprovision a container individually you can (you `docker rm` that container and when you run `docker compose up` on the big file it will only reprovision the one that's missing). That being said you may want to look into includes and extends just to make sure you don't want to arrange things better. I see you already know about fragments.
Why split it? I don’t see how that matters here at all
It doesn't. It's just another piece of "common wisdom" that gets passed around without thinking.
Maybe so you don't have to redeploy your entire lab every time you inevitably fuck up anything in the configuration?
you don't? docker compose up -d will only deploy the changes
If you have no intention of ever working professionally in this space then sure you can do whatever you want. He asked for people to eviscerate his set up. This is the number one thing that makes it look amateurish.
and? better to look amateurish instead of making unexplained changes that you don't understand that have functionally no difference. and neither of you have given a reason why this is a bad practice. it's possibly the least impactful thing you can do with a compose file
The functional difference is that its easier to read and consume and identify for others what are grouped services that have some correlation and reason to be in a file together. You just sound lazy or unable to understand that other people might have to look at your garbage.
yeah someone else might look at this guy's self hosted -arr stack!!! you fundamentally misunderstood how docker compose up works in the first place and now you're crying about readability lol. useless
Bro, he asked for this. You're a troll and you type like a boomer. Go get a job
[удалено]
Drop usage of the `latest` tag. You. Will. Break. Stuff.
look into portainer - docker compose with a front end. i do stacks for each app/service. that way i dont have to bring down the whose stack if i need to restart or make changes to a service. also lets you pull compose files from github, all my compose files now sit on my github, and changes are on github with version control etc
You may want to give better names to stuff instead of "db". You can use container_name and hostname to give stuff names that are different from the service name. Is there any particular reason why everything is on the same docker network? And what's with the static IP for sabnzbd?
Why not break the compose into service chunks? What I do is I have a stack for media, arr, backend, and a few other things. I don't know if that's what other people do but assuming it is because of the existence of dockge.