These are some differences between a docker and a VM image which I could list out:
1. Snapshot process is faster in Docker than VMs
We generally start with a base image, and then make our changes, and commit those changes using docker, and it creates an image. This image contains only the differences from the base. When we want to run our image, we also need the base, and it layers our image on top of the base using a layered file system. File system merges the different layers together and we get what we want, and we just need to run it. Since docker typically builds on top of ready-made images from a registry, we rarely have to “snapshot” the whole OS ourself. This ability of Dockers to snapshot the OS into a common image also makes it easy to deploy on other docker hosts.
2. Startup time is less for Docker than VMs
A virtual machine usually takes minutes to start, but containers takes seconds, and sometime even less than a second.
4. Docker images have more portability
Docker images are composed of layers. When we pull or transfer an image, only the layers we haven’t yet in cache are retrieved. That means that if we use multiple images based on the same base Operating System, the base layer is created or retrieved only once. VM images doesn’t have this flexibility.
5. Docker provides versioning of images
We can use the docker commit command. We can specify two flags: -m and -a. The -m flag allows us to specify a commit message, much like we would with a commit on a version control system:
$ sudo docker commit -m "Added json gem" -a "Kate Smith" 0b2616b0e5a8 ouruser/sinatra:v2 4f177bd27a9ff0f6dc2a830403925b5360bfe0b93d476f7fc3231110e7f71b1c
6. Docker images do not have states
In Docker terminology, a read-only Layer is called an image. An image never changes. Since Docker uses a Union File System, the processes think the whole file system is mounted read-write. But all the changes go to the top-most writeable layer, and underneath, the original file in the read-only image is unchanged. Since images don’t change, images do not have state.
7. VMs are hardware-centric and docker containers are application-centric
Let’s say we have a container image that is 1GB in size. If we wanted to use a Full VM, we would need to have 1GB times x number of VMs you want. In docker container we can share the bulk of the 1GB and if you have 1000 containers we still might only have a little over 1GB of space for the containers OS, assuming they are all running the same OS image.
8. Supported image formats
Docker images:
- bare. The image does not have a container or metadata envelope.
- ovf. The OVF container format.
- aki. An Amazon kernel image.
- ari. An Amazon ramdisk image.
- ami. An Amazon machine image.
VM images:
- raw. An unstructured disk image format; if you have a file without an extension it is possibly a raw format
- vhd. The VHD disk format, a common disk format used by virtual machine monitors from VMware, Xen, Microsoft, VirtualBox, and others
- vmdk. Common disk format supported by many common virtual machine monitors
- vdi. Supported by VirtualBox virtual machine monitor and the QEMU emulator
- iso. An archive format for the data contents of an optical disc, such as CD-ROM.
- qcow2. Supported by the QEMU emulator that can expand dynamically and supports Copy on Write
- aki. An Amazon kernel image.
- ari. An Amazon ramdisk image.
- ami. An Amazon machine image
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/
My Linkedin - https://www.linkedin.com/in/rajeshkumarin
- Best AI tools for Software Engineers - November 4, 2024
- Installing Jupyter: Get up and running on your computer - November 2, 2024
- An Introduction of SymOps by SymOps.com - October 30, 2024
