WHAT’S THE DIFFERENCEBetween a VM and a Container?

2

Welcome to “What’s the Difference between a VM and a Container”

ONE SIMPLE IDEA

3

CHANGED EVERYTHING.

First, I will tell you a story about a simple idea that changed everything.

1873

In 1873, This is what toothpaste looked like.

1896

In 1896 one of the Colgate brothers saw paint in a tube like this, and decided to use it for toothpaste.

WE COULDN'T IMPROVE THE PRODUCT SO WE IMPROVED

THE TUBE.

6

- Colgate, 1908

This was the Colgate sales slogan in 1908.

1962Colgate Research Center

In 1962 Colgate opened the Colgate Research Center.

1978

8

THE LAB ASSISTANT

In 1978 a lab assistant working at the CRC came up with a fabulous idea.

She said that it would double the company’s sales, and it could be done for almost no cost on an immediate basis. She pitched it to the executives to secure a 2% cut for a year if it worked. The idea: Make the hole twice as big.

OMG, SALES DOUBLED!

10

They did it, and as predicted, it quickly doubled Colgate’s sales.

WELL, ACTUALLY…

11

This story would be even more awesome if the lab assistant part of the story was actually true, but it’s just urban legend. The story illustrates one thing very clearly: seemingly simple ideas can have a huge impact.

1) PRESSURE BUILT UP IN A FINITE BOUNDED SYSTEM NEEDS TO BE RELEASED SOMEWHERE OR THE SYSTEM WILL BREAK. 2) THERE ARE DIMINISHING RETURNS TO SQUEEZING THE TUBE AFTER A CERTAIN POINT.

TOOTHPASTE TUBE THEORY

Here is something that is actually true.

IMAGE PLACEHOLDER 1920 X1080

IDEA13

Recently, there was a technical innovation that changed the game for containers the way the toothpaste story went. I will detail this idea for you in a moment.

ADRIAN OTTO

14

Distinguished Architect, Rackspace Founder, OpenStack Containers Team Founder and PTL, OpenStack Magnum Organizer, Docker Los Angeles

Hi!

THE DIFFERENCE

15

1

2

3

EFFICIENCY

PERFORMANCE

SECURITY

These are the three key points of differentiation between virtual machines and containers.

16

HISTORY OF VIRTUALIZATION• 1960’s IBM S/360 Mainframes are the 800# Gorilla

• Single user system designed for batch jobs • 1963 MIT Project MAC ($2M grant from DARPA)

• Vendor Choice == GE (Commercial interest in time sharing computer) • Whoops! IBM panicked! Created CP-40 for Bell Labs, CP-67.

• Virtual Machines on the CP-67 using “CP (Control Program)” in 1967! • 1987 Insignia Solutions “SoftPC” • 1997 Apple (Connectrix) “VirtualPC” • 1999 VMWare “VMWare Workstation”

Virtual Machines have commercially existed since the IBM CP-67 in 1967.

17

APPLICATION VIRTUALIZATION• 1990 Sun Microsystems “Stealth” • Address C/C++ Portability problems • Renamed Oak -> Webrunner -> Java (1995)

• 1996 Sun Microsystems “Java” • Java Development Kit (JDK) • Java Runtime Environment (JRE) • Java Virtual Machine (JVM)

Sun attempted to answer code portability using Java starting in 1990.

18

OPEN SOURCE VIRTUALIZATION• 1999 VMWare “VMWare Workstation”

• Commercial License • 2003 Xensource

• Open Source • 2007 Citrix acquired Xensource

• Renamed Xensource to Xenserver • 2007 Oracle VirtualBox

• VirtualBox Open Source Edition (OSE) • 2007 Linux KVM, Kernel 2.6.20

Commercially supported open source virtualization for workstations hit the mainstream in 1999, and for servers since 2003.

19

HISTORY OF CONTAINERS (1/2)• 1979 UNIX chroot (added to BSD in 1982) • 2000 FreeBSD Jails (filesystems, users, networks) • 2001 Linux VServer (VPS Solution) • 2005 OpenVZ (filesystems, users/groups, process tree, networks, devices, IPC) • 2006 Process Containers (Linux Kernel 2.6.24, limit CPU, mem, disk, network IO) • 2008 Control Groups (cgroups added to Linux Kernel) • 2008 LXC (LinuX Containers, CLI and language bindings for 6 languages) • 2011 Warden, CloudFoundry • 2013 LMCTFY, Google

Namespace concepts like chroot have been around since 1979.

20

HISTORY OF CONTAINERS (2/2)

• 2013 Docker, DotCloud -> Docker Inc. • 2014 Rocket, CoreOS • 2016 Windows Containers, Microsoft

In 2013 containers caught fire, and hit the mainstream by 2015.

21

EVERYTHING CHANGED IN 2013

2013DOCKER IMAGE

The concept of the Docker Image is the innovation that started to make containers something really compelling, and caused it to become popular.

22

Docker is an open source project sponsored by Docker, Inc. Docker Engine is how Docker Inc. refers to the open source software called “Docker”.

23

• Kernel Feature • Groups of processes • Control resource allocations

• CPU • Memory • Disk • I/O

• May be nested

LINUX CGROUPS

Cgroups control the level of utilization processes on a host can consume. Containers are placed within a Cgroup.

24

• Kernel Feature • Restrict your view of the system • Mounts (CLONE_NEWNS) • UTS (CLONE_NEWUTS)

• uname() output • IPC (CLONE_NEWIPC) • PID (CLONE_NEWPID) • Networks (CLONE_NEWNET) • User (CLONE_NEWUSER)

• See also: privileged/unprivileged modes • May be nested

LINUX KERNEL NAMESPACES

Kernel Namespaces restrict access of processes to a limited view of the system defined at the time CLONE_* syscalls are used.

25

• NOT A FILESYSTEM • NOT A VHD • Basically a tar file • Has a hierarchy • Arbitrary depth • Layered filesystem

• Top layer can be writable • Fits into the Docker Registry

DOCKER CONTAINER IMAGE

Base Image

Child Image

Grandchild Image

Forget everything you think you know about images, because container images are totally different. The concept of layering allows for amazing speed benefits that allow containers to start in a fraction of the time of VMs.

26

• Git Repo Semantics • Pull • Push • Commit

• Hierarchy

DOCKER REGISTRY

Base Image

Child Image

Grandchild Image

The Docker Registry is a hosted service provided by Docker, Inc. that allows you to save and share your docker images.

27

• Combines several things • Linux Cgroups • Kernel Namespaces • Docker Image • Has a lifecycle

CONTAINER

CGROUPS NAMESPACES IMAGE DOCKER CONTAINER+ + =

A container is an amalgam of concepts.

28

• Like a Makefile (shell script with keywords) • Extends from a Base Image • Results in a new Docker Image • Imperative, not Declarative

DOCKERFILE

DOCKERFILE BASE IMAGE DOCKER CONTAINER+ =

A Dockerfile is used to create a container image, and contains all the instructions needed to build one.

29

FROM centos:centos6 MAINTAINER Adrian Otto <aotto@aotto.com> RUN yum -y install httpd EXPOSE 80 ADD start.sh /start.sh CMD /start.sh

DOCKERFILE EXAMPLE

$ docker build -t webserver .

This is how to build a simple web server container that contains only a few megabytes of data in the image itself, just the changes on disk for the “yum install httpd” plus some metadata about the container.

30

FROM webserver MAINTAINER Adrian Otto <aotto@aotto.com> RUN yum -y install mysql-server php EXPOSE 80 ADD start.sh /start.sh CMD /start.sh

DOCKERFILE EXAMPLE

$ docker build -t lampstack .

This is how to base a container image on an existing one. I create a LAMP stack container image here based on my webserver image.

30

FROM webserver MAINTAINER Adrian Otto <aotto@aotto.com> RUN yum -y install mysql-server php EXPOSE 80 ADD start.sh /start.sh CMD /start.sh

DOCKERFILE EXAMPLE

$ docker build -t lampstack .

This is how to base a container image on an existing one. I create a LAMP stack container image here based on my webserver image.

THE DIFFERENCE

31

1

2

3

EFFICIENCY

PERFORMANCE

SECURITY

Remember, these are the three key differentiators between virtual machines, and containers.

32

THE DIFFERENCE

1 EFFICIENCY

Containers have a lower memory overhead, and require less storage on disk, because all apps share the same kernel, even if they use different operating system distros.

33

THE DIFFERENCE

2 PERFORMANCE

Apps running on bare metal on a host execute faster because there is no visualization in the execution path of a process once is has started. With VM’s there are multiple sets of context switches for each interaction with the hardware.

33

THE DIFFERENCE

2 PERFORMANCE

Apps running on bare metal on a host execute faster because there is no visualization in the execution path of a process once is has started. With VM’s there are multiple sets of context switches for each interaction with the hardware.

33

THE DIFFERENCE

2 PERFORMANCE

Apps running on bare metal on a host execute faster because there is no visualization in the execution path of a process once is has started. With VM’s there are multiple sets of context switches for each interaction with the hardware.

34

THE DIFFERENCE

3 SECURITY

The attack surface area between neighboring containers on the same host is considerably larger than the attack surface area between neighboring VMs.

IMAGE PLACEHOLDER 1920 X1080

35

Constructed 1672-1695 (23 years). Imagine how many soldiers it would take to successfully defend this fortress.

IMAGE PLACEHOLDER 1920 X1080

CASTILLO DE SAN MARCOS35

Constructed 1672-1695 (23 years). Imagine how many soldiers it would take to successfully defend this fortress.

IMAGE PLACEHOLDER 1920 X1080

36

Try protecting 80 fortresses, and if one of them is breached, they all fall. Totally different class of problem.

37

VIRTUALIZATION MAPPINGS

Physical Virtual

System Partition

Logical Processor Virtual Processor

Advanced Programmable Interrupt Controller (APIC) Virtual APIC + Synthetic Interrupt Controller (SynIC)

Physical Address = System mPhysical Address (SPA) Guest Physical Address (GPA)

Narrow attack surface area between virtual machines.

38

LINUX SYSCALL INTERFACE

Much wider attack surface area between neighboring containers.

38

LINUX SYSCALL INTERFACE

397 CALLS IN KERNEL 3.19

Much wider attack surface area between neighboring containers.

39

THE DIFFERENCE

3 SECURITY

Think of container security isolation like fences, where VM isolation is more like walls.

39

THE DIFFERENCE

3 SECURITY

Think of container security isolation like fences, where VM isolation is more like walls.

39

THE DIFFERENCE

3 SECURITY

Think of container security isolation like fences, where VM isolation is more like walls.

40

CONTAINTER ISOLATION TECHNIQUES

What’s special about this key? It’s a sweeping vulnerability present in the common door locks. There are other lock designs that are not vulnerable, but they cost more. There are ways to make neighboring containers isolated near the level of VMs, but they don’t all produce an environment were all software can run without modification.

40

CONTAINTER ISOLATION TECHNIQUES

What’s special about this key? It’s a sweeping vulnerability present in the common door locks. There are other lock designs that are not vulnerable, but they cost more. There are ways to make neighboring containers isolated near the level of VMs, but they don’t all produce an environment were all software can run without modification.

40

CONTAINTER ISOLATION TECHNIQUES

What’s special about this key? It’s a sweeping vulnerability present in the common door locks. There are other lock designs that are not vulnerable, but they cost more. There are ways to make neighboring containers isolated near the level of VMs, but they don’t all produce an environment were all software can run without modification.

40

CONTAINTER ISOLATION TECHNIQUES• SELinux / AppArmor • Secure Computing Mode (seccomp) • Container Nesting • Docker Auth Plugins • User Namespaces • Encrypted Filesystems • Address Space Layout Randomization (ASLR) • Hardware Security Features (NX, VT-d, TPM, TXT, SMAP)

What’s special about this key? It’s a sweeping vulnerability present in the common door locks. There are other lock designs that are not vulnerable, but they cost more. There are ways to make neighboring containers isolated near the level of VMs, but they don’t all produce an environment were all software can run without modification.

THE DIFFERENCE

41

1

2

3

EFFICIENCY

PERFORMANCE

SECURITY

In review, these are the three key points of differentiation between VM and Container technology. If performance and efficiency are your primary concerns, then containers make sense. If you want the benefit of containers with the security of VM’s then combine them, or match them with additional security techniques that provide enough fortification to prevent breakouts.

Copyright © 2016 Rackspace | Rackspace® Fanatical Support® and other Rackspace marks are either registered service marks or service marks of Rackspce US, Inc. in the United States and other countries. Features, benefits and pricing presented depend on system configuration and are subject to change without notice. Rackspace disclaims any representation, warranty or other legal commitment regarding its services except for those expressly

stated in a Rackspace services agreement. All other trademarks, service marks, images, products and brands remain the sole property of their respective holders and do not imply endorsement or sponsorship.

ONE FANATICAL PLACE | SAN ANTONIO, TX 78218US SALES: 1-800-961-2888 | US SUPPORT: 1-800-961-4454 | WWW.RACKSPACE.COM

42