Docker Meetup Edinburgh

My personal notes ...

Monday, October 22, 2018

Monday evening, right after the first full-day of the OpenSource Summit Europe in Edinburgh a Docker Meetup!

Container Runtimes, draw some lines

Vincent Batts, Red Hat @vbatts,


Container Runtimes, a history

chroot + unshare (mnt ns) + cgroups




  • all the things
  • 2013 python script became golang
  • (not a single good link to the source)


  • 2013
  • academic offering
  • dead, but still a good example of form over function


  • Dec 2014
  • spec-first design (appC spec)


  • from odis/openVZ folks
  • C library of container helpers (not docker or lxc related)

libcontainer (now runc)

  • 2014
  • to have something golang native, rather than shell-out to lxc (eventually meant more shelling-out)
  • the original OCI runtime


  • 2014
  • container manager built on lxc
  • (came after Docker made asks of lxc, then abandoned it for libcontainer)

OCI Specification

Container Runtime Interface


  • 2014
  • was (is?) entirely too docker-centric
  • with rkt it was clear there were big changes needed
  • Enter CRI (2016)
  • gRPC interface for ImageService and RuntimeService

Image 2016-12-19 at 17.13.16.png

migration via dockershim

  • completely switched to docker via CRI in v1.8

cri-o (originally oci-d)

  • kubernetes only use-case
  • OCI images and runtime
  • primarily called runc, but is flexible to call other runtimes


  • primarily docker use-case, but includes a CRI shim - OCI and Docker images


  • swiss arm knife of sorts
  • uses kvm pieces
  • supports 2.6.32+ kernel
  • imports from runc, docker, p2p backend, and expose a CRI socket


  • crictl
  • the cli for working or debugging directly with CRI layer

OCI Runtimes


  • 2014
  • to have something golang native, rather than shell-out to lxc
  • (eventually meant more shelling-out)
  • the original OCI runtime


  • 2017
  • an OCI runtime
  • written in rust

kata-containers (formerly clear containers and hyperV)

  • mixed years
  • an OCI runtime
  • thinVM (qemu with custom machine type)

nabla-containers (IBM research)

  • has an OCI runtime
  • unikernel approach
  • requires tailored container images with their executor

nvidia fork of runc

  • inherently an OCI runtime
  • exposes GPU specific configuration

google/gvisor (runsc)

  • has an OCI runtime
  • syscall emulation layer
  • uses a bit of kvm
  • feels a bit like thrown over the wall

windows/hcsshim (runhcs)

  • has an OCI runtime
  • windows native container API


  • thin OCI runtime written in C


  • OCI runtime wrapper around bubblewrap


  • OCI runtime wrapper around systemd-nspawn


  • OCI pet project of community member

systemd-nspawn native support (pr9762)

  • preferable than wrapper
  • still has a couple of pieces missing like hooks and compatible cli

Non-Docker options


  • utility for working with OCI container images
  • unpack, modify, repack


  • initially just remote inspect images
  • now copies (local <=> remote) and translates formats


  • drop-in for docker build, as well as shell subcommands
  • direct invocation
  • now supports non-root builds


  • easy alias for docker
  • direct invocation
  • now supports non-root


OpenFaaS with Istio

Stefan Prodans, OpenFaas team VMware

Stefan Prodans guide to Istio + OpenFaas

Istio service mesh guides

Istio: Greek for sail

What the hell does serverless mean?

Aaron Edell, article on Hackernoon

Serverless Framework for Processes Projects and scale

Serverless computing is most likely going to be the infrastructure ROI king of 2018. It would be wise for any business looking to scale to take a hard look at it. So… what the hell is serverless computing?

How can you not have servers?

How can you not have servers?

It seems a bit counter-intuitive to think that the future of cloud computing and scale is a concept that sounds like philosophical bullshit. “Who needs servers, man…?” But its actually quite serious. Let’s clear the air on the most irritating aspect of serverless; serverless computing still requires servers, so the name is totally misleading. The difference between traditional cloud computing and serverless is that you, the customer who requires the computing, doesn’t pay for underutilized resources. Instead of spinning up a server in AWS for example, you’re just spinning up some code execution time. The serverless computing service takes your functions as input, performs logic, returns your output, and then shuts down. You are only billed for the resources used during the execution of those functions. Function as a Service (FaaS) Platforms

Serverless computing should really be called function-as-a-service platform. If you’ve heard about AWS Lambda or Google Cloud Function, then you’ve heard about FaaS. The benefits of these platforms is that developers don’t have to think about multi-threading or load-balancing. They can just focus on their code. They trust the FaaS to handle all the resource management for them. It also turns out to be a lot cheaper than being billed for a fixed quantity of servers. There are some downsides to using FaaS from cloud companies as well. For one, they will spin down your runtime environments if you’re not using it a lot. Paradoxically, they also limit the total amount of resources available to you, introducing latency and problems with high-performance. Monitoring, debugging, and security are also tricky with these cloud providers (as they would be with any cloud computing workflow) due to the fact that it…well… runs in a public cloud that you don’t have access to or control of.


Read the rest at Hackernoon

Why I love containderd … and Docker

Phil Estes, @estesp, IBM

Make it boring!

The goal of standardising containers is ultimately,to make them boring - Jonathan Boulle

An ode to boring: Creating Open and Stable Container world - Bob Wise (Medium)

Lets make containers boring - Vincent Bats (Red Hat)

But many platform builders and operators are looking for “boring infrastructure": a basic component that provides the robust primitives for running containers on their systems, bundled in a stable interface, and nothiing else. - Docker Blog, containerd announcement