Consider making `DockerClient` an interface

[bsideup]

Hi.

To be able to use jib-core on environments where there is no Docker CLI installed, or programmatically (e.g. with Testcontainers), it would be helpful to be able to provide a custom implementation of DockerClient that will be using the REST API, for instance.

It seems to me that the interface will have the following methods:

• load(ImageTarball, Consumer<Long>) for uploading the tarball to the daemon
• save(ImageReference, Path, Consumer<Long>) for downloading images from the daemon
• inspect(ImageReference) to get various detauls

Not necessarily but nice to have: an optional docker-java-based implementation that does not require the CLI to be installed.

[chanseokoh]

Hi @bsideup,

Thanks for the feedback. I believe you are talking about turning the DockerClient class into a Java interface, right?

Technically it's easy to turn it into an interface, but the class is an internal one, and when we move off from Java 8 (which I don't think will happen within a couple years), the class will become hidden and inaccessible through JPMS enforcement (though maybe there will be a way for others to force opening it). Only open will be the classes under the .api packages after Java 8. For all others, they will just be internal classes that we don't want people to use (although we will probably end up revisiting the API when we move to JPMS). Will this matter to you? What exactly the current problem is, and how will making the class an interface help?

an optional docker-java-based implementation that does not require the CLI to be installed.

For this, we have #1997 (though this is not a priority for us). Help always wanted.

[loosebazooka]

@bsideup because this requires us to rethink what we expose, does this workaround make sense for you: build a TarImage instead of a DockerDaemonImage and load that your own way into the docker daemon?

[bsideup]

@chanseokoh @loosebazooka please excuse me for not following up - I missed the notifications :(

What exactly the current problem is, and how will making the class an interface help?

If you make it an interface, I could provide an implementation that uses docker-java (potentially instantiated by Testcontainers), so that Jib can be used on systems where Docker CLI is not available, or fine tune the client (e.g. point it to a remove Docker daemon over some exotic transport)

For this, we have #1997 (though this is not a priority for us). Help always wanted.

I will look at it, thanks!

@loosebazooka build a TarImage instead of a DockerDaemonImage and load that your own way into the docker daemon?

That could work. Although, by the time I submitted the issue, I think there wasn't such API, unless I am mistaken.

[loosebazooka]

If you're using jib-core: https://github.com/GoogleContainerTools/jib/blob/196813099fa0294cfc70e72db59ade80ed33a7db/jib-core/src/main/java/com/google/cloud/tools/jib/api/Containerizer.java#L103

Also available as a task in the plugins

• maven https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#build-an-image-tarball
• gradle https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#build-an-image-tarball

[chanseokoh]

so that Jib can be used on systems where Docker CLI is not available, or fine tune the client (e.g. point it to a remove Docker daemon over some exotic transport)

If this helps at all: although it still requires a Docker CLI, you can set <dockerClient><environment> to pass environment variables to the CLI (such as DOCKER_HOST or DOCKER_TLS_VERIFY) to connect to a remote Docker daemon.

[chanseokoh]

Oh, for jib-core, you can set the variables via DockerDaemonImage.setDockerEnvironment().

[bsideup]

@chanseokoh unfortunately it does not help, because:

1. I may not have Docker CLI on the host
2. I may need to communicate over an established communication tunnel that cannot be represented with DOCKER_HOST and other environment variables

[chanseokoh]

Ref: https://github.com/GoogleContainerTools/jib/issues/3571#issuecomment-1037107437

[JoeWang1127]

Closing as part of cleanup. Please re-open if it's still relevant

[elefeint]

This was completed in #3703.