I’ll add to best of my knowledge,
The ‘master’ Win setup I did in ~May does not have docker Desktop running in background, yet soon as I open Ubuntu then w/in 30s I see GEA online in Losant and of course the docker losant container running in Ubuntu (docker container ls). Pretty cool!
And tho I don’t know which edge workflow version, believe it may still be using {{agentEnvironment.LOCAL_HOST}}.
Whereas this ‘new’ setup w/ Desktop doesn’t show GEA online (nor container running in Ubuntu) unless I first open Desktop (which takes a couple minutes itself), not to mention the resources thing from above. Definitely clunkier…
In the Windows testing we did in our lab, we received the same Cannot resolve host error that you’re receiving. $(hostname).localdoes resolve correctly in the WSL terminal, but does not resolve from within our Docker container. After a bit of research, we found that Docker Desktop adds the host.docker.internal hostname, which resolves correctly.
kubernetes.docker.internal may also exist, but only if you’ve enabled Kubernetes in Docker Desktop. This DNS entry points to the cluster endpoint and is where you can access the Kubernetes control plane.
I did notice that /etc/resolve.conf in the WSL environment contains the same IP that host.docker.internal resolves to.
So, another approach is to mount /etc/resolve.conf into the Docker contain using the -v argument. That file can then be parsed by your workflow to obtain the IP address. I don’t think this IP will change since it points to a virtual adapter, but I’m not 100% sure. If it were to change, my guess is that it would only change on reboot, in which case when your container restarts it will receive an updated value.
When you have a moment, can you please paste the contents of /etc/resolve.conf so I can confirm we’re seeing the same thing? You can get it by running the following command in a WSL terminal:
Ok so I wondered why my hands wanted to type ‘resolv’ vs ‘resolve’ and then remembered I tried this earlier too.
cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.19.160.1
In some exciting news I did roll back to GEA 1.37.0 (running in Ubuntu Docker 23.0.1 + {{agentEnvironment.LOCAL_HOST}} for SQL node svr address), and wow - works without Windows Docker!
Means I can see things happening in debug window of GEA workflow with no apparent error…
Now how to bring this up for current versions of Docker, GEA?
Affirmative,
I even reset the machine and went to latest docker (24.0.6) and stayed on GEA 1.37.0 still using {{agentEnvironment.LOCAL_HOST}}, and works great, no Win Docker (again, whew).
And are you using the Alpine build (docker pull losant/edge-agent:1.37.0-alpine) or the regular version (docker pull losant/edge-agent:1.37.0)?
I’m trying to pinpoint where the problematic change was here; I would more expect hostname resolution issues to be tied to different Docker versions vs.GEA versions but if it is working for you in that GEA version regardless of Docker version, that may point to something.
