Support for podman/buildah

[valdar]

Add support for https://podman.io/ and https://buildah.io/

As more environment get installed by default with this container toolchain, Fedora 31 and Openshift 4 Clusters as an example, would be good to support those as well.

Blocked by:
#253

[rohanKanojia]

@dev-gaur @manusa : WDYT?

[manusa]

We certainly need to provide support for both, same as we are doing with JIB.

JKube must strive to be the single entry point for any cloud-native Java application, supporting any image builder available is a must to accomplish this.

[manusa]

Podman 2.0, should work OOTB, but we can easily provide support for earlier versions (e.g. just by running the CLI and loading the generated image tarball)

[manusa]

testcontainers/testcontainers-java#2088

fabric8io/docker-maven-plugin#1330 (comment) - 2.0 Problems with Content-Type header

[rmarting]

This feature should be implemented soon because the latest versions of OpenShift 4.X includes only podman and buildah instead of docker. Also Fedora 32 does not includes docker and podman is only included.

To test the new environments I am updating a sample project developed some time ago from:

• jkube 0.1.0 (k8s and openshift)
• docker
• OpenShift 3.11

to:

• jkube 0.2.0 (k8s and openshift)
• podman 2.0.3
• OpenShift 4.5

but I found the following error:

[INFO] --- k8s-maven-plugin:0.2.0:build (default-cli) @ kafka-clients-sb-sample ---
[INFO] k8s: Running in Kubernetes mode
[INFO] k8s: Building Docker image in Kubernetes mode
[INFO] k8s: Running generator spring-boot
[INFO] k8s: spring-boot: Using Docker image fabric8/java-centos-openjdk8-jdk:1.5 as base / builder
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.357 s
[INFO] Finished at: 2020-07-30T17:01:17+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.eclipse.jkube:k8s-maven-plugin:0.2.0:build (default-cli) on project kafka-clients-sb-sample: Execution default-cli of goal org.eclipse.jkube:k8s-maven-plugin:0.2.0:build failed: No <dockerHost> given, no DOCKER_HOST environment variable, no read/writable '/var/run/docker.sock' or '//./pipe/docker_engine' and no external provider like Docker machine configured -> [Help 1]

Is there any plan to allow setup the builder strategy (podman, docker) in jkube plugins?

[manusa]

Hi @rmarting

I'm not sure about this, but with the latest OpenShift 4, S2I image build strategy should work OK without any config from your side by using (OpenShift-Maven-Plugin mvn oc:build). Images will get built inside the cluster and added to the internal registry (whatever that is).

In case you want to use Docker (the default build strategy for Kubernetes-Maven-Plugin), these builds never run in the cluster (when using kubernetes-maven-plugin), so you'll always have to push those images to a shared/public registry (k8s:push).

You can also run Docker builds within an OpenShift cluster, but then again this is completely delegated to the cluster, so it should work regardless of docker implementation being Buildah or any other thing. In this case you should use openshift-maven-plugin, but with a flag to perform a Docker build in the cluster mvn -Djkube.build.strategy=docker oc:build.

The versions you mention in your issue are quite old. Could you please check with the current release (1.0.0-rc-1) by using the openshift-maven-plugin - mvn oc:build oc:resource oc:apply?

Besides your current issue (that should get fixed with project as is), as stated in previous comments, support for Podman is definitely in our Roadmap.

[rmarting]

Hi @manusa

Basically I am using the artifacts provided in Maven Central (only version 0.2.0) and not building jkube with the latest versions. I reviewed the documentation but I could not find how to setup podman instead of docker because my laptop has not include it.

I don't want to use Docker, I only want to verify that from my development local environment I can build an image using jkube and deploy into my OpenShift cluster, but it seems that if I don't have docker installed, I am not able to do it.

s2i works inside OpenShift, but this is not my case.

I will try to build locally the latest version of jkube and test with the options that you describe. Thanks.

[manusa]

Ok GAV Maven coordinates changed, that's why you don't find the new artifacts.

They are published (no need to build):

• https://search.maven.org/search?q=a:openshift-maven-plugin
• https://search.maven.org/search?q=a:kubernetes-maven-plugin

As stated, if you are targeting an OpenShift cluster, you can/should openshift-maven-plugin, there will be no need to install anything in your laptop.

If you want to try out kubernetes-maven-plugin and still not install docker in your machine, then you can use it with jib build strategy mvn k8s:build -Djkube.build.strategy=jib. In this case, you will need the extra step of pushing the image to an accessible registry.

[manusa]

I managed to make this work by making some minor changes to our ApacheHttpClientDelegate
as suggested in fabric8io/docker-maven-plugin#1330 (comment).

1. Start Podman's REST API server:

$ podman system service --time=100 tcp:127.0.0.1:2375

2. Declare a DOCKER_HOST environment variable to point to the endpoint: DOCKER_HOST=tcp://127.0.0.1:2375

3. Run you Docker build goals

This is the only required change for the previous scenario to work:
(in ApacheHttpClientDelegate#addDefaultHeaders and related methods)

    private HttpUriRequest addDefaultHeaders(HttpUriRequest req, Object body) {
        req.addHeader(HttpHeaders.ACCEPT, "*/*");
        if (body instanceof File) {
            req.addHeader(HttpHeaders.CONTENT_TYPE, URLConnection.guessContentTypeFromName(((File)body).getName()));
        } else if (body != null) {
            req.addHeader(HttpHeaders.CONTENT_TYPE, "application/json");
        }
        return req;
    } 

[manusa]

I'll provide an initial PR with the previous suggested fix, since this should be considered a BUG.

Once corrected we can consider additional enhancements to automatically detect the Podman REST API socket ($XDG_RUNTIME_DIR/podman/podman.sock).

[manusa]

The final agreement was to provide better documentation on how to use Podman >= 2.x with JKube.

Podman is now already covering the gap and providing the necessary bindings so that it acts as a seamless and transparent Docker implementation.

However, the files where Docker persists the auth credentials when running docker login are not the same as the ones Podman is using ${XDG_RUNTIME_DIR}/containers/auth.json.

We should consider checking that file too when we are loading Docker auth credentials.

See also: https://gitter.im/eclipse/jkube?at=60350c579337c51bc6a5fc2b

[manusa]

Since Podman usage has been documented in #981, we can close this issue now.

Further improvements to the Podman UX should be documented/requested in separate issues.

[vilmosnagy]

We'd like to use this plugin in our Gitlab CI environment with podman.

But the podman system service --time=0 unix:/run/user/$(id -u)/podman/podman.sock command gives the following error in the CI (inside a container):

$ podman system service --time=0 unix:/run/user/$(id -u)/podman/podman.sock
time="2022-09-06T13:45:13Z" level=error msg="unable to write system event: \"write unixgram @d9cec->/run/systemd/journal/socket: sendmsg: no such file or directory\""
Error: unable to create socket: listen unix /run/user/0/podman/podman.sock: bind: no such file or directory

Has anyone ever got this plugin to work with podman within Gitlab CI?

[rohanKanojia]

@vilmosnagy : Umm, which container image are you using? Maybe that image doesn't support podman?

I think this question is better suited for https://github.com/containers/podman/discussions

[vilmosnagy]

@rohanKanojia any container image with podman installed 🙂

In my exact situation we use maven:3.8.4-openjdk-11, and install podman with apt update && apt install -y podman. But the job is ran on GitlabCI, inside an other container which is started by the Gitlab CI runner.

[wardev]

https://www.redhat.com/sysadmin/podman-inside-container