mirror of https://github.com/docker/compose.git
Merge pull request #2276 from dnephin/update_networking_docs
Update docs about networking for current release
This commit is contained in:
commit
6cd9bab35b
|
@ -14,7 +14,11 @@ weight=6
|
||||||
|
|
||||||
> **Note:** Compose's networking support is experimental, and must be explicitly enabled with the `docker-compose --x-networking` flag.
|
> **Note:** Compose's networking support is experimental, and must be explicitly enabled with the `docker-compose --x-networking` flag.
|
||||||
|
|
||||||
Compose sets up a single default [network](/engine/reference/commandline/network_create.md) for your app. Each container for a service joins the default network and is both *reachable* by other containers on that network, and *discoverable* by them at a hostname identical to the service's name.
|
Compose sets up a single default
|
||||||
|
[network](/engine/reference/commandline/network_create.md) for your app. Each
|
||||||
|
container for a service joins the default network and is both *reachable* by
|
||||||
|
other containers on that network, and *discoverable* by them at a hostname
|
||||||
|
identical to the container name.
|
||||||
|
|
||||||
> **Note:** Your app's network is given the same name as the "project name", which is based on the name of the directory it lives in. See the [Command line overview](reference/docker-compose.md) for how to override it.
|
> **Note:** Your app's network is given the same name as the "project name", which is based on the name of the directory it lives in. See the [Command line overview](reference/docker-compose.md) for how to override it.
|
||||||
|
|
||||||
|
@ -30,13 +34,23 @@ For example, suppose your app is in a directory called `myapp`, and your `docker
|
||||||
When you run `docker-compose --x-networking up`, the following happens:
|
When you run `docker-compose --x-networking up`, the following happens:
|
||||||
|
|
||||||
1. A network called `myapp` is created.
|
1. A network called `myapp` is created.
|
||||||
2. A container is created using `web`'s configuration. It joins the network `myapp` under the name `web`.
|
2. A container is created using `web`'s configuration. It joins the network
|
||||||
3. A container is created using `db`'s configuration. It joins the network `myapp` under the name `db`.
|
`myapp` under the name `myapp_web_1`.
|
||||||
|
3. A container is created using `db`'s configuration. It joins the network
|
||||||
|
`myapp` under the name `myapp_db_1`.
|
||||||
|
|
||||||
Each container can now look up the hostname `web` or `db` and get back the appropriate container's IP address. For example, `web`'s application code could connect to the URL `postgres://db:5432` and start using the Postgres database.
|
Each container can now look up the hostname `myapp_web_1` or `myapp_db_1` and
|
||||||
|
get back the appropriate container's IP address. For example, `web`'s
|
||||||
|
application code could connect to the URL `postgres://myapp_db_1:5432` and start
|
||||||
|
using the Postgres database.
|
||||||
|
|
||||||
Because `web` explicitly maps a port, it's also accessible from the outside world via port 8000 on your Docker host's network interface.
|
Because `web` explicitly maps a port, it's also accessible from the outside world via port 8000 on your Docker host's network interface.
|
||||||
|
|
||||||
|
> **Note:** in the next release there will be additional aliases for the
|
||||||
|
> container, including a short name without the project name and container
|
||||||
|
> index. The full container name will remain as one of the alias for backwards
|
||||||
|
> compatibility.
|
||||||
|
|
||||||
## Updating containers
|
## Updating containers
|
||||||
|
|
||||||
If you make a configuration change to a service and run `docker-compose up` to update it, the old container will be removed and the new one will join the network under a different IP address but the same name. Running containers will be able to look up that name and connect to the new address, but the old address will stop working.
|
If you make a configuration change to a service and run `docker-compose up` to update it, the old container will be removed and the new one will join the network under a different IP address but the same name. Running containers will be able to look up that name and connect to the new address, but the old address will stop working.
|
||||||
|
@ -45,19 +59,13 @@ If any containers have connections open to the old container, they will be close
|
||||||
|
|
||||||
## Configure how services are published
|
## Configure how services are published
|
||||||
|
|
||||||
By default, containers for each service are published on the network with the same name as the service. If you want to change the name, or stop containers from being discoverable at all, you can use the `hostname` option:
|
By default, containers for each service are published on the network with the
|
||||||
|
container name. If you want to change the name, or stop containers from being
|
||||||
|
discoverable at all, you can use the `container_name` option:
|
||||||
|
|
||||||
web:
|
web:
|
||||||
build: .
|
build: .
|
||||||
hostname: "my-web-application"
|
container_name: "my-web-application"
|
||||||
|
|
||||||
This will also change the hostname inside the container, so that the `hostname` command will return `my-web-application`.
|
|
||||||
|
|
||||||
## Scaling services
|
|
||||||
|
|
||||||
If you create multiple containers for a service with `docker-compose scale`, each container will join the network with the same name. For example, if you run `docker-compose scale web=3`, then 3 containers will join the network under the name `web`. Inside any container on the network, looking up the name `web` will return the IP address of one of them, but Docker and Compose do not provide any guarantees about which one.
|
|
||||||
|
|
||||||
This limitation will be addressed in a future version of Compose, where a load balancer will join under the service name and balance traffic between the service's containers in a configurable manner.
|
|
||||||
|
|
||||||
## Links
|
## Links
|
||||||
|
|
||||||
|
|
|
@ -21,11 +21,12 @@ The following labels are provided in additional to the standard labels:
|
||||||
Most issues should fit into one of the following functional areas:
|
Most issues should fit into one of the following functional areas:
|
||||||
|
|
||||||
| Area |
|
| Area |
|
||||||
|----------------|
|
|-----------------|
|
||||||
| area/build |
|
| area/build |
|
||||||
| area/cli |
|
| area/cli |
|
||||||
| area/config |
|
| area/config |
|
||||||
| area/logs |
|
| area/logs |
|
||||||
|
| area/networking |
|
||||||
| area/packaging |
|
| area/packaging |
|
||||||
| area/run |
|
| area/run |
|
||||||
| area/scale |
|
| area/scale |
|
||||||
|
|
Loading…
Reference in New Issue