Publish a base image containing javaagent

[anuraaga]

I have been publishing such an image for the aws distro from the beginning and it comes in quite handy. More importantly, we do need a docker image containing the javaagent somewhere for work to auto-instrument apps in k8s (open-telemetry/opentelemetry-operator#464).

I figured it's useful to provide this image here - one problem is that there are ~a million Java base images out there, so picking only one is ambiguous. But even then, at least I personally prefer copying out of a docker image in a multi-stage build vs curling from the GitHub release as it tends to be more reproducible / cache better so the docker image is still great even when picking my own base. I went with zulu here because it is the only official image I could find with a JRE-only image published and it didn't seem worth doing jlink ourselves of e.g. eclipse-temurin, which also is a sensible base for us since we use it for the smoke tests.

Will add to release-build script after verifying on main build.

If there is no interest in publishing this here, it's ok since it is yet another published artifact, and I'll just publish within ghcr.io/open-telemetry/opentelemetry-operator instead.

[iNikem]

I will not tire of promoting Liberica images:

bellsoft/liberica-openjdk-alpine  17  124MB
bellsoft/liberica-openjre-alpine  17  171MB
azul/zulu-openjdk-alpine          17-jre-headless  195MB

[iNikem]

Are you sure you want to do that on every pr merge? Why not nightly?

[pavolloffay]

It image is mainly needed when the javaagent is released.

[anuraaga]

It only takes a few seconds, much less than the actual snapshots so figured it's ok on each main push. It doesn't create a new tag each time.

[trask]

I think we also need to publish in release-build.yml and patch-release-build.yml? (release-build.yml since we have discussed releasing from a branch)

[pavolloffay]

@anuraaga we should define what this image does in regards to the open-telemetry/opentelemetry-operator#464.

EDIT: The operator defines command that copies javaagent from the docker image to a volume. At the moment it expects the image to be present at /javaagent.jar. We can change the path however I would like to make sure that the javaagent image is consistent across releases - e.g. it does not contain a version.

[trask]

But even then, at least I personally prefer copying out of a docker image in a multi-stage build

👍

This seems like the standard use case, layering in the javaagent into an existing docker build.

Should (can?) we use scratch base image and just promote this?

If we have to pick a "winner" for Java distro, I'd vote for eclipse-temurin

[trask]

I think we also need to publish in release-build.yml and patch-release-build.yml? (release-build.yml since we have discussed releasing from a branch)

[anuraaga]

I will not tire of promoting Liberica images:

Oops my initial search didn't bring up the magic triplet of (17, alpine, jre) for liberica (had only found the jdk) but it does look like a nice base image.

We can change the path however I would like to make sure that the javaagent image is consistent across releases - e.g. it does not contain a version.

Thanks for the callout, agree that even the multi-stage build approach is simpler without the version there, i.e. always having the path at the same location. I think I'll have to stick to a Dockerfile instead of jib then but guess that should be basically equivalent for a single-jar file rather than a complex classpath, no layering tricks needed anyways.

Should (can?) we use scratch base image and just promote this?

It feels like it loses functionality (drop in and go) that could be there, while also supporting the multi-stage build with the exact same usage. But it's true that perhaps the base image is just too ambiguous to go with any - I'm starting to lean towards scratch. Any other thoughts on this?

[anuraaga]

After discussing this, we decided that we can't imagine people actually using an image we publish as their Java base image. While a scratch image provides some benefit over downloading from the GitHub release, it's pretty minor and at least now is probably not worth us publishing / supporting a whole artifact (docker image) for it. So will close this and publish within opentelemetry-operator instead.