You are part of a development team and you want to try out the latest version of the VM that your application uses. Or you want to make some configuration changes and test them out in your development environment. However, you are not sure if your changes would be useful or successful. And hence you want an ability to roll back the changes or potentially version control them. How do you do it? Vagrant comes to the rescue!!
What is Vagrant?
Vagrant is an open source tool for building and maintaining portable development environments. With the rise of complex architectures involving several different servers and technology stacks, Vagrant simplifies the task of creating and maintaining the required stack of software/libraries etc.
Vagrant stores the configuration in the form of a text file(s) and these files could be put under your favorite version control system such as git. If changes don’t work out, you can easily roll back and go to the earlier working stage. This capability improves the development productivity a lot and hence Vagrant has become a darling of several development teams.
This tool uses a concept of “provisioners” and “providers”. Provisioners are tools that allow to customize/modify the environments – examples are Chef and/or Puppet. Whereas Providers are services which provide virtual machines such as AWS, Docker, VMWare etc.
Vagrant abstracts the machine. It sits as a wrapper on top of underlying hardware. You can throw away the vagrant configuration and create new one very easily, by simply changing the config files. It provides command line interface, which can work in any environment irrespective of the underlying VM or OS. This additional layer provides the portability, simplicity, and interoperability. One developer can easily share this environment she has created with others and other can quickly set up the replica of the shared environment.
One might be tempted to compare Vagrant with other configuration management tools such as Chef/Puppet/Ansible. However, Vagrant is commonly used along with one of these tools as they serve different purposes.
Paravirtualization is a type of virtualization, which allows us to install and run one or more different operating systems (Guest OS) on a single physical server (Host OS). You might get tempted to compare it with Hypervisor and you wouldn’t be wrong. They have similarities and differences.
A Hypervisor is a software that allows installing one or more different operating systems on a single physical server. The OS which runs the Hypervisor is called as Host OS and the OS which is run by Hypervisor is called Guest OS. Here, guest OS doesn’t have a clue that it is running in a virtualized environment. This is where Hypervisor differs from Paravirtualization.
So how does Paravirtualization work?
In virtualization, Hypervisor acts as a relay between guest OS and host OS. In Paravirtualization, guest OS needs to know that it is interacting with Hypervisor and hence needs to make different API calls. This calls for modifications to the guest OS and hence creates a tight coupling between guest OS and Hypervisor used. Since proprietary OS providers such as MS do not allow OS level modifications and hence you would end up using open source operating systems such as Linux. A good combination is Linux with Xen server
You would be wondering if there are any real advantages of paravirtualization. Paravirtualization has shown performance improvements for certain applications or in certain use cases, but it has not shown the reliability. Especially with the rise of software level virtualization, which shows very high reliability, need for Paravirtualization has gone down. The cost associated with guest OS modifications, tight coupling with Hypervisor, is not getting offset by the not-so-predictable performance gains. So, you wouldn’t find many instances where paravirtualization is used.
Kubernetes is a tool or a system for automating the deployment of containerized applications. In a loose analogy, one can say what Chef is for infrastructure deployments, Kubernetes is for container deployments.
History of Kubernetes
It was part of Google’s internal tool system called “Borg” which was later made as Open-source in 2015. Internal codename of this project was “Seven” and is reflected in the logo of this system.
Kubernetes has been maintained by Cloud Native Computing Foundation which is a collaboration between Google and Linux Foundation.
What does Kubernete offer?
It offers to manage the “immutable infrastructure” in an automated fashion. Typically, containers are launched using images which do not change. If you want to make changes to the software piece which is part of the container, you simply update the image, launch new containers and throw away the older containers. Kubernetes allows you to do this efficiently.
The lowest level abstraction that Kubernete provides is called a “Pod”. It consists of one or more containers which can run on a same “node”. A Node is a server or VM on which Kubernetes cluster is running. The containers in a Pod could be sharing resources and can communicate with each other. This allows running tightly knit services to be run from the same Pod.
In Kubernetes configuration, Pods are not updated but are simply destroyed. New Pods are created when any of the containers are required to be updated.
“Deployments” are something that runs the Kubernetes cluster. They store the configuration, dependencies, resource requirements and access etc. Kubernete also has a “ReplicationController” which allows you to replicate the Pods as per the need.
Hypervisor means supervisor of supervisor – a strong supervisor. It is hardware or software, which allows to create and control one or more virtual systems. Hypervisor are also known as Virtual Machine Monitor(VMM).
A computer, on which Hypervisor runs, is called as “Host Machine”. The operating system is referred as “Host OS”. Hypervisor allows to create one or more virtual systems on top of Host Machine’s hardware. Each virtual system may have different operating system. Such operating system is referred as “Guest OS”.
The need to use hardware more efficiently gave rise to the Hypervisors. They emulate the underlying hardware for the virtual machines as per the configuration.
It is easy to confuse VMs with Containers, however, there is clear differentiation between these two entities. VMs bundle operating systems within them whereas Containers do not.
Types of Hypervisor
Bare-Metal – This layer is installed directly at hardware level and doesn’t have any Host OS at all. It directly allows to install guest operating systems. These type of Hypervisors obviously give speed and efficiency as they work directly off the hardware. They give deterministic response times, smaller memory footprint and fine grained control.
Hosted – These reside on top of host operating system. These are preferred where speed has lesser consideration, but manageability requirement is higher. Additionally, these are available on a wider range of underlying hardware and are easier to setup and install.
Virtualization is a technique of dividing resources of a computer into multiple execution environments. Virtualization can happen at hardware level or at OS Level. Containers are the latest trend in this space. Although the concept is very old, since unix days, this type of virtualization has picked momentum since Docker Inc introduced their technology.
What Are Containers?
Containers provide an isolated space to run a specific application or a set of applications utilizing the underlying Host OS through OS level virtualization. OS Level virtualization allows to run multiple applications “contained” in an isolated space and hence the name. Isolation also provides security. It would be easy to confuse them with VM (virtual machines).
VMs host their own OS within themselves (Guest OS). They run on top of another OS (known as Host OS) and provide abstraction at hardware level. This guest OS could be different from host OS. They need to bundle all the dependent libraries and applications within and hence turnout to be bulky.
Containers use underlying host OS through OS level virtualization. All the containers running on a given machine need to use the same OS as that of host OS. They can share the libraries with underlying OS and hence turn out to be very lightweight.
Docker Inc. is a leading provider for in this space and has been doing that since 2014.
As can be seen easily from above diagram, applications running in VM are very bulky as they need to have OS as well bundled with them. Whereas Containers are lightweight and hence multiple instances could be run on single Host OS.