Allow building custom docker images with selected plugins

[nineinchnick]

Description

Make it easier to build custom images without specific plugins (or with only selected ones). This should come in handy when some plugins come up in security scans because they might have outdated dependencies.

The script requires to specify a tag prefix if any plugins are to be excluded or included.

Based on #12507, please skip the first commit.

Is this change a fix, improvement, new feature, refactoring, or other?
build script new feature

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)
build script

How would you describe this change to a non-technical end user or system administrator?
n/a

Related issues, pull requests, and links

Documentation

( ) No documentation is needed.
(x) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[nineinchnick]

It feels like it should be easier for end-users to discover this section. @mosabua WDYT about adding a docs section about the Docker image? It's a pretty popular deployment method and currently, there's no mention of it in the docs.

[mosabua]

I very much would like to have such a section .. same for the RPM and the Helm chart .. I am hoping that @nineinchnick @colebow and @bitsondatadev and take that on as a bit of a project soon. We do have a bunch of docs that can be lifted and shifted for this..

[findepi]

I view this as an out-of-scope for the project. Let's not add this, let's focus on our standard builds.

[nineinchnick]

I view this as an out-of-scope for the project. Let's not add this, let's focus on our standard builds.

Sure. I can make one last attempt at describing how the Dockerfile expects to find the extracted tarball, so users can apply any changes there. I'll close this PR in a bit.

[findepi]

Users who really care about redundant plugins should be able to take official Docker image, and just rm -r ... chosen plugin folders. This requires no docs, and is self-maintaining (if the official docker image layout changes, the build fails).
I trust this can be combined with squashing layers to produce a smaller image.

I would recommend this to (power-)users, but i wouldn't want to document this, as I don't want to commit to maintaining this.

[mosabua]

Btw ... users should NOT do an rm -rf in the docker image .. that way the image doesn't actually get smaller in terms of layers .. instead they should fork and build a new separate image from the tarball that doesn't add stuff in the first place.

And we can certainly add this kind of stuff to the documentation .. e.g. in the developer guide or some sort of expert section. But lets definitely cover the basics first.

[mosabua]

Another thought @nineinchnick .. we might want to have a separate packaging code repo at some stage... e.g. we could have a docker base image that adds only the requirements and the minimal plugins for Trino to start up .. and then users could use that base image and add more plugins by extending that base image.. I started a mini hack along those lines recently when we were thinking about pulling out the rpm .. see https://github.com/simpligility/trino-packages

[findepi]

Btw ... users should NOT do an rm -rf in the docker image .. that way the image doesn't actually get smaller in terms of layers ..

Please acknowledge my comment above (#12508 (comment))

we might want to have a separate packaging code repo at some stage... e.g. we could have a docker base image that adds only the requirements and the minimal plugins for Trino to start up .. and then users could use that base image and add more plugins by extending that base image.

Good idea if we really want to add more complexity and maintain it.
I would strongly prefer we keep complexity at bay, because removing things later is super hard (eg #11521).

[mosabua]

Btw ... users should NOT do an rm -rf in the docker image .. that way the image doesn't actually get smaller in terms of layers ..

Please acknowledge my comment above (#12508 (comment))

Ack .. I just wanted to clarify that I tried that before and its not pretty and doesnt really work well. its better to start clean .. and in our case thats actually much easier as well since we have the tarball already.

we might want to have a separate packaging code repo at some stage... e.g. we could have a docker base image that adds only the requirements and the minimal plugins for Trino to start up .. and then users could use that base image and add more plugins by extending that base image.

Good idea if we really want to add more complexity and maintain it. I would strongly prefer we keep complexity at bay, because removing things later is super hard (eg #11521).

Agreed.. thats why I am suggesting a separate repository that is in addition .. and not as strictly and thoroughly maintained as the core repo .. it could rely more on community demand and contributions. @nineinchnick myself and others can explore that separately...