How does WithHostname is supposed to work

[pearl ivy]

I'm trying to use WithHostname because serviceBinding isn't the right solution to handle services in the DockerSDK.

However, it seems my services are not reachables and I do not understand why... Here's a simple repro:

package main

import (
    "context"
    "dagger/test/internal/dagger"
)

type Test struct{}

func (t *Test) Test(ctx context.Context) *dagger.Container {
    _, err := dag.Container().
        From("redis:alpine").
        WithEnvVariable("ALLOW_EMPTY_PASSWORD", "yes").
        WithExposedPort(6379).
        AsService(dagger.ContainerAsServiceOpts{UseEntrypoint: true}).
        WithHostname("redis").
        Start(ctx)
    if err != nil {
        panic(err)
    }
    secondService := dag.Container().From("alpine").WithExec([]string{"apk", "add", "redis"})

    return secondService
}

$ dagger call test terminal

x> redis-cli -h redis
Could not connect to Redis at redis:6379: Name does not resolve

It works if I try with service binding, and according to the test in Dagger (https://github.com/dagger/dagger/blob/6227e68b9a484890a7494eb879d711cebb477e60/core/integration/services_test.go#L169), I would expect my test to work 😦

/cc @harsh dune @meager spire

Not that the service is running according to the traces: https://v3.dagger.cloud/Quartz/traces/4a8dfe17e35a9f4a7b3c70a724867d6b

Funny things, if I type the full service hostname (redis.b93s2i1huiomi.22ubvu0rhfd1m.dagger.local), I can connect to the service, why is that so?

[rotund ibex]

@pearl ivy I think Terminal doesn't play very well with WithHostname

can you try calling redis -h redis ping in a WithExec in your pipeline and check if that works?

[pearl ivy]

It works

Okay, if that's the only issue I think it's okay

I don't need terminal in my docker sdk implementation, it was just to test, I'll update my code to not with serviceBinding but simply hostname

Oh yeah, is there a way to set multiple hostnames??

In case of docker compose, you can either access a service by its container's name or its service name

services:
  backend: # http://backend:XXX
    container_name: api # http://api:XXX

[rotund ibex]

nope, only one can be currently set

[pearl ivy]

One of my problem is that I have a compose with both, and that uses both

[pearl ivy]

Hmm sad

Well then there's one case that I can't support in my implementation

[rotund ibex]

that's fine I guess

does compose allow setting multiple aliases for the same service?

or it only sets those two and that's it?

the container name I'd say it's not a "feature" of compose but basically how Docker networking works

it'd be analogous as using the default dagger service endpoint

[pearl ivy]

These 2 only afaik

[rotund ibex]

I think we're good then

compose users generally use the service name

which is what we want with the WithHostname

[pearl ivy]

But I have an example with a ELK where logstack reach ES with http://es but kibana is looking for http://elasticsearch, that's why I wanted to expose both

I guess this example with simply not work, while it actually does with docker-compose cli

[rotund ibex]

https://github.com/dagger/dagger/issues/9473

[pearl ivy]

ty

[rotund ibex]

lol that's strange.. but yeah I see why some examples could break

well.. adding multiple hostnames should be possible then

[pearl ivy]

Would be nice yes

[rotund ibex]

cc @meager spire @lean jolt do you see any drawbacks on adding multiple hostname support via WithHostname?

[pearl ivy]

Seems like it's also not with with services

I'll do a repro

[meager spire]

Nope! Seems easy

[pearl ivy]

This one is quite critical: https://github.com/dagger/dagger/issues/9473
It also fails for running services, I added a repro in a comment

@meager spire Could you help me fix that one today? It's a blocker for dockerSDK :/
Is there any files I should look at to begin with

[meager spire]

hostnames have pretty strict namespacing requirements to prevent leaking their use outside of the originating module; that might be "by design" at the moment

does it behave any differently if you call .Terminal() from within the module and return that, instead of calling terminal from the outside?

[pearl ivy]

I'll test, that's a very good question

[pearl ivy]

It works when using inside Terminal()

I'll try with services to see if that's the same

[meager spire]

i lied - this might not be easy, looks like buildkit only supports configuring one hostname. but, theoretically we could do something out of band with our dnsmasq setup

[pearl ivy]

Seems like it works too if I returns asService instead of doing a container.Up

[rotund ibex]

nice! So the main blocker is the multi-host thing, now?

[pearl ivy]

It's not a nice workaround since it limits the DX of docker-compose because you can't interact with the container you're running nor add extra things (so it's strickly the same as docker-compose and dagger doesn't add much values...) but that will do for now I guess

And yeah multi-hostname would be nice but it's an edge case I guess that we I can document

Or I'll just keep using withServiceBinding for now I think, it's not as good as withHostname but it's better that limitting the DX

Until we correctly handle hostname outside module for terminal/service

[lean jolt]

What's the limit to the DX?

[meager spire]

(side note: seeing if I can get https://github.com/cline/cline to implement multi-hostname support while I work on other things, kinda fun)

[rotund ibex]

are you using it from the IDE or CLI?

[meager spire]

IDE (VScode)

could sure use some sandboxing though, it's working out of my same src/dagger dir so it's kinda held hostage 😛

(i could just give it a separate dir, but what's the fun in that)