Containerized Chaos

Applying Chaos Principles to Docker Containers


Chaos Engineering Meetup Hamburg · July 12th, 2016

Thilo-Alexander Ginkel · TG Byte Software GmbH
@thiloginkel · [email protected] ·

About /me

About /me

  • Thilo-Alexander Ginkel

  • Freelance Software Engineer, Trainer and Consultant

  • Full-stack software engineer, but I especially like

    • Backend development

    • DevOps including Docker, Ansible, Puppet

  • <advertisement>Available for contract work</advertisement>










  • Who is using Docker?

  • In Production?

  • Who is applying Chaos Engineering principles?

  • In Production?



  • Docker Introduction

  • Chaos Engineering Recap

  • Pumba: Containerized Chaos

  • Demo

  • Q&A



  • Container-based virtualization

now what finding nemo

Docker Container vs. VM


  • Hardware-based virtualization

  • OS-agnostic, i.e., most OSes are supported as guest

  • VM typically hosts a full-blown operating system

Docker Container

  • Technically, a mash-up of existing tech + a few novel parts

  • Containers share the host’s Linux kernel, i.e., no hypervisor

  • Mashup of existing technologies

    • Linux Kernel namespaces (isolation)

    • cgroups ("control groups"; resource isolation)

    • chroot (file system isolation)

    • UnionFS (file system overlay)

    • networking (iptables, bridge networks)

  • Plus a novel application packaging format (standardized by OCI)

Docker Container vs. VM

vm vs container



  • Image

    • Frozen file system snapshot

    • (Fine print: Immutable layered set of file system changes on top of a base image)

  • Container

    • A running instance of an image

    • Note: There can be many instances of the same image






  • "Build once, run anywhere"

  • Containers…​

    • …​consist of just what’s needed to run a given service

    • …​are short-lived

    • …​should be state-less

  • Immutable infrastructure / "cow vs. cattle"

  • State is kept in volumes

Docker Hands-On

Chaos Engineering

Chaos Engineering

  • Inject failures into (production) systems to continuously challenge resilient system design

  • Chaos Monkey: Randomly kills AWS instances (VMs)

  • But what about Docker containers?

    • Single host instance potentially hosts dozens of containers

    • But: Single containers can also fail on their own

    • (Ideally) being stateless: Perfect victims for chaos experiments

    • Can we simulate single container failures?

    • Of course! :-)

Pumba: Containerized Chaos

Pumba: Containerized Chaos

  • Who is Pumba(a)?

    • A character (warthog) from the Lion King ;-)

    • Name derived from Swahili: "to be foolish, silly, weakminded, careless, negligent" (Source: Wikipedia)

Pumba: Containerized Chaos

  • What is Pumba?

    • A chaos testing tool for docker containers

    • Open source on GitHub:

    • Monitors containers on a docker host and periodically {terminates|kills|removes} a victim

    • Optionally reports to Slack

    • Shipped as a Docker image

Pumba: Containerized Chaos

Demo Time



  • A Dockerized environment provides the perfect foundation for running Chaos Experiments

  • Pumba can be a valuable addition to existing chaos testing tools (such as Chaos Monkey) for inducing single container failures throughout the system landscape


Thank you!

Image Credits