Docker for OPS.

Find Session:

Batteries included, but swappable.

Docker comes out of the box with many features and tools, but none are locked in and the project is fully open source.

Docker has three extension points.

  • User-Facing APIs
  • Plugins
  • Drivers

Layers

User Facing API

Extending through observation

The workload and effort required is very small. Using simple HTTP/JSON REST API, by default listens on /var/run/docker.sock

The Docker CLI is nothing more than a thin wrapper around a base API. Everything the client does is passed through the dockerd daemon.

Socat API example

Events

  • The /events end point is powerful for automation
  • Gives live external visibility on every interaction

Running docker events will print out everything that happens on the daemon. In real time.

This will not show logs, only what the docker daemon performs in terms of container start/stop and network setup.

You can add functionality to the engine, without modifying the engine. Internally, Docker uses this API to create new features and for testing.

Plugins

Past, present, and future

  • A process external to the Docker engine that extend the functionality of the system.
  • Plugins are available for volumes, networks and authorization subsystems
  • Extend functionality on a single node, or across the entire cluster
  • Introduced in Docker 1.8
  • Plugins use the Docker API through the engine to give individual containers extra functionality

Plugins can be a container, or host process. I.E, running outside of Docker, or inside the Docker engine. Plugins require high availability, needing to be accessible throughout the world to ensure images have their dependencies. Plugins must Define predictable runtime behavior. Plugins that are developed as containers, must have a defied boot order to be available before other containers start.

New Plugins infrastructure

  • Available in the Docker Store
  • Plugins start and stop alongside the Docker engine, before containers are started.
  • New plugin manifest file that defines the plugin specification
  • All plugin management available within the Docker API and CLI (Which are the same).

Sample plugin: tiborvass/no-remove

  • Simple extension of local volume driver
  • Impliments a variation of Remove

Plugin example

Docker plugin install plugin-name  
Docker plugin ls  
Docker plugin disable plugin-name  

Plugins will be stabile supported in Docker 1.13, currently in 1.12 it is experimentationinal

Plugin manifest syntax

Future improvements

In 1.13

  • Swarm deployed plugins
    • Plugins will be deployed across the swarm and managed by the orchestrator
    • Relies on the same plugin infrastructure

Drivers

Execution backend drivers

A whole lot of effort is required to work with drivers.
Open container initiative defined the industry standard interfaces for run times.

Two tools came from the standard

  • runC
    • Tool for running containers according to OCI spec
  • containerd
    • A deamon to control containers running OCI spec

As of Docker 1.11, the Engine relies on containerd and runC to run containers. Behind the Docker Engine, it relies on OCI spec for all containers.

As of Docker 1.12 runC can be replaced by whatever you need. dockerd --add-runtime custom=/bin/my_runtime This can be done globally or per container by passing --runtime to the docker run command.

Platform specific

  • Solaris runZ
  • Different workloads, different performance/security trade offs
    • Intel Clear Containers
    • Hyper_ runV (Hypervisor-based, running as a VM, not sharing anything with host)
  • Anything the community can come up with