- November 12, 2018
- Posted by: AFourTech
- Category: Blogs
A Brief History…
So, in my previous article (http://afourtechnologies.com/dockers-and-containers/), we saw the basics of Dockers. But how many of us really know that Dockers actually started life in 2010 as an open-source side project in a company called ‘dotCloud Inc.’ which was founded by Solomon Hykes. Then, on September 19, 2013, dotCloud and Red Hat announced an alliance to integrate Docker with OpenShift Red, which is Hat’s Platform-as-a-Service (PaaS) offering. And finally, on October 29, 2013 dotCloud, Inc was officially renamed to Docker, Inc.
You can go through the Docker timeline here.
At the heart, Dockers are essentially a Linux-only tool developed in the Go language, and it builds on Linux Containers (LxC) to create Virtual Environments (VE’s).
Question: VE’s v/s VM’s or VE’s = VM’s??
Answer: VE’s are way-way different from VM’s.
VM’s as we know them, are created using a software application called a Hypervisor or an Emulator such as HyperV, VMWare, Oracle VirtualBox etc, and are full-scale images of a source machine, including the OS, RAM, HDD, Virtual Processors, Network Access etc. What this essentially means is that VM’s eat up quite a bit of disk space and are time-consuming to setup, deploy and start up.
Dockers on the other hand, are the exact opposite. Dockers isolate the OS from the kernel. The Docker then creates a ‘level-zero’ package from the kernel-machine baseline, and any subsequent changes are captured as snapshots; or namespaces as they are also called, and can be run in standalone containers as virtual systems.
Next Question: I can even create a Snapshot of my VM…so how is a Docker any different?
Answer: A VM’s snapshot is essentially a copy of the VM’s Virtual Hard Disk file at a given point in time. The Snapshots provide a change log for the virtual disk and can be used to restore the VM to a particular point in time when a failure or system error occurs.
Unlike VM’s, the Docker’s Snapshots capture only the changes from the ‘base template’, and not the full machine setup. From this point on, namespaces are stored and can be installed on their own to create full environments on any Docker-ready host.
So just how does this all work for me and/or my organization???
It’s a very common and (slightly) flawed understanding, that a Docker is a VM. So, the next obvious question that comes by, is that ‘if a Docker is a VM? How different is it from the conventional VM’s that we have been using this far?
In reality, Docker does not create its own VM with a distinct OS and processors and hardware emulation etc etc etc. Instead, the Docker (like we saw a bit earlier) is a VE or Virtual Environment – or a lite VM if that is the way you would like to put it; and it rides on the already existing kernel’s image of the underlying hardware, and only creates a ‘container’ in which we can run our apps.
So let’s just think of Docker as a Super Turbo Charged version of the LxC; that has on offer the following additional features that LxC doesn’t:
- Portable deployment across machines: you can use Docker to create a single object containing all your bundled applications. This object can then be transferred and quickly installed onto any other Docker-enabled Linux host.
- Versioning: Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc.
- Component reuse: Docker allows building or stacking of already created packages. For instance, if you need to create several machines that all require Apache and MySQL database, you can create a ‘base image’ containing these two items, then build and create new machines using these already installed.
- Shared libraries: There is already a public registry (http://index.docker.io/) where thousands have already uploaded the useful containers they have created. Again, think of the AWS common pool of different configs and distros – this is very similar.
For an exhaustive list of Docker’s capabilities, read on…(inspired by the Docker FAQ)
Docker is not a replacement for lxc. “lxc” refers to capabilities of the Linux kernel (specifically namespaces and control groups) which allow sandboxing processes from one another, and controlling their resource allocations.
On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:
- Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. Lxc implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom lxc configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine’s specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same docker container can run – unchanged – on many different machines, with many different configurations.
- Application-centric.Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines – basically servers that boot faster and need less ram. We think there’s more to containers than just that.
- Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, debian packages, rpms, source tarballs, or any combination of the above, regardless of the configuration of the machines.
- Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to “git pull”, so new versions of a container can be transferred by only sending diffs.
- Component re-use.Any container can be used as an “base image” to create more specialized components. This can be done manually or as part of an automated build. For example, you can prepare the ideal python environment, and use it as a base for 10 different applications. Your ideal PostgreSQL setup can be re-used for all your future projects. And so on.
- Docker has access to a public registry (https://registry.hub.docker.com/) where thousands of people have uploaded useful containers: anything from redis, couchdb, postgres to irc bouncers to rails app servers to hadoop to base images for various distros. The registry also includes an official “standard library” of useful containers maintained by the docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.
- Tool ecosystem.Docker defines an API for automating and customizing the creation and deployment of containers. There are a huge number of tools integrating with docker to extend its capabilities. PaaS-like deployment (Dokku, Deis, Flynn), multi-node orchestration (maestro, salt, mesos, openstack nova), management dashboards (docker-ui, openstack horizon, shipyard), configuration management (chef, puppet), continuous integration (jenkins, strider, travis), etc. Docker is rapidly establishing itself as the standard for container-based tooling.
Coming Up: Steps, Installation and Configuring a basic DevOps VM with the following: