Linux Containers 101

calcotestudios.com/talks

http://calcotestudios.com/talks

Lee Calcote
November 8th, 2018

from engines to orchestrators

Lee Calcote

linkedin.com/in/leecalcote

@lcalcote

gingergeek.com

lee@calcotestudios.com

clouds, containers, functions, applications, and their management

calcotestudios.com/talks

github.com/leecalcote

What is a Container?

Isolated Operating System Process
Includes Everything The App Needs to Run
Shares Underlying OS Kernel
No translation layer
Inherently Portable
Managed by Docker Engine

Host

Operating System Definition

Application Binaries / Code

Libaries

Why use a Container?

Efficiency
Portability
Security
Choice

@lcalcote

docker version

Dockerfile

Instructions on how to build a Docker image
Looks very similar to “native” commands
Important to optimize your Dockerfile

@lcalcote

Linux container example

Images are pushed and pulled from registries
Registries can be SaaS / public or on-prem
Tags can be applied to images to denote versions
Effective Dockerfiles are extremely important

@lcalcote

docker images

Managing Images

Stored in registries

Stateless

Immutable

Run a Container

Single task:

$ docker container run alpine hostname

Background:

$ docker container run --detach alpine top

Interactive:

$ docker container run --interactive --ttyalpine bash

Logs:

$ docker logs <container>

@lcalcote

introductory examples

Ad-hoc exec:

$ docker exec <container> <command>

Container Network Model

Local Drivers

Docker Runtime

Bridge

Container Network Model (libnetwork)

Remote Drivers

None

Overlay

Third-party

MACvlan

@lcalcote

Container Network Model
object model

Network Sandbox

Endpoint

Network

Container

Network Sandbox

Endpoint

Container

Network Sandbox

Endpoint

Container

Endpoint

Network

Docker Engine

Network Driver

IPAM Driver

Microsegmentation - traffic is not relayed

@lcalcote

Types of Container Networking

None
Links and Ambassadors
Container-mapped
Bridge
Overlay

Underlay
- Host
- MACvlan
- IPvlan
- Direct Routing
- Point-to-Point
- Fan Networking

network namespace ≈ VRF

veth ≈ always come in pairs

@lcalcote

A host can only expose a given port once
Some uses cases require the same port multiple times
Docker uses port mapping to achieve this

@lcalcote

docker container run -d -p 80 nginx

Ports

docker container inspect

None

container receives a network stack, but lacks an external network interface.

it does, however, receive a loopback interface.

good ol' l0

eth0

eth1

container

network namespace

Host

l0

loopback 0

host network namespace

docker run -it --net=none alpine ifconfig
docker network ls
docker network inspect bridge

@lcalcote

Bridge

default networking for Docker
uses a host-internal network
leverages iptables for network address translation (NAT) and port-mapping

Ah, yes, docker0

bridge

eth0

eth1

container

Host

@lcalcote

docker network inspect bridge

Workshop Labs

github.com/leecalcote/containers-101

Types of Containers

the thick and thin of them

System Containers

Like a VM
Full OS image
Multiple processes

Application Containers

Single process

Use namespaces to deal with resource isolation for a single process.
Use cgroups to manage resources for a group of processes.

Similarities:

@lcalcote

no bigotry here

rkt
docker
runC
kurma

---

containerd
systemd

OpenVZ
Solaris Zones
BSD jails
Linux-VServer
AIX WPARs
LXC

----

LXD
CGManager
machinectl

----

qemu-kvm, lkvm

System Container Engines

Application Container Engines

@lcalcote

no bigotry here

Container Specifications

Implemented by -

rkt is the canonical implementation
Kurma leverages runC
Jetpack is an implementation of for FreeBSD using jails and ZFS

Implemented by -

runC is the reference implementation
runV is a hypervisor-based runtime
cc-oci-runtime launches an Intel VT-x secured Clear Containers 2.0 hypervisor

@lcalcote

Runtimes

runtime-spec
- a specification for the lifecycle of a running container
runtime-tools
- tooling for the runtime

image-spec
- a software shipping container image format spec with security and naming as components
image-tools
- tooling for the image

@lcalcote

https://opencontainers.org

Get your engines started.

and get started with your engines

Popular Engine
process models

rkt executes as CLI; no daemon
Can run Docker Images and also App Container Images (ACIs)
Security has been a focal concern
uses HTTPS to locate and download remote ACIs and their attached signatures

Docker Engine runs a daemon
the defacto standard

rkt

@lcalcote

Text

Popular Engine
process models

rkt

systemd

$ rkt run postgres

application

systemd

$ docker run postgres

application

containerd

runC

@lcalcote

Docker Engine daemon

Definition:

[ awr -k uh -streyt -or]

[k uh n- tey-ner]

Core
Capabilities

Cluster Management
- Host Discovery
- Host Health Monitoring
Scheduling
Orchestrator Updates and Host Maintenance
Service Discovery
Networking and Load-Balancing

Additional
Key Capabilities

Application Health Monitoring
Application Deployments
Application Performance Monitoring

minimal capabilities required to qualify as a container orchestrator

@lcalcote

One size does not fit all.

A strict apples-to-apples comparison is inappropriate and not the objective, hence characterizing and contrasting.

@lcalcote

Kubernetes

kubectl

...and so does pronunciation.

@lcalcote

#netiquettematters

Genesis & Purpose

an opinionated framework for building distributed systems
- or as its tagline states "an open source system for automating deployment, scaling, and operations of applications."
Written in Golang, Kubernetes is lightweight, modular and extensible
considered a third generation container orchestrator led by Google, Red Hat and others.
- bakes in load-balancing, scale, volumes, deployments, secret management and cross-cluster federated services among other features.
Declaratively, opinionated with many key features included

crowned the winning horse

@lcalcote

Docker Swarm

Genesis & Purpose

Swarm is simple and easy to setup.
Swarm is responsible for the clustering and scheduling aspects of orchestration.
Originally an imperative system, now declarative
Swarm’s architecture is not complex as those of Kubernetes and Mesos
Written in Golang, Swarm is lightweight, modular and extensible

the easiest horse to mount

@lcalcote

Nomad

Genesis & Purpose

designed for both long-lived services and short-lived batch processing workloads.
cluster manager with declarative job specifications.
ensures constraints are satisfied and resource utilization is optimized by efficient task packing.
supports all major operating systems and virtualized, containerized or standalone workloads.
written in Go and under the Unix philosophy.

the nimble horse

@lcalcote

Mesos

+

Marathon

Genesis & Purpose

Mesos is a distributed systems kernel
- stitches together many different machines into a logical computer
Mesos has been around the longest (launched in 2009)
- and is arguably the most stable, with highest (proven) scale currently
Mesos is written in C++
- with Java, Python and C++ APIs
Marathon as a Framework
- Marathon is one of a number of frameworks (Chronos and Aurora other examples) that may be run on top of Mesos
- Frameworks have a scheduler and executor. Schedulers get resource offers. Executors run tasks.
- Marathon is written in Scala