Service container used inside a function but also exposed to the host

[sonic osprey]

Hi there, I watched the video https://www.youtube.com/watch?v=v7wGMP7XLJo&t=7s and I have a, potentially, silly question:

Is it possible to have a Service defined inside a function that also binds ports to the host?

I tried using the .Up() method (Go SDK) and I see from the logs that the ports should be bound but they are not accessible from the host and the container that uses it with WithServiceBinding, also the call to Up is blocking (not sure if it's my fault) so I also tried to use a goroutine to make it async but without success.

The only thing that I believe might work is to refactor the service definition into a standalone function and chain a dagger call spinup-service up && dagger call do-something-with-service --svc=tcp://....

Am I missing something?

In the video Host-container networking is mentioned so I guess the feature exists but I am doing something wrong 🙂

Thanks in advance for your help!

[icy cargo]

hey!

yes, if your Dagger function returns a *dagger.Service, then whatever ports that service exposes, will be mapped to the host automatically when you call dagger call $myfunc up

[sonic osprey]

Hi @icy cargo ! Gotcha but my question refers to the fact that I am using a *dagger.Service inside a function that returns *dagger.Container is there a way to have that service also bound to the host?

[icy cargo]

no, not currently. Module functions are by definition scoped to their inputs and outputs due to design and security considerations.

If you need your function to bind a port to the host, you need to return either a *dagger.Service or *dagger.Container which will be the one that exposes it to the host

what's the use-case here @sonic osprey?. I'd like to understand what you're trying to achieve as there might be a different way to do it

[sonic osprey]

I see, basically I am deploying a master-slave system where something running on the host is a slave service that needs to communicate with the master that is span up and managed by the dagger function call.

The slave has to perform an handshake with the master and the master will respond to that but of course for this to work I need the slave to see the master (via host networking).

I'll try refactoring the code a bit so that I can spin up the master via *dagger.Service up then I'll call, separately, the *dagger.Container that manages master (and that will have the *dagger.Service as input dependency) and waits for slave to handshake.

I guess this qualifies as an edge case 🙂

[icy cargo]

so IIUC, both the master and the slave will run as daggerized functions, correct?

when you mentioned that the slave will run in the host machine, I initially thought that the slave wasn't Daggerized also

FWIW seems like the approach you've described in your last parragraph should work

[icy cargo]

@sonic osprey there's also another option here which is starting both the master and the slave within the same Dagger pipeline and bind whichever you need to the host machine. Is this something that would be more useful in your case?

[sonic osprey]

Thanks @icy cargo for the follow-up! I need to clarify something - I may have oversimplified my setup in my previous messages because I wanted to keep it simple but I realise that I might have withheld important information, here's the full context.

The actual architecture is:

• Master runs in a service container inside a VM on the host machine
• Slave is a non-daggerized application running directly on the host machine
• The slave needs to perform a handshake with the master via host networking

My main confusion is about the difference between:

1. Calling dagger call myfunction up from CLI
2. Using *dagger.Service.Up() from within a Dagger function

It feels like they should be doing the same thing (I haven't looked at the source code yet, I will as soon as I have some spare time).

Currently, I got it working by:

1. Running dagger call master-service up in one terminal to start and expose the master service
2. Then calling another function that uses this service

While this works, it feels a bit awkward because:

• It requires manual orchestration of multiple commands
• In CI, I'll need to handle service cleanup separately (like killing the service after tests)
• It feels like we're falling back to makefile-style orchestration

Is there a more "Dagger-native" way to handle this kind of setup where I need a long-running service exposed to the host, but also need to coordinate with it from both Dagger functions and non-Dagger applications?

[icy cargo]

My main confusion is about the difference between:
Calling dagger call myfunction up from CLI
Using *dagger.Service.Up() from within a Dagger function

the difference about this is that dagger.Service.Up won't bind the ports to the host machine. The only way to achieve that is by calling dagger call myfunc up. The main reason is because functions are sandboxed and the only way to interact with the caller environment (host) is via the function inputs and outputs. This is intentional so we can keep the security model consistent

if the idea is to run this in CI, wouldn't it be better to run the slave also in Dagger so you don't have to deal with all the host <> dagger networking dance?

that way you can test the entire slave + master + whatever else you need within Dagger functions without having to bind things in the host

[sonic osprey]

I cannot run the slave in dagger because of platform constraints. Thank you a lot for your help regardless!

[icy cargo]

gotcha.. well.. there's an alternative for you as a last resort

if you're ok with not using Dagger modules / functions, you can still leverage the pure Dagger SDK and use the Host API to start the service and bind the port with a pipeline. ref: https://docs.dagger.io/api/sdk/#custom-applications

the difference is that Dagger won't provide the SDK runtime and you'll not be able to leverage the modules features for it. You can still make full use of the Dagger SDK to build and start containers and services and bind them to the local machine which will unblock you in what you're trying to achieve

LMK if that makes sense and if you have any questions

[sonic osprey]

Oh... this looks wonderful actually. I am guilty of not having RTFM 🙈. I am going to give it a spin asap. Thank you so much @icy cargo 🫡