Creating and Using Docker Like Boss

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 39

Creating and Using Docker Like Boss

Starting nginx server from Docker


The number of times we hit refresh we can see the log entries are happening in our cli.
Every time you run a new container you get a new unique id
how to check process running inside a container
docker container top webhost (webhost is a container name)
lets run mongo-db container
ps aux to show run all the processes

How to Pass environment Variables


Docker container

docker container logs mysql


How to get root password
curl localhost
curl localhost:8080
What’s going in Container
Docker container inspect container_name
Docker stats gives streaming view of our stack
-it (tty and i is for stdin)
containers only run as long as the command at startup runs

as we see that it will actually stop the container since it was not running in detached
mode.

docker container exec (run additional process in running


container)

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.

Fix for nginx

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

Docker Networks Concepts


we can see docker container ip and host ip are not on same
network

c1-> container; bridge/docker0(virtual network is attached to


ethernet host),
We can create more virtual network like below net_my_app and
two container mysql, and httpd

Only one port is available for container


Docker Networks
here we can see it has created the virtual network my_app_net as with driver bridge
and that’s because that’s the default driver, It's a simple driver that simply creates a
virtual network locally with its own subnet somewhere around the 172.17 and above,
because it will increment as it goes. So, 17, then 18, 19, 20 and so on.
It doesn't have any of the advanced features that we might see later in this course, like
overlaid networks that allow private networking between hosts, and other third party
drivers like Weave.
Now if I do a docker container inspect of my original webhost, you'll see that it's actually now on
two networks. The original bridge network,
and I basically did the equivalent of giving it a new Ethernet interface on a different network,
with a different IP that was received from the DHCP.
So we're now on the 17 network in the 18 network.
If I wanted to disconnect that, I could do the same with just disconnect. Then if I went back and
did an inspection again, you'll see that it's now back with only the one network.

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,

we should see two containers


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 andyou need to set a configuration file in it to talk to,
maybe let's say the PHP server will talk to
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.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy