The question arose when I saw the definition of Docker on wikipedia in its article in English . The following sentence caught my attention:
All containers are run by a single operating system kernel and are thus more lightweight than virtual machines.
which translated is:
All containers are run by a single operating system kernel and are therefore lighter than virtual machines.
I used to think that they were the same, but in the sentence it can be seen that a distinction is made.
A virtual machine provides virtual hardware , so to speak. That is, when you create a virtual machine it is as if you had built a PC "by components", choosing how much RAM to put in it, how much hard disk, etc. All the elements of that "PC" are virtual in the sense that they do not really exist but are instead emulated or borrowed from the host on which they run (the virtual PC's hard drive is actually a file inside the host PC, the virtual PC screen is actually a window inside the host PC, etc)
In a sense, the virtual machine is like an emulator, with the difference that the CPU is not actually emulated, but special features of the real CPU are used that allow a virtualized CPU to run on it. Therefore the CPU architecture of the virtual PC will be the same as that of the (real) host PC.
The virtual machine comes without operating. You have to install one. In principle, you can install any operating system supported by its hardware architecture, without the host operating system having anything to do with it. So on an OSX host you can install a Windows or Linux OS on the virtual machine. The way to install the operating system would be the same as on a real machine, that is, boot the machine from a (virtual) DVD that contains the installation, partition and format the (virtual) hard disk and install the new operating system on it.
When the virtual machine boots, it will do so as a real machine would, that is, reading the boot sector of its (virtual) hard disk and loading the boot program contained therein, which will continue loading the rest of the operating contained in that disk hard (virtual).
If you create multiple virtual machines on the same (real) host PC, each requires its own amount of reserved RAM, its own virtual hard drive, and so on. This means that the host space used by the virtual machines is the sum of those used by each of them. The virtual machines do not share anything even if they all use the same operating system. Each one has its own independent (which can be slow) boot process, etc.
A container is a completely different thing. The container is not a virtualization of the hardware, but a virtualization (so to speak, it's really something else) of an entire kernel and its drivers . You can't install different kernels in different containers, since they all actually use the host's kernel.
The container is actually a way of separating processes, memory, network interfaces, and file systems using namespaces so that each container can only "see" what is in its namespace, and not what is in others. containers, but they are all running under the same operating system, which is usually Linux because it is the one that supports this separation by namespaces.
A container is instantiated from an image, which does not contain the kernel but only the rest of the tools that the container needs to work. When a container is said to have "Ubuntu", it doesn't actually have all of that operating, just the tools that would typically be found in the
/usr/bin
, , etcetera/usr/lib
setup ./etc
It does not contain the kernel, nor does it need to boot, as it uses the host's kernel that is already booted. It's much faster to get up and running, as it just involves mounting your image so it's visible in a file system namespace and launching a process (within your process namespace).The images are also lighter as they do not include the kernel or the drivers or the unnecessary utilities, but only those that the process destined to run inside that container will need.
And better yet, if you launch multiple containers based on the same image, the image is stored once and shared by all of them, because it's read-only (no container can modify what's in it). This makes launching many containers infinitely faster and "cheaper" (in terms of resources used) than launching virtual machines.
Perhaps there would be much more to tell about containers and how they do their "magic", but it would be extremely long. I think that this introduction can serve to better clarify some ideas for you when you continue reading on other sites.
Update Virtual Machines, Containers and Cloud.
Through what is called Cloud Computing, you can run services on machines that are not yours, paying Cloud providers such as Amazon, Azure or Google among others. One model for doing this is to create virtual machines, with whatever features you need. The price is paid per minute of operation and depends on the characteristics that you put on the virtual machine. However, it is very infrequent to turn that machine on and off every minute. The normal thing, if it is providing a continuous service, is to have it permanently on, with which the cost in the end is fixed per month.
Once you are paying to have one (or several) virtual machines in the cloud, you can install docker on them and use each machine to deploy multiple containers. This gives you a lot of flexibility to configure the architecture of the application, without having to pay anything extra. The container fits perfectly with the "microservices" architectural model.
Another deployment model is that you do not have to create the virtual machines, or install anything on them, or manage them, but simply the code that would have to be executed in response to certain events. It is what they call "Function as a Service". In this case you only pay for the time the function is running (in milliseconds). On servers with very little traffic it can be cheaper than having your virtual machine always on. The way cloud providers implement it "underneath" is that there are obviously always-on virtual machines (for which you do not pay in this model), on which they instantiate containers that are the ones that execute your functions. Since instantiating a container is very fast and you can have many in the same virtual machine,
Containers and Cloud are an inseparable couple today.
A container is lighter, since while in a virtual machine you need to install an operating system to function and thus virtualize (or eliminate the need to directly manage) the server hardware, a container works using (virtualizing) the operating system that has the server. machine (with Docker installed) on which the container is running.