Yes! +1 on design 😉

SGTM 👍
What's the difference from DAB?

@AkihiroSuda a lot of people were wondering why the intermediate .dab file was required, and were requesting an option to directly deploy from a compose file. Having an option to directly create services from a compose file would answer that request.

Cool 👍

I tried this, but got something very weird. Possibly I'm reading the logs wrong, or it's because I'm running inside a container, but this is what happened;

I built this PR (make BIND_DIR=. binary shell), and started the daemon (dockerd --debug --experimental))

On an empty cache inside the container, I tried to run this docker-compose file (basically an example from the docs, but changed to format "3");

version: '3'

services:
   db:
     image: mysql:5.7
     volumes:
       - "./.data/db:/var/lib/mysql"
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     links:
       - db
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_PASSWORD: wordpress

Because it uses a bind-mount, I created the .data/db first, then deployed the stack;

docker deploy --compose-file ./docker-compose.yml mystack

However, I think docker went into an endless loop of pulling the same image(s). Maybe I'm reading the logs incorrectly, but there's multiple "download complete" messages; https://gist.github.com/thaJeztah/77f7c28100f9c5b35303554812191648#file-pull-loop-log-L235-L236

But docker images never showed any images.

Manually pulling the images, and then deploying the docker-compose file worked.

I'm not sure it's related to this PR, or an existing bug

Ok, ignore my previous comment; I'm on a very slow network, and the log-messages are just confusing (room for improvement there); these messages;

DEBU[0553] pull in progress                              image="wordpress:latest" status="Verifying Checksum"
DEBU[0553] pull in progress                              image="wordpress:latest" status="Download complete"

are shown for each layer, but I read them as "image download complete"

re-vendored to pickup the license

@dnephin build is failing;

20:56:27 ---> Making bundle: binary-client (in bundles/1.13.0-dev/binary-client)
20:56:28 Building: bundles/1.13.0-dev/binary-client/docker-1.13.0-dev
20:56:28 cli/command/stack/deploy.go:13:2: cannot find package "github.com/aanand/compose-file/loader" in any of:
20:56:28    /go/src/github.com/docker/docker/vendor/github.com/aanand/compose-file/loader (vendor tree)
20:56:28    /usr/local/go/src/github.com/aanand/compose-file/loader (from $GOROOT)
20:56:28    /go/src/github.com/aanand/compose-file/loader (from $GOPATH)
20:56:28 cli/command/stack/deploy.go:14:2: cannot find package "github.com/aanand/compose-file/types" in any of:
20:56:28    /go/src/github.com/docker/docker/vendor/github.com/aanand/compose-file/types (vendor tree)
20:56:28    /usr/local/go/src/github.com/aanand/compose-file/types (from $GOROOT)
20:56:28    /go/src/github.com/aanand/compose-file/types (from $GOPATH)
20:56:29 Build step 'Execute shell' marked build as failure

Oh right, I didn't rebase the vendor changes correctly, oops

I tested this some more, and looks to be working as expected; both creating, and updating (i.e. run docker stack deploy again with a modified docker-compose.yml)

One thing I was worried about is if services would be created with an network alias, but that works as well 👏

I'm moving this to code review

@albers hm, I suspect #28341

Yes, this does not work. Help output is same for both operating modes (local daemon, current master):

$ docker version | grep Experimental
 Experimental:        false
$ docker --help > normal.txt
# restart daemon with --experimental
$ docker version | grep Experimental
 Experimental:        true
$ docker --help > experimental.txt
$ diff normal.txt experimental.txt
$

@thaJeztah Help output is fixed again (experimental features only showing up when daemon is running in experimental mode) in current HEAD. But is was broken in RC1.

Docs is being tracked through docker/docs#685

Does this mean that reading docker-compose through docker directly, in 1.13, will support all the unsupported options that docker-compose bundle (up to 1.9.0) drops?
ie: will it be on the same level as docker-compose right now without swarm?

@RRAlex some options are not supported (e.g. container_name, because you cannot have multiple containers with the same name, which would prevent scaling the service), some other options may still be added in future. Also, because this implementation is intended for deployment, not local development, it creates services instead of individual "containers". The docker service concept does not support some features (e.g. there's no docker service exec etc).

@thaJeztah Makes sense for container_name.
But are the other options now supported? (cap_add, read_only, security_opt, mem_limit, etc.)

Related: docker/compose#3680 (comment)

@RRAlex things are going fast, so I'm not 100% sure if they are all supported, but you can download the release candidates to give it a spin 👍. Since you're interested in this feature, it would be welcome if you could test it, for your use case and see if things are missing, or where improvements can be made (feel free to break it anyway you can 😄)

Seems like those 2 aren't supported in 1.13.0-rc2 yet, at least with our docker-compose.yml (which uses almost every options). It seems better than .dab support if they really are the only two left.

> docker stack deploy --compose-file docker-compose.yml  test
Compose file contains unsupported options:

cpu_shares: Set resource limits using deploy.resources
mem_limit: Set resource limits using deploy.resources

Any plans to support those before the final release?

You can set the equivalent swarm mode option with deploy.resources.limits.cpus and deploy.resources.limits.memory.

Will compose support other options that docker service has, like --constraint?

@liyaka yes, it's in deploy.placement.constraints 👼

@vdemeester is it in the new compose version? where can I found the updated documentation?
Thanks.

Definitely not the documentation, but hope this helps: https://github.com/docker/compose/blob/master/compose/config/config_schema_v3.0.json

WIP documentation can be found here; docker/docs#716