docker network create -d transparent TransparentNetwork1
It’s also required to add a gateway if you plan to use statically assigned IP addresses
for containers (for dynamic IP addresses with DHCP, the gateway will be sent as part
of the DHCP offer and therefore does not need to be configured on the network). The
gateway should be the gateway IP for the network to which the physical NIC is
connected and the one that containers need to use based on the statically assigned IPs.
docker network create -d transparent --gateway=10.7.173.1
"TransparentNetwork1"
If the container host has only a single NIC, it will be used for the newly created
external vSwitch. If the container host has multiple NICs, one will be randomly
chosen. Alternatively, you can set a specific NIC to be used by adding -o
com.docker.network.windowsshim .interface="
command.
If the container host is a VM and you are using DHCP for IP assignment to the
containers on a transparent network, you will need to enable MAC spoofing for the
container host VM.
Get-VMNetworkAdapter -VMName savdalcontainer | Set-VMNetworkAdapter `
-MacAddressSpoofing On
DEPLOYING A LAYER 2 BRIDGE
Much like a transparent network, a Layer 2 Bridge network creates an external
vSwitch and uses similar options. You must also specify the subnet for an L2 Bridge
network.
docker network create -d l2bridge --subnet=192.168.1.0/24
--gateway=192.168.1.1 BridgeNetwork1
Creating and Interacting with Containers
A deep dive into the intricacies of using containers and Docker is beyond the scope of
this chapter. However, I want to walk you through a few examples to help reinforce
how containers work and the basics of using them.
As a quick refresher, remember that containers are all about layers. The actual
container host OS kernel that is shared between the containers appears at the bottom
of Figure 10.6. (If using Hyper-V containers, it just so happens that only one container
exists on that kernel.) On the kernel is the base OS image that marks the start of the
container environment which has no parent image. On top of the base image are
various images that include middleware, runtimes, and other content upon which the
final application depends. At the top is the container instance that is writeable: the
sandbox. The processes running in the sandbox see the unioned filesystem and
registries down through the layers.