Through the use of the bridge Driver, users can provision custom bridges to connect to containers. You can create as many as you like with the only real limitation being that you must use unique IP addressing on each bridge. That is, you can't overlap with existing subnets that are already defined on other network interfaces.
In this recipe, we'll learn how to define a user-defined bridge as well as some of the unique options available to you during its creation.
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.
In the previous recipe, we talked about the process for defining a user-defined network. While the options discussed there are relevant to all network types, we can pass other options to the Driver our network implements by passing the --opt flag. Let's quickly review the options that are available with the bridge Driver:
com.docker.network.bridge.name: This is the name you wish to give to the bridge.com.docker.network.bridge.enable_ip_masquerade: This instructs the Docker host to hide or masquerade all containers in this network behind the Docker host's interfaces if the container attempts to route off the local host .com.docker.network.bridge.enable_icc: This turns on or off Inter-Container Connectivity (ICC) mode for the bridge. This feature is covered in greater detail in Chapter 6, Securing Container Networks.com.docker.network.bridge.host_binding_ipv4: This defines the host interface that should be used for port binding.com.docker.network.driver.mtu: This sets MTU for containers attached to this bridge.
These options can be directly compared with the options we define under the Docker service to make changes to the default docker0 bridge.
The preceding table compares the service-level settings that impact the docker0 bridge to the settings available to you as part of defining a user-defined bridge network. It also lists the default setting used if the setting is not specified in either case.
Between the Driver-specific options and the generic options that are part of the network create subcommand, we have quite a bit of flexibility when defining container networks. Let's walk through a couple of quick examples of building user-defined bridges:
docker network create --driver bridge --subnet=10.15.20.0/24 --gateway=10.15.20.1 --aux-address 1=10.15.20.2 --aux-address 2=10.15.20.3 --opt com.docker.network.bridge.host_binding_ipv4=10.10.10.101 --opt com.docker.network.bridge.name=linuxbridge1 testbridge1
The preceding network create statement defines a network with the following characteristics:
- A user-defined network of type
bridge - A
subnetof10.15.20.0/24 - A
gatewayor bridge IP interface of10.15.20.1 - Two reserved addresses:
10.15.20.2and10.15.20.3 - A port binding interface of
10.10.10.101on the host - A Linux interface name of
linuxbridge1 - A Docker network name of
testbridge1
Keep in mind that some of these options are included for example purpose only. Practically, we don't need to define the Gateway for the network Driver in the preceding example since the defaults will cover us.
If we create the earlier-mentioned network upon inspection, we should see the attributes we defined:
user@docker1:~$ docker network inspect testbridge1
[
{
"Name": "testbridge1",
"Id": "97e38457e68b9311113bc327e042445d49ff26f85ac7854106172c8884d08a9f",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "10.15.20.0/24",
"Gateway": "10.15.20.1",
"AuxiliaryAddresses": {
"1": "10.15.20.2",
"2": "10.15.20.3"
}
}
]
},
"Internal": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.host_binding_ipv4": "10.10.10.101",
"com.docker.network.bridge.name": "linuxbridge1"
},
"Labels": {}
}
]
user@docker1:~$docker network create --subnet=192.168.50.0/24 --ip-range=192.168.50.128/25 --opt com.docker.network.bridge.enable_ip_masquearde=false testbridge2
The preceding network create statement defines a network with the following characteristics:
- A user-defined network of type
bridge - A
subnetof192.168.50.0/24 - A
gatewayor bridge IP interface of192.168.50.1 - A container network range of
192.168.50.128/25 - IP masquerade on the host turned off
- A Docker network named
testbridge2
As stated in Example 1, we don't need to define the driver type if we're creating a bridge network. In addition, if we're OK with the gateway being the first available IP in the container defined subnet, we can exclude that from the definition as well. Inspecting this network after creation should show us results similar to this:
user@docker1:~$ docker network inspect testbridge2
[
{
"Name": "testbridge2",
"Id": "2c8270425b14dab74300d8769f84813363a9ff15e6ed700fa55d7d2c3b3c1504",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "192.168.50.0/24",
"IPRange": "192.168.50.128/25"
}
]
},
"Internal": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.enable_ip_masquearde": "false"
},
"Labels": {}
}
]
user@docker1:~$