Discussion:
Bug#1054884: docker-registry runs only as a single instance, but multiple instances can be needed
Add Reply
Hadmut Danisch
2023-10-27 23:40:01 UTC
Reply
Permalink
Package: docker-registry
Version: 2.8.2+ds1-1
Severity: wishlist
X-Debbugs-Cc: ***@danisch.de

Dear Maintainer,

the debian package for the docker-registry is built to run exactly one
instance with exactly one config file.


However, the docker-registry is limited in its capabilities, it can
either run as a local private registry for your own images, or it can
act as a proxy/cache for exactly one upstream server.

In Reality, one would need more than one instance to run, e.g. one as a
store for local images, one as a proxy/cache for docker.io, and so on.


I'd therefore propose:


- turn the systemd unit into a template (basically put a @ in the
filename and replace some data with %i , and run the registry with

/etc/docker/registry/%i.yml

i.e. allow to run an arbitrary number of instances for different
purposes.


- maybe give two example config files, i.e. one for the store of local
home made images at Port 5000, and a second as a cache/proxy for
docker.io at Port 5001.


best regards
Hadmut






-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.2.0-35-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages docker-registry depends on:
ii adduser 3.134
ii init-system-helpers 1.65.2
ii libc6 2.36-9+deb12u3
ii sysvinit-utils [lsb-base] 3.06-4

docker-registry recommends no packages.

docker-registry suggests no packages.

-- no debconf information
Reinhard Tartler
2024-08-31 11:50:01 UTC
Reply
Permalink
Control: severity -1 wishlist
Control: tag -1 help
Post by Hadmut Danisch
the debian package for the docker-registry is built to run exactly one
instance with exactly one config file.
This is correct, and keeps the package easy and simple to use for the
intended use-case.
Post by Hadmut Danisch
However, the docker-registry is limited in its capabilities, it can
either run as a local private registry for your own images, or it can
act as a proxy/cache for exactly one upstream server.
In Reality, one would need more than one instance to run, e.g. one as a
store for local images, one as a proxy/cache for docker.io, and so on.
In those cases, I would probably want to run the docker-registry inside
a (podman) container anyways, where the "single-instance" assumption
still holds.
Post by Hadmut Danisch
filename and replace some data with %i , and run the registry with
/etc/docker/registry/%i.yml
i.e. allow to run an arbitrary number of instances for different
purposes.
- maybe give two example config files, i.e. one for the store of local
home made images at Port 5000, and a second as a cache/proxy for
docker.io at Port 5001.
That sounds reasonable to me. I'm not that familiar with writing systemd
unit files myself, but I'd be happy to review a patch for the described
functionality and an upgrade path for existing systems.

Thanks!
-rt
Hadmut Danisch
2024-08-31 12:50:01 UTC
Reply
Permalink
Attached is the unit file (template type) I wrote and that works for me
to run multiple instances. It is important to give every instance
configuration file a different port number, like

version: 0.1

log:
  fields:
    service: registry

storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/docker-registry/fedora_org
  delete:
    enabled: true

http:
  addr: :5012
  headers:
    X-Content-Type-Options: [nosniff]
  tls:
    minimumtls: tls1.2
    ciphersuites:
      - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    certificate: /etc/docker/registry/tls_cert.pem
    key:         /etc/docker/registry/tls_key.pem

proxy:
  remoteurl: https://registry.fedoraproject.org



Of course, you can do it with containers as well. But then the question
is, would you want to run debian/ubuntu at all or use some simpler
distribution which more or less consists of container starting.

regards

Hadmut
Reinhard Tartler
2024-08-31 13:20:01 UTC
Reply
Permalink
Post by Hadmut Danisch
Attached is the unit file (template type) I wrote and that works for me
to run multiple instances.
Do you have thoughts on how do we provide an upgrade path from existing
systems to this new file?

-rt
Hadmut Danisch
2024-08-31 13:40:01 UTC
Reply
Permalink
Post by Reinhard Tartler
Do you have thoughts on how do we provide an upgrade path from
existing systems to this new file?
Soft way:

Just add this template to the package (it will do no harm unless
actived) and write a README  (and a hint into registry.conf) for multi
instance use:


1. explain why

2. tell not to run the single instance version and the multi instance at
the same time, i.e.  systemctl disable --now registry

3. foreach conf file run  systemctl enable --now ***@name    e.g. 
***@registry



Hard way:

remove the single version unit file from the package and put the
template in instead

in the prepare script mv old /var/lib/docker-registry/* files into
/var/lib/docker-registry/registry/*    ( or name it "default")


execute systemctl enable --now docker-***@registry     (or
something like docker-***@default)


So it will  (if registry.conf has not been modified) run as before and
most people will not notice that

1. the path has moved from /var/lib/docker-registry to
/var/lib/docker-registry/registry

2. the unit name is change from docker-registry to docker-***@default


But this leaves the door open to run as many instances as needed.
Explain in README.


regards
Reinhard Tartler
2024-08-31 14:40:02 UTC
Reply
Permalink
Hey Arnaud, Dmitry, Tianon and Tim,

I'm reaching out to you as the 4 people listed as Co-maintainers of the
package. Having done the
most recent upstream updates as a team upload, this question may require
a more opinionated approach.

May I ask you for your opinion on how to proceed with the presented
approaches?

Also, I have to note that this package has not seen a regular maintainer
(i.e., non-team upload)
in over 4 years. Are you still interested in contributing and
maintaining this package? It'd be
great if we could keep the list of co-maintainers accurate so that
questions like the one at hand
get routed to responsive people to avoid unnecessary wait times on
responses.

thanks,
-rt

-------- Original Message --------
Subject: Re: Bug#1054884: docker-registry runs only as a single
instance, but multiple instances can be needed
Date: 2024-08-31 09:28
Post by Reinhard Tartler
Do you have thoughts on how do we provide an upgrade path from existing
systems to this new file?
Soft way:

Just add this template to the package (it will do no harm unless
actived) and write a README  (and a hint into registry.conf) for multi
instance use:


1. explain why

2. tell not to run the single instance version and the multi instance at
the same time, i.e.  systemctl disable --now registry

3. foreach conf file run  systemctl enable --now ***@name    e.g. 
***@registry



Hard way:

remove the single version unit file from the package and put the
template in instead

in the prepare script mv old /var/lib/docker-registry/* files into
/var/lib/docker-registry/registry/*    ( or name it "default")


execute systemctl enable --now docker-***@registry     (or
something like docker-***@default)


So it will  (if registry.conf has not been modified) run as before and
most people will not notice that

1. the path has moved from /var/lib/docker-registry to
/var/lib/docker-registry/registry

2. the unit name is change from docker-registry to
docker-***@default


But this leaves the door open to run as many instances as needed.
Explain in README.


regards
Tianon Gravi
2024-08-31 16:00:01 UTC
Reply
Permalink
Running multiple instances, especially on a single machine, is an extremely
advanced and esoteric use case, so I would personally find it surprising to
add and maintain explicit support for doing so in the package.

This is something that's relatively easy for users who need it (and
especially understand the choice they're making) to do for themselves via
local configuration.

- Tianon
Post by Reinhard Tartler
Hey Arnaud, Dmitry, Tianon and Tim,
I'm reaching out to you as the 4 people listed as Co-maintainers of the
package. Having done the
most recent upstream updates as a team upload, this question may require
a more opinionated approach.
May I ask you for your opinion on how to proceed with the presented
approaches?
Also, I have to note that this package has not seen a regular maintainer
(i.e., non-team upload)
in over 4 years. Are you still interested in contributing and
maintaining this package? It'd be
great if we could keep the list of co-maintainers accurate so that
questions like the one at hand
get routed to responsive people to avoid unnecessary wait times on
responses.
thanks,
-rt
-------- Original Message --------
Subject: Re: Bug#1054884: docker-registry runs only as a single
instance, but multiple instances can be needed
Date: 2024-08-31 09:28
Post by Reinhard Tartler
Do you have thoughts on how do we provide an upgrade path from existing
systems to this new file?
Just add this template to the package (it will do no harm unless
actived) and write a README (and a hint into registry.conf) for multi
1. explain why
2. tell not to run the single instance version and the multi instance at
the same time, i.e. systemctl disable --now registry
remove the single version unit file from the package and put the
template in instead
in the prepare script mv old /var/lib/docker-registry/* files into
/var/lib/docker-registry/registry/* ( or name it "default")
So it will (if registry.conf has not been modified) run as before and
most people will not notice that
1. the path has moved from /var/lib/docker-registry to
/var/lib/docker-registry/registry
2. the unit name is change from docker-registry to
But this leaves the door open to run as many instances as needed.
Explain in README.
regards
Loading...