Provide clickhouse/clickhouse-server image as the official image

[Felixoid]

Hello dear team.

For some time we want to provide the ClickHouse DB as an official image. The image https://hub.docker.com/r/clickhouse/clickhouse-server/ is intensively tested and rebuilt regularly for multiple architectures.

It's built for every release automatically from https://github.com/ClickHouse/ClickHouse/tree/master/docker/server.

So, I'd like to start the review process. What do you think will be the appropriate next step for it?

[tianon]

You'll want to read through https://github.com/docker-library/official-images#contributing-to-the-standard-library (and https://github.com/docker-library/official-images/blob/master/NEW-IMAGE-CHECKLIST.md), and then open a PR to start the review process in earnest. If you have specific questions or problems, I'm happy to do my best to answer them.

[Felixoid]

Sorry for not getting back to you sooner, but I have a question.

As I get it, the PR should contain a new file library/clickhouse with some content. But as well I need to create the PR to docker-library/docs repo. And there it looks like we need some repository with a dedicated tree for an image. Or we could use the same directory as I've shown above?

How the process of releasing new versions looks like? I think, the ubuntu content can be used as an example. So we have some active releases, and update it regularly. On each new release, we build and push new tags. I assume it will look completely different. Right?

[Felixoid]

I think https://github.com/docker-library/official-images/blob/master/library/golang is a much better example, so we can use the same repository as the source of the official image.

On the other hand, we need more directories in https://github.com/ClickHouse/ClickHouse/tree/master/docker/server for the active releases, right? It's impossible to use build arguments during the build, and every Dockerfile should be launched as just 'docker build .`?

[tianon]

Yeah, ubuntu is definitely a bad example for your use case and golang is a better one 😅

Correct on creating library/clickhouse and a clickhouse directory in docker-library/docs (with no README.md in it as that file is auto-generated from the other files).

https://github.com/docker-library/faq#an-images-source-changed-in-git-now-what might actually be a pretty helpful flow for you to get a full sense of what "maintenance" looks like (it doesn't talk about docs but those I think are more straightforward) 👀

You are correct that we do not support build args -- each Dockerfile must be standalone. 👍 Having it as part of your main development repository is OK, but you will want to make sure you have some way to do updates to it out-of-band from your regular releases (because this is more packaging, and it doesn't make sense to release a whole new version just for packaging changes), and yes if you want to support multiple releases you'll need some way to manage that (although that can be done via other branches if that's the workflow you prefer - we like having them all together because it's very common that we end up needing to apply a set of changes across all of them at once, which gets a bit tedious if they're each in a separate branch).

[Felixoid]

Hmm, what about the current way to build images from Dockerfile.ubuntu and Dockerfile.alpine? I think it's a custom approach, and won't work as well. Because the thing I see in each file in library directory uses the directory-based approach.

Maybe, an easier approach will be to generate a side repository on each tag, so it would minimize the noise in the main repository.

[tianon]

Yeah, noise in the main repository is something to be wary of - you can use File: directives to use a custom Dockerfile name though (see eclipse-temurin or mysql for a couple examples which do so).

[Felixoid]

Thanks, I have all I need now, I guess.

The intermediate repository looks redundant to me now.

I'll update the Dockerfiles in each release branch (e.g. 22.8 and 23.2) accordingly. I think, the task to update docker-library/official-images will be launched with other nightly builds to avoid noise here. We update all releases approximately once a week, so one update looks better than five.

So now I need to prepare our infrastructure to do the described staff.

Can I at the same time ask about reviewing our alpine and ubuntu Dockerfiles?

[Felixoid]

Hello dear @tianon, sorry for the long silence.

Here I finally have a generated docker LDF, so I would like to get feedback on whether it will work out. It was generated for this tree

The content is the full set of tags we can build now. The file for the currently supported releases would look like that. So, as suggested, we can push the first version as the above, and adjust it further.

If it's good, I'll proceed with the documentation part, and then on the automate everything.

[Felixoid]

Both PRs for docs docker-library/docs#2397 and official library #15846 are created 🤞

[tianon]

Closing in favor of #15846