Can't access service from host when `.up()` is used in SDK, but works w/ dagger function chaining.

[fleet bridge]

Hey all,

Wondering if I'm doing something wrong here. I have a service I want to expose to the host (for local testing), and I've encountered something kinda strange.

What happens is, if I use container.asService(...).up(), the service is unresponsive and no traffic makes it to the service (for argument's sake, this is port 8888).

However, if I run dagger call my_func --my-arg arg up, the service is accessible on localhost.

I'm curious; is this known behavior/why is this the case? I am on OS X, by the way.

Also; I was curious if it was possible to expose more than one service to the host at the same time.

[meager cradle]

@fleet bridge this is because of Dagger's sandboxing. When you call Service.up(), the service is exposed in the client's context. When you call up from your CLI, that's your host system's context. But when you call it from your dagger function's code, it's the linux container running your function. For safety reasons a function cannot interact with the caller's system.

To be specific, when you call up() from inside your dagger function, that allows you to connect directly to the service with native code running in the function.

(for example you could start a postgres DB, then connect to it with a postgres client library)

[fleet bridge]

thank you for helping me understand how it works!

[meager cradle]

@fleet bridge you're not the only one who got confused 🙂 We're discussing ways to make it more intuitive.