Skip to content

Instantly share code, notes, and snippets.

View dmcgowan's full-sized avatar

Derek McGowan dmcgowan

View GitHub Profile

Generic format for registry documents

Why do we need standard registry document formats anyway?

A registry is a data store for content addressed data. At the lowest level it is just a large key (hash) to value (document) store, but one of the things we have learned about data stores is that they are more useful if they allow for structured data (a Merkle tree, technically a dag), with data being allowed to point to (hashes of) other data items. The complexity added by this is that if the data store needs to follow the links in documents it needs to know how to parse them. The primary use case for this parsing is for garbage collection: the usual storage model allows for an object that is not referenced internally or from a tag (a generic name that can be given to items in the store) may be garbage collected. Without this it is difficult to remove any items from the store. Tags exist to give human friendly names and to anchor items into the store while they exist.

Probably the best developed system alo

@mmdriley
mmdriley / registry_api_v1.md
Last active April 15, 2019 14:57
Docker Registry API walkthrough

Docker Registry API V1 walkthrough

Matthew Riley (mattdr@google.com)

This document summarizes the interactions between the Docker client and the Docker Hub during push and pull commands through version 1 of the registry API. It was compiled to aid in writing a compatible registry server implementation after the existing API documentation proved occasionally incomplete or inaccurate.

Behavior and code links were as of Docker v1.2.0.

docker {push|pull} H:P/R[:T]
Host, Port, Repository ([namespace/]image), Tag