Group:Software/research/ExternalRepositories/DockerRegistries

Introduction

Docker registries contain distributions or operating system images.

These repositories are usually referenced in Dockerfiles. So users need to be careful if they want to use Dockerfile files.

Additionally docker itself might need to be patched not to refer to repositories that contain nonfree software. For instance Parabola and probably other FSDG distributions as well have an issue that needs to be reported and fixed:

# docker run -it --rm archlinux bash -c "echo hello world"
Unable to find image 'archlinux:latest' locally
latest: Pulling from library/archlinux
b72d4d4e6198: Pulling fs layer 
3b001a57ac96: Download complete 

Since Guix is FSDG compliant, that it runs on most GNU/Linux distributions and that it can create docker images and that it can also run software very easily in containers, it might be easier to use Guix directly than to have to rely on docker repositories/registries. For instance to run 'ls' in a container, one can just run 'guix shell --container --network --emulate-fhs bash coreutils -- ls'. Containers environments can easily be defined with manifest files.

And finally Guix can generate docker images with 'guix --image-type=docker system.scm' where system.scm contains an operating system definition, so docker itself (patched to remove the reference to nonfree repositories) can also be used in an FSDG compliant way.

The Guix manual has all the details on how to use all that.

For the status of docker image of FSDG compliant distributions, see the DistroExecutionEnvironments wiki page.

Registries reviews

Repository website	Licenses requirements	Reliability of license fields
docker hub / docker.io	Not FSDG compliant: Has images with nonfree software like the Windows base OS images. So if there is a license policy it probably allows that.	?
registry.fedoraproject.org	Probably not FSDG compliant.	Strict policy.

Review of images on non-fsdg compliant registries

Repository	Image	FSDG status
docker hub / docker.io	pureos/*: pureos/amber pureos/byzantium etc	yes: PureOS byzantium should be an unmodified PureOS according to its build instructions. The other images from Purism should also be ok since they correspond to pureOS versions.

Running registries

Strategies

Running your own registry is relatively easy.

So we have a set of (non mutually exclusive options) as if we create new docker registries or not.

Patching docker

We could just patch docker to remove the default registry and not create any new registry.

Alternatively we could patch docker to point to use localhost:5000 as default registry and point to a tutorial that explain how to run your own registry.

Or we could point to an existing FSDG compliant docker registry (to be created).

Creating Registries

A new FSDG compliant docker registry could be created, so FSDG distributions or the FSDG community could run one if volunteers wants to do the work of setting that up and maintaining it. The downside is that the hosting infrastructure would not be under the direct control of existing FSDG compliant distributions but under the control of different people. But the advantage is that the work will be really minimal from the distribution side.

Another option would be to have each distribution host their own registry. This way it would not how trust work as users already have to trust their distribution.

A more complex option would be to investigate how docker registries work on the lower level, to see if it's possible to have a static registry with just a web server and have "docker registry compatible files" be generated as part of the distribution release process.

For instance Parabola already releases installers somewhat regularly, so they would also do the same for official docker images. Trisquel would do that during official releases of Trisquel, Guix could automate it, etc.

Running your own registry

Issues with the docker container for running the docker registry

The official documentation describes how to deploy the registry, however the instruction use an already made docker container. That container contain software under the Apache license and also bundles in dependencies like software from the Alpine GNU/Linux distribution. Alpine hasn't even been reviewed by GNU, and if that image is somehow FSDG compliant (nobody looked into it yet so we don't know, and it's better to assume it's not until someone looks), they might not stick to continue being FSDG compliant in the future, so it makes more sense to not use that image.

Building the docker registry tool by hand

We can use the osx-setup-guide documentation to build the 'registry' application and the dependencies licensing information to get a list of dependencies, and this way build our own version.

Using Guix to install the registry tool

There is already a docker-registry guix package for the docker registry tool to Guix. The package also contain configuration files examples.

Example local deployment

We can start with a very basic configuration that has no authentication.

For that we can save the following content in the config.yml file:

version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: localhost:5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3

We can then start our local docker registry:

$ sudo registry serve config.yml

Then after installing docker we need to start the docker daemon:

$ sudo systemctl start docker

We can then start importing a Guix docker image in docker:

$ docker load < /gnu/store/hwqv5gfzjz47mj539q9b2g10i1ib052d-docker-image.tar.gz
Loaded image: guix:latest

Then we tag the image:

$ sudo docker tag guix 127.0.0.1:5000/guix

And we can finally push it to our registry:

$ sudo docker push 127.0.0.1:5000/guix
Using default tag: latest
The push refers to repository [127.0.0.1:5000/guix]
701791c5c44b: Pushed 
latest: digest: sha256:a1fc2fe8bb91b9d78cb03838861207563128dc605d792b4ed62c4d23161c414f size: 529

Building FSDG compliant docker images

For having official images, the DistroExecutionEnvironments Wiki page has information on how to create official docker images for various FSDG compliant distributions (at the time of writing: PureOS, Trisquel, Parabola), and it should be easy to upstream an operating system definition for a minimal docker image in Guix as Guix has already everything in place to create docker images.

Registry configuration file

The official documentation details the configuration file format.

Research on how docker registries work

With a bit of work in may be possible to just publish images at given URL without the 'registry' application, in ways that are usable in docker files and tools, it might be even easier as distributions could just release docker images like they release installation "iso" images. And some distributions (like Guix) already have everything in place to continuously build updated images.

For that we will at least need to generate registry manifest v2 files, and maybe more (TODO: we need help to look into it). There are some documentation that gives some more details about how registries work under the hood and/or what is needed to implement the registry API:

• https://containers.gitbook.io/build-containers-the-hard-way/#registry-format-oci-image-manifest
• https://docs.docker.com/registry/spec/manifest-v2-2/
• https://docs.docker.com/registry/spec/api/#digest-parameter

I've not read them yet completely, so I don't know if we can just publish some files on a web server (with some small configuration to return json files in folders).

See also

• Group:Software/research/ExternalRepositories/FlatpakRegistries