Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What’s the difference/relationship between registry and distribution/registry? #91

Open
x-yuri opened this issue Apr 1, 2019 · 11 comments

Comments

@x-yuri
Copy link

x-yuri commented Apr 1, 2019

I've tried asking on Docker Forums, but nobody seems to know the answer.

distribution/registry's page on DockerHub says:

WARNING: NOT the registry official image!!! What you LIKELY want is docker pull registry

But I can see that registry simply builds distribution/registry image, takes the binary out of it, then builds it again. What’s the deal?

And now that I look at it, there's also docker-library/official-images repository. Okay, one might guess that the development is done in docker/distribution, but the images are released by docker-library/official-images. But then what is docker/distribution-library-image repository for? Can you elaborate on the process by which docker/distribution becomes a package?

@tianon
Copy link
Contributor

tianon commented Apr 2, 2019

distribution/registry is likely a Docker Hub "Automated Build" of https://github.com/docker/distribution/blob/master/Dockerfile, so you're likely to get the latest and greatest development improvements from master by using that image (assuming it's still actively rebuilding for pushes; last change to GitHub was ~29 days ago, last push was ~3 months ago, so doesn't appear to be actively updating).

https://github.com/docker/distribution is the source repository for the "Docker Open Source Registry".

https://github.com/docker/distribution-library-image is where the packaging of releases of the Open Source Registry happen targeting https://github.com/docker-library/official-images (which is where all top-level unprefixed Docker Hub images are maintained as part of the "Docker Official Images Program"; see https://github.com/docker-library/official-images#what-do-you-mean-by-official).

@Jean-Baptiste-Lasselle
Copy link

Jean-Baptiste-Lasselle commented Aug 23, 2019

then

Hi @x-yuri , here you go with the relation (let's speak machine language, or french, I propose you machine first) : sry update later, I made a mistake, if you already read what I first wrote. I will do some more tests, and will write back here my results.

@Jean-Baptiste-Lasselle
Copy link

Jean-Baptiste-Lasselle commented Aug 23, 2019

Update to @x-yuri , heres how, mainly I run the whole thing, but only modified to add 2 env. variables, to make it all possible 100% offline :

export OPS_HOME=`mktemp -d --tmpdir bootie-dockie.XXXXXX`
export URI_REPO_BUILD_IMAGE_REGISTRY=https://github.com/docker/distribution-library-image
export URI_REPO_CODE_SOURCE_REGISTRY=https://github.com/docker/distribution.git
export BRANCH_NAME_OR_RELEASE_VERSION_TAG
export REGISTRY_V2_DESIRED_RELEASE_VERSION=2.1.7

# Le script update.sh va faire un git clone pour faire un build GOLANG
# mais il ne faut pas installer GOLANG, le build est réalisé dans 
# le conteneur [ID=$(docker create distribution-builder-$GOARCH)]
# You don't have to install GOLANG, because the source code's build is 
# made inside the  [ID=$(docker create distribution-builder-$GOARCH)] container
# see the make command that triggers the go build in the multi stage 
# docker build Defined in the Dockerfile : 
# https://github.com/docker/distribution/blob/master/Dockerfile
# and expecially the [COPY --from] too.
# So all you have to do is to set the GO ENV VARIBLES :+1: 
#  
# il faut simplement définir les variables d'environnement : 
export GOOS=linux 
export GOARH=amd64 

# two env. variables holding the GO VERSION. just for test purposes, not 
# to ever use in production, or merge on any branch 
export VERSION=1.12.9
export GO_VERSION=$VERSION

echo "Right, now that we have the GOLANG environement set here, let's get to build registry from source : "

mkdir $OPS_HOME/buildfromsrc/

git clone "$URI_REPO_BUILD_IMAGE_REGISTRY" $OPS_HOME/buildfromsrc/
cd $OPS_HOME/buildfromsrc/

# et moi j'ai rajouté la variable d'envrionnement 
# export URI_REPO_CODE_SOURCE_REGISTRY, dans le script "update".

# 
# Le Script update.sh va : 
# => faire le [ git clone -b $REGISTRY_V2_DESIRED_RELEASE_VERSION $URI_REPO_CODE_SOURCE_REGISTRY ] , 
# => faire le build from source,
# => puis mettre à jour deux fichiers, dans chacun des répertoires : 
#      + $OPS_HOME/buildfromsrc/amd64 :   
#      + $OPS_HOME/buildfromsrc/arm64
#      + $OPS_HOME/buildfromsrc/arm
# 
#     Ces deux fichiers sont le fichier exécutable, résultat du build GOLANG, et le fichier [./docker-entry-point.sh]
# 



chmod +x ./update.sh
./update.sh

#
# ### Une fois cette mise à  jour des fichiers de contexte de build docker terminée
# 
#     il ne reste plus qu'à aller faire le build docker de l'image `registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION` 
#     pour chaque architecture de processeur (importance de l'ARM)
# 


echo " Oh, here you will need to do one more thing : build from scratch [amd64/alpine:3.8], [arm64/alpine:3.8], [arm/alpine:3.8] " && exit 1

docker build -t amd64/registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION amd64
docker build -t arm64v8:registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION arm64
docker build -t arm32v6:registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION arm
# Note : amd64, arm64v8, arm32v6 : exactly like on public hub.docker.com
#
# ### Maintenant il faut lancer la recette de provision docker-compose de mon private docker registry 
echo "  Now run a docker-compose for private docker registry, based on your image in your private docker registry (you'll find many examples on github) "
# 
#     et ensuite je pousse les 6 images docker que j'ai du créer localement 
#     (docker push all the followingf images to your new private docker registry) : 

# + amd64/alpine:3.8
# + arm64v8/alpine:3.8
# + arm32v6/alpine:3.8  
# + amd64/registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION
# + arm64v8:registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION
# + arm32v6:registry:$REGISTRY_V2_DESIRED_RELEASE_VERSION
# +++ wanna also mention the [FROM golang:1.12-alpine AS build] you'll need 
#        it for the build from source of the 'registry' executable binary built, in the
#        docker "multi-stage"-build of a docker image, see the 
#            [COPY --from=build /go/src/github.com/docker/distribution/bin/registry /bin/registry]
#        code line inside the registry multistage build dockerfile : 
#        https://github.com/docker/distribution/blob/1fb7fffdb26687adf375a4433a58a0d66a13fede/Dockerfile#L25 
# 
# ### Pour finir, je fais un backup, il faut donc avant la lancée en prod, fair eunrtest du backup / restore, pour l'exploitation complète du registry.
#     (then immefdiately backup your booted repo, to get a reproduceable first consisent initial state for production )
#      Note: meaning the very first time you do that, you WILL have to (maybe write) (surely test) your backup and restore automatic recipes
#      Only after that your fit anfd good to go for production.
# 


#
# ### Manquent : https, authentification, base de données, et une ou deux autres conneries que j'ai oubliées.
# 
# 


But there 's more

Here above, what did we do? Wel,, we :

  • took the officially distributed source code for the registry application. An application developed in golang.
  • and we built :
    • an the executable binary file, registry, using go build commands
    • a docker image with that new binary inside of it.
    • the build from source process of registry uses a docker container,
    • and just to say, when built inside that container, we find the executable binary file freshly built, inside the container, at the path /bin/registry (remember that)

Okay, SO now let's say you're in a private company, and they might or might not have docker ee licenses, and then if you wanna be sure its about making an investigation among all people you know, etc...

Well you have another way :

  • run :
sudo yum install -y docker-distribution 
  • if it worked, guess what ?
ls -allh /bin/registry && /bin/registry --help
  • Oh, I just learned at work a few days ago (because usually i don't use docker-distribution like that), that you can then :
sudo systemctl enable registry
sudo systemctl start registry
sudo systemctl status registry
  • But don't dot that,
sudo systemctl stop registry
sudo systemctl disable registry
  • and do this : modify the update.sh from the first discussed recipe. exactly, replace line 32, :
docker cp $ID:/bin/registry $GOARCH
  • by this line :
cp /bin/registry $GOARCH
  • and remove all lines that do the git clone and docker build :
#!/bin/bash

set -e

if [ $# -eq 0 ] ; then
	echo "Usage: ./update.sh <docker/distribution tag or branch>"
	exit
fi

VERSION=$1

if [ "$GOARCH" == "" ] ; then
	echo "Must set GOARCH in environment"
	exit
fi

# cd to the current directory so the script can be run from anywhere.
cd `dirname $0`


# MADE_AVAILABLE_BY_SMTHG_LIKE_REHAT_SATELLITE
export CHECK_IF_VERSION_IS_AVAILABLE=$(yum list docker-distribution --showduplicates|grep $VERSION)
# with that, you can 

# 
# learned the "x"things fro empty null shell script long ago from good old JBoss EAP... ;)
# 
if [ "x$CHECK_IF_VERSION_IS_AVAILABLE" == "x" ]; then 
  echo "version $VERSION of the [docker-distribution] package unavailable in repositories ...Ask"   
  echo "your machine's administrator to add this package 's version inside one of the"
  echo "package repositories configured for this machine. "
  echo "E.g., using Redhat Satellite / Spacewalk" 
  exit 1;
else 
  echo "Fetching and building distribution $VERSION..."; 
fi;

sudo yum install -y docker-distribution $VERSION
# Update the local binary and config.
docker cp $ID:/bin/registry $GOARCH


cp Dockerfile.noarch $GOARCH/Dockerfile
cp docker-entrypoint.sh config-example.yml $GOARCH

echo "Done. Now you can docker build inside [$GOARCH] , and yi based your new docker image from a corporate-validated, registry binary, not built from open source, but learning from open source. Happy Dockie"

@thetredev
Copy link

thetredev commented Sep 11, 2023

@tianon I'm still confused. There is a distribution/distribution on Docker Hub, which is most likely the automated build of https://github.com/docker/distribution/blob/master/Dockerfile, and appears to be the same as registry, at least on first glance. However, they have different digests. Also, distribution is from CNCF apparently, and registry is from the "official images".

What I get from this: distribution is a CNCF project which forms the fundamental APIs to host OCI images. registry is somehow a "Docker specific" version of distribution (but I don't know what's specific about it when it comes to images).

Am I right with my assumptions? If so, do you know the "Docker specifics"? I guess it's something about OCI image specifications, but I can be very wrong.

@milosgajdos
Copy link
Member

milosgajdos commented Sep 11, 2023

Hi, one of the maintainers of distribution/distribution.

You are right to assume distribution/distribution is the CNCF project. It was donated by Docker to CNCF a few years ago. Again, you correctly assumed that there is a relation b/w the official registry image and the one in the distribution namespace in Docker Hub.

At the moment the official images are built off the 2.x release branch of the distribution/distribution GH repository. This branch has been put into maintenance mode (releases are very rare and mostly related to security updates) until the v3 release is cut (no ETA). That being said, any v2.x releases are also released as new Docker Official Images (DOI).

What you see in Docker Hub in distribution namespace, particularly the edge tag is what gets pushed to it automatically every time something is merged into main branch. This is a temporary solution until v3 is cut and is considered to be unstable.

We, the maintainers, need to figure out the path forward with regard to DOI pipeline once the v3 release arrives.

@thetredev
Copy link

@milosgajdos thanks for explaining!

@tianon
Copy link
Contributor

tianon commented Dec 21, 2023

This can probably be considered resolved now that the GitHub repository has moved? 👀

@thaJeztah
Copy link
Member

Looks like the readme could use some TLC to scrub some of the Docker references, links to docker's docs, and update it to refer to the OCI distribution spec (not Docker Registry v2 spec)

IMG_0166
IMG_0165
IMG_0167

@milosgajdos
Copy link
Member

milosgajdos commented Dec 21, 2023

How is this README generated? Distribution maintainers maintain the readme for https://hub.docker.com/r/distribution/distribution, but I'm not sure how the DOI readme is done

Never mind, found it https://github.com/docker-library/docs/tree/master/registry

@milosgajdos
Copy link
Member

Docs update PR here: docker-library/docs#2402

Once that's merged in, we can close this issue 😄

@thaJeztah
Copy link
Member

OHMAN; sorry for the huge screenshots; posted them from my phone, and I keep forgetting those hi-dpi ones get posted so large 😂

I'll look at your PR; thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants