Docker Creating User Defined Network

Docker - Creating user-defined networks

By Default, there are at least two different network drivers that are the part of every Docker installation, bridge, and host.
But there is another Network Driver is available out-of-the-box as well and that is Overlay.
Now I will show you the basics of creating a user-defined network

Networks are defined by using the network create subcommand

tarun@stellar-things:~$ docker network create --help

Usage:  docker network create [OPTIONS] NETWORK

Create a network

Options:
      --attachable           Enable manual container attachment
      --aux-address map      Auxiliary IPv4 or IPv6 addresses used by Network driver (default map[])
      --config-from string   The network from which copying the configuration
      --config-only          Create a configuration only network
  -d, --driver string        Driver to manage the Network (default "bridge")
      --gateway      IPv4 or IPv6 Gateway
      --ingress              Create swarm routing-mesh network
      --internal             Restrict access to the network
      --ip-range strings     Allocate container ip from a sub-range
      --ipam-driver string   IP Address Management Driver
      --ipam-opt map         Set IPAM driver
      --ipv6                 Enable IPv6 networking
      --label list           Set metadata on a network
  -o, --opt map              Set driver specific
      --scope string         Control the network's scope
      --subnet strings       Subnet in CIDR format that represents a network segment

• aux-address - This is the Ip reservations method in DHCP scope. This allow us to define ip address which should not be used by docker to assign it to spwaned container.

• Driver: This allow to choose the network type.

• gateway: Defines Gateway for the network. If it is not specified, Docker will assume that it is the first available IP address in the subnet.

• internal: This allows you to isolate networks.

• ip-range: This allows you to specify a smaller subnet of the defined network  to use for containers add. .

• ipam-driver: In addition to consuming third-party network drivers, you can also leverage third-party IPAM drivers.

• ipv6: This enables IPv6 networking on the network.

• label: This allows you to specify additional information about the network that will be stored as metadata.

• ipam-opt: This allows you to specify options to pass to the IPAM Driver.

• opt: This allows you to specify options that can be passed to the network Driver.

• subnet: This defines the subnet associated with the network type you are creating.

Some of the setting may overlaps here, we can define at a service level for Docker networking and the user-defined options listed in the preceding term list. Examining the options, you may be tempted to compare the following configuration flags:

These settings seems largely equivalent, they are not at all identical. The only two that act in the exact same fashion are --fixed-cidr and ip-range. Both of those options, define a smaller subnetwork of the larger master network to be used for container IP addressing. The other two options are similar, but not identical.

In the case of the service options, --bip applies to the docker0 bridge and --default-gateway applies to the containers themselves. On the user-defined side, the --subnet and the --gateway option, apply directly to the network construct being defined (in this comparison, a bridge). Recall that the --bip option expects to receive an IP address in a network, not the network itself. The B-IP defines in the manner covers both the subnet aswellas the gateway, which are defined separately when defining a user-defined network. That being said, the service definition is a little more flexible in that it allows you to define both the interface of the bridge as well as the gateway assigned to containers.

Keeping with the theme of having sane defaults, none of these options are actually required to create a user-defined network. You can create your first user-defined network by just giving it a name:

tarun@stellar-things:~$ docker network create mynetwork
a1ce138e10173d0be640059db17fa4734c66841753f520814b9a6c0f6b65e0c7
tarun@stellar-things:~$

Now see what docker uses for defaults.

tarun@stellar-things:~$ docker network inspect mynetwork
[
    {
        "Name": "mynetwork",
        "Id": "a1ce138e10173d0be640059db17fa4734c66841753f520814b9a6c0f6b65e0c7",
        "Created": "2018-02-25T13:27:15.824350853+05:30",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Docker assumes that if you don’t specify a Driver that you’d like to create a network using the bridge Driver. It also automatically chooses and assigns a subnet for this bridge if you don’t define one when you create the network.

It also automatically selects the first useable IP address for the Subnet as the gateway. Because we didn’t define any options specific to the Driver, the network has none but again, there are defaults that are used in this case. Those will be discussed in the recipes related to each specific Driver.

Networks that are empty, that is, they have no active endpoints, may be deleted using the network rm command:

tarun@stellar-things:~$ docker network rm  mynetwork
mynetwork
tarun@stellar-things:~$

One other item that’s worth noting here is that Docker makes user-defined networks persistent. In most cases, any Linux network constructs that are manually defined are lost when the system reboots. Docker records the network configuration and takes care of replaying it back when the Docker service restarts. This is a huge advantage to building the networks through Docker rather than on your own.

Thank you