Docker Ecosystem Rosetta Stones

Navigating the Docker ecosystem can be confusing at the best of times.

I’ve been involved in numerous conversations where people have confused Indexes, Registries, Commits, diffs, pushes, Pods, Containers, Images… the list goes on.

I’ve put together these references to try and help with these confusions. Please get in touch if anything seems amiss, or you have any suggestions for improvements.

Reference is kept here.


Container A running instance of a Docker image
Image A tagged history of layers make up an image
Layer A set of file-level diffs. See diff
Privileged Containers are privileged if they run with full root powers. Normally, root within the container has a reduced set of capabilities
Registry A registry is a hosted service containing repositories of images, which responds to the Docker registry API
Swarm Docker Swarm is a clustered set of Docker nodes connected and managed by a Swarm manager running on each node

Docker vs Git

Docker Git
Blob Most often seen in the context of registries (API version 2) where the objects managed by the registry are stored in binary objects The git index points to blobs that refer to content making up the repository’s history
Commit Takes the differences in the container you reference to the last image, and creates a new layer. The added layer and all previous layers constitutes a new image Takes the changes in your index and stores them in your local repository with a message
Diff Gives you the files added, updated, or deleted in a layer Gives a line-by-line diff of files between two revisions in the git repository’s history
History The layers that make up an image (in order) constitute an image’s history The ordered previous revisions in a repository
Hub DockerHub is an index of images and Dockerfiles managed by GitHub is a popular central point of reference for software projects that use git
Index Apparently deprecated term for a registry A binary file in a git repository that stores references to all the blobs that make up a repository
Pull Images are pulled from registries to your local host Get a set of commits and apply them to your local repository
Push Committed and tagged images can be pushed to registries Commits can be pushed to remote repositories
Repository A collection of images distinguished by tag, eg A git project, ie the folder you might pull from a git remote
Remote N/A, though if someone uses this term, they probably mean registry A repository stored in another location, eg on GitHub or
Revision N/A See commit
Tag Tags are applied to repositories to distinguish different images, eg is a different image from, but both are in the same repository A reference to a git repository in a particular state


Endpoint IP and port that accepts TCP or UDP flows
Kube-proxy Receives information about changes to services and endpoints
Kubelet See Replication Controller
Replication Controller Container supervisor. One of these runs on each host, ensuring the correct pods are running and in the appropriate number
Controller Manager Orchestrates replication controllers
Pod A grouping of containers that run on one host, and share volumes and a network stack (ie including IP and ports). Pods can run as one-offs, while long-running services should be spun up by replication controllers
Service An abstracted endpoint for a set of pods or other endpoint


Build Controller Component that manages the building of Docker images ready for deployment
Deployment Controller Component that manages the deployment of Docker images to pods on nodes in the cluster
Image Stream A set references to other images (and/or image streams). This provides a virtual view of related images, which allow operational control of events when any of the referenced image (and/or image streams) are changed. These events might trigger a rebuild or redeployment of a build.
Route A DNS-resolveable endpoint that maps to an ip address and port
Image Stream Tag Image Streams can be tagged in a similar way to Docker image tags


Docker vs Kubernetes vs OpenShift

Docker Kubernetes OpenShift
Cluster A cluster is a set of Nodes that run Docker Swarm  A Kubernetes Cluster is a set of master nodes and minions An OpenShift Cluster is a set of OpenShift ‘master nodes’ plus a set of OpenShift nodes
Label Name value pair applied to an object, eg an image or container Name value pair applied to an object, eg pod or node Name value pair applied to an object, eg route
Master The Swarm Node acting as the elected master The node or nodes that act as the cluster master, keeping track of centralised information using etcd nodes The node or nodes that act as the cluster master, keeping track of centralised information using etcd nodes
Minion N/A Node on which Pods can be run Rarely used, but would correspond to an OpenShift Node
Namespace Kernel facility to allocate an isolated instance of a global resource, eg filesystem or network. Docker is partly a product that orchestrates these isolated components in a consumable way Isolated sets of resources for management purposes Isolated sets of resources for management purposes
Node A host within a Swarm cluster A host within a Kubernetes cluster A host within an OpenShift cluster
Project N/A N/A Extension of Kubernetes’ namespace concept with the addition of RBAC etc.
Service Stable endpoint that forwards requests to (transient) containers Stable endpoint that forwards requests to (transient) pods Stable endpoint that forwards requests to (transient) pods
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Docker Ecosystem Rosetta Stones

  1. Pingback: Docker ecosystem Rosetta Stones | 0ddn1x: tricks with *nix

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s