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`.
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.
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.
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`.
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
> 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.
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.
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.
Love Docker Compose. At an old job, we used it to provide every developer with a local version of the frontend, backend and database, all in separate containers that only talked to each other. All of that with one command!
I had a similar set up and it made debugging really easy. Instead of building and running every app you could just run the full environment with known good images and replace the app you're working on with the debuggable instance running in the IDE.
These days you can even build, and deploy a debuggable image from an IDE easily so you don't need to bridge the network.
Practically speaking how was that implemented? I would guess maybe an environment variable per app? I'm just starting out with this kind of setup on a personal project
People have been making this facetious argument since Docker launched a decade ago, it's even more ridiculous to make it now. My job would very literally be harder and take much longer to accomplish things without the benefits of containers. Anyone who still feels this way about containers for software dev today needs to get off their grumpy stool and embrace the benefits.
Funnily enough I chose docker compose because it was such an easy abstraction. I tell it i want a bunch of containers and specify their network relationship in a simple flat file. I tell it that I want each of them to expose their debugger port on a different local port, then I can just hook up a normal debugger and go. Couldn't be easier!
I'm an odd one out -- I actually don't like Compose and it may partly have to do with my dislike for YAML. I often have a hard time finding or understanding the docker-compose equivalent of a docker CLI command or flag.
I've taken to replacing docker compose files with bash scripts for my personal projects. So far, it's been OK.
> I've taken to replacing docker compose files with bash scripts for my personal projects. So far, it's been OK.
I'm sorry but this is just incredibly messy for anything that's not trivial. We have tons of docker-compose services, all instantiated N times and each having their own network, secret, volume, env var, target etc configuration. In my mind it doesn't make sense to replace a 100 line YAML with a gargantuan messy shell script only old graybeards understand.
I share the same feeling about compose. I used to put things in Makefiles, to also have the dependencies of containers of other containers. But I have not yet found a good way to replace `docker compose up' functionality, in case the containers are already running. It does some magic to only replace the containers that need replacing and keeps things running.
You might be interested in what we're building at Kurtosis: you define your app in a deterministic subset of Python, and then we do the magic to change only what's necessary on subsequent runs (what we call "idempotent runs"). It also supports parameterization.
Where do all these people who keep complaining about YAML come from? Sure it's not perfect but don't you have other things to do in your dev job?
If your job is to write config all day, and nothing else (which is the only reason I think you'd care that much to dislike docker compose JUST because of yml), maybe the thing you actually dislike is the nature of the job?
