Hi c/selfhosted,
I have another project idea. However, before I start I want to make sure there is interest in the community and a similar project does not exist yet.
I was thinking about a “compose” website that contains the compose files and basic information of the projects listed in the awesome-selfhosted list. Users can search for projects, browse by categories, etc. In my opinion when finding a new project you want to try out it, is a bit cumbersome to find the corresponding compose file to get started.
Let me know if there is any interest in such a project. Also I have no idea how I would name the project, so give me your best suggestions :). Thanks!
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?It’s not that it’s uncommon, but slightly different for each project.
I collated library would be kinda cool.
That said, I don’t know how much utility this project would have.
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.
Why compose and not just containers?
Why would anyone use containers without compose?
Especially people who are newer? It’s far easier.
Compose doesn’t have a versioned standard, it did for a bit iirc, which also means you can’t always just grab a compose file and know it will always just work.
Most self hosted works fine with giant all in one containers, even for complex apps, it’s when you need to scale you usually hit problems with an all in one container approach and have to change.
Huh? They officially support it and there is no need for a version any more. It’s standardised. As a matter of fact, if you try to start a compose stack that starts with a version number it gives you a warning that it’s not needed.
The lack of version is the problem. Syntax has changed over time, so when someone finds or has an older compose file, there is no hint it won’t work with the current version of docker-compose until you get errors and no graceful way to handle it.
I have tried probably over a hundred and never had that happen once. I hear you. But, there is only one version now and if your compose file doesn’t work it’s just incorrect.
for a selfhosted service which is a single self-contained process in a single container, is there still a benefit to using compose, and if so, what would that be? genuine question since I’m not providing a compose example for a foss service I made.
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.
