Containers1

Containers 101

Objective
This learning lab aims to provide you with background on the term "Containers", what they are, what they aren't and how they relate to other technologies often used interchangeably, such as 'Docker'.

Completion time: 10 minutes

Audience
DevOps engineers
Application developers
IT teams addressing the developer need for Docker and Containers
Containers...
At the simplest explanation, containers are just a way of separating running processes or code without what we know as VM's or full virtualisation.

Imagine being able to guarantee that App A and App B cannot see, or interfere with each other on the same host (They don't even know each other exist) without having to spin up a full VM and Operating system for each. This is what containers essentially give us.

How?
This is achieved through features built into the operating system, just like a hypervisor is responsible for creating and managing VM's, Linux now has the ability to create these isolated containers.

In Linux, this technology is called CGroups it allows you to portion off resources from the system.

From Wikipedia: CGroups (abbreviated from control groups) is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes.
Windows also has similar isolation features for containerising windows apps and processes.

The important thing here is that theres only one kernel, lots of containers all running on top of one operating system, which is handling the isolation. Unlike virtualisation, in which you install a whole operating system for each.

A history lesson
This type of separation is nothing new, technologies have existed to "containerise" or separate applications from each other for a long time;

1960's Mainframes supported lightweight isolation of tasks (aided by hardware)
Solaris 10 Zones provided a very similar solution to what we class as containers today.
chroot jails on unix/linux are an early attempt at the same lightweight isolation.
Each solution came with varying levels of success and importantly, security.

So whats changed? Why Containers now?
The fact you're already three paragraphs in to this learning lab is part of the problem.... or used to be.

Developers (or the operations teams they relied upon) used to have to care deeply about all of the above if they wanted to use containers, they needed to know the ins and outs of CGroups for example. Then, once they worked out how to isolate their app, they still need a way of actually installing that "container" onto their system, running it, updating it, the usual software deployment lifecycle.

Simply put, this was a technology, not a polished product, the barrier to entry for most was too high and the advantages too unclear.

Containers today; supporting players.
The word "Containers" today is as much about the tools that have grown around these technologies, with a focus on user experience, reducing the developer and operations "time to get stuff done".

While CGroups are still used under the covers, most people using containers today don't know that, they don't have to! The tools have focused on making the deployment lifecycle a lot easier.

It is this usability and extra tooling which is driving the recent explosion containers... Which we'll cover next!


https://learninglabs.cisco.com/modules/dnc-2017-cloud-native-docker/docker-101/step/1