Saturday, 9 May 2015

What are Containers?

Where Did Containers Come From?

In the beginning there were monolithic physical servers. They each ran a single operating system like Linux or Windows.

Then we devised virtual machines and we could run multiple guest operating systems on a single host server. This gave us huge flexibility - the ability to use physical servers more effectively (server density and multi tenancy) and change their use comparatively rapidly (in hours or even minutes).
Physical Server with 2 VMs

Finally, products like Vagrant, Chef and Puppet gave us the ability to script the creation of  VMs. That made it much easier to get consistency across development, test and production environments.

When combined with IaaS VMs became an amazingly effective way to get more from physical infrastructure and cut hosting costs.

Containers Are a Powerful New Take on VM Concepts

How are containers different to VMs?

VMs are great, but when you’re running several guest OSs on a host OS you’re duplicating a lot of functionality - multiple full network stacks for instance. That’s a waste.

Physical Server with 2 Containers

Containers are not VMs - but they kind of act like them. Containers are processes that run on your host OS, but behave conceptually much like a very lightweight VM. They focus on providing the separation and configurability of a VM with minimal duplication between container and host OS. This means you can fit more containers than VMs on a physical server (lower costs) and you get much faster launch speeds (a container could potentially be instantiated fast enough to handle a single network packet).

Each container could run several applications (a "fat" container) but they often just run a single application ("thin").

Containers are managed on your host OS using a container engine application (Docker for example). Like a hypervisor, a container engine routes network traffic to individual containers and divides up and controls access to shared Host resources like memory and disk. Docker also cleverly provisions a container’s contents via preconfigured images and scripts (in much the same way Vagrant allows you to script VM creation).

Each container then emulates a cut down “guest” that supports a restricted set of applications. For example, a web server or a database.

In order to make containers even faster, they can be hosted on a stripped down open source Linux variant like CoreOS or Snappy Ubuntu, but this isn’t necessary, many ordinary Linux variants support containers out of the box.

Are there Windows Containers?

Containers were originally developed for Linux, but Microsoft are in the process of developing similar function for Windows.

Why are Containers Better than VMs or Bare Metal?

Containers have most of the advantages of VMs: flexibility and scriptability. However, they can achieve higher server densities and faster instantiation than VMs because of the reduction in duplication between the host OS and guest OSes.

It is the extreme speed of instantiation and destruction of containers that we’re exploiting in Force12.

How are Containers Worse than VMs?

You can’t mix different OSes on the same host with containers (for example, you couldn’t have a Windows container on a Linux host). That potentially reduces the flexibility, although this often isn’t much of an issue in real world scenarios outside of dev and test.

You can’t give a container its own IP address. The container inherits the IP address of the host and you can only distinguish individual containers using port numbers (although there are some open source projects like Calico that can indeed allow full IPV4 or IPV6 addressing of containers).

Containers running on the Host are just processes. They are not as sandboxed in terms of disk, memory, cpu etc.. as a VM would be. This currently makes them less secure in a multi-tenant environment. Again, that’s being worked on.

No comments:

Post a comment