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.
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 both docker-compose run and podman-compose run.
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.
4am@lemm.ee 1 week ago
Why would anyone use containers without compose?
Especially people who are newer? It’s far easier.
x00z@lemmy.world 1 week ago
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.
tripflag@lemmy.world 1 week ago
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.
lambalicious@lemmy.sdf.org 1 week ago
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.catloaf@lemm.ee 1 week ago
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.
JollyGreen_sasquatch@sh.itjust.works 1 week ago
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.
lambda@programming.dev 1 week ago
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.
JollyGreen_sasquatch@sh.itjust.works 1 week ago
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.