#rust - Troubleshooting `host.docker.internal` from Dagger container (access to local KinD cluster)

1 messages · Page 1 of 1 (latest)

drifting pollen
#

I'd be grateful for any assistance or advice accessing host.docker.internal from within my Dagger containers (my goal is to deploy to a local KinD cluster from Dagger). Note that I'm using the experimental Rust SDK, which I understand may limit the features and knobs I have access to.

System:

  • Ubuntu 18.04 LTS
  • Dagger SDK: Rust
  • Dagger engine image: registry.dagger.io/engine v0.8.4 as installed by Rust SDK
#

Steps:

Start with Dagger engine installed by the SDK:

CONTAINER ID   IMAGE                              COMMAND                  CREATED              STATUS              PORTS                       NAMES
6673b26d7d87   registry.dagger.io/engine:v0.8.4   "dagger-entrypoint.s…"   About a minute ago   Up About a minute                               dagger-engine-5097823f019aa092
5dbc5b6e5af5   kindest/node:v1.27.3               "/usr/local/bin/entr…"   36 hours ago    Up 19 minutes   127.0.0.1:40113->6443/tcp   kind-control-plane

As expected, host.docker.internal is not available automatically on Linux:

docker exec -it 61a2c128d6cb /bin/sh
/ # ping host.docker.internal
ping: bad address 'host.docker.internal'

Stop/remove the container, re-run with --add-host=host.docker.internal:host-gateway, and verify that host.docker.internal resolves within the Dagger Engine container proper (but not necessarily in Dagger API 'Containers'):

docker stop 6673b26d7d87; docker rm 6673b26d7d87

docker run -d --add-host=host.docker.internal:host-gateway --name dagger-engine-5097823f019aa092 --privileged registry.dagger.io/engine:v0.8.4

Container list again:

CONTAINER ID   IMAGE                              COMMAND                  CREATED          STATUS          PORTS                       NAMES
08406023da01   registry.dagger.io/engine:v0.8.4   "dagger-entrypoint.s…"   32 seconds ago   Up 31 seconds                               dagger-engine-5097823f019aa092
5dbc5b6e5af5   kindest/node:v1.27.3               "/usr/local/bin/entr…"   36 hours ago    Up 19 minutes   127.0.0.1:40113->6443/tcp   kind-control-plane

docker exec -it 08406023da01 /bin/sh

/ # ping host.docker.internal
PING host.docker.internal (172.17.0.1): 56 data bytes
64 bytes from 172.17.0.1: seq=0 ttl=64 time=0.125 ms
#

But host.docker.internal still doesn't resolve within Dagger API containers, when querying from the SDK (dagger run cargo run):

#[tokio::main]
async fn main() -> color_eyre::eyre::Result<()> {

    let client = dagger_sdk::connect().await?;

    let container = client.container().from("ubuntu:latest")
        .with_exec(vec!["apt-get", "-y", "update"])
        .with_exec(vec!["apt-get", "-y", "install", "iputils-ping"])
        .with_exec(vec!["ping", "host.docker.internal"]); // Fails with `ping: host.docker.internal: Name of service not known`

    let _stdout = container.stdout().await?;

    Ok(())
}
#

Am I missing a step, or could this be a bug on my machine/installation?

Zooming out, I'm aware host.docker.internal has been brought up here as a workaround for local registries, but is it the recommended approach for accessing locally published host services in general? And are there other approaches to accessing local KinD clusters rather than host.docker.internal? I've seen discussion here about setting up kind or k3s from within Dagger as service containers, but my goal to deploy to a cluster running locally outside of Dagger. It looks like this was once a supported use-case a supported use-case, but not sure what kind of configuration was required, or if the goals/assumptions around networking with the host have changed since then.

Thanks all!!

GitHub
Setup Kind cluster in CI by TomChv · Pull Request #337 · dagger/da...

Change
Setup a local kind kubernetes in the CI to test kubernetes deployment.
The setup lasts between 1 minute 30 and 2 minutes

misty needle