Support Kaniko builds

[edrandall]

Description

maven-fabric8-plugin already supports docker-daemonless builds using Jib, but Jib has a limited (though useful) support of layering a Java application on top of an existing base image.

It would be really useful if this were taken to the next level with Kaniko support. We could then build our entire suite of applications using the same (fabric8) abstraction and no need for a docker daemon or d-in-d anywhere. The main advantages of using the fabric8 plugin being that:

• configuration is standardised
• dependencies for running the underlying tool (Jib, Kaniko, whatever) are automatically downloaded.

[rohanKanojia]

@rhuss @manusa @dev-gaur @lordofthejars : What do you think about this? Can we support this use case?

[lordofthejars]

Well, it is similar to buildah. We could provide support for both. It is true that nowadays kaniko is getting some traction because of tekton.

[rhuss]

Actually, the idea is really to support as many build system that makes sense. Kaniko is one of them. Ideally, that should just be different implementation of the jkube-kit buiildservice (as sketched out on the fabric8-kit github page, with a sample implementation for the current docker build). The start is here: https://github.com/fabric8io/fabric8-kit/tree/master/build

[manusa]

I'd like to support this build system too, but I would do it in scope of JKube. We should make JKube image build system as abstract as possible so that concrete implementations are easy to add and don't require extra work besides invoking the implementation specific build commands from the provided common build model.

From the earlier comments I'd like to highlight and keep in mind these statements: "configuration is standardised", "support as many build system that makes sense". I think they summarize pretty much some of JKube goals and what we should be focusing on.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[edrandall]

Link back to #1534

• https://developers.redhat.com/blog/2020/01/28/introduction-to-eclipse-jkube-java-tooling-for-kubernetes-and-red-hat-openshift/

[dloiacono]

any news about Kaniko support on Jkube ? @manusa

[edrandall]

Problem with JKube is that is is not a straight migration from f8 / dmp. The approach seems to be, aim for lowest-common-denominator, removing f8 features that don't immediately fit their model, rather than maintaining support for them. Example: https://github.com/eclipse/jkube/issues/644

[manusa]

any news about Kaniko support on Jkube ? @manusa

Hi @dloiacono, Support for Kaniko is tracked in https://github.com/eclipse/jkube/issues/767 This is scheduled for the mid-term in our roadmap. Our current priorities are finishing up with the Gradle plugin support and improve Helm chart generation with better support for placeholders/values.

Problem with JKube is that they are not a straight migration from f8....

Hi @edrandall. Could you be more specific about the features you are missing right now in JKube as compared to FMP? Only some very Maven specific features were dropped. Any thing else you are missing should be reported and at least considered from the project perspective.