Docker Registry API to be standardized in OCI

When Docker was first released, the team quickly put together a protocol and implementation of the

When Docker was first released, the team quickly put together a protocol and implementation of the  and the magic truly began. An  provides a common service to store images across machines. It is what allows one to build an image on one machine, then pull down that same image and run it on others. One now had the power to pull down an entire software distribution and run it at the drop of a finger tip. This implementation powers the Docker Hub and eventually was open sourced as . This protocol and the implementation behind it Pushing and pulling images continued throughout the ages but, as users began to use Docker with other registries, issues with the V1 protocol arised. The central theme of the problems was around the concept of shared identity across registries and the tight coupling with the Docker implementation. The problem was that if a single  pulls images from two separate registries, they may disagree on which image has which identifier. Something needed to change to ensure using multiple registries wouldn’t lead to problems for users. Towards the end of 2014, Docker began addressing these problems with the introduction of    with the initial API structure. Key to this design was  images, which allowed registries to have common identifiers for images, and the decoupling of internal details of the image format from the Docker Engine, allowing it to evolve on its own. The community came together and produced 140 comments on that proposal that were incorporated into the specification and implementation. The result of this effort was the release of Docker Registry 2.0 with GA support in Docker 1.6 in the spring of 2015. Since then, the Docker community has evolved As a result of the popularity of Docker, this protocol has become widely adopted across the industry. It is battle tested in a wide variety of environments. The protocol integrates well with complementary technologies such as signing and verification, as is available in . By  to the OCI, we can ensure that this important part of the container experience becomes an official OCI standard. The  previously introduced the  and  used by container runtimes. With the acceptance of the  proposal, the protocol that has been a key part of using containers will flourish as part of OCI.