As we discussed in our last blog, Docker has a lot of concepts to understand. Before jumping into Docker, getting to know these concepts will help you understand its capabilities before you jump in. In part 2 of Docker Concepts (see part 1 here), we look at networking, ports and volumes & mounts.
Volume & Mounts
Volume and Mounts refer to how you mount and persist files in your container. Each container is separate so you can’t see files or changes created in another container, even if they are using the same image.
Each time you restart the container, any changes you’ve made won’t be there as it starts from the image; therefore, your changes aren’t persistent.
Let’s be honest, it’s a pain to rebuild your application after each change when in development and changes are happening frequently.
But we can use volumes to create shared spaces that containers can use for sharing files between themselves and persisting changes between rebuilds.
A volume, by default, is hidden from the main host machine and is just used between the running containers. They must also be explicitly attached to a container when it is started.
The easiest way to think of it is as a network attached to a USB thumb drive that is plugged into several container computers at once.
We can make volumes more useful by defining mount points for them. The mount point takes a volume from being a hidden utility between containers to a full disk drive we can access on the host machine.
A mount allows us to add, remove and control files in the running container from the host machine. We do this by attaching a path on the host maching to the volume so this gets mounted inside the containers and they can access it. Useful for development, when files are changing a lot or when you need to persist a database.
When thinking about using volumes or mounts the comparison comes down to:
- Do I care where this is stored?
- Will I need to access it?
- Will I need to change it from the host?
Networks
With all this talk about separate containers, you may be wondering how they talk to each other. Well, as containers are isolated, we need to define how they communicate with each other.
Docker supports multiple types of networking setups (or drivers):
- Bridge – can be used on a single host to control how containers interact
- Host – disable Docker networks that rely on network settings from the host machine
- Overlay – used when containers are shared over multiple pieces of physical hardware
- Macvlan – used when a container needs to appear like a physical device on a LAN by giving it a MAC address
- None – completely disabled network
Some networks can communicate by sharing files on volumes but this is pretty inefficient, over a network using protocols is usually better.
In Docker, for containers to be able to talk to create a network. Then add containers to that network. This allows them to communicate, otherwise, they are isolated.
You can have multiple networks, and for security, this may make sense in production.
Your load balancer probably doesn’t need to talk to MySQL but your app servers do. A load-balanced network of the app servers and load balancer allows them to talk, same with a MySQL network of the database and app servers. But prevents the load balancer and MySQL from talking directly to each other.
Docker does smart things to try and make it as easy as possible to connect containers on the same network, often the DNS name needed will be the name of the container connected to the network.
Ports
How does the host communicate with containers? In Docker, you will have services running then usually have to expose information back to the host so Docker can use it.
The means of communication has to be explicitly set, otherwise, Docker will not know what to do.
Your running containers will expose services using ports (like a normal client and server, you connect on port 80 for https or 22 for SSH).
You may be running multiple containers so you can’t guarantee a specific port is available on your host to access the container’s service.
You must tell Docker what ports a container can expose to the host (help keeps them secure, single-purpose & isolated).
Then you have to tell Docker how to map those ports from your host to the containers.
You can map to the same expected ports just fine, (80:80, 443:443) but you may have services using those ports already and need to specify what ports to forward from the host to the container.
Up Next: Docker File
We’ve now covered all the Docker concepts you need to know before you explore it for yourself. In the last part of our Docker series, we’ll be covering the Docker File.
To catch up with the rest of our Docker series, see parts one, two, three and four.
