Expose ports from the inside | Dagger | Page 1

hushed tree Jan 10, 2025, 12:46 AM

#

No don't think so, up is also synchronous so I think you'd just end up blocking on the "inner up" and never hit the "outer up", unless I'm missing something

#

Depending on exactly what the overall goal/use-case is, there might be a better way of accomplishing this

tough pine Jan 10, 2025, 1:23 AM

#

I guess the use case would be for a service to expose its ports from the outside in the case where it's dagger-aware

#

So that the special case where 1) your dagger client is running in a nested dagger container, and 2) you call Service.up in that nested session, that propagates to your own container exposing those ports. Just like if the parent called withExposedPort() on your container, except it doesn't need to, because the withExec or asService that is running your client, took care of it

#

(messy explanation sorry)

#

Actually I have often wished docker supported this: you're running a shell in a dev container, running new stuff - forgot to expose a port - but too late, you have to re-run the whole thing because you're missing -p and there's no way to expose a new port "from the inside"

exotic pebble Jan 10, 2025, 5:59 AM

#

Not once the service has started, but if you call up from the service type after it's defined, you can get the ports from the service by calling service.ports?

#

so if you have a module that returns *Service, you can call Ports on it to get the exposed ports 🤔

#

cc @tough pine

#

also the *Containertype has ExposedPorts() which gives you the same thing

tough pine Jan 10, 2025, 6:06 AM

#

But I want to expose the ports from inside the container

exotic pebble Jan 10, 2025, 6:07 AM

#

tough pine But I want to expose the ports from inside the container

I think the proxymodule will work for that?

#

you can wrap the inner service in a proxy and expose that to the host

tough pine Jan 10, 2025, 6:09 AM

#

that won't work, because the inner service still has exposed ports from outside the service container

#

What's possible: dag.Container().From("nginx").WithExposedPort(80).AsService() port is explicitly exposed from outside the container
What I want: dag.Container().From("my-dagger-aware-tool").AsService(dagger.ContainerAsServiceOpts{ExperimentalPrivilegedNesting: true}) -> container exposes ports for itself from the inside

#

Expose ports from the inside

exotic pebble Jan 10, 2025, 7:35 AM

#

IDK why I thought this was going to work:

// Returns a container that echoes whatever string argument is provided
func (m *Lala) Test(ctx context.Context) *dagger.Service {

    return dag.Container().From("alpine").
        WithExec([]string{"apk", "add", "curl"}).
        WithExec([]string{"sh", "-c", "curl -fsSL https://dl.dagger.io/dagger/install.sh | BIN_DIR=/usr/local/bin  sh"}).
        WithExec([]string{"sh", "-c", "dagger core container from --address nginx with-exposed-port --port 80 up"}, dagger.ContainerWithExecOpts{ExperimentalPrivilegedNesting: true}).
        WithExposedPort(80).AsService()

}

^ because even if the dagger core runs in a nested session, the service forwarding is user level proxy so in my head "it should" be able to forward the requests.

thing is that I can't get the above to work because there seems to be some sort of deadlook where the outer service tunnel never gets started. I have the theory this is probably because the engine / client was not designed to be able to create two tunnels from within the same session?

I'm probably missing something but I don't see why the above shouldn't work

tough pine Jan 10, 2025, 7:41 AM

#

It's just that in my case, I don't know in advance which ports will be exposed, so I can't do the WithExposedPort(80)

#

(use case is an interactive dagger shell session running inside the container, with eg. a user ssh-ing in, or a LLM remote-controling it, and at any time they can decide to run eg. dagger core container from --address nginx with-exposed-port --port FOOBAR up

exotic pebble Jan 10, 2025, 11:47 AM

#

tough pine It's just that in my case, I don't know in advance which ports will be exposed, ...

But what you really care is the frontend port that will ultimately be exposed in the inner container and you can instruct the LLM to always use the same frontend port?

exotic pebble Jan 10, 2025, 12:57 PM

#

Solomon this also works fwiw:

func (m *Lala) Test(ctx context.Context) string {

    go func() {
        dag.Container().From("alpine").
            WithExec([]string{"apk", "add", "curl"}).
            WithExec([]string{"sh", "-c", "curl -fsSL https://dl.dagger.io/dagger/install.sh | BIN_DIR=/usr/local/bin  sh"}).
            WithEnvVariable("CACHE", time.Now().String()).
            WithExec([]string{"sh", "-c", "dagger core container from --address nginx with-exposed-port --port 80 as-service with-hostname --hostname web up"}, dagger.ContainerWithExecOpts{ExperimentalPrivilegedNesting: true}).Sync(ctx)
    }()

    var out string
    for {

        var err error
        out, err = dag.Container().From("alpine").
            WithExec([]string{"apk", "add", "curl"}).
            WithEnvVariable("CACHE", time.Now().String()).
            WithExec([]string{"curl", "-f", "http://web"}).Stdout(ctx)
        if err == nil {
            break
        }
    }
    return out

}

I've stopgapped the deadlock by removing the outer service and using with-hostname instead. Not sure if this gives you any other ideas.

#Expose ports from the inside