From Chefland to Dockerland : Theory for a DevOps Noob

What this post is not?

A guide to get started with tools available for Configuration management or Container Orchestration.

What its about then?

The intent of this post is to demystify the boundaries between Configuration management systems and Container management systems. It also attempts to explain why there is a need for yet another orchestrator i.e a Container Orchestrator.

Before we delve in to details, lets take a look at a subset of terminology used in the DevOps community first that will make this post simpler to follow. This may be too basic for most of us but may serve good for those still clouded with the buzz.

  • Hypervisor

    A program that allows hardware virtualization/emulation. It has the ability to create multiple self contained units (called Virtual Machines) that can run on a single host OS. Its the one responsible for allocating host’s hardware, memory and processor to the VM’s.

  • Virtual Machine

    An isolated process that provides functionality of a physical computer viz. run a OS(known as the Guest OS) and host applications. A VM runs in its own kernel space and is backed by the physical resources of host OS. It has its own dedicated hardware stack like network adapter, storage and CPU. Hypervisor is the one that manages a VM.

  • Container Engine

    A software that allows virtualization of the OS sub systems or services such that it can create light weight isolated self contained units (called Containers) over the shared host kernel(OS).

  • Container

    A Light weight, isolated self contained process that can host applications over the host OS. It shares the host systems’ kernel and is limited to interacting with only its designated resources. It can be seen as a stripped-down version of VM with just enough software to deploy and run an application. They are managed by Container Engines. The “kernel sharing” is really the key difference between a Container and a VM.

  • Container Image

    An image is an immutable file that’s a snapshot of a container. They create a container when started. Since images can get large, they can be composed of other images.Images are stored in a image registry which serves as a repository for these images.

Why use VMs anyway?

The reason we had VMs to host applications at the first place was to remove the need for more physical hardware. VMs allow efficient use of computing resources, both in terms of energy consumption and cost effectiveness.

And now the containers?

The shift from VMs to Containers was primarily driven by Container’s innate lean and fast capabilities. This is due to the fact that it shares the host kernel and is native to it. Simply put, unlike VMs, it does not have to wait while the guest OS negotiates with the hypervisor for resources. Here are some key benefits of using containers:

  1. Container images ensure high portability across environments. So an image that’s built in Dev environment can be easily ported to higher environment with a higher confidence of predictable builds.
  2. Helps in faster setup and accelerates development. The need for manual software setup is gone.
  3. Helps minimize the environment specific unknowns by use of images that are portable and bring up coherent environments.
  4. Allow scaling and high availability by virtue of its light weight nature.
  5. Easy to use

Where do the Chefs and Puppets fit in this landscape?

Choosing a suitable technology to provision virtual servers(VMs or containers) is just one aspect of the DevOps space. “How” they need to be provisioned and managed is another crucial one. Chef, Puppet and many other such tools help us fulfill the latter. They are known as Server Configuration management tools. You can think of a configuration management tool to be one that allows you to handle changes to a system while maintaining its integrity. It lets you represent configuration both at the machine and the application level. Such tool should typically have following capabilities:

  1. Platform Agnostic
  2. Infrastructure provisioning: Allow configuration and testing of infrastructure code commonly known as Server orchestration or infrastructure provisioning.
  3. Automated Load balancing : Allow load balancers to be configured, created and managed by infrastructure code.
  4. Automatic failover : Allow configuration of a failover process by means of which an application can be moved to a standby server in case of a failure.
  5. Automated Package management : Install packages and associated dependencies by auto-detecting system’s package manager. A package manager is a software that installs and manages software packages and its dependencies.
  6. Automated server monitoring : Allow configuration of server monitoring using constructs provided by the CM. They may even allow defining custom metrics to monitor system’s performance and availability.

So Vagrant or Docker?

Vagrant is a Virtual Machine manager that lets you provision multiple virtual machines with their own configuration. You can setup the desired environment once the VMs are provisioned using provisioning scripts. This can be done using any of the Configuration management tools discussed earlier. Docker, on the other hand, is a container engine that allows container based provisioning. Docker has gained a lot of interest and popularity. With Docker, its the application that gets bundled as an image instead of a heavy weight VM.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s