This lecture will expand on the concept of bridge networks, as briefly discussed in the previous lecture. We will discuss the intricacies of networking with Docker, and cover many of the basic tools used.
We will begin using an Ubuntu-based image as the basis for this exercise.
We will review some of the instructions inside the image:
- From: specifies that the image is Ubuntu
- Run: installs some packages with the Apt package manager, which contain networking binaries
- Copy: copies the web application binaries that we used previously
- Command: set the default command to run bash
You will be introduced to the Docker network command, which shows the existing networks:
- Bridge Network: the default network; created when a network is not specified for a container
- Host Network: adds the container to the host's networking; used for binding containers ports to host ports
- Non Network: completely isolated; no networking interface
For the majority of the lecture, we will go into greater depth about each of the types of networks. For each network, we will walk through the processes each handles. You will perform hands-on practice to verify each network works as expected.
Welcome back. In the previous lesson, we touched on networking just a bit when I mentioned bridged networks. Networking with Docker can get as intricate as networking anywhere else. So we're not going to be covering everything there is to know in this lesson. However, in this lesson we will cover some of the basics that will help get you started.
For this lesson, we're going to use an image that's based on Ubuntu 16. 04 and then add some networking tools on top to help kind of show the networking concepts just a bit. Here's a look at the file. It starts with the From instruction, specifying that the base image is Ubuntu, and then it specifies the tag of 16.
04. The next instruction is the Run instruction, which is used to install some packages with the Apt package manager. These packages contain some networking binaries, things such as ping, arp-scan, IP, and others. The Copy instruction, we're using that to copy the same web application binary that we used previously.
And then finally, the Command sets the default command to run bash. So this image will have the tools needed to test out networking with Docker. Okay, so now that you've seen the image we'll be using, I want to introduce a new command. This is the docker network command, and we're going to us the ls subcommand to show the existing networks.
The three that are listed here are the three that are pre-configured by Docker. The info in this table is pretty basic. There's an ID, a name, a driver, and a scope. All of these have a local scope, which means they all exist as networks only on this local host. We're only going to cover these three local options in this course, though future courses will cover additional types.
Let's go through these three types. The bridge network is the default. Whenever you start up a new container and you don't specify a network, it's going to use the default bridge network. Okay, so I've created a new directory called networking and I'm currently in that directory. There are no containers running, and there are four images here, though none of these are the image based on that Dockerfile that I showed a minute ago.
So let's build that image. So here's a refresher of the contents of that Dockerfile. By listing off the contents here in this directory, you can see that we have the web app binary here alongside the Dockerfile. So using docker build, we can build this, and we can tag it with a repo name of ubuntu_networking.
So this will take a minute. I'm going to speed things along, and I'll see you in just a second. Okay, with this done, let's check the images. And there it is, perfect. Now we can start up a container based on this image. And so we're here at the bash prompt. Let's list off the interfaces here for this container.
And there we have the loopback interface, and we have the eth0 with an address of 172. 17. 0. 2. This container is using the bridge driver, which is connected to the interfaces on the host. So it has full connectivity. If I ping google.com, there you go. We have some results that come back. Okay, I want to detach from this container without stopping it.
That's something I haven't shown previously, but you can do that by pressing CTRL-p and then CTRL-q. And if I run docker ps, notice that the container is still running. From here on the host, you can interact with the container via its IP address. So if I ping it, there's our response. Let's start up a few additional containers so that we can see how these containers see each other on the same network.
So this one has an IP address here ending in three. So now we have two containers running inside of the network. Let's start up one more. Okay, if we try and ping the others, you can see that we get some results back. I want to show all of the containers on this network, so for that I'm going to use the arp-scan tool.
I have the command copied to my clipboard, so I'm just going to paste it in. Okay, take a look at the results. We have the default gateway at the IP address ending in one. Then the other two are the two containers that I started before this one. So all of these containers that I started up are in this bridge network.
They have access to interact with each other as well as being able to reach the outside world. Now there's not much you can do to customize the default network. However, you can create your own networks if you need some sort of customization. All right, let's check out the next network on the list, which is our host network.
The host network is an interesting one. Host networks add the container to the host's networking. This means if you have an application inside of the container running on, say, port 8080, it's going to be bound to port 8080 on the host. A host network has no isolation between the host and the containers.
Let's test this out by running the web application, which binds to port 8080. Because this isn't the default network, we need to specify the host network in the command prompt here using the network flag. So this command will run the container in the background using the host network, and it's going to run that web application.
Now listing off the containers, you can see that it's running, and if we inspect the container, you'll see that it doesn't get its own IP address. Check out here under the networks section, the IP Address property is empty, and that's because everything is exposed on this current host. So now if we curl localhost on port 8080, then we get our HTML back.
Now recall that in the Dockerfile, we didn't actually expose port 8080, and we didn't publish any of those ports manually. When using host networking, whatever ports you open up in the container are going to be bound to the host. Okay, let's check out the third networking option, which is the none network.
This, as the name suggests, means there's no network at all. Let's start up a container using the none network. Okay, so here we're at our bash prompt. If I list off the network interfaces, you can see that there's only the loopback interface. And if I try and ping google.com, it's going to fail. And there it is.
It's failed. So the none network is just what it says. There's no networking interface. It's completely isolated. All right, let's wrap up this intro to networking here. Now there's a lot more that could be covered regarding networking, though it should be covered once you have a more solid grasp of Docker.
So we're going to save that for a future course. In the next lesson, we're going to cover persistent storage options when we cover volumes. So if you're ready to keep learning, then I'm going to see you in the next lesson.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.