Docker-Compose, an orchestration tool for defining and running multi-container applications within Docker, has released its newest version 1.3 with improvements to make it work more effectively further down the app life cycle to testing and production.
Compose 1.3 is faster and more stable, and comes with some cool new features.
Because Compose now uses container labels, rather than names, to keep track of containers, it is both faster and easier to integrate with individual tools.
Compose also no longer uses “intermediate containers” when recreating containers for a service, making docker-compose up less complex and more resilient to failure.
One exciting feature with the new release is that `docker-compose up` now has an experimental behaviour that allows users to recreate containers that have changed without having to tear down and reconstruct the containers. Users can try out the feature by passing the–x-smart-recreate option to `up`.
Another new feature is that when docker-compose is invoked in a subdirectory of a project, it will climb through parent directories until it finds a `docker-compose.yml`.
Docker-Compose 1.3 has added several new configuration codes to `docker-compose.yml`, including:
* Dockerfile, such as `docker build –file`, allows users to specify an alternate Dockerfile to use with build
* labels, such as `docker run –labels`, allows users to add custom metadata to containers
* `extra_hosts`, such as `docker run –add-host`, allows users to add entries to a container’s `/etc/hosts` file
* pid: host, such as `docker run –pid=host`, allows users to reuse the same PID namespace as the host machine
* cpuset, such as `docker run –cpuset-cpus`, allows users to specify which CPUs to allow execution in
* read_only, such as `docker run –read-only`, allows users to mount a container’s filesystem as read-only
* security_opt, such as `docker run –security-opt`, allows users to specify security options and
* log_driver, such as `docker run –log-driver`, allows users to specify a log driver.
Finally, many of the bugs have been fixed for Compose 1.3, including the truncated running of `docker-compose run`, service’s volumes not updating after volume configuration was changed in `docker-compose.yml`, the failure to authenticate against third-party registries, the failure to remove a container with `docker-compose run –rm` if a service had a restart policy in place, the refusal of `docker-compose scale` to scale a service beyond one container if it exposed a specific port number on the host and the refusal of Compose to create multiple volume entries with the same host path.
The upgrade to Compose 1.3 does contain breaking changes, so users will need to remove or migrate existing containers before running apps. Compose now requires Docker 1.6.0 or later.
