That Randy Brown

Docker Compose is a Container Configuration Language

I realized recently that I've been thinking about docker compose a bit too narrowly, primarily driven by my experience. I use docker compose to define a set of containers with some dependency that represent a constellation of containers that run together, usually to represent a full application surface.

Because of this, back when I was working on anvil, I build a secondary json object that injected all the necessary meta to a docker run command. Part of the reason for this overhead was that it facilitated me deploying individual containers into the ecosystem independently, which was I thought a weakness of docker compose.

It turns out, this is not a weakness of docker compose in reality--only in utilization. Compose isn't necessarily best thought of as a description of a collection of containers, but as a descriptive file for container configuration and instantiation. Just like my bespoke json, except in yml. I realized essentially that I had rebuilt docker compose, but worse.

Docker Compose is, I think, better conceptualized as a language for describing container configuration and metadata for a given ecosystem than as a relationship definition between different containers. This enables thinking of use cases for docker compose outside the relationship between one or more containers (and I use compose a lot this way these days--replacing bloated docker run commands with a docker compose file).