Creating and Using Docker Like Boss
Creating and Using Docker Like Boss
Creating and Using Docker Like Boss
as we see that it will actually stop the container since it was not running in detached
mode.
alpine a very small 5mb image of linux which is just vanila it does
not have running, which has its own package manager, it’s a small
security focused distribution
alpine doesn’t have bash but it has sh but its not full featured as
bash;
alpine has package manager apk we can use apk to install bash.
Anywhere I do a docker container run <stuff> nginx , where nginx is the image you
should use, replace that with nginx:alpine , which still has ping command in it.
Docker Concepts for Private and Public Comms for
Containers
Then if I went back and did an inspection again, you'll see that it's now back with only the one
network.
As you can see, there's lots of interesting options for Docker networking and really the end goal
here, and one thing I love to brag about with containers, is that if you're running all of the
applications on a single server, in this case, you're able to really protect them. Because in the
physical world where we were creating virtual machines and hosts in a network, we would often
overexpose the ports and networking on our application servers.
In these cases, if you were to take your app containers and have them all in one network together
in a virtual network, you're only going to be exposing the ports on your host that you specifically
use the -p with. And everything else is a little bit safer with that protected firewall inside their
virtual network.
Later on, when we get into Docker Swarm, we're actually going to learn about multi-host
networking and how this gets even better when we start to scale up and scale out.
To recap, we just covered a bunch of commands for managing Docker networks.
We played around with the ls and the inspect commands, created a Docker network, and used the
default driver of bridge.
We didn't actually need to use a --driver.
And last, we tried out the network connect and the network disconnect commands for adding and
then removing a NIC from a running container.
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.
It 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 And we do a ping to the new nginx,
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.