remove registry docs

[dvdksn]

This removes the documentation for registry (a CNCF project) from docs.docker.com and adds corresponding redirects to the distribution/distribution GitHub, e.g. https://deploy-preview-15888--docsdocker.netlify.app/registry/deploying/

Do not merge: awaiting confirmation on Docker Hub conformance to OCI spec

Todo: use the new _redirects.yml and remove stubs

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	401642c
🔍 Latest deploy log	https://app.netlify.com/sites/docsdocker/deploys/6368fc4385e2770008b79801
😎 Deploy Preview	https://deploy-preview-15888--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[thaJeztah]

Thanks! Changes itself LGTM (pending the discussion if we need to preserve some bits or replace them with something)

[thaJeztah]

So; progressive insight (could use input from @milosgajdos on this);

• The "specs" we refer to in the distribution repository are the specs from before they were used as starting point for the OCI distribution spec.
• While "obsolete", the only place they currently live is in distribution/distribution
• BUT distribution/distribution itself, basically now implements the OCI distribution spec (which superseeds the "docker v2 registry spec"
• AND the OCI distribution spec does not define authentication (nor search/indexing).

As a result, various projects refer to docs.docker.com as canonical location for the specs, e.g. https://github.com/containerd/containerd/blob/72177ca663a2b63c6d9c87a7d6e2e8d5a32ad446/remotes/docker/authorizer.go#L276

Question is; will distribution/distribution continue to maintain the docs for an obsolete spec that they no longer implement?
(Perhaps they do for the authentication part? Not sure about the "distribution" / "registry part"

And if not, then where should those docs live (if Docker Hub implements them)? (Basically, who "owns" the Auth spec?)

[milosgajdos]

And if not, then where should those docs live (if Docker Hub implements them)? (Basically, who "owns" the Auth spec?)

Auth spec seems to be in a bit of a limbo that has been driving people in the community pretty crazy as demonstrated in both upstream issues and discussions.

I think we need to find a way how to shift the spec to the open -- should CNCF own it as part of the distribution? Or should it be standardised by OCI? I tend to lean towards the latter, but not sure how to go about shifting that responsibility to them

[crazy-max]

Ah forgot I had this branch main...crazy-max:docker.github.io:registry-remote when I was working on the new fetch_remote plugin. Guess it's not necessary anymore 😅

[crazy-max]

 - ./_site/docker-hub/service-accounts/index.html
  *  internally linking to ../registry/recipes/mirror.md, which does not exist (line 211)
     <a href="../registry/recipes/mirror.md">Mirroring Docker Hub</a>

Would need to change: https://github.com/docker/docs/blame/main/docker-hub/service-accounts.md#L54

To - [Mirroring Docker Hub](/registry/recipes/mirror/) I think.

[thaJeztah]

And if not, then where should those docs live (if Docker Hub implements them)? (Basically, who "owns" the Auth spec?)

Auth spec seems to be in a bit of a limbo that has been driving people in the community pretty crazy as demonstrated in both upstream issues and discussions.

Authentication (and "search") were deliberately left out of the specification when the OCI distribution spec was initiated. Some reasons for that;

• because requirements would be very different between implementations (e.g. cloud providers already have their own authentication mechanisms)
• trying to shoehorn those into a single "spec" would be "challenging"
• specifying the distribution spec (API) itself was a higher priority, and we didn't want that to be blocked on Authentication

Which left us with;

• The OCI distribution spec defining the API for the registry itself (implemented by both distribution/distribution and Docker Hub)
• The only "spec" for authentication being the pre-OCI "docker distribution v2 spec" (living in the distribution/distribution repository)
• Various registry implementations using the "docker distribution v2 spec" as a de-facto / reference implementation.

I think we need to find a way how to shift the spec to the open -- should CNCF own it as part of the distribution? Or should it be standardised by OCI? I tend to lean towards the latter, but not sure how to go about shifting that responsibility to them

There was a discussion during KubeCon where people wanted to add authentication to the OCI spec. There was still debate about "to what extend", so one option was to document "known implementations" (not a strict requirement).

I think in the meantime we can;

• Pull in the (auth related) docs from distribution/distribution, as it's the current 'defacto' spec(ish)
• If we do, we should probably limit it to only the parts relevant to Docker Hub registry.
• Alternatively (better?) just add docs specific to Docker Hub's implementation. We can "refer" to the distribution/distribution repository as "this is roughly what's implemented", but more of a FYI.

[dvdksn]

I think in the meantime we can;

• Pull in the (auth related) docs from distribution/distribution, as it's the current 'defacto' spec(ish)

• If we do, we should probably limit it to only the parts relevant to Docker Hub registry.

• Alternatively (better?) just add docs specific to Docker Hub's implementation. We can "refer" to the distribution/distribution repository as "this is roughly what's implemented", but more of a FYI.

The first option is what this PR is currently doing: pulling the auth spec from distribution/distribution upstream. This is no different to how we currently do it (for auth). For the API spec we will just refer to upstream (not Docker Registry V2, but OCI spec). Registry storage drivers were purged completely from our site.

I agree that it would be ideal to have a dedicated description for the Hub implementation of auth, with an external reference for more information. Outside the scope for this PR but we should have a followup for this.

Related, at some point we might want to revisit where we describe the v2 image manifest schema 2. That is ALSO currently in distribution upstream. Works for now 🤷🏻

[dvdksn]

to be revisited