They are also Docker Compose, which is frankly one of the nicest pieces of software I’ve used in a long time.
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.
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.
- 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.
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.
>t. The guy who gets endlessly tired of having to unfsck the layers of abstraction into something mere mortal devs/testers can reason through about.
These days you can even build, and deploy a debuggable image from an IDE easily so you don't need to bridge the network.
I've taken to replacing docker compose files with bash scripts for my personal projects. So far, it's been OK.
If anyone has good ideas, please share!
Setting up an N-node Cassandra cluster: https://docs.kurtosis.com/how-to-parameterize-cassandra#inst...
Idempotent runs documentation: https://docs.kurtosis.com/concepts-reference/idempotent-runs
This site might help: https://www.composerize.com/
Also you can also run that site in docker.
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.
That's why I said "personal projects".
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?
That said, it does work great - it even works with user namespaces, which makes it very powerful!