#Dagger behind NLB 🧵
1 messages · Page 1 of 1 (latest)
Moving a proof of concept Dagger Engine setup to a module and updating it a bit.
Looking at adding TLS to the NLB, have the NLB decrypt and forward TCP to Dagger, but getting an unexpected error from the Dagger engine: Error: start engine: no driver for scheme "tls" found.
The Dagger client here is connecting to a remote engine via NLB URL which is listening on tls <port>, forwarding to a target group on tcp://<url>:<port>
I think this is the client unable to receive tls response, and I'd need to run something alongside the client to receive the tls traffic from the NLB and send tcp onto the client? Is it just suggested to not bother with TLS?
not to detract from the direction you're working on: i've had good success connecting to the docker / dagger engine using SSM (guessing you're on AWS?) https://github.com/cablehead/vibenv.dag?tab=readme-ov-file#setup
it's nice that you can go direct to the engine, while the cloud host has no inbound open ports
@frozen kayak the engine client doesn't currently allow connecting via a TLS endpoint. Mind opening an issue please?
Can do. Estimate how much work this would be?
it shouldn't have to be that much effort-wise since the engine currently allows starting with the appropriate TLS certs. Part of that logic can be taken from how our cloud provisioner works nowadays: https://github.com/dagger/dagger/blob/b9a64f6bf2dff6e9c851b9b5a73d569c163f8fa2/engine/client/drivers/cloud.go?plain=1#L31
Having said that, it's not in our top most priority to implement that now so if you're willing to contribute to it, happy to help by reviewing
Probably beyond my Go knowledge, especially with no familiarity with the Dagger codebase, but I'll take a look anyway out of curiosity
Is this already supported @vapid epoch? cmd/engine/main.go has flags for tlscert tlskey tlscacert, and getListener creates a Listener and passes that to tls.NewListener along with tlsConfig?
it's implemented on the server side but not exposed to the client