3 ms·

Docker feels incomplete without Compose. Dockerfiles on their own are usually missing a lot of critical information about how to run the container in practice (

Docker feels incomplete without Compose. Dockerfiles on their own are usually missing a lot of critical information about how to run the container in practice (volumes, environment variables, network dependencies, ports to forward, etc). With plain Docker you usually have to read a bunch of documentation to figure all that out; with Compose all that information is in the file and you can just run `docker compose up`.

msm_ 3y ago
Dockerfiles are more versatile. For example Kubernetes also uses Docker images (thanks to the OCI specification), but you don't configure Kubernetes with docker-compose.yml files, and Kubernetes usually doesn't even use Docker under the hood. But sure, for local deployment docker-compose is awesome.
- giobox 3y ago
  > Dockerfiles are more versatile Not sure I follow? Docker Compose in no way trys to replace a Dockerfile or docker images - every container you specify in one still has the exact same Dockerfile, compose can't replace this. I also think Compose is a fantastic tool, but to start comparing to Dockerfiles and Kubernetes suggests not understanding what Compose is for. The thing Compose does better than a bunch of loose dockerfiles especially is document in a runnable fashion the relationships between key containers in a given stack. This information alone can tell you a lot about how you would deploy in more complex environments, as well as giving you something you can usually deploy instantly with a docker compose up for local development work. Without compose, you typically have to rely on loose documentation much more, which may be stale or outdated and obviously isn't "runnable" like docker compose is. I also find it far easier to understand what volumes are critical for persistence when its coded in the Compose yaml, vs a bunch of -v args in the documentation for a docker run command launch.
wdfx 3y ago
I don't think that's really a docker problem. Its more about the instances of software that you want to run together. e.g. nginx in isolation is useless. But is really useful when you want to expose a bunch of other services on a single http(s) interface. When you are working at the compose level you are thinking about an ecosystem of services working together and of course then you are you using the compose tools to achieve that. But managing each component in isolation is much more tedious.
- Ajedi32 3y ago
  Even with only one service I still consider Compose to be a necessity. Otherwise you need to manually specify how to mount the volumes, set the environment variables, and forward ports when you run the container. Only the most trivial containers are easily usable with plain `docker run`.
  - wdfx 3y ago
    That's a fair point I suppose that docker itself doesn't provide a declarative config for starting containers. But that is also true of a whole bunch of tools which only either provide cli or config but not both
    - yownie 3y ago
      yes all of which results in extremely poor end user experience. I'm glad we're in agreement here.
  - aquova 3y ago
    I agree. Having containers start at boot automatically is a useful enough feature to make compose worth it.
mieubrisse 3y ago
Strongly agree. There's a big knowledge gap between the container author and the container consumer that Docker doesn't have a great toolkit for bridging. The best we get are the ENV, EXPOSE, and VOLUME directives, but authors should really have tools to say: - what filepaths are important (both for volume-mounting and for files output by the container) - what envvars (or CMD, or ENTRYPOINT) are needed - what ports will be opened, and what they mean - what protocols the ports talk ...etc. I'd really like containers to one day behave like software libraries: you pass in a set of documented parameters, and get an object that you can pass around and use in return.
krick 3y ago
> Dockerfiles on their own are usually missing a lot of critical information about how to run the container Uh, of course they do, since they say nothing about how to run a container. Dockerfiles encode an image (also not really deterministically, contrary to the common belief, but that's details), not a container. And docker-compose.yaml represents making a bunch of containers from images. These are completely separate things.

msm_ 3y ago

Dockerfiles are more versatile. For example Kubernetes also uses Docker images (thanks to the OCI specification), but you don't configure Kubernetes with docker-compose.yml files, and Kubernetes usually doesn't even use Docker under the hood. But sure, for local deployment docker-compose is awesome.

giobox 3y ago
> Dockerfiles are more versatile Not sure I follow? Docker Compose in no way trys to replace a Dockerfile or docker images - every container you specify in one still has the exact same Dockerfile, compose can't replace this. I also think Compose is a fantastic tool, but to start comparing to Dockerfiles and Kubernetes suggests not understanding what Compose is for. The thing Compose does better than a bunch of loose dockerfiles especially is document in a runnable fashion the relationships between key containers in a given stack. This information alone can tell you a lot about how you would deploy in more complex environments, as well as giving you something you can usually deploy instantly with a docker compose up for local development work. Without compose, you typically have to rely on loose documentation much more, which may be stale or outdated and obviously isn't "runnable" like docker compose is. I also find it far easier to understand what volumes are critical for persistence when its coded in the Compose yaml, vs a bunch of -v args in the documentation for a docker run command launch.

wdfx 3y ago

I don't think that's really a docker problem. Its more about the instances of software that you want to run together. e.g. nginx in isolation is useless. But is really useful when you want to expose a bunch of other services on a single http(s) interface. When you are working at the compose level you are thinking about an ecosystem of services working together and of course then you are you using the compose tools to achieve that. But managing each component in isolation is much more tedious.

Ajedi32 3y ago
Even with only one service I still consider Compose to be a necessity. Otherwise you need to manually specify how to mount the volumes, set the environment variables, and forward ports when you run the container. Only the most trivial containers are easily usable with plain `docker run`.
- wdfx 3y ago
  That's a fair point I suppose that docker itself doesn't provide a declarative config for starting containers. But that is also true of a whole bunch of tools which only either provide cli or config but not both
  - yownie 3y ago
    yes all of which results in extremely poor end user experience. I'm glad we're in agreement here.
- aquova 3y ago
  I agree. Having containers start at boot automatically is a useful enough feature to make compose worth it.

mieubrisse 3y ago

Strongly agree. There's a big knowledge gap between the container author and the container consumer that Docker doesn't have a great toolkit for bridging. The best we get are the ENV, EXPOSE, and VOLUME directives, but authors should really have tools to say: - what filepaths are important (both for volume-mounting and for files output by the container) - what envvars (or CMD, or ENTRYPOINT) are needed - what ports will be opened, and what they mean - what protocols the ports talk ...etc. I'd really like containers to one day behave like software libraries: you pass in a set of documented parameters, and get an object that you can pass around and use in return.

krick 3y ago

> Dockerfiles on their own are usually missing a lot of critical information about how to run the container Uh, of course they do, since they say nothing about how to run a container. Dockerfiles encode an image (also not really deterministically, contrary to the common belief, but that's details), not a container. And docker-compose.yaml represents making a bunch of containers from images. These are completely separate things.