‫For this lecture, you need to understand some of the previous concepts around networking and also
‫around creating containers.
‫Now that we understand the concepts of Docker networking and how all the virtual networking and IP stuff
‫works, let's look at some of the command line options for managing it.
‫First, there's the obvious network ls. Since we can create multiple networks, we surely have an ls command
‫to list them.
‫We have the usual inspect command which you're probably used to by now from all the other inspecting
‫we're doing.
‫That'll show us the details about a specific network.
‫Then we have a create command that has an optional driver that we can specify for using built-in
‫and third-party drivers to create a new virtual network.
‫Then we have the connect and disconnect commands for changing a live running container so that a
‫new NIC is created on a virtual network for that container.
‫It's kind of like sticking a network card in a computer while it's running.
‫So here we go.
‫So back to my command line. Taking the concepts that we just learned, I can actually do a docker
‫network ls. This shows me all of the networks that have been created. In this case,
‫when you run the same command, you're probably going to see the same three. Depending on your operating
‫system and version of Docker, you might see the bridge network called docker0 or bridge, but they both
‫mean the same thing. Which is it's the default network that bridges through the NAT firewall to the physical
‫network that your host is connected to. Up until now, we haven't had to worry about it because all
‫of our containers have just attached to that network and worked.
‫Now that we have this Nginx container running, if I do a docker network inspect, the bridge network,
‫you'll actually see that it lists the containers attached to that network. You'll see that our Nginx
‫one, that we called webhost, is attached there.
‫You can actually see its IP address. And you'll see up here that these networks automatically assign
‫IP addresses, and it's showing you here with the IPAM config that the subnet defaults to 172.17,
‫which is typically the default network for any Docker host.
‫But it can be changed, and then the gateway for this network that will eventually route out to the physical
‫network.
‫If we went back to the docker network ls, we can see these other two networks. The host network is
‫what we talked about before that is a special network that skips the virtual networking of Docker and
‫attaches the container directly to the host interface.
‫As you can imagine, there's pros and cons to that because it prevents the security boundaries of
‫the containerization from protecting the interface of that container.
‫But it also, in certain situations, can improve the performance of high throughput networking and get
‫around a few other issues with specific special software out there.
‫Then we have the last one of none, which is kind of the equivalent of having an interface on your
‫computer that's not attached to anything, but we can create our own.
‫Let's create a Docker network...create my_app_net.
‫Now we're going to do a docker network
‫ls again. You'll notice that it created my new virtual network with a driver of bridge.
‫And that's because that's the default driver.
‫It's a simple driver that simply creates a virtual network locally with its own subnet somewhere around
‫the 172.17 and above, because it will increment as it goes. So, 17, then 18, 19, 20 and so on.
‫It doesn't have any of the advanced features that we might see later in this course, like overlaid
‫networks that allow private networking between hosts, and other third party drivers like Weave.
‫If you look at the docker network create command with help, you'll see that I can specify not just
‫the driver that I want to use, but a lot of the IP and network options that you might need in an advanced
‫scenario.
‫We can do several things with these networks and how we connect them to our containers.
‫We can use the --network option when we create a container.
‫So, docker container run name
‫new nginx, and then network, and then my app
‫net, and then the nginx image.
‫If we did a docker network inspect on the my app network, you would see that the new Nginx
‫I just created is now on that network. It has a new IP address of 172.18.
‫So it's the next subnet in the list.
‫But we don't actually have to start new containers, because just like in the real world where you can
‫unplug and replug in Ethernet devices and reconnect to wireless networks, you can also do the same with
‫existing networks and existing containers.
‫For this, we use the docker network connect and disconnect options and you can use --help
‫to see all the options there for Docker network.
‫In this case, what we want to do is docker network, and we want to take the existing container that
‫we created first and connect it to our new network.
‫I'm going to pick the new my app network, and then I'm going to pick the original webhost we created.
‫Now if I do a docker container inspect of my original webhost, you'll see that it's actually now on
‫two networks. The original bridge network,
‫and I basically did the equivalent of giving it a new Ethernet interface on a different network, with a different
‫IP that was received from the DHCP.
‫So we're now on the 17 network in the 18 network.
‫If I wanted to disconnect that, I could do the same with just disconnect. Then if I went back
‫and did an inspection again, you'll see that it's now back with only the one network.
‫As you can see, there's lots of interesting options for Docker networking and really the end goal here,
‫and one thing I love to brag about with containers, is that if you're running all of the applications
‫on a single server, in this case, you're able to really protect them. Because in the physical world where
‫we were creating virtual machines and hosts in a network, we would often overexpose the ports and networking
‫on our application servers.
‫In these cases, if you were to take your app containers and have them all in one network together
‫in a virtual network, you're only going to be exposing the ports on your host that you specifically use
‫the -p with. And everything else is a little bit safer with that protected firewall inside their
‫virtual network.
‫Later on, when we get into Docker Swarm, we're actually going to learn about multi-host networking
‫and how this gets even better when we start to scale up and scale out.
‫To recap, we just covered a bunch of commands for managing Docker networks.
‫We played around with the ls and the inspect commands, created a Docker network, and used the default driver
‫of bridge.
‫We didn't actually need to use a --driver.
‫And last, we tried out the network connect and the network disconnect commands for adding and then removing
‫a NIC from a running container.