#enabling dag.Host()

1 messages · Page 1 of 1 (latest)

cedar frigate
#

oh and the code

// Run the GitHub Webhook Listener
func (m *GithubWebhooks) Listen() (*dagger.Service, error) {
    http.HandleFunc("/", handler)
    err := http.ListenAndServe(":8080", nil)
    if err != nil {
        return nil, err
    }
    return dag.Host().Service([]dagger.PortForward{{Backend: 8080}}), nil
}

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World!")
}
#

the goal is to take that http.ListenAndServe in the runtime container and return it as a dagger.Service

cedar frigate
#

update on this

  • the "hanging" I was seeing was really not hanging and working as intended lol. I needed a go http.ListenAndServe facepalm
  • @shy citrus helped get past some broken type things on the llm branch
  • Trying to get through tunneling to non-Container services is not supported. Maybe the tunnel needs to get created with Native: true? I haven't figured out yet where to wire that through without breaking things
shy citrus
#

hrm don't think native: true would help there, that just configures how to select ports (frontend == backend)

cedar frigate
#

ah got it. Maybe there's a way to set svc.Container to the runtime container?

shy citrus
#

what are you trying to tunnel?

cedar frigate
shy citrus
#

slightly surprised it ended up down that code path, but i haven't been following extremely closely

cedar frigate
#

maybe there's an easier way?

shy citrus
#

where does the tunnel come in? thinkies oh, are you calling up on the outside?

cedar frigate
#

yes exactly

shy citrus
#

so the goal is to start a service in the container, and then serve traffic to it through the (outer) host network?

cedar frigate
#

yes. If there's any other way to do that, I'm in

#

I don't specifically care about host.service

shy citrus
#

i think i also wanted that recently haha

#

hmmmm

cedar frigate
#

yeah feels like a common enough use case

shy citrus
#

the problem is the module function is trying to do two things: 1) run a service indefinitely, but then 2) return the service from the function. right now 2) implies the function exits, hence no 1)

cedar frigate
#

ah true

shy citrus
#

trying to think of any gymnastics to get around it, but conceptually that feels confusing at least

cedar frigate
#

maybe some way to pass the http.Serve as a callback to some dag function

shy citrus
#

maybe a good topic for the core dev architecture chat in 10mins 😛

shy citrus
cedar frigate
#

my specific use case is to run a go webserver that listens for github webhook events and depending on the event call different functions in my module. So there's no good way to just run that in a container in my module. Maybe if there's some dagger-in-dagger in the service container calling a second module for the event functions... but 🤮

shy citrus
#

technically i think we could have a function that "returns" (i.e. makes the internal API calls that return a value from a function) but then doesn't actually exit, but it would probably require some SDK changes, e.g. to wait on your http.ListenAndServe goroutine instead of just exiting from main()

#

not sure how it would look in other languages

#

seems plausible though

cedar frigate
shy citrus
#

don't think so. it would be started fresh, and it wouldn't be told to run the service

#

(core dev chat starting)

shy citrus
#

(cc @trail monolith - this is the thread if you wanna follow along)

#

the basic idea we came up with was to have a way to ✨somehow✨ turn any object that implements serve: Void (aka Serve(context.Context) error) into a Service

no idea if that's feasible on a demo timeline - maybe with some hacks. ideally we'd have self-calls for this, but we can get by without it

cedar frigate
#

sounds great! i'll push forward on other demos for now but I'm eager to try this out!

slate junco
#

There's another possible route maybe - if we made all core types interfaces like we discussed - maybe the module type could implement Service?

#

I guess that doesn't really help since either way, your function has to return, and there's no way for long-running code started by a dagger function to outlive its function

#

Feels like maybe the "start a container, let it call dagger-in-dagger" route is more realistic? But then the limitation is self-calls

cedar frigate
#

Yeah I can go forward with the dagger-in-dagger and see how bad it really looks. Maybe I can abstract some of the bad parts away so it doesn't look scary

slate junco
#

I think making the server a standalone go program (not a dagger module), in a sub-package, with a dagger.json with dependencies on modules you want to call + generated client to call them from the standalone server, will really help clean it up

#

then the remaining problem (besides plumbing the above) is: which module? I think actually Tom got "self calls" to work in generated client so it might be possible for the standalone server at ./pkg/webhook-server to call ./foo-module

#

it might just work