Interest in a website containing the docker-compose files of projects listed in the awesome-selfhosted list
-
S [email protected] shared this topic
-
While most have examples in their readme's on Docker hub and Github, not all of them do, so I sometimes have to hunt down an example buried in their git repo somewhere. So a searchable page for popular self-hosted app docker compose files would be welcome.
I don't think I've seen such a page anywhere else.
-
I know of these:
https://github.com/bitnami/containers/tree/main/bitnami/
https://github.com/docker/awesome-compose
They're not specific to projects listed in the awesome-selfhosted list though.
-
-
Have you looked at this?:
-
I'd assume the projects either have a docker-compose example in the readme or in the repository files alongside the actual project.
Is that so uncommon? -
Why compose and not just containers?
-
-
I'm really happy that the community stepped up and continued his great work.
-
-
Yeah, that's fair. Very convoluted and difficult documented.
-
It's not actually going that great, there is already infighting on the direction of the scripts.
-
-
-
You answer my question with a question... But I'll answer it.
Compose is meant for multi-container applications or development. It's good for custom applications where you need to manage every service yourself so you mostly see them used for stuff like web stacks.
Single container applications are much easier to run and manage for the end-user and most of the awesome-selfhosted apps are already served as single container images on the docker hub. There is absolutely no need to use compose for any of those because you are not managing every service of the app yourself.
I have a big server with lots of containers running for apps. For example, I have a container for my blog, one for FreshRSS, and even one for Teamspeak. But I only use Compose for one application and that's my own custom one. That one consists of an nginx container, php container, etc. I don't need to dive into the different services of FreshRSS for example, but I do need to for my own custom app.
-
I find it a lot easier to write out the yaml and save it in a file than to run a command every time, and I hate yaml.
-
It might be cool, but it seems like it would be missing the context and documentation that would be present in it's project repo.
-
Persistence of "mental state" mostly. By setting up a compose, you have a written down notion of things like volumes, environment variables and other elements stored somewhere for the behaviour of the container, that can not be ignored or defaulted if you don't wish it, for when you need to undo and redo a container and default behaviours are important.
While sure, those elements can be set in a loooong
${engine} run...command, it's easy to forget to set up something important or copy and paste an accidental endline. A compose file (plus a sample envfile, if you so wish) helps keep the way to set up variables and state under control. Made much easier now that we have bothdocker-compose runandpodman-compose run. -
-
Non-Fungible Tokens?
