In the beginning, applications ran on one operating system on one physical server, period. Then came hypervisors and virtual machines. A VM offers a full operating system and associated resources, and several VMs can run in the same physical machine. However, VMs must still be started or “spun up” in a server. They can consume a relatively large amount of resources and there are often limits on their portability.
Containers offer a new type of virtualization by packaging an application and its dependencies – runtime, system tools, system libraries – together, but while using a host’s operating system. As a result, containers use less resources, can be moved from one host to another, and are simpler and faster to deploy. They offer a number of advantages for DevOps:
- In-built version control. Different versions of application libraries on other machines no longer affect your application, because it already has what it needs in its container.
- Suited to microservices. A highly modular microservices architecture fits well with agile development and therefore with DevOps. Each microservice can then be put into a container with the runtime files it needs.
- Pre-build before deployment. Stable containers can be built earlier in the DevOps cycle and made ready for immediate deployment. By comparison, virtual machines need time to “spin up” within a physical machine.
- Roll Back. Containers are a key function of the fail fast and rollback capability needed in CI/CD environment. If a release makes it through to production but is found to have a defect the current release container can be stopped and last version spun-up.
Does that mean containers will replace virtual machines? Although the resource savings and the speed of deployment make containers attractive, they are less secure than VMs and they must often all use the same Linux operating system. Coexistence is more likely. In shared environments like public clouds, containers are currently often implemented within a VM, for this reason. There are also competing virtualization automation tools that provide similar isolation in VM instances like that of Vagrant another HashiCorp product.
Container technology has only recently achieved widespread recognition, starting with the introduction of Docker in 2013. Since then, the number of container technologies has increased:
- Docker. Originally built on Linux Containers or LXC, the Docker containers now have their own execution environment. The Docker platform is also supported by Microsoft Azure and Docker has a strategic partnership with the IBM Cloud. Google created Kubernetes, a tool specifically for managing Docker containers across server clusters.
- Rocket. While Docker has become a complex platform, the goal of Rocket is to provide a simple, secure, re-usable component (like the original Docker design goal) for deploying applications.
- Drawbridge. Microsoft’s own Drawbridge container technology has so far been used internally and as a sandboxing solution within Azure services. Plans for wider availability have not yet been announced, even though the technology was first prototyped in 2011.
- LXD. Offered by Canonical, LXD is based on top of LXC. LXD provides system containers, where each container runs a copy of a Linux distribution. By comparison, Docker and Rocket are application container managers. A Docker or Rocket container could run inside an LXD container, and benefit from LXD host resource management and security.
- VAGRANT. Initially a developer tool but consistently finding its way into production environments as an alternative to containers. Vagrant will isolate dependencies and their configuration within a single disposable, consistent environment, without sacrificing any of the tools you are used to working with (editors, browsers, debuggers, etc.). Once you or someone else creates a single Vagrantfile, you just need to vagrant up and everything is installed and configured for you to work. (this is from their site)
Which container technology should you use? Developers may find Docker attractive because it has a large ecosystem. They may opt for LXD for its flexibility in mixing and matching different Linux operating environments. Operations staff may prefer for Rocket for reasons of simplicity and security. Microsoft shops may opt for Docker, supported by Microsoft’s Azure, or in the future perhaps – but don’t hold your breath – Microsoft’s own Drawbridge containers.