Docker-101 Part-3 would enable you to understand various components of Docker Architecture and we would be going through various Docker CLI commands.
Docker uses a client-server architecture. The core component of Docker Architecture is the Docker daemon which basically does all the run-time operations and acts as an interpreter in between containers and the Operating System kernel. The Docker client and Docker daemon can be on the same Docker host or you can connect Docker Client to a remote Docker daemon as well. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface.
In this tutorial, Let’s first install various components in a docker architecture.
Docker Host is a physical/virtual machine on which Docker CE/EE can be installed.
The Docker daemon (dockerd) listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. A daemon can also communicate with other daemons to manage Docker services.
The Docker client (docker) is the primary way that many Docker users interact with Docker. When you use commands such as docker run, the client sends these commands to docker, which carries them out. The docker command uses the Docker API. The Docker client can communicate with more than one daemon.
A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use, and Docker is configured to look for images on Docker Hub by default. You can even run your own private registry. If you use Docker Datacenter (DDC), it includes Docker Trusted Registry (DTR).
When you use Docker, you are creating and using images, containers, networks, volumes, plugins, and other objects. This section is a brief overview of some of those objects.
An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image that is based on the Ubuntu image but installs the Apache web server and your application, as well as the configuration details needed to make your application run.
A container is a runnable instance of an image. You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks, attach storage to it, or even create a new image based on its current state.
Docker’s networking subsystem is pluggable, using drivers. Several drivers exist by default, and provide core networking functionality:
The default network driver. If you don’t specify a driver, this is the type of network you are creating. Bridge networks are usually used when your applications run in standalone containers that need to communicate. See bridge networks.
For standalone containers, remove network isolation between the container and the Docker host, and use the host’s networking directly. a host is only available for swarm services on Docker 17.06 and higher. See use the host network.
Overlay networks connect multiple Docker daemons together and enable swarm services to communicate with each other. You can also use overlay networks to facilitate communication between a swarm service and a standalone container, or between two standalone containers on different Docker daemons. This strategy removes the need to do OS-level routing between these containers. See overlay networks.
Macvlan networks allow you to assign a MAC address to a container, making it appear as a physical device on your network. The Docker daemon routes traffic to containers by their MAC addresses. Using the macvlan driver is sometimes the best choice when dealing with legacy applications that expect to be directly connected to the physical network, rather than routed through the Docker host’s network stack. See Macvlan networks.
For this container, disable all networking. Usually used in conjunction with a custom network driver. none is available for swarm services. See disable container networking.
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:
- Volumes are easier to back up or migrate than bind mounts.
- You can manage volumes using Docker CLI commands or the Docker API.
- Volumes work on both Linux and Windows containers.
- Volumes can be more safely shared among multiple containers.
- Volume drivers let you store volumes on remote hosts or cloud providers, encrypt the contents of volumes, or add other functionality.
- New volumes can have their content pre-populated by a container.
This concludes this week’s series of Docker-101 Part-3, after which you should now have a good understanding of various docker components in a docker architecture.
Please share your views on the article and inputs to make it better for the next set of DIY articles we are bringing on Docker Containers.