Don't require the docker client to be present

[Michael-F-Bryan]

I'm trying to use cross in my CI jobs to cross-compile a library so I can provide precompiled binaries to my users. It looks like cross currently shells out to the docker program, meaning you need to have the client installed on your machine in order to use cross.

I know there's at least one docker client available on crates.io. What are your thoughts on trying to use something like that instead of requiring the docker client to be installed?

[jamesmunns]

Hey @Michael-F-Bryan, I'm open to the idea, but would not know how to implement that. I would be happy to review a PR for it though!

[Alexhuszagh]

rust-docker currently hasn't been maintained in over 7 years, and we support much more than just Docker now (including podman, and I've gotten Lima to work as well), and this still requires a docker daemon running. It uses the try! macro as well, so it's well before Rust 1.0.

Not all container engines with a CLI API compatible with Docker will necessarily use a client/server architecture, and we'd have to listen on different endpoints. For example, podman by default doesn't use expose a socket for an HTTP API in rootless mode, although it can if enabled. For example, we'd need to probe the following locations, and support an entirely different API:

• /var/run/docker.sock
• /run/user/$UID/podman/podman.sock

$ curl --unix-socket /run/user/1000/podman/podman.sock http://localhost/v1.41/images/json

We'd also need to support the following tools:

• docker inspect
• docker run
• docker cp
• docker exec
• docker images
• docker stop
• docker volume
• docker rm
• docker ps

A lot of this is due to remote Docker support. I'm not entirely sure if that's worth it. We may be able to support this if CROSS_CONTAINER_ENGINE_SOCKET was provided, but it would be a lot of code.

Probably the best solution now would be to use bollard, but because this has numerous dependencies with major compile-time overhead, it would require feature-gating it. We'd also need to make sure this other code-path does not go out-of-sync with our default code.

If anyone wants to contribute, that would be great, but it would need:

• Wrappers for commands to ensure our CLI and bollard-based APIs would be identical
• Be feature-gated
• Provide an API for the socket/gateway path
• Tests to ensure it works

Other downsides include that it would not work with lima (except when emulating docker/podman) and likely other container engines.

[Alexhuszagh]

This might still be possible, we just need to add on the following requirements:

• docker build (optionally, with buildkit): Docker::build_image
• docker inspect: Docker::inspect_container
• docker run Docker::start_container, Docker::create_exec, and Docker::start_exec
• docker cp (unsure)
• docker exec: same as docker run
• docker images: Docker::list_images
• docker stop: Docker::stop_container
• docker volume: Docker::list_volumes, Docker::remove_volume, and Docker::prune_volumes
• docker rm: Docker::remove_container
• docker ps: Docker::list_containers

Would require CROSS_CONTAINER_ENGINE_SOCKET or assuming the defaults. In short, everything could be done via bollard, I believe.

The steps required would be as follows:

1. Convert into api, shell, and client submodules in the docker docker module.
2. Structify the data that needs to be passed.
3. Create API functions that automatically call the shell variant.

Then, when implementing client:

1. Feature gate client.
2. Implement into for the structified data to the bollard structs.
3. Implement client API functions.
4. Change api to use shell or client depending on some environment variable or config option if the client feature is enabled.

This is doable, and maybe less work than initially imagined.