Register Docker Application in Eureka with "preferIpAddress": true

[Isuama]

When I register application in IIS and point it to Eureka as shown in this sample, it properly works with these parameters in appsetting.json. "eureka": { "client": { "serviceUrl": "http://172.15.100.155:8761/eureka/", "shouldFetchRegistry": false }, "instance": { "port": 8091, "hostName": "fortune_service", "ipAddress": "http://172.15.100.11",

  "preferIpAddress": true
  // Remove comments to enable SSL requests
  // More changes in Program.cs are required if using direct C2C communications
  //,"securePortEnabled": true
}

}

When I point cursor over the Eureka Status it shows me the status url (IP I have given above)

But when I run application as a Docker and retrieve value from Confi-Server, it get registered with a dynamic IP for the status and I am unable to discover registered URL. Kindly expect help from someone.

[Isuama]

I found that application get registered in Eureka with the docker container IP rather than the IP I have used in the configuration.

[dtillman]

@Isuama : I pushed a Fortune Teller sample solution that has Docker enabled that should help you understand how to set this up. The sample was created using the built-in Visual Studio tooling for Docker and Docker compose. I added the Eureka service to the docker compose file so it starts up when you run the Fortune Teller sample using Docker compose.

https://github.com/SteeltoeOSS/Samples/tree/dev/Discovery/src/AspDotNetCoreDocker

Hope that helps.

Dave

[Isuama]

Thank you @dtillman. I guess what you have done was, exposing the same port inside the docker container and consuming the same port from outside. What I have found out, it was an issue from Steeltoe Discover Client as it always takes the host IP rather than the ipAddress mentioned in yml. It doesn't make any sense registering the IP, but in our case we needed it badly. If we run docker command with the -h it solves the problem. But it is a workaround for us until Steeltoe fixes that. Appreciate your response.

[dtillman]

@Isuama,

If you need to control what is registered in eureka, then you can set registrationMethod=hostName and then put a value in the hostName setting (DNS or IP address). That is what will end up getting registered in the eureka server and ultimately retrieved and used by the client.

As a FYI, in the sample I used docker-compose (DC) to run the FORTUNE-TELLER-UI, the FORTUNE-TELLER-SERVICE, and the Eureka server ( I just used a standard VS2017 project with Docker compose enabled).

DC creates a network with all those services running with-in it and makes networking very easy so you don't have to worry about the details. The DC network has a built-in hostname resolution service so all the registration/lookup happens on the DC network using names and addresses defined there. I also exposed each of the services(UI, eureka, etc) to the host using port mapping so you can access each container from a browser on the host. I probably could have not exposed the F-T-Service to the host since the communications from the UI to the F-T-Services is done on the DC network...but I elected to do so for testing.

Let me know if the above "hostName" doesn't work for you! Doc Link for registrationMethod Dave

[reeshuai]

I also encountered the same problem.

[Isuama]

@Isuama,

If you need to control what is registered in eureka, then you can set registrationMethod=hostName and then put a value in the hostName setting (DNS or IP address). That is what will end up getting registered in the eureka server and ultimately retrieved and used by the client.

As a FYI, in the sample I used docker-compose (DC) to run the FORTUNE-TELLER-UI, the FORTUNE-TELLER-SERVICE, and the Eureka server ( I just used a standard VS2017 project with Docker compose enabled).

DC creates a network with all those services running with-in it and makes networking very easy so you don't have to worry about the details. The DC network has a built-in hostname resolution service so all the registration/lookup happens on the DC network using names and addresses defined there. I also exposed each of the services(UI, eureka, etc) to the host using port mapping so you can access each container from a browser on the host. I probably could have not exposed the F-T-Service to the host since the communications from the UI to the F-T-Services is done on the DC network...but I elected to do so for testing.

Let me know if the above "hostName" doesn't work for you! Doc Link for registrationMethod Dave

Dear Dave, Could you please explain then why they have a property like preferIpAddress and ipAddress. As per my understanding if we set preferIpAddress =true and set an IP it should work, isn't it. But trust me, It doesn't work.

[jkonicki]

This is worth investigating further and trying to address in a later release.

[bart-vmware]

I'm pretty confident this works as expected, after #1280 has been merged. I've added a test to verify:

[Fact]
public async Task ExplicitlyConfiguredIPAddressIsPreserved()
{
    var appSettings = new Dictionary<string, string?>
    {
        ["Eureka:Instance:hostName"] = "ignored-host-name",
        ["Eureka:Instance:ipAddress"] = "192.168.10.20",
        ["Eureka:Instance:preferIpAddress"] = "true"
    };

    WebApplicationBuilder builder = WebApplication.CreateBuilder();
    builder.Configuration.AddInMemoryCollection(appSettings);
    builder.Services.AddEurekaDiscoveryClient();

    await using WebApplication webApplication = builder.Build();
    var appManager = webApplication.Services.GetRequiredService<EurekaApplicationInfoManager>();

    appManager.Instance.IPAddress.Should().Be("192.168.10.20");
    appManager.Instance.HostName.Should().Be("192.168.10.20");
}

Please let me know if this is still causing problems.