Native image S2I build support

[vorburger]

Would you guys have any interest in a contribution (from me..) for OpenShift S2I support?

Background & "motivation" for this is that, AFAIK oc new-build --binary (as doc here) from a Dockerfile is not always available in all OpenShift instances. For example, AFAIK we don't enable that in our own OpenShift Online (at least in our free tier; it's security related); the same may be the case for future customers.

Full disclosure: I've some S2I experience as the current maintainer over on fabric8io-images/s2i ... see also this blog post where I introduced Java 11 and Gradle support for that S2I Java Builder.

The way I imagine this would work is that there would have to be a protean-s2i Builder image (perhaps extending s2i-java) which would have to include the GraalVM binary, build with -Pnative (and probably -Dnative-image.docker-build=true althought I don't yet get what that's really good for..), and then copy and launch the built native, instead of java -jar - just like the example Dockerfile (but a new TBD getting-started-native-s2i protean-quickstarts would have no Dockerfile).

I do fully realize that with where S2I stands right now, this will lead to a horribly fat image, which will include the Graal VM. While we could hack it to wipe that (as an option, as that prevents incremental builds), which would help for security but may be not even for image size (layers?), the longer term solution is work in S2I (Knative build?) to sort this out; see e.g. fabric8io-images/s2i#180 (and fabric8io-images/s2i#192). I would propose to let such possible future work be out of scope of this initial issue.

If this isn't a priority or actively not welcome because you have other plans, just say so & close this.

[vorburger]

@stuartwdouglas just noticed your related work under docker/ ... this could perhaps build on that.

[cescoffier]

@vorburger That would be great but there is one "small" issue. Compiling a native image takes up to 3Gb of memory and so far in the cluster I've used this is way above my quota.

On the docker side, I've started to look at distroless, kind of fun except the Bazel aspect :-(

[vorburger]

there is one "small" issue. Compiling a native image takes up to 3Gb of memory and so far

Oh! :-( But that would apply whether we build with S2I or a Dockerfile, so is kind of orthogonal to this.

Upon re-reading the Deploying the application in OpenShift doc I just realized that currently actually documents a locally built native executable which is pushed ( --from-dir=.) into OpenShift, and technically does not show building a microservice container "on" OpenShift today.

I've started to look at distroless

as per chat: For native, you could use registry.fedoraproject.org/fedora-minimal (or centos/centos7-atomic, older) which at 90 MB is not quite those 40 MB but still much better than the 202 MB from centos:7. (If you want a smaller image with a JVM, watch fabric8io-images/s2i#192 where I'm trying to figure out how to do that...)

kind of fun except the Bazel aspect :-(

You should be able to use the distroless base images without Bazel? But Bazel is amazing for super fast intelligent incremental building! 😸 As is Gradle; I've no idea why we're sticking to middle aged Maven in a cutting edge project like this? 😄 But that's perhaps not the point of this issue...

[cescoffier]

Oh! :-( But that would apply whether we build with S2I or a Dockerfile, so is kind of orthogonal to this. Upon re-reading the Deploying the application in OpenShift doc I just realized that currently actually documents a locally built native executable which is pushed ( --from-dir=.) into OpenShift, and technically does not show building a microservice container "on" OpenShift today.

Exactly, we were unable to get the build on OpenShift working because of the quota.

[siamaksade]

Image size is very important for the S2I native build. Chained builds might help with that a bit. One build produces the binary, the chained build lays it over a minimal image.

[vorburger]

This issue is now about Native image S2I build support; #1306 is about non-native Java S2I building.

[vorburger]

Closing this issue as I consider this Done with today's merge of #1358.