DOCKER - 16 Network and DNS

Hello everyone and welcome to this introductory course to Docker. In this lesson, you'll learn how to use and play with DNS and its impact on containers in custom networks and default networks. We'll quickly see how important it is to have good DNS, because you can't get away with IP addresses in containers, things are so dynamic. We'll look at the differences between default networks and custom networks in terms of how they handle DNS. Next we will see the --link option for container run to enable DNS on the default bridge network.
There is one last thing that is crucial for all these containers and virtual networks and their communication with each other; and that's the naming. Because in the world of containers that constantly pop up and disappear, move, grow and shrink, we can't just rely on IP addresses to communicate from one thing to another. Because we can't assume any minute that the IP addresses will even be the same. The container can leave or it can fail, then Docker brings it back somewhere else. It's all too dynamic and complicated to deal with. So it turns out that there is a built-in solution to this problem, namely DNS naming. Docker uses container names as the equivalent of a hostname for containers to communicate with each other. Now if you remember we just had two containers running... docker container ls New_Nginx was on a new network, called my_app_net. Docker network inspect my_app_net As I created this new network, which is not the default bridge network, a new special feature, namely automatic DNS resolution for all containers in this virtual network, is provided, from all other containers of this virtual network and their names. If I create a second container on this virtual network, they will be able to find each other, regardless of IP address, with their container names. So let's try this:
Docker container a –d --name my_nginx --network my_app_net nginx (and we'll call it my nginx...and we'll specify my_app_net and nginx network). Now if we look at this network, docker network inspect my_app_net, we should see 2 containers; and, if I do a docker container exec –it , from the new container I just created my_nginx - And we ping to new_nginx, you will notice that the DNS resolution works. This makes it very easy for you to have a container and you need to define a configuration file to communicate with, say maybe the PHP server will communicate with the MySQL server. Ctrl-c, and you'll see it works the other way too. docker container exec –it new_nginx ping my_nginx If I start from the new_nginx container and try to ping my_ngnix, you'll find that the resolution works both ways. And that's what solves a huge problem when you're making containers, because you can't predict how long they'll last and where they might be a minute from now in a production design where you have loads of Docker Swarm servers. So it might not change much on your machine locally, but if you stop 3 or 4 containers, then start the same containers and in a different order, they might not have the same IP address. But their hostnames, or container names, will always be the same. And so you can count on them. Now if we do a docker network ls, the default bridge network has a downside here. The DNS server is not integrated by default. So you can use the --link. So when you create a container, docker container create --help, you will notice that there is a link option and you can actually specify manual links between containers in this default bridge network. But actually, it's much easier to create a new network for your apps, so you don't have to do it every time. And in a future section, when we talk about Docker Compose, you'll see how it gets even easier, because Compose will automatically create new virtual networks every time you create an application. Communication between your containers becomes even easier. To quickly recap, we explained in this course that containers couldn't, or shouldn't, rely on IP addresses to talk to each other, because they just couldn't rely so much. And that DNS is really the standard for how we intercommunicate between containers on the same host and between hosts. It is therefore recommended to always create custom networks, because it is easier than doing a --link all the time.
That's all for this video, but see you soon for the next one.