Push image to alternative registries

[danieletorelli]

Following up the discussions of the last days (see #307) and considering the side effects of how official images are maintained on Docker Hub, that often adds its own delays to the rollouts, I'd love if you'd evaluate pushing Caddy images also to alternative registries (e.g. GitHub CR).

Redundancy is always a good choice, especially when it's easy to achieve and I'm sure that many users would appreciate having your images stored in multiple locations.

[hairyhenderson]

In general the delay at the docker-library/official-images repo is minimal.

In this particular case, the delay has been simply due to the fact that I issued the PR on a weekend. We can't expect Docker employees to work on the weekend (and normally I try not to either).

Having a single source for the Caddy Docker image is beneficial - it reduces confusion, it reduces complexity, and it reduces the number of artifacts we need to support.

Having said that, I can also see the benefit in shipping the image to other registries.

IMO we should continue to follow the current plan, which is to automate the release as much as possible, and reduce the dependency on a single human (me).

If there is an actual need to push images to additional registries after this work is done, we can consider it.

[douglasparker]

In general the delay at the docker-library/official-images repo is minimal.

The delay has an affect on a lot of people that depend on timely releases- that much was made clear.

Having a single source for the Caddy Docker image is beneficial - it reduces confusion, it reduces complexity, and it reduces the number of artifacts we need to support.

Let's be real, having alternative registries isn't confusing at all... Anyone that is confused about using an alternative registry likely shouldn't be deploying anything public facing in the first place.

As for complexity, I also think that's a stretch. All of the popular alternative registries follow the OCI. It's as simple as tagging and pushing to a new registry.

[francislavoie]

Let's be real, having alternative registries isn't confusing at all...

Except that we have actual evidence of confusion.

For example we have both https://hub.docker.com/_/caddy and https://hub.docker.com/r/caddy/caddy, where the former is the official image and the later is simply our CI target.

Many users end up using caddy/caddy instead of caddy and they complain about not seeing tags, because we don't push tags there (e.g. latest is still pointing to v2.0.0-rc.3.

As for complexity, I also think that's a stretch. All of the popular alternative registries follow the OCI. It's as simple as tagging and pushing to a new registry.

Right but we only have a script to generate the stackbrew config as pre official images guidelines right now with https://github.com/caddyserver/caddy-docker/blob/a82cbc5b1bf43757f718d8b21adcca6a0df560c7/stackbrew.tmpl. We'd have to write something up that generates a list of docker tag commands or whatever for each release, and that's effort.

It also means that it's more code we need to maintain, adds time burden not only the first time writing it but any time in the future we want to adjust our release processes. It also means more documentation, more things to be aware of if new maintainers hop on board, etc.

Anyway, we're considering it but there's a lot of pros and cons to weigh.

[douglasparker]

Let's be real, having alternative registries isn't confusing at all...

Except that we have actual evidence of confusion.

For example we have both https://hub.docker.com/_/caddy and https://hub.docker.com/r/caddy/caddy, where the former is the official image and the later is simply our CI target.

Many users end up using caddy/caddy instead of caddy and they complain about not seeing tags, because we don't push tags there (e.g. latest is still pointing to v2.0.0-rc.3.

I've actually made this mistake. I think the problem here is the naming convention for the ci target, not the fact that there are two repositories. If your CI target was more clearly defined (or made internal?) there would be much less confusion. Simply pull the image based on the fqdn of the preferred registry.

As for complexity, I also think that's a stretch. All of the popular alternative registries follow the OCI. It's as simple as tagging and pushing to a new registry.

Right but we only have a script to generate the stackbrew config as pre official images guidelines right now with https://github.com/caddyserver/caddy-docker/blob/a82cbc5b1bf43757f718d8b21adcca6a0df560c7/stackbrew.tmpl. We'd have to write something up that generates a list of docker tag commands or whatever for each release, and that's effort.

It also means that it's more code we need to maintain, adds time burden not only the first time writing it but any time in the future we want to adjust our release processes. It also means more documentation, more things to be aware of if new maintainers hop on board, etc.

Anyway, we're considering it but there's a lot of pros and cons to weigh.

fwiw, I haven't looked at the complexities of caddy builds- I just personally haven't had any issues automating docker builds across registries.

It's my opinion that automating everything will save you more time in the long run. Manual input for releases just sounds really inefficient.

[danieletorelli]

In general the delay at the docker-library/official-images repo is minimal.

In this particular case, the delay has been simply due to the fact that I issued the PR on a weekend. We can't expect Docker employees to work on the weekend (and normally I try not to either).

IMO we should continue to follow the current plan, which is to automate the release as much as possible, and reduce the dependency on a single human (me).

If there is an actual need to push images to additional registries after this work is done, we can consider it.

It's the right thing to automate the releases as much as possible and reduce dependencies from humans. Humans are busy, make mistakes, have holidays to enjoy and have all rights to do so, leaving the boring and repetitive work to machines.

If then the idea is to reduce the human factor for your releases, you shouldn't depend also on Docker employees human factor. This only adds complexity and possible mistakes to the context.

If you would've had a critical security issue to ship immediately, then you would have the complexity of fixing the issue + the complexity of releasing your work + the complexity of Docker employees releasing the final image. This might mean days, as it happened in this case and "days" are not acceptable on really critical security issues.

I wish you that the situation I described above would never happen, but we all know that is a matter of "when", not "if", simply because critical security issues are a reality that impacts us all. That's why is way better to prevent those situations in advance.

For what concerns the effort of setting up a release on an alternative registry. It's something you can do with less than 50 lines of YAML in a Github Action workflow and doesn't require any additional maintenance, so it's not that dramatic.

[hairyhenderson]

I'm going to close this for now, as there's not really anything helpful that's come out of this issue.

As I said above, we'll consider this once the automation work is complete.

As "simple" as this all sounds to bystanders, I assure you it's not. Not because it's technically difficult, but because of the human factor (i.e. me). I have a full-time job and a very busy personal life. Spare time is precious, and I simply haven't had the ability to spend time automating the process.

If anyone else wants to help out by issuing PRs with a suggested automated release process (that's going to work correctly with our official builds), by all means please feel free.