Docker Networks Simplified — Part 2
In this article we're gonna learn and play with DNS and how it affects containers in custom networks and default networks. We're gonna go over how important is it that we have awesome DNS because we can't rely on damn IP address inside containers since things as super dynamic. Yay!
We'll also check out the badass — link option for container run for enabling DNS on the default bridge network.
Naming
The one thing that is crucial to all these containers is naming because in a world of containers often launching, disappearing, moving, expanding and all the sweet sweet wonderfulness of these microservices.
Forget IP's, Static IP's and using IP's to talking to containers is an antipattern. Do your best to avoid it
We no longer can rely on IP addresses as the way to talk from one thing to another because we can't assume that the IP addresses from minute to a minute will be the same, the container might go away it's just too dynamic and complicated to deal with that stuff.
Turns out that there is a built-in solution to this and that is the glorious DNS naming. Docker uses the container names as the equivalent of a hostname for containers talking to each other.
No more reading let's see the actual stuff
Let's check the available docker networks right now. type in the command.
You can see that there are currently three networks. The bridge network is the default network created by docker. If we don't explicitly specify the network the container joins bridge.
To create a new custom docker network we can use the command below.
If you look at the network my_app_network you can see that the driver used is bridge. That's because that's the default driver. It's a simple driver that simply creates a virtual network locally.
Creating a container inside the custom network
You can create a container that will be inside the new network by using the command.
Now if we inspect the newly created network.
We can see that the container that we previously created is in the network my_app_network with the IP address 172.18.0.2
Unplug and Plug Containers
We don't have to start a container in order for it to be in a network. Just like in the real world where we can unplug and replug ethernet devices, we can also do the same with existing networks and existing containers and for this we use.
docker network connect and docker network disconnect
In order to explain docker network connect. I'm gonna start a container sasuke_nginx in the default docker network bridge and then connect the container to a custom network called akastsuki. Let's start by creating a new container by running the command.
Let's create a new custom network called akastsuki.
If we now do a docker inspect on sasuke_nginx we can see that the container is in the default network bridge. To connect the container to the network we can use the command.
docker network connect akastsuki sasuke_nginx
Now if we do a container inspect of sasuke_nginx we can see that it is connected to the new network.
If we want to disconnect the container from the network we can use the disconnect command.
docker network disconnect akastsuki sasuke_nginx
Finally
The one thing that I love to brag about with containers is that, if you're running all of the applications on a single server you're able to protect them because in the physical world where we were creating virtual machines and hosts in a network we would often overexpose a port so in this case, we are only exposing the ports that we specifically need and everything else is a little bit safer with the protected firewall.
