As mentioned, defining and managing networks can now be done directly through Docker with the addition of the network subcommand. The network command provides you with all the options you need to build networks and connect containers to them:
user@docker1:~$ docker network --help
docker network --help
Usage: docker network COMMAND
Manage Docker networks
Options:
--help Print usage
Commands:
connect Connect a container to a network
create Create a network
disconnect Disconnect a container from a network
inspect Display detailed information on one or more networks
ls List networks
rm Remove one or more networks
Run 'docker network COMMAND --help' for more information on a command.
user@docker1:~$In this recipe, we'll learn how to view defined Docker networks as well as inspect them for specific details.
The docker network subcommand was introduced in Docker 1.9, so you'll need a Docker host running at least that version. In our examples, we'll be using Docker version 1.12. You'll also want to have a good understanding of your current network layout, so you can follow along as we inspect the current configuration. It is assumed that each Docker host is in its native configuration.
The first thing we want to do is figure out what networks Docker thinks are already defined. This can be done using the network ls subcommand:
user@docker1:~$ docker network ls NETWORK ID NAME DRIVER SCOPE 200d5292d5db bridge bridge local 12e399864b79 host host local cb6922b8b84f none null local user@docker1:~$
As we can see, Docker shows that we have three different networks already defined. To view more information about a network, we can use the network inspect subcommand to retrieve specifics about the network definition as well as its current state. Let's take a close look at each defined network.
The bridge network represents the docker0 bridge that the Docker engine creates by default:
user@docker1:~$ docker network inspect bridge
[
{
"Name": "bridge",
"Id": "62fcda0787f2be01e65992e2a5a636f095970ea83c59fdf0980da3f3f555c24e",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16"
}
]
},
"Internal": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
user@docker1:~$ The output from the inspect command shows us a wealth of information about the defined network:
Driver: In this case, we can see that the network bridge implements theDriverbridge. Although this may seem obvious, it's important to call out that all network functionality, including native functionality, is implemented through drivers.Subnet: In this case, thesubnetis the default we expect from thedocker0bridge,172.17.0.1/16.bridge.default_bridge: A value oftrueimplies that Docker will provision all containers to this bridge unless told otherwise. That is, if you start a container without specifying a network (--net), the container will end up on this bridge.bridge.host_binding_ipv4: By default, this will be set to0.0.0.0or all interfaces. As we saw in Chapter 2, Configuring and Monitoring Docker Networks, we can tell Docker at a service level to limit this by passing the--ipflag as a Docker option to the service.bridge.name: As we suspected, this network represents thedocker0bridge.driver.mtu: By default, this will be set to1500. As we saw in Chapter 2, Configuring and Monitoring Docker Networks, we can tell Docker at a service level to change MTU (Maximum Transmission Unit) by passing the--mtuflag as a Docker option to the service.
The none network represents just what it says, nothing. The none mode is used when you wish to define a container with absolutely no network definition. After inspecting the network, we can see that there isn't much there as far as a network definition is concerned:
user@docker1:~$ docker network inspect none
[
{
"Name": "none",
"Id": "a191c26b7dad643ca77fe6548c2480b1644a86dcc95cde0c09c6033d4eaff7f2",
"Scope": "local",
"Driver": "null",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": []
},
"Internal": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]
user@docker1:~$As you can see, Driver is represented by null, implying that this isn't a Driver for this network at all. There are a few use cases for the none network mode and we'll cover those later on when we talk about connecting and disconnecting containers to defined networks.
The host network represents the host mode we saw in Chapter 2, Configuring and Monitoring Docker Networks, where a container was bound directly to the Docker host's own network interfaces. By taking a closer look, we can see that much like the none network, there isn't much defined for this network:
user@docker1:~$ docker network inspect host
[
{
"Name": "host",
"Id": "4b94353d158cef25b9c9244ca9b03b148406a608b4fd85f3421c93af3be6fe4b",
"Scope": "local",
"Driver": "host",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": []
},
"Internal": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]
user@docker1:~$Although the host network certainly does more than the none mode, it wouldn't appear so from inspecting its definition. The key difference here is that this network uses the host Driver. As this network type uses the existing host's network interfaces, we don't need to define any of that as part of the network.
When using the network ls command, you can pass additional parameters to further filter or alter the output:
--quiet(-q): This only shows the numeric network IDs--no-trunc: This prevents the command from automatically truncating the network ID in the output that allows you to see the full network ID--filter(-f): This filters the output based on either network ID, network name, or by network definition (built-in or user-defined)
For example, we can show all user-defined networks with this filter:
user@docker1:~$ docker network ls -f type=custom NETWORK ID NAME DRIVER SCOPE a09b7617c550 mynetwork bridge local user@docker1:~$
Or we can show all networks with a network ID that contains 158:
user@docker1:~$ docker network ls -f id=158 NETWORK ID NAME DRIVER SCOPE 4b94353d158c host host local user@docker1:~$