Replace composition with Compose app.

Signed-off-by: Daniel Nephin <dnephin@docker.com>
This commit is contained in:
Daniel Nephin 2015-11-02 15:14:42 -05:00
parent eab265befa
commit 8bdde9a731

View File

@ -15,8 +15,8 @@ weight=2
Compose supports two methods of sharing common configuration: Compose supports two methods of sharing common configuration:
1. Extending individual services with [the `extends` field](#extending-services) 1. Extending individual services with [the `extends` field](#extending-services)
2. Extending entire compositions by 2. Extending entire Compose file by
[using multiple compose files](#multiple-compose-files) [using multiple Compose files](#multiple-compose-files)
## Extending services ## Extending services
@ -88,7 +88,7 @@ You can also write other services and link your `web` service to them:
### Example use case ### Example use case
Extending an individual service is useful when you have multiple services that Extending an individual service is useful when you have multiple services that
have a common configuration. The example below is a composition with have a common configuration. The example below is a Compose app with
two services: a web application and a queue worker. Both services use the same two services: a web application and a queue worker. Both services use the same
codebase and share many configuration options. codebase and share many configuration options.
@ -213,8 +213,8 @@ In the case of `environment`, `labels`, `volumes` and `devices`, Compose
## Multiple Compose files ## Multiple Compose files
Using multiple Compose files enables you to customize a composition for Using multiple Compose files enables you to customize a Compose application
different environments or different workflows. for different environments or different workflows.
### Understanding multiple Compose files ### Understanding multiple Compose files
@ -248,12 +248,12 @@ relative to the base file.
### Example use case ### Example use case
In this section are two common use cases for multiple compose files: changing a In this section are two common use cases for multiple compose files: changing a
composition for different environments, and running administrative tasks Compose app for different environments, and running administrative tasks
against a composition. against a Compose app.
#### Different environments #### Different environments
A common use case for multiple files is changing a development composition A common use case for multiple files is changing a development Compose app
for a production-like environment (which may be production, staging or CI). for a production-like environment (which may be production, staging or CI).
To support these differences, you can split your Compose configuration into To support these differences, you can split your Compose configuration into
a few different files: a few different files:
@ -301,7 +301,7 @@ host, mounts our code as a volume, and builds the web image.
When you run `docker-compose up` it reads the overrides automatically. When you run `docker-compose up` it reads the overrides automatically.
Now, it would be nice to use this composition in a production environment. So, Now, it would be nice to use this Compose app in a production environment. So,
create another override file (which might be stored in a different git create another override file (which might be stored in a different git
repo or managed by a different team). repo or managed by a different team).
@ -332,7 +332,7 @@ production.
#### Administrative tasks #### Administrative tasks
Another common use case is running adhoc or administrative tasks against one Another common use case is running adhoc or administrative tasks against one
or more services in a composition. This example demonstrates running a or more services in a Compose app. This example demonstrates running a
database backup. database backup.
Start with a **docker-compose.yml**. Start with a **docker-compose.yml**.