connhelper: Allow socket path when using SSH

[panekj]

- What I did

Modified connhelper to allow socket path in SSH URI

- How I did it

Removed error if path is specified when using ssh:// scheme
Added capture of URI Path
Append --host flag with formatted socket path as unix://%s between passed args

- How to verify it

Run below

Linux/macOS:

DOCKER_HOST='ssh://host/var/run/docker.sock' docker system info

Windows

$env:DOCKER_HOST='ssh://host/var/run/docker.sock'
docker system info

- Description for the changelog

Allow specifying socket path when connecting via SSH

- A picture of a cute animal (not mandatory but encouraged)

[panekj]

alternative impl, since Args() can receive arguments other than docker but I don't know how likely that is, if it happens at all

	case "ssh":
		sp, err := ssh.ParseURL(daemonURL)
		if err != nil {
			return nil, errors.Wrap(err, "ssh host connection is not valid")
		}
		return &ConnectionHelper{
			Dialer: func(ctx context.Context, network, addr string) (net.Conn, error) {
				args := []string{"docker"}
				if sp.Path != "" {
					args = append(args, "--host", fmt.Sprintf("unix://%s", sp.Path))
				}
				args = append(args, "system", "dial-stdio")
				return commandconn.New(ctx, "ssh", append(sshFlags, sp.Args(args...)...)...)
			},
			Host: "http://docker.example.com",
		}, nil
	}

[thaJeztah]

Do you have a specific use-case for this? IIUC, the current design was for the remote CLI to already be configured to connect to a specific socket location (/var/run/docker.sock by default, but could be different if set in ~/.docker/config.json). This PR would mean that the remote CLI would control the remote CLI "on-the-fly" to connect to a different path?

[panekj]

I didn't knew it could be set in config but that would not help if I have multiple daemons running on the remote host, since I would have to change the config each time before connecting.
With this change I can keep it as a simple context or use on-demand via DOCKER_HOST

[panekj]

This PR would mean that the remote CLI would control the remote CLI "on-the-fly" to connect to a different path?

Basically, yes.

[neersighted]

I'm also skeptical of this method and the format. Giving a special meaning to the colon character is not great (and do we already support :port?), and trying to configure the remote CLI seems a bit fraught. It feels to me like a context or at least a URL anchor/query might be better ways to encode and represent this, if it's even desirable.

[neersighted]

I took a closer look at this diff, and this is a lot more palatable now that I see this is not in fact a microformat, but instead simply using standard URL parsing logic ala Git. user@host:port/path/to/docker.sock will work, as will user@host:/path/to/docker.sock.

However, I think that Args definitely needs refactoring. It now only works in terms of the docker CLI, and hardcodes knowledge that the path to the CLI will be the first field of add. That should become more generic (or maybe we should set DOCKER_HOST instead as SSH always invokes a shell) to make this maintainable.

[panekj]

I took a closer look at this diff, and this is a lot more palatable now that I see this is not in fact a microformat, but instead simply using standard URL parsing logic ala Git. user@host:port/path/to/docker.sock will work, as will user@host:/path/to/docker.sock.

This has been a well established format for all tools that are based on SSH (ssh, scp, git, etc.)

[panekj]

However, I think that Args definitely needs refactoring.

I would be glad to leave that work for whoever has better understanding of whole codebase and vision for the feature (and more time to do it).

[neersighted]

Yes, your examples have a null port (user@host:/path) which is misleading, a simple user@host/path example could have been used. Now that that is clear, my objections are addressed. Your alternate proposed implementation that keeps the --host concern out of the Args function looks much better; could you please push that version up for further discussion?

[panekj]

Yes, your examples have a null port (user@host:/path) which is misleading

Sorry, it's my unfortunate habit if typing the URI :)

[thaJeztah]

LGTM

@neersighted @laurazard LGTY?