#debug connection
1 messages · Page 1 of 1 (latest)
Hey, thanks for the info.
Let me follow with a few more questions. It seems, with the connection refused that the container is unable to reach registry.local:5001.
Quick questions to isolate a bit more:
- Is your registry running locally as a docker container, a host process or in kubernetes ?
- Are you on Linux / Mac / Windows ?
- Even if it works on your host, can you try from inside docker:
docker run --rm alpine sh -c "wget -qO- https://registry.local:5001/v2/"
4.Is this registry using HTTP or HTTPS? (The error shows HTTPS but want to confirm)
I've made a repro (and I fixed it), I'm 99.999% sure it's a networking issue, that hides under the hood 2 issues:
- the hostname is not found inside the container, so you need to use docker's internal hostname (depends on mac vs linux. For example, I need to rely do
dagger -M call container from --address host.docker.internal:5001/test-image:dev terminalwherehost.docker.internalis the internal hostname on mac and on linux it's often this IP172.17.0.1.
So first step is to change the registry.local to the internal hostname I just gave above
- Then you'll hit the self signed certificates, also depends on mac vs linux. A user fixed it that way: https://github.com/dagger/dagger/issues/9683#issuecomment-2676118535
I did it that way on my Mac (here is my shell history):
$ vim ~/.config/dagger/engine.toml
$ docker ps
$ docker rm -f $(docker ps -q --filter "name=dagger-engine-*")\n
$ docker run --rm -d \\n -v /var/lib/dagger \\n -v $PWD/engine.toml:/etc/dagger/engine.toml \\n --name dagger-engine-custom \\n --privileged \\n --add-host host.docker.internal:host-gateway \\n registry.dagger.io/engine:latest
$ export _EXPERIMENTAL_DAGGER_RUNNER_HOST="docker-container://dagger-engine-custom"\n
$ dagger -M call container from --address host.docker.internal:5001/test-image:dev terminal\n
basically I create my own dagger engine with the self signed cert already set
the content of vim ~/.config/dagger/engine.toml is :
cat ~/.config/dagger/engine.toml
debug = true
[registry."host.docker.internal:5001"]
http = true
insecure = true
Last thing, I'm 99% sure that cu will follow this _EXPERIMENTAL_DAGGER_RUNNER_HOST env var. So once you make it work with just dagger, then it's just a matter of reusing this env var pointing to that custom engine (or other solution on linux) in your normal cu usage and you should be good-to-go
I've tried this on Mac & Ubuntu. The registry is running as a local docker container (in the same docker as dagger) currently on ubuntu plucky. Registry is using HTTPS, although I have tried HTTP as well. I'm pretty sure the DNS is working inside the container because it TCP dials the right IP... ah, I haven't tried the internal docker network IP. I'll have a play with that and your other suggestions and get back to you.
I've got it talking to the registry. Not sure if dagger/cu is timing out while the massive container is spun up or there is some other issue. Will have to dig into is some more tomorrow but thanks again for your help @vocal plume
Custom engine or using just the internal docker network IP ? Btw, I made a comment to start easing the configuration of insecure registries: https://github.com/dagger/dagger/pull/11019#issuecomment-3275716748. Building a custom engine is too painful atm
@vocal plume Once I knew that the "connection refused" message was definitely coming from inside the dagger container, it was much easier to debug. I ended up using the internal docker domain name for host.
I also switched back to an insecure registry to avoid having to convince dagger to trust the self-signed certs but still had to use your custom dagger engine config and the _EXPERIMENTAL_DAGGER_RUNNER_HOST env var.
@vocal plume is it possible to tell dagger to mount a volume into the cu container? The local registry makes it a lot faster and more predictable so cu isn't failing so frequently... but I'm still copying 8Gb every time I start a container and I think even Claude gets bored of that sometimes.
Mmmh unfortunately it is not and would require a bit more work on our end ... not unfeasable but requires a lot of engineering
However, when mounting the repo, we do follow the .gitignore. So I'd include into the gitigonre what's not necessary atm: https://pkg.go.dev/dagger.io/dagger#HostDirectoryOpts
That's a shame; if I could mount a populated uv cache into the container it would speed things up tremendously. Good to know about .gitignore but the problem is trying to get 8Gb of essentially static data into the container without having to wait for it to copy every time.
oouh, a uv cache, so it's probably not going to get updated by container-use ? This one could potentially be negotiable
That’s right. I don’t know if uv is happy for it to be fully read-only but it’s effectively just static data
mmh could you please file an issue ? 🙏