DOCKER - 15 Virtual-Networks
Hello everyone and welcome to this introductory course to Docker.
For this course, you should understand the previous concepts regarding networking and building containers.
Now that we understand Docker networking concepts and all about virtual networking and IP, let's see some of the command line options to manage it.
First, there is docker network ls. As we can create multiple networks, so we have a command
ls to list them.
We have the inspect command, this will show us the details of a specific network.
Next we have a create command which has an optional driver that we can specify to use built-in and third-party drivers to create a new virtual network.
Next we have the connect and disconnect commands to modify a running container so that a new NIC is created on a virtual network for that container.
It's a bit like inserting a network card into a computer while it's on.
So back to the command lines. With the concepts we just learned, I can make a docker network ls. This shows me all the networks that have been created.
Depending on your operating system and your version of Docker, you may see the bridged network called docker0 or bridge, but they both mean the same thing. This is the default network that connects the NAT firewall to the physical network your host is connected to. Until now, we didn't have to worry about that, because all of our containers connected to that network and worked.
Now that we have this Nginx container running, if I do docker network inspect, the bridge network, you will actually see that it lists the containers attached to this network. You will see that our Nginx, which we called Webhost, is attached to it.
You can see its IP address. And you'll see here that these networks automatically assign IP addresses, and it shows you here, with the IPAM configuration, that the subnet is default 172.17, which is usually the default network for any Docker host.
But this can be changed and then the gateway of this network which will eventually be routed to the physical network.
If we go back to the docker network ls, we will be able to see these other two networks. For host, this is a special network that bypasses Docker's virtual networking and attaches the container directly to the host interface.
As you can imagine, this has advantages and disadvantages, as it prevents containerization's security measures from protecting that container's interface.
But it can also, in certain situations, improve the performance of high-speed networks and solve some problems with specific software.
Then we have the last one the network none, which is kind of the equivalent of having an interface on your computer that isn't connected to anything, but we can create our own.
Let's create a Docker network ... docker network create my_app_net
We will now redo a docker network ls. You will notice that it created my new virtual network with a bridge driver.
And that's because it's the default driver.
It's a simple driver that just creates a virtual network locally with its own subnet somewhere around 172.17 and above, as this will gradually increase. So 17, then 18, 19, 20 and so on.
It does not have any of the advanced features that we may see later in this course, such as overlay networks that allow private networking between hosts and other third-party drivers such as Weave.
If you look at the docker network create command with --help, you'll find that I can specify not only the driver I want to use, but also the many IP and network options 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 –d --name new_nginx --network my_app_net nginx
If we do a docker network inspect on the my_app_net, you can see that new_Nginx that I just created is now on that network. It has a new IP address at 172. 18
So that's the next subnet in the list.
But we don't need to start new containers, because just like in the real world where you can unplug and replug ethernet cables and reconnect to wireless networks, you can also do the same with existing networks and containers. .
b
For this we use docker network connect and disconnect options and you can use --help to view all available options for docker network.
Here we want a docker network connect and we want to take the existing container we created first and connect it to our new network.
I will choose my_app_net, then the webhost we had created.
Now if I do a docker container inspect webhost you will see that it is currently on two networks. The original bridge network, and I pretty much did the equivalent of assigning it a new ethernet interface on a different network, with a different IP address received from DHCP.
So we are now on network 17 and network 18.
If I wanted to disconnect that, I could do the same with just docker network disconnect my_app_net webhost. If I go back and do an inspection again, you will see that the system is now back with a single network.
As you can see there are many great options for the Docker network and the end goal here is that if you run all the applications on one server then in this case you can really protect them. Because in the physical world where we create virtual machines and hosts in a network, we often overexpose the ports and the network on our application servers.
In these cases, if you took your application containers and bundled them all into a virtual network, you would expose only the ports on your host where you specifically used the -p option. And everything else is a bit safer with this protected firewall inside their virtual network.
Later, when we talk about Docker Swarm, we are going to learn more about multi-host networking. To recap, we just described a set of commands for managing Docker networks.
We used the ls and inspect commands, created a Docker network and used the default bridge driver.
We didn't need to use the --driver
Finally, we tested the network connect and disconnect commands to add and then remove a network card
of a running container.
That's all for this video, but see you soon, for the next one.