What is the correct way to obtain the DNS of another service?

[atrauzzi]

Let's say I have this:

var minio = builder
    .AddContainer("minio", "minio/minio")
    .WithEnvironment("MINIO_ROOT_USER", "blah")
    .WithEnvironment("MINIO_ROOT_PASSWORD", "blah")
    .WithVolume("storage", "/minio")
    .WithArgs(["server", "--console-address", $"0.0.0.0:{minioConsolePort}", "--address", $"0.0.0.0:{minioApiPort}", "--compat", "/minio"])
    .WithHttpEndpoint(minioConsolePort, minioConsolePort, "console")
    .WithHttpEndpoint(minioApiPort, minioApiPort, "api")
    .WithExternalHttpEndpoints()
;

var proxy = builder
    .AddContainer("nginx-proxy", "nginx")
    .WithBindMount("./nginx.linux.conf", "/etc/nginx/nginx.conf", true)
    .WithBindMount("./ssl.pem", "/keys/ssl.pem")
    .WithBindMount("./ssl.key", "/keys/ssl.key")
    .WithHttpsEndpoint(443, 443)
    .WithReference(minio.GetEndpoint("console"))
    .WithExternalHttpEndpoints()
;

Given that I'm running nginx, would this be the correct way of referring to the service?

server {
        listen 80;
        listen 443 ssl;
        server_name ~^minio\.(.*)\.localdev\.com$;

        location / {

            proxy_read_timeout 1200;
            proxy_connect_timeout 1200;
            proxy_send_timeout 1200;

            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

            set $backend "http:https://_console.minio:8075";

            proxy_intercept_errors on;
            proxy_pass $backend;
            proxy_pass_request_headers on;
            proxy_set_header Host $host;
        }
    }

(apologies for rookie mistakes, I've been spending this last little bit finally sharpening up on Aspire after Build 2024 😉 )

[davidfowl]

The correct way is using environment variables, but nginx configuration doesn't readily support environment variables in all of the places so the next best thing is hardcoding ports.

            set $backend "http:https://host.docker.interal:8075";

We'll need to built-in support for rewriting files with env variables within bind mounts for containers.

[davidfowl]

#4192

[atrauzzi]

Subscribed! 🙂

[atrauzzi]

Hmm, on a closer look, @davidfowl -- I'm still not able to configure my nginx proxy to point to the running container. I've tried just about every combination of hostnames and static IPs that are common in these scenarios...

If I'm running on linux, with rootless podman (pasta networking mode??)... What would I have to tell nginx to forward to?

Historically I've been able to use host mode networking and then of course 127.0.0.1 works. I suspect Aspire is not using that, so each running container must be getting its own IP and when I am doing WithReference, it's granting visibility? Do I need to set a resolver for nginx?

[danegsta]

Currently the containers are running on the default Docker network, so localhost in your nginx container will only refer to that specific container instance.

One option that may work to unblock you in the short term would be to create a custom Docker bridge network with docker network create <network name> and use the .WithContainerRuntimeArgs method to manually attach your service container to the network with a well known name (.WithContainerRuntimeArgs("--network", "<network name>", "--network-alias", "console.minio")) and attach nginx to the same network (.WithContainerRuntimeArgs("--network", "<network name>")). That should let you resolve the service within the nginx container via console.minio:{minioConsolePort}.

[atrauzzi]

@danegsta - Could I use those args to toggle host networking in any way?

[danegsta]

You could try setting "--network", "host" via the same RuntimeArgs override method, but I'm suspicious we'll start throwing service endpoint errors as that's not a scenario we currently support; there's definitely some code that assumes containers are running attached to a Docker bridge network.

[atrauzzi]

Ah, and just per your last comment, there's no visibility facilitated between containers? (by default 🙂 )

[danegsta]

Yeah, we don't currently setup anything for container-to-container networking, but it's something we know we need to improve on; I'm hopeful that we'll introduce some improvements to the container-to-container experience soon, but I expect it'll be an ongoing process to continually improve the experience for Docker CE and Podman users to get as much parity as we can between every supported container runtime.

[atrauzzi]

Gotcha! :)
Please make sure to give podman both on linux and on Windows priority. The weather has really shifted against Docker. The (large, multinational) company I'm at has a "no more Docker" policy which I suspect is becoming more the norm.

[atrauzzi]

@danegsta -- Last followup I think... Any idea what I'd have to provide for resolver in my nginx config?

[atrauzzi]

Hah, nevermind, I was wildly trying different IPs and 10.89.0.1 seemed to work!