Create an extension for using podman to build container images

[edeandrea]

Description

Currently we have Jib, Docker, OpenShift, and Buildpack container images. There isn't a way to use podman to build a container image and have it loaded into the local registry.

I'm proposing a new container-image-podman extension which would essentially mirror the container-image-docker extension and implement similar capabilities, as supported by podman.

Implementation ideas

No response

[quarkus-bot]

/cc @geoand (jib,openshift), @iocanel (openshift)

[edeandrea]

I was thinking about this a bit. Right now if you use the container-image-docker extension and set quarkus.docker.executable-name=podman, then container image building/pushing/etc works with Podman right out of the box.

Do we really need a separate extension?

The only real difference I see is if we want to build multi-arch images. RIght now we have the quarkus.docker.buildx sub-config item which uses the docker buildx Docker extension.

For podman, building multi-arch images is built in. The only difference is the sequence of commands you need to use. Rather than pretty much copy/pasting the entire container-image-docker extension and just changing a few things, couldn't we instead invent a new sub-config item (maybe quarkus.docker.podman.*?) and add the multi-arch stuff in there?

This way the amount of change will be much, much less, and we won't need to invent a new extension which is 90% copy/pasted code (plus a bunch of new BuildItems that are copy/pastes of the docker ones (DockerStatusProcessor, IsDockerWorking, DockerStatusBuildItem, etc).

If we decide in the future we want to support podman-specific ways of building images using things like containerfiles, then sure maybe we need a new extension. But for now we just want to build/push images.

If we just add a new sub-config item and leave just a container-image-docker extension, then we're only changing a little bit in a couple of methods within DockerProcessor.

Thoughts?

[geoand]

(maybe quarkus.docker.podman.*?)

This is rather unintuitive.

I would do one of the following:

• keep the extension as it and do nothing but update the docs.

• split up the existing docker extension into a base and a docker specific one, then build a podman one on top of the base one

[edeandrea]

Yeah I agree that quarkus.docker.podman.* isn't intuitive.

Really everything works out of the box just by setting quarkus.docker.executable-name=podman EXCEPT for building multi-arch images. For that, the sequence of commands is different between docker buildx & podman. Thats where the differentiation would need to be.

I like the idea of stripping out common stuff from container-image-docker. Probably 95% of whats there now would be common.

It would basically come down to

if (buildingMultiArchImages) {
    if executable-name == docker then do these steps
    else if executable-name == podman then do these steps instead
}

Everything else would remain exactly the same.

[edeandrea]

What about if I only have a single processor, but 2 sets of config items

1. The current quarkus.docker config item
2. A new quarkus.podman config item

Then the processor brings in both, errors out if both are configured, then goes down the correct path. Maybe there are 2 processors with a base class that has shared logic, but ulitimately only quarkus.docker.* or quarkus.podman.* can be configured at any given time, unless we allow them to use something like quarkus.container-image.builder=docker|podman for them to say which they want to use.

[edeandrea]

i'll throw something together and do a draft PR and we can discuss/review and make any changes. Might be easier that way so there's something concrete rather than talking in the abstract.

[geoand]

What about if I only have a single processor, but 2 sets of config items

I think that's suboptimal because a user that wants podman would just add that extension to the classpath and the tooling can help autocomplete the necessary properties.

[edeandrea]

a user that wants podman would just add that extension to the classpath

Are you saying that it should be split into 2 completely separate extensions (container-image-docker and container-image-podman)? Or keep a single extension (container-image-docker) and just do some refactoring and add some new config?

[geoand]

I'm saying that I propose two different extensions (that can share code however), or just keep things as they are and simply document what users should do when using podman

[edeandrea]

or just keep things as they are and simply document what users should do when using podman

If they want to build multi-arch images, they can not do this currently using the container-image-docker extension. There would need to be changes to allow that feature. So 2 extensions it is.