#Tilt-like workflows thread, let's roll

1 messages · Page 1 of 1 (latest)

quick ore
#

How might I wire a debugger into said container under this approach?

#

Consider our example earlier. DaggerSession1 runs the kube process. DaggerSession2 is a golang app, that is my app, let's call it ToDoListApp. I want a local dev experience that is kube-first. I run DaggerSession1 to start kube, then I start DaggerSession2 to run ToDoListApp, build and publish to the container registry, and deploy into DaggerSession1's kube

#

Is there anything special I might need to do to expose a debugging port in DaggerSession2?

#

Just thinking out loud here a few different options, I could run my debugger in daggersession2, or as a service in daggersession1 kube, and expose the port to host. I'm not sure which way would be harder to work with

fast heath
#

Is there anything special I might need to do to expose a debugging port in DaggerSession2?

no, as long as your k8s service is exposing the debugger port, you can use the same service tunneling capabilities to connect from your local machine

#

you could also run kubectl proxy from another session against your kube cluster and tunnel that

#

there's multiple options

#

how does tilt currently do it?

quick ore
#

vanilla port forwarding is how you might do it with tilt, similar to docker compose watch. Tilt itself i is agnostic and doesn't have debugger specific configuration. For the purposes of this discussion we can probably say that tilt is analagous to docker compose watch, but for kube