It is composed of 3 components:
Also known as the Docker daemon, it is a daemon that runs on any Linux distribution and exposes an external API for managing images, containers, and other entities that are progressively added in Docker distributions, such as volumes or virtual networks. Its functions include:
- Creation of Docker images.
- Publication of Docker images to a Docker Registry, which is another Docker component.
- Downloading Docker images from a registry.
- Execution of containers using local images.
- Management of running containers, allowing for stopping, restarting, viewing logs, or resource usage statistics.
This tool uses the remote API of the Docker Engine, commonly referred to as the Docker command, which serves as the command-line interface (CLI) tool. To manage a Docker Engine, the Docker CLI can be configured to communicate with a local or remote Docker Engine, allowing control over both the local development environment and production servers.
The most common Docker commands are:
docker info docker images docker build docker push
It typically runs on a separate server and is where the images generated by Docker Engines are published, making them available for use by any other machine. It is a fundamental component within the Docker architecture as it allows for the distribution of applications. Docker Registry is an open-source project, but Docker offers a paid Docker Hub where you can upload your own images, access public images from other users, and official images of major applications such as MySQL, MongoDB, Ubuntu, Redis, and many more, which can be found on the official website: https://hub.docker.com/
Docker Registry functions in a similar way to Git, providing image management with a service similar to GitHub, where each image, also known as a repository, is a succession of layers.
Kubernetes allows for the monitoring and proper management of containers created, for example, with Docker. This process is commonly referred to as orchestration.
We could say that an image is a snapshot of a container, meaning that once I run it on a server it is already the container, which has all the necessary configuration for the service to work, such as packages and everything else. required for its operation.
Now, it’s important to note that images are made up of layers, where an image can have n number of layers.
We are going to explain an example where we have 3 Layers.
Layer Number 1: Typically, the first layer has a FROM statement where we define the base operating system, so the image will contain a lightweight operating system that usually doesn’t exceed 120 megabytes. Later, we will see how we can download that operating system or initial image into the layer.
Layer Number 2: In this layer, we will use the RUN instruction, which allows us to perform a task such as installing a service within the operating system, for example, the Apache HTTP server.
Layer Number 3: For this example, we will assign the CMD instruction to this layer, which represents the command that will be executed or what will start the service.
If we have a FROM statement with Centos in layer 1, and in layer 2 we have a RUN instruction (e.g., yum -y install httpd), in layer 3, we would define a command that starts the service from layer 2.
These 3 previously created layers are read-only, so it will not be possible to modify them. The actions that I will be able to perform is to create additional layers on top of the existing ones or create a new image.
The layers are created using a file called Dockerfile, which is a basic plain text file and the default file that Docker will look for. In this file, we define the layers as follows:
FROM centos:7 RUN yum -y install httpd CMD ["apachectl","-DFOREGROUND"]
This last line, CMD, would start the Apache service that we installed in the previous layer. With Foreground, we are instructing it to execute in the foreground.
We could define a container as an additional layer, which is going to allow the execution in real time of the 3 previous layers, so for the example, layer 4 would be the container and it is going to allow running Centos, it is going to install Apache and run the CTL command to start it.
Layer 4 could be defined as a writing layer, since it has execution, so we will be able to access the 3 previous layers with reading and writing. It should be noted that all the changes that we make in layer 4 will be temporary, since the images, being read-only, do not store said change, so it is not recommended to make configurations on the Container.
Additionally, containers contain volumes, being a very complete topic, which is why we are going to deal with it in another blog.
Finally, in containers, we have networks, which allow containers to communicate with each other primarily.