Feature Request - build to docker without docker binary

Description of the issue: The docker build requires docker CLI to load the image built by jib to the docker daemon. It would be great if you could remove this dependency by implementing a simple HTTP post of the tarball to a configurable target. Example with curl:

curl --unix-socket /var/run/docker.sock --header "Content-Type: application/x-tar" --data-binary "@target/jib-image.tar" http://localhost/images/load

So far the communication flavours that I am aware of are:

• HTTP via unix socket (example above)
• HTTP via TCP
• HTTPS via TCP
• HTTP via windows named pipe

Expected behavior: Being able to build to docker without a docker binary installed.

[eddumelendez]

Hi,

I will be taking care of this implementation. I would like to discuss the following approach

1. Use com.github.docker-java:docker-java-transport-zerodep to deal with the communication and do not reinvent the wheel
2. turn DockerClient into an interface with 4 method signatures mode, save, load and inspect and create a DefaultDockerClient which is mostly the existing DockerClient but implementing it
3. add a new implementation for DockerClient call SocketDockerClient???
4. Register DefaultDockerClient and SocketDockerClient via SPI
5. Add a new argument mode for gradle, maven where options are default or socket. support for jib-cli can be added later.

This option allows to ship jib with both supports. It also enables to add new dependency to the plugin in maven and gradle and add the custom implementation via SPI. I was also looking at the plugin framework but doesn’t seem to resolve this part and adding support for it can be a big one.

Looking forward to hear from you.

[eddumelendez]

Does that library work without any Docker component in host or target?

right, no docker installation is required. It talks directly to the daemon that it is configured.

Isn’t the current implementation cli? What is the difference between default and cli?

yes, by cli I meant jib cli 😄

Sounds good. Add DockerClient interface to com.google.cloud.ttools.jib.api package. Instead of mode(), consider naming it supported() or some such to allow for inferring whether an implementation is supported from environment, and not just direct user directive. This will cover @dimovelev 's suggestions. Not sure what parameters make sense for supported() – perhaps a simple map? Either way, you’ll have to figure out how to best pass the mode from CommonCliOptions available in Containerizers.create() down to Containerizer.to().

It makes sense to me. Thanks for the feedback! I just wanted to make it explicitly for the user instead of make it work under the hood with not much aware but given the parameters that are needed we can implement what was suggested.

Default and CLI will start out the same, right? Might as well only allow “socket” and “cli”, and document that “cli” is default.

yes

I would also propose to do multiple steps, where the first step is to make Jib’s DockerClient part of the public API, to enable “bring your own client” 👍

this sounds a great approach