‫Requirements for this lecture are that you've seen the previous network lectures and are understanding
‫of the key concepts for Docker networks and the commands that go with it.
‫All right.
‫And this lecture, you're going to learn and play with DNS and how it affects containers in custom networks
‫and default networks.
‫We're going to go over
‫quickly how important it is that we have good DNS because you can't rely on IP addresses inside containers
‫since things are so dynamic. We'll look at the differences between default and custom networks in
‫regards to how they deal with DNS.
‫And then we'll check out the --link option for container run for enabling DNS on the default
‫bridge network.
‫So there's one more thing that's crucial to all of these containers and virtual networks and them talking
‫to each other; and that's naming. Because in the world of containers constantly launching and disappearing
‫and moving and expanding and shrinking, and all the wonderfulness of these micro services that we're
‫seeing crop up everywhere, is that we no longer can easily rely on IP addresses as the way to talk
‫from one thing to the other. Because we can't assume from minute to minute that the IP addresses are even
‫going to be the same.
‫The container might go away or it might fail and then Docker brings it up somewhere else.
‫It's just too dynamic and too complicated to deal with that.
‫So it turns out that there is a built-in solution for this, and that is DNS naming. Docker uses the
‫container names as the equivalent of a host name for containers talking to each other.
‫Now if you remember we just had two containers running...
‫if you remember the Nginx was on a new network, called my_app_net.
‫Right.
‫And has the one container on it. Because I created this new network,
‫that's not the default bridge network,
‫it actually gets a special new feature, which is automatic DNS resolution for all the containers on that
‫virtual network from all the other containers on that virtual network using their container names.
‫If I were to create a second container on that virtual network, they'll be able to find each other, regardless
‫of what the IP address is, with their container names.
‫So let's try this: docker container run name ... and we'll call it my nginx...and we're going to specify the
‫network as my app net
‫from the nginx image.
‫Now, if we look at that network, we should see 2 containers; and, if I do a docker container exec,
‫from the new container I just created -- oops we also need the IT in there --
‫And we do a ping to the new nginx,
‫you notice that DNS resolution just works. This makes it super easy for you to have one container and
‫you need to set a configuration file in it to talk to, maybe let's say the PHP server will talk to
‫the MySQL backend. Ctrl-c out of that, and you'll see that it works the other way as well.
‫If I jump into the new nginx container and I try to ping the my ngnix, you see that the resolution
‫works both ways.
‫And this is what solves a huge problem when you're spinning up containers because you can't predict
‫how long they're going to last and where they might be a minute from now in a production design where
‫you've got a cluster of Docker Swarm servers.
‫So it may not change very much on your local machine, but if you stop 3 or 4 containers, and then
‫you start the same containers, and you start them in a different order,
‫they may not have the same IP address. But their host names, or their container names, will always be the
‫same.
‫And so you can rely on them.
‫Now I should note, if we do a docker network list, the default bridge network has one disadvantage here.
‫It does not have the DNS server built into it by default.
‫So you can use the --link.
‫So when you create a container, you'll notice there's a link option and you can actually specify manual
‫links between containers in that default bridge network.
‫But really, it's just much easier to create a new network for your apps so that you don't have to do
‫this every time.
‫And in a future section, when we talk about Docker Compose, you'll see how so much of this gets even easier
‫because Compose automatically will create new virtual networks whenever you spin up an app with it.
‫So communicating amongst your containers gets even easier.
‫As a quick recap, we covered in this lecture about how containers can't really, or shouldn't really,
‫rely on IP addresses for talking to each other because they just can't be relied on.
‫And that DNS is really the standard here for how we do intercommunication between containers on the
‫same host and across hosts.
‫And so I recommended you always create custom networks since it's just easier that way than doing a
‫--link all the time.
‫And then I gave you a teaser about Docker Compose and how it's going to make all this easier,
‫especially the networking.