In module, how do you expose a service from the Host for Container.Publish()?

[gusty skiff]

I've been trying to POC some mass builds that we have to do where there are four or 5 parent containers that are mixed and matched in several ways resulting in hundreds of downstream containers. I'd like to cache these containers locally with something like docker run -p 5000:5000 registry:3 That way all the downstream functions can utilize the same registry for reusable components. However if I try to pass something like container | from alpine | publish localhost:5000 it fails as refused.

I also tried something like utilizing tailscale to give it a publicly resolvable address:
container | from alpine | publish registry.<random>.ts.net and it looks like it is bypassing the wireguard endpoint on my host.

Anyone have a guide or something I could reference to figure this out? Or should I just use a public registry and be done with it?

I've also tried things like this, but this only exposes the service into the container, not to the container.Publish command

// Start and return an HTTP service
func (m *MyModule) HttpService() *dagger.Service {
        return dag.Container().
                From("registry").
                WithExposedPort(5000).
                AsService()
}

// Send a request to an HTTP service and return the response
func (m *MyModule) Get(ctx context.Context) (string, error) {
        return dag.Container().
                From("alpine").
                WithServiceBinding("registry", m.HttpService()).
                WithExec([]string{"wget", "-O-", "http://registry:5000/v2/_catalog"}).
                WithExec([]string{"wget", "-O-", "http://registry.<random>.ts.net:5000/v2/_catalog"}).
                Stdout(ctx)
}

[true zodiac]

@gusty skiff if all this is running within the same engine there's no need to cache the intermediate containers in a registry given that everything will be cached internally by dagger.

This way, when re-using that same container in other parts of the pipeline, it'll be retrieved from the dagger cache automatically

[gusty skiff]

That does make sense. I'm trying somewhat to avoid a bit of refactoring the dockerfiles which always reference HEAD^ container.

It would also allow rebuilding a child directly if the parents didn't already exist

but maybe that's a bit convoluted

It probably also just suggests to use a real registry and not just a throw away one

[true zodiac]

Yes, exactly. This is also handled by Dagger automatically. If that dockerfile container has been built by any other parts of the pipeline or past pipelines, it'll be re-used unless anything invalidated the cache for which it has to be re-built. Otherwise, it'll be built on-demand if not found in the cache

having an external registry is generally a convenient solution when running a pipeline that needs to spread across multiple engines for different reasons (hardware, network requirements, etc)