Previously Compose did not have a specification, only the implementation, and it was tied to Docker's products. The aim here is to open it up, and let the specification evolve in new directions, such as better supporting deployment on Kubernetes, as an example. It is supported with some other implementations but we want to bring these closer together.

Compose has a lot of users, and hundreds of thousands of Compose files on GitHub, so we wanted to open up development as much as possible.

(I work at Docker)

I've been mostly avoiding Docker, Docker-compose etc. (We got stuck at the "Ansible > Digital Ocean works fine for us" stage. Docker was too new at the time and never really had a reason to re-examine things)

But just this past week after a ton of pain previously trying to get a working Geodjango stack running on my Mac locally for experimentation I discovered a docker-compose script that gave me everything I wanted in about 5 minutes. A sample app. Django, nginx, redis, PostGIS and all the complex dependencies - all working together. I literally typed "docker-compose up" and I had a working web GIS-enabled web app running on localhost. And the fact that the deployment to staging is hopefully just as simple makes me smile.

Of course - production is a different story as I then have to worry that all the magic pieces aren't full of backdoors and security holes but I guess that's a job that needs doing anyway.

Tangentially, it is a little irksome how the docker-compose tool is released completely independently from Docker itself. There are binaries published on GitHub for amd64, but if you want it on an ARM platform, you need to install with pip. But pip can't install system packages, so you also need to know the incantation to install those (python3 python3-pip libffi-dev libssl-dev).

I'm sure there's a historical reason for it not being `docker compose ...`, but it sounds like it's a good time to promote it.

Sweet, looks good. I reckon docker and docker-compose have been probably some of the greatest enablers for my development process, and how I think about desiging software systems.

Good news! Everybody wants to just write a docker compose file and use that in production. Deploy on ECS or k8s or heroku, it would be awesome. That's the simplicity most people want for small projects.

I'm not a devops person at all, but this pile of abstractions seems like it's going the wrong way. Like, this seems almost like a parody?

You have this problem where you want to set up infrastructure in an abstract way, so you come up with a way to write some infrastructure requirements and now you have a program that does all the actions necessary to take your setup from wherever it is, to what you specified.

Then you have multiple of those systems, and it gets confusing. So you come up with a generic way to specify the abstractions that can be sort of compiled into any of the flavors, so that you can set up infrastructure using any of the sub-abstractions available, instead of only a specific one.

This has the smell of a FactoryFactoryFactory sort of thing. Like, if this whole cottage industry were my architecture project I would be saying to myself "This is too much, a rickety, foot-gun-laden tower, destined to crumble. I've obviously chosen a poor abstraction, lemme back way the hell up."

Am I just totally wrong here? I feel like I'm taking crazy pills.

This is pretty exiting for 2 reasons...

1. Writing all the YAML to deploy an application into Kubernetes is a lot of work. If one does everything fully filled out it's pretty normal to have over a thousand lines of YAML... or much more. With lots of repeat yourself. Tools built from a simpler spec that can "compile" to that would be so great. Like writing in a higher level language instead of machine code or assembly.

2. There are a variety of platforms now. I first thought of Kubernetes vs Nomad. But, Kubernetes using Istio is a different platform from Kubernetes where applications use Ingress. There is more diversity showing up. Being able to define an application in one spec and "compile" for different situations would be useful.

Just my 2 cents. As a Kubernetes user I'm happy to see the higher level tool bar moving. It's desperately needed.

This is cool- hopefully this allows standardized podman-compose.

My two wishes are:

1. Bring back extends

2. Specify services that are only intended to be run

Maybe #2 is possible now and I just don't know it?

I wrote a wrapper at previous job around docker-compose that made it easy to define aliases within the compose file for complete run commands... Eg to run migrate in your rails container.

Nice! I wonder if there will be a mapping between compose and the cli maintained as part of this?

(Disclaimer, I maintain https://composerize.com/, hoping this helps us track parity)

This is great news. Docker really screwed up v2->v3 and have continually suppressed Compose’s potential because it wasn’t inline with swarm. Looking forward to Compose getting some new life put into it.

To read the spec: https://github.com/compose-spec/compose-spec/blob/master/spe...

This is good. My main annoyance with Docker in the past was that I would make a decent Compose file for local dev but then have to rewrite everything in a proprietary YAML format for use in CI and prod.

Docker Compose has always been an awesome file format, built on top of an idiosyncratic orchestration engine that doesn't interoperate well with anything else.

Writing a spec is a good first step! If work is underway to make this a shared multi-service dev environment that works across Kubernetes, ECS, etc, that would be even better.

When I read the spec, there are ominous words about partial implementations. That makes me nervous. But I'm cautiously optimistic.

Just diving into Docker, and I'm already a bit confused... There's a docker stack (or swarm) that allows me to define containers (services?) and their networking... but then there's also docker compose, which does the same thing? Even the yaml config specs are similar.

Maybe they'll address https://github.com/docker/compose/issues/745 now...

This is great. Docker sometimes feels like a tangle of hacks, for example docker-compose build and docker build diverge and don't use the same layers. More standardization is better

This is great. I might use it in my web app http://www.trackmycouriers.com

ok, so... what? The notion here is to take the compose file, which is basically saying "this is what I want the state of docker to look like", and turn it into a generic application specification that multiple orchestration engines can contribute to and use... And... How would this work? Are we gonna have this smorgasbord of definitions in compose now with a subset of each working on specific orchestration systems, or something? Because that would be completely useless.

So unless there genuinely is a commitment to being able to have each orchestration engine just unreservedly guaranteed take any definition possible in docker-compose and deploy it, then there is no value to be gained here. None. Without that guarantee, then for every system you attempt to deploy a compose file to, you must DEEP DIVE into its internals to understand its limitations and costs and tradeoffs.

This gigantic massive timesink of a process is something I have always had to do. And I always discover all kinds of things that would have absolutely blocked practical deployments. This is the real thing that's bothering me, not that k8s and azure and docker all can sorta read some subset of a configuration. I don't care at all about that. It's not useful.

> Docker is working with Amazon Web Services (AWS), Microsoft and others in the open source community

Google?