Apparently, containers and virtual machines seem to be very similar concepts. But although these two solutions have common characteristics, they are profoundly different technologies, in the same way, that we must start thinking about how the architectures of our applications are different. We can create a container with our monolithic application inside, but in this way, we will not fully exploit the strength of the containers, and therefore, of Docker.
A possible software architecture suitable for a container infrastructure is the classic microservice architecture. The idea is to break down the application into many small components—each with their own specific task—that are able to exchange messages and cooperate with each other. The deployment of these components will then take place individually, in the form of many containers.
A scenario that can be handled with microservices is absolutely impractical with a virtual machine since every new virtual machine instantiated would require a good expenditure of energy for the host machine. Containers, on the other hand, are very light, since they carry out completely different virtualization from that practiced by virtual machines:
In virtual machines, a tool called a Hypervisor takes care of reserving (statically or dynamically) a certain amount of resources from the host OS to be dedicated to one or more OSes, called guests or hosts. A guest OS will be completely isolated from the host OS. This mechanism is very expensive in terms of resources, so the idea of combining a microservice with a virtual machine is completely impossible.
Containers, on the other hand, make a completely different contribution to the issue. The isolation is much blander and all the running containers share the same kernel as the underlying OS. Hypervisor overhead completely disappears, and a single host can host hundreds of containers.
When we ask Docker to run a container from its image, it must be present on the local disk, otherwise Docker will warn us of the problem (with a message reading Unable to find image 'hello-world: latest' locally) and will download it autonomously.
To find out which images were downloaded from Docker on our computer, we use the docker images command:
C:>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
dockerize.py latest bc3d70b05ed4 23 hours ago 91.8MB
<none> <none> ca18efb44b3c 24 hours ago 91.8MB
python alpine3.7 00be2573e9f7 2 months ago 81.3MB
The repository is a container of related images. For example, the dockerize repository contains various versions of the dockerize image. In the Docker world, the term tag is more correctly used to express the concept of image versioning. In the preceding code example, the image has been tagged as the latest and is the only tag available for the dockerize repository.
The latest tag is the default tag: whenever we refer to a repository without specifying the tag name, Docker will implicitly refer to the latest tag, and if this does not exist, then an error will be shown. Therefore, as a best practice, the repository tag form would be preferable as it allows greater predictability regarding the content of the image, avoiding possible conflicts between containers and errors due to the lack of the latest tag.