Are VMs fit for (All) Today’s (Cloud) usages?

• Performance overhead of indirections (guest OS and hypervisor)
• Large memory footprint
• Slow startup time
• License and maintenance cost of guest OS

• Do we really need to virtualize hardware and a full OS?
• What about DevOps?

Why does it work? Separation of concerns

Why people care?

Developers: Build once… run anywhere (dependencies, packages, versions, automation, w/o overhead like VMs)
Administrators: Configure once… run anything (lifecycle efficiency, remove inconsistencies, segregation of duties, addresses the cost of VMs)

Linux Containers

• Run everywhere
  • Regardless of kernel version
  • Regardless of host distro
  • Physical or virtual, cloud or not
  • Container and host architecture must match…
• Run anything
  • If it can run on the host, it can run in the container
  • If it can on a Linux kernel, it can run

At High-Level: It looks like a VM
At Low-Level: OS-Level Virtualization

Using Namespaces to separate “Views” of Users

• Namespace: naming domain for various resources
  • User IDs (UIDs)
  • Process IDs (PIDs)
  • File paths (mnt)
  • Network sockets
  • Pipe names
• Namespaces are isolated by kernel

Isolating resources with cgroups

• Linux Control Groups (cgroups): collection of Linux processes
  • Limits resource usages at group level (e.g., memory, CPU, device)
  • Fair sharing of resources
  • Track resource utilization (e.g., could be used for billing/management)
  • Control processes (e.g., pause/resume, checkpoint/restore)

Efficiency: almost no overhead

• Processes are isolated, but run straight on the host
• CPU performance = native performance
• Memory performance = a few % shaved off for (optional) accounting
• Network performance = small overhead; can be optimized to zero overhead

Docker

• Docker Inc
  • Founded as dotCloud, Inc. in 2010 by Solomon Hykes (renamed to Docker Inc. in 2013)
  • Estimated to be valued at over $1 billion (101-250 employees)
• Docker the software
  • A container engine written in Go (based on linux container)
• Docker community
  • Now 1851 contributors, 16.2k forks of docker engine on GitHub (called Moby)

Why are Docker Containers Lightweight?

Docker Engine

• daemon: Rest API (receiving instructions) and other features
• containerd: Execution logic (e.g., start, stop, pause, unpause, delete containers)
• runc: A lightweight runtime CLI

Docker Images

• Not a VHD, not a file system
• uses a Union File System
• a read-only Layer
• do not have state
• Basically a tar file
• Has hierarchy (arbitrary depth)

Docker Image Registry

• Registry containing docker images
  • Local registry on the same host
  • Docker Hub Registry: Globally shared
  • Private registry on docker.com

Docker Swarm

• Docker Swarm: A group of nodes collaborating over a network
• Two modes for Docker hosts
  • Single Engine Mode: Not participating in a Swarm
  • Swarm Mode: Participating in a Swarm
• Each swarm has a few managers (one being leader) that dispatch tasks to workers. Managers are also workers (i.e., execute tasks)

Security Implications of Containers

• Unlike VMs whose interface is hardware instructions, containers’ interface is OS system calls
• More difficult to protect syscalls
  • Involve large amount of code in the OS
  • And there are many syscalls

Reference

Container & Docker: https://tech.osci.kr/docker/2018/09/10/45749387/