Publish an OCI Artifact and/or Image to ghcr.io

[ba-work]

With k8s 1.33 OCI volume support hitting beta and kind releasing 1.33, it became trivially easy for me to test running the jmx exporter as an OCI volume and it worked great.

This would greatly simplify some CI and deployment stuff since it enables easy decoupling of the exporter's jar and the application's jar. For example, getting metrics out of keycloak:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: app
          image: quay.io/keycloak/keycloak
          args: ["start-dev"]
          env:
            - name: JAVA_OPTS_APPEND
              value: -javaagent:/exporter-jar/jmx-exporter.jar=12345:/exporter-config/config.yaml
          volumeMounts:
            - name: exporter-jar
              mountPath: /exporter-jar
            - name: exporter-config
              mountPath: /exporter-config
      volumes:
        - name: exporter-jar
          image:
            reference: localhost:5000/jmx-exporter:v1.2.0
        - name: exporter-config
          configMap:
            name: exporter-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: exporter-config
data:
  config.yaml: 'rules: [pattern: ".*"]'

The image I made for the exporter is this:

FROM scratch
ADD jmx-exporter.jar .

And I'm certain there is an oras incantation that could be used to make a "true" OCI artifact.

[dhoard]

I understand the request, but IMHO, this isn't something we should pursue right now. As you pointed out, building the actual image is easy.

But...

• The K8s feature is in beta
• Registry selection will undoubtedly not match what a user wants/needs
• Enterprise users typically download, scan, and then upload the container images to their private registry, which is more work than just building the container image themselves
• Testing. Where/how do we test it?

[ba-work]

These are all valid criticisms, thoughts on each:

• The K8s feature is in beta
  Fair, but k8s betas are extremely reliable, and tend not to change the contract that much. This is also not relevant to artifact itself which can be used for more than just a k8s volume. Betas are reliable enough that most PaaS's even offer explicit paid support on on them eg. AKS: https://learn.microsoft.com/en-us/azure/aks/support-policies#unsupported-alpha-and-beta-kubernetes-features

• Registry selection will undoubtedly not match what a user wants/needs
  I put ghcr.io in the title because that's selfishly what I want, however this is a problem for the consumer, not the producer. Just picking any public registry (or all) with a free tier should be acceptable where the ecosystem at large is comfortable handling whatever. Anecdotally, at we already have automations and comfort for interactions with any of the typical: public.ecr.aws, quay.io, ghcr.io, etc. and I would expect most enterprises do as well.

• Enterprise users typically download, scan, and then upload the container images to their private registry, which is more work than just building the container image themselves
  This is backwards, it's far easier to mirror+scan requiring essentially no CI or changes. The most exercised automation is very much anything handling OCI images. For example, we aren't going to invest time/energy in building 100s/1000s of open source images (which can actually counterintuitively outnumber the proprietary workload stuff), its better spent in mirroring/scanning.

• Testing. Where/how do we test it?
  GitHub actions just like the current tests. For example, a test of a successful OCI package, could be:

  1. build jar
  2. package as OCI artifact/image (and push to a registry)
  3. pull artifact, and extract jar
  4. run whatever blackbox tests

Thanks for reading, hopefully I can convince you this is worthwhile :)

[ChristianCiach]

This issue has suddenly become relevant again, now that Bitnami will paywall their images.

[hgranillo]

There's more use cases for a jmx-exporter container image than OCI volumes. Like for example sidecar containers.