-
Notifications
You must be signed in to change notification settings - Fork 5.7k
WIP: Docker networking support #1676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,84 @@ | ||
| <!--[metadata]> | ||
| +++ | ||
| title = "Networking in Compose" | ||
| description = "How Compose sets up networking between containers" | ||
| keywords = ["documentation, docs, docker, compose, orchestration, containers, networking"] | ||
| [menu.main] | ||
| parent="smn_workw_compose" | ||
| weight=6 | ||
| +++ | ||
| <![end-metadata]--> | ||
|
|
||
|
|
||
| # Networking in Compose | ||
|
|
||
| > **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](http://TODO/docker-networking-docs) 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. | ||
|
|
||
| > **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 [CLI docs](cli.md#p-project-name-name) for how to override it. | ||
|
|
||
| For example, suppose your app is in a directory called `myapp`, and your `docker-compose.yml` looks like this: | ||
|
|
||
| web: | ||
| build: . | ||
| ports: | ||
| - "8000:8000" | ||
| db: | ||
| image: postgres | ||
|
|
||
| When you run `docker-compose --x-networking up`, the following happens: | ||
|
|
||
| 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`. | ||
| 3. A container is created using `db`'s configuration. It joins the network `myapp` under the name `db`. | ||
|
|
||
| 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. | ||
|
|
||
| Because `web` explicitly maps a port, it's also accessible from the outside world via port 8000 on your Docker host's network interface. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In 1.8 timeframe is it likely that Longer term I think
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (cc @dave-tucker) Does this mean that the web container needs to be both on the Also, given the "container in multiple networks" problem won't be solved generically for the first release, would this need to be a specially-handled case on the Engine side? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dave-tucker might be best placed to comment on what will be implemented in 1.8 timeframe. My best guess is:
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That all makes sense. I just want to ensure the dev use case still works: web needs to be able to talk to db (so it needs to be on the app's network), but it also needs to talk to the outside world (so it needs to be on the My understanding is that those are two separate networks, and so it needs to be able to join both. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll let @dave-tucker comment, but having a container join two networks was one of the scenarios we were trying to avoid to 1.8 (because it needs a decent amount of thought to get right across the broad range of plugin network drivers). So I was expecting the
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the clarification. Since this document doesn't go as far as to mention network drivers (or multi-host) at all, I think it's fair to leave this sentence as is. Perhaps there should be another section about "Running an app on multiple hosts", which both explains the driver architecture and points out its limitations re: ports. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A design for handling -p has been discussed in significant detail. It does not require changing the driver API. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dave-tucker Let me double check. (I based my comments about the port option not being passed to remote drivers on what someone had told me. I didn't check the code myself.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dave-tucker It looks like it is in the API now. (It wasn't when we first started writing the Calico driver, but was added some time later, probably pre DockerCon but hard to say.) I think that means in theory remote drivers could implement the port mapping. I don't have a feel for how many have or how people may have interpreted any requirement to do so. There seems to be little documentation around what libnetwork is expecting drivers to do with the parameter (and no comments in the code either) so your guess is as good as mine. I think the fact you say it doesn't currently work in multi-host and are proposing to silently attach to the bridge also is an indication greater clarity in this area would be helpful. (I'm slightly hesitant about endorsing the silently connecting to the bridge workaround without understanding more about exactly how this is intended to work. e.g. How is the container's namespace configured to ensure traffic goes down the right interface etc.) Perhaps the discussion @shykes refers to is somewhere public and will help clarify for those of us who aren't already familiar with it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I should probably reiterate, that I do see the port mapping option as being important for a range of drivers and deployment scenarios. (For example, I quite like Kubernetes approach of allowing every host to act as a port mapping redirect. It makes a lot of sense to me in public cloud deployments given the current limitations of cloud APIs.) I'm just trying to clarify what is supported today vs what is longer term, and how the feature is intended to behave longer term. |
||
|
|
||
| ## 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 any containers have connections open to the old container, they will be closed. It is a container's responsibility to detect this condition, look up the name again and reconnect. | ||
|
|
||
| ## 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: | ||
|
|
||
| web: | ||
| build: . | ||
| hostname: "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 | ||
|
|
||
| Docker links are a one-way, single-host communication system. They should now be considered deprecated, and you should update your app to use networking instead. In the majority of cases, this will simply involve removing the `links` sections from your `docker-compose.yml`. | ||
|
|
||
| ## Specifying the network driver | ||
|
|
||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this section should focus on providing the flexibility to run multiple apps in a single network. For example, I don't think support for containers connecting to multiple networks in 1.8 timeframe is realistic. I think there are broad range of libnetwork, network driver and service discovery interaction and implementation issues that need to be resolved to make that work sensibly. I suggest restricting each container to a single network for 1.8. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep. Everything works neatly in the example given, but it's easy to construct a scenario which is not so clear; for instance if there are containers published as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, I'm just going to remove this section for now. |
||
| By default, Compose uses the `bridge` driver when creating the app’s network. The Docker Engine provides one other driver out-of-the-box: `overlay`, which implements secure communication between containers on different hosts (see the next section for how to set up and use the `overlay` driver). Docker also allows you to install [custom network drivers](http://TODO/custom-driver-docs). | ||
|
|
||
| You can specify which one to use with the `--x-network-driver` flag: | ||
|
|
||
| $ docker-compose --x-networking --x-network-driver=overlay up | ||
|
|
||
| ## Multi-host networking | ||
|
|
||
| (TODO: talk about Swarm and the overlay driver) | ||
|
|
||
| ## Custom container network modes | ||
|
|
||
| Compose allows you to specify a custom network mode for a service with the `net` option - for example, `net: "host"` specifies that its containers should use the same network namespace as the Docker host, and `net: "none"` specifies that they should have no networking capabilities. | ||
|
|
||
| If a service specifies the `net` option, its containers will *not* join the app’s network and will not be able to communicate with other services in the app. | ||
|
|
||
| If *all* services in an app specify the `net` option, a network will not be created at all. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has there been any discussion about namespacing these like
com.docker.compose.<project_name>or a little less verbosecomposition.<project_name>?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I would be in favour of namespacing - to most Compose users, the network name is an implementation detail that they won't spend any time looking at (unlike container names, which appear in
docker psand generally all over the place), so verbosity isn't much of a concern.com.docker.compose.*sounds good to me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we need to be slightly careful of how we namespace network names since there is a reasonable chance they may end up featuring in service discovery namespacing at some point in the future. e.g. myapp.mynetwork.mycompany.com as a DNS entry (with the DNS search path including .mynetwork.mycompany.com by default for myapp's containers, so a simple app doesn't need to worry about this namespacing).