tyler.durden
/
compose
mirror of https://github.com/docker/compose.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update docs for version being a string. 

Signed-off-by: Daniel Nephin <dnephin@docker.com>
This commit is contained in:
Daniel Nephin 2016-02-04 12:17:20 -05:00
parent 386974f831
commit a7c2987991
3 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/compose-file.md
View File

@ -183,7 +183,7 @@ Express dependency between services, which has two effects:
Simple example: Simple example:
version: 2 version: '2'
services: services:
web: web:
build: . build: .
@ -658,7 +658,7 @@ In the example below, instead of attemping to create a volume called
`[projectname]_data`, Compose will look for an existing volume simply `[projectname]_data`, Compose will look for an existing volume simply
called `data` and mount it into the `db` service's containers. called `data` and mount it into the `db` service's containers.
version: 2 version: '2'
services: services:
db: db:
@ -748,7 +748,7 @@ attemping to create a network called `[projectname]_outside`, Compose will
look for an existing network simply called `outside` and connect the `proxy` look for an existing network simply called `outside` and connect the `proxy`
service's containers to it. service's containers to it.
version: 2 version: '2'
services: services:
proxy: proxy:
@ -780,7 +780,7 @@ There are two versions of the Compose file format:
- Version 1, the legacy format. This is specified by omitting a `version` key at - Version 1, the legacy format. This is specified by omitting a `version` key at
the root of the YAML. the root of the YAML.
- Version 2, the recommended format. This is specified with a `version: 2` entry - Version 2, the recommended format. This is specified with a `version: '2'` entry
at the root of the YAML. at the root of the YAML.
To move your project from version 1 to 2, see the [Upgrading](#upgrading) To move your project from version 1 to 2, see the [Upgrading](#upgrading)
@ -842,7 +842,7 @@ under the `networks` key.
Simple example: Simple example:
version: 2 version: '2'
services: services:
web: web:
build: . build: .
@ -855,7 +855,7 @@ Simple example:
A more extended example, defining volumes and networks: A more extended example, defining volumes and networks:
version: 2 version: '2'
services: services:
web: web:
build: . build: .
@ -887,7 +887,7 @@ A more extended example, defining volumes and networks:
In the majority of cases, moving from version 1 to 2 is a very simple process: In the majority of cases, moving from version 1 to 2 is a very simple process:
1. Indent the whole file by one level and put a `services:` key at the top. 1. Indent the whole file by one level and put a `services:` key at the top.
2. Add a `version: 2` line at the top of the file. 2. Add a `version: '2'` line at the top of the file.
It's more complicated if you're using particular configuration features: It's more complicated if you're using particular configuration features:
@ -950,7 +950,7 @@ It's more complicated if you're using particular configuration features:
named volume called `data`, you must declare a `data` volume in your named volume called `data`, you must declare a `data` volume in your
top-level `volumes` section. The whole file might look like this: top-level `volumes` section. The whole file might look like this:
version: 2 version: '2'
services: services:
db: db:
image: postgres image: postgres

8
docs/networking.md
View File

@ -28,7 +28,7 @@ identical to the container name.
For example, suppose your app is in a directory called `myapp`, and your `docker-compose.yml` looks like this: For example, suppose your app is in a directory called `myapp`, and your `docker-compose.yml` looks like this:
version: 2 version: '2'
services: services:
web: web:
@ -63,7 +63,7 @@ If any containers have connections open to the old container, they will be close
Links allow you to define extra aliases by which a service is reachable from another service. They are not required to enable services to communicate - by default, any service can reach any other service at that service's name. In the following example, `db` is reachable from `web` at the hostnames `db` and `database`: Links allow you to define extra aliases by which a service is reachable from another service. They are not required to enable services to communicate - by default, any service can reach any other service at that service's name. In the following example, `db` is reachable from `web` at the hostnames `db` and `database`:
version: 2 version: '2'
services: services:
web: web:
build: . build: .
@ -86,7 +86,7 @@ Each service can specify what networks to connect to with the *service-level* `n
Here's an example Compose file defining two custom networks. The `proxy` service is isolated from the `db` service, because they do not share a network in common - only `app` can talk to both. Here's an example Compose file defining two custom networks. The `proxy` service is isolated from the `db` service, because they do not share a network in common - only `app` can talk to both.
version: 2 version: '2'
services: services:
proxy: proxy:
@ -123,7 +123,7 @@ For full details of the network configuration options available, see the followi
Instead of (or as well as) specifying your own networks, you can also change the settings of the app-wide default network by defining an entry under `networks` named `default`: Instead of (or as well as) specifying your own networks, you can also change the settings of the app-wide default network by defining an entry under `networks` named `default`:
version: 2 version: '2'
services: services:
web: web:

2
docs/overview.md
View File

@ -32,7 +32,7 @@ they can be run together in an isolated environment.
A `docker-compose.yml` looks like this: A `docker-compose.yml` looks like this:
version: 2 version: '2'
services: services:
web: web:
build: . build: .