Docker Registry Design

First a little background; Docker is an open source platform designed to make applications ship in small footprint containers which are easy to maintain.  The idea is to speed up the development lifecycle and go to production more rapidly.  Docker helps to abstract the application from the underlying system environment.  This approach also makes it easier to build application images which can run anywhere.

The images need to be stored for use before execution somewhere, though.  That is where a Docker Registry comes in.  The registry is analogous to code source control (i.e. subversion or git).  Since we have three major environments (development, QA and production) we have a docker registry for each environment.

Now onto the fun part!  They say a picture is worth a thousand words.. let’s try:

docker-registry.png

 

There’s 40 words in our picture.  Close enough.. let’s explore this diagram in more detail and what led us to this design.

Specifications:

  • Minimizes Single Points of Failure (SPoF)

  • Reliable:  Be realistic that anything can fail at any time.

  • Easily maintainable: Well known technologies and no fancy tricks to slow down troubleshooting or recovery

A Deeper Look:

  • Load balancing and fault recovery from the user to the registry servers is fronted by anycast using ExaBGP.

  • The registry code runs natively, not in a docker container.  That means fewer pieces, fewer things to go wrong and fewer levels of unnecessary abstraction.

  • The Search HA Interface is a classic heartbeat managed virtual IP backed with two MySQL databases which replicate to each other.

  • The storage layer is Gluster with three replicas.

There was skepticism about using the Gluster distributed filesystem, as a storage backend when I raised this issue with my colleagues at meetups and tech talks.  However, we went this route because Gluster is more easily administered, maintainable and recoverable than object storage systems.

We looked into Amazon S3, but didn’t like the transit cost.  It also meant more components could go wrong (S3 itself, Internet connectivity or our border network equipment) and violate the SPoF and reliability specifications.  In practice, our Gluster storage clusters have been running well and within acceptable service level targets.

For companies such as ours where we have knowledge and resources to invest internally, this is a great solution.  It enables us to provide a reliable service to our peers and consumers within our company and ultimately to our customers.

Feel free to submit your questions or comments below regarding Dockery registry and how you can incorporate it on your own.