[FEATURE] docker context support

[developer-guy]

Signed-off-by: Batuhan Apaydın batuhan.apaydin@trendyol.com

What

I realized that when we work with different Docker Daemons running on remote hosts by using the Docker Context feature, k3d couldn't get corresponding Docker Daemon information properly.

Why

I tried the same demo with the KinD tool, and because it is using docker with an exec call, it works well with different Docker Contexts. So k3d should also be working too.

This PR fixes #593.

Implications

This PR comes with a lot of updates within the vendor directory.

[iwilltry42]

Hi @developer-guy , I really don't know why I didn't look into this again so far, sorry!
Can you please update the PR to use main-v5 as the base?

[iwilltry42]

Fixed the conflicts and merged it manually. Thanks for your contribution @developer-guy !

[iwilltry42]

Unfortunately, this breaks when using a non-tcp docker context (e.g. SSH). 🤔
Can you create a follow-up PR for this, please?

UPDATE: came up with this PR #674, but couldn't test it with TLS secured docker endpoint. Can you give this a try please @developer-guy ?

[jawabuu]

Hey @iwilltry42
Does this merge support HTTP docker hosts e.g.

DOCKER_HOST=localhost:2375

Currently k3d returns this

Failed Cluster Preparation: Failed Network Preparation: error during connect: Get "https://localhost:2375/v1.24/networks?filters=%7B%22name%22%3A%7B%22%5E%2F%3Fk3d-k3s-default%24%22%3Atrue%7D%7D": http: server gave HTTP response to HTTPS client

[iwilltry42]

Hi @jawabuu , I'm currently testing with #674 (follow-up PR for this), so results might differ slightly.
I created a docker-in-docker container locally and ran the docker daemon on a remote physical server.
Those options worked:

• unix://
• ssh://
• tcp:// (which is implied, if you don't specify a protocol) <- this is what you have

The only thing I didn't test successfully yet is a TLS protected daemon process.

UPDATE 1: now also tested with TLS (via context) 👍