VM vs Docker

I keep rereading the Docker documentation to try to understand the difference between Docker and a full VM. How does it manage to provide a full filesystem, isolated networking environment, etc. without being as heavy?
Why is deploying software to a docker image (if that's the right term) easier than simply deploying to a consistent production environment?
I like Ken Cochrane's answer.
But I want to add additional point of view, not covered in detail here. In my opinion Docker differs also in whole process. In contrast to VMs Docker is not (only) about optimal resource sharing of hardware, moreover it provides a "system" for packaging application (Preferable but not a must, as a set of Microservices).
To me it fits in the gap between Developer Oriented tools like rpm, debian packages, maven, npm + git on one side and Ops tools like Puppet, VMWare, Xen you name it...
Why is deploying software to a docker image (if that's the right term) easier than simply deploying to a consistent production environment?
Your question assumes some consistent production environment. But how to keep it consistent?Consider some amount (>10) of servers and applications, stages in the pipeline.. To keep this in sync you'll start to use something like Puppet, Chef or own provisioning scripts, unpublished rules and/or lot of documentation... In theory servers can run indefinitely, and be kept completely consistent and up to date. Practice fails to manage a server's configuration completely, so there is considerable scope for configuration drift, and unexpected changes to running servers.
So there is a known pattern to avoid this, the so called Immutable Server. But the immutable server pattern was not loved. Mostly because of the limitations of VM's it was used before Docker. Dealing with several Gigabytes big images, moving those big images around, just to change some fields in the app, was very very laborious. Understandable...
With Docker ecosystem you will never need to move around Gigabytes on "small changes" (Thanks aufs and Registry) and you don't need to worry about losing performance by packaging applications into a Docker container on runtime. You don't need to worry about versions of that image. And finally you will even often be able to reproduce complex production environments even on your linux laptop (don't call me if doesn't work in your case ;))
An of course you can start docker containers in VMs (it's a good idea). Reduce your server provisioning on VM level. All the above could be managed by Docker.
P.S. Meanwhile Docker uses its own implementation "libcontainer" instead of LXC. But LXC is still usable.


Through this post we are going to draw some lines of differences between VMs and LXCs. Lets first define them.
VM:
A virtual machine emulates a physical computing environment, but requests for CPU, memory, hard disk, network and other hardware resources are managed by a virtualization layer which translates these requests to the underlying physical hardware.
In this context the VM is called as the Guest while the environment it runs on is called the Host
LXCs:
Linux Containers (LXC) are operating system-level capabilities that make it possible to run multiple isolated Linux containers, on one control host (the LXC host). Linux Containers serve as a lightweight alternative to VMs as they don’t require the hypervisors viz. Virtualbox, KVM, Xen etc.
Now unless you were drugged by Alan (Zach Galifianakis- from the Hangover series) and have been in Vegas for the last year, you will be pretty aware about the tremendous spurt of interest for linux containers technology and if I will be specific one container project which has created a buzz around the world in last few months is – Docker leading to some echoing opinions that cloud computing environments should abandon virtual machines (VMs) and replace them with containers due to their lower overhead and potentially better performance.
But the big question is, is it feasible?, will it be sensible ?
a. LXCs are scoped to an instance of Linux. It might be different flavors of Linux ( e.g. a Ubuntu container on a Centos host but it’s still Linux. ) Similarly, Windows-based containers are scoped to an instance of Windows now if we look at VMs they have a pretty broader scope and using the hypervisors you are not limited to Operating Systems linux or windows.
b. LXCs have low overheads and have better performance as compared to VMs. Tools viz. Docker which are built on the shoulders of LXC technology have provided developers with a platform to run their applications and at the same time have empowered ops people with a tool that will allow them to deploy the same container on production servers or data centers. It tries to make the experience between a developer running an app, booting and testing an app and an operations person deploying that app seamless because this is where all the friction lies in and purpose of DevOps is to break down those silos.
So the best approach is the cloud infrastructure providers should advocate an appropriate use of the VMs and LXC, as they are each suited to handle specific workloads and scenarios.
Abandoning VMs is not practical as of now. So both VMs and LXCs have their own individual existence and importance.

Good answers. Just to get an image representation of container vs VM, have a look at the one below.
Container vs VM
shareimprove this answer
   

Docker encapsulates an application with all its dependencies, a virtualizer encapsulates an O.S. that can run any applications it can normally run on a bare metal machine.
They both are very different. Docker is lightweight and uses lxc/libcontainer ( which relies on kernel namespacing and cgroups ) and does not have machine/hardware emulation such as hypervisor, KVM. Xen which are heavy.
docker & lxc is meant more for sandboxing,containerization and resource isolation. It uses the host OS's ( currently only linux kernel) clone API which provides namespacing for IPC, NS (mount), network, PID, UTS etc., what about memory, io, cpu etc., ? that is controlled using cgroups where you can create groups with certain resource ( cpu, memory...) spec/restriction and put your processes in there. On top of lxc, Docker provides storage backend (http://www.projectatomic.io/docs/filesystems/) e.g.,union mount filesystem where you can add layers and share layers between different mount namespaces . This is a powerful feature where the base images are typically readonly and only when the container modifies something in the layer will it write something to read-write partition ( a.k.a. copy on write ) . It also provides many other wrappers such as registry and versioning of images. With normal lxc you need to come with some rootfs or share the rootfs and when shared, the changes are reflected on other containers. Due to lot of these added features, docker is more popular than lxc. lxc is popular in embdded environment for implementing security around processes exposed to external entities such as network and UI. docker is popular in cloud multi tenancy environment where consistent production environment is expected.
Normal vm (virtualbox, VMware) uses hypervisor and related technologies either have a dedicated firmware that becomes the first layer for the first OS ( host OS, or guest OS 0 ) or a software that runs on the host OS to provide hardware emulation such as cpu, usb/accessories, memory, network etc., to the guest OSes. VMs are still (as of 2015) popular in high security multitenant environment.
docker/lxc can almost be run on any cheap hardware (<1GB of memory is also OK as long as you have newer kernel) vs normal vms need atleast 2GB of memory etc., to do anything meaningful with it. But docker support on host OS is not available in OS such as windows (as of nov/2014) where as may types of vms can be run on windows,linux, macs.

Comments

Popular posts from this blog

WMI Static Port configuration

Optimizing your JVM for Best Performance

How do I disable FOREIGN KEY checking for the time of database schema migration?