Since its release, Docker-Compose has been well received, with prominent users including Yelp.
With its success, Compose has been reactive to meeting users’ demands, creating a new function that makes it easier to configure the same app for multiple environments and to share configuration between apps. Compose 1.2 accomplishes this with the introduction of the keyword `extends`.
With `extends`, users are able to share configuration between services and to refer to a service defined elsewhere to include its configuration in a locally-defined service. The configuration can be added to or overridden as needed. The `extends` function allows users to work in two files without constant copying and pasting.
Many other improvements have come with the upgrade to Compose 1.2. Most notably, Compose 1.2 comes with improved integration with Docker-Swarm. Most Compose apps now will work out of the box with Swarm, as long as the apps don’t use the build function. That’s because when using Compose with a Swarm cluster, containers that depend on one another will be co-scheduled on the same node.
Another improvement with the Docker-Swarm integration is that repeated invocations of `docker-compose up` with a Swarm cluster now will work reliably.
With the upgraded Compose, a service can now share another service’s network namespace with `net: container:
Also, `volumes_from` and `net: container:
`docker-compose run` now accepts a `–user` argument to specify a user to run the command as, just like `docker run` does.
Users can specify how long the wait should be when attempting to gracefully stop containers, as the `up`, `stop` and `restart` commands now accept a `–timeout` (or `-t`) argument. This works just like `docker stop`.
Just like `docker rm`, `docker-compose rm` now accepts `-f` as a shorthand for `–force`.
For those using the `-f | –file` argument to specify a configuration file in another directory, when directories are passed to build, filenames are passed to `env_file` and volume host paths are passed to volumes, they now are treated as relative to the directory of the configuration file, not the directory that `docker-compose` is being run in.
