Open nareshkhatri81 opened 6 years ago
Environmental variables contains host ip address which we should use to connect to naming service.
Recommend hitting the http reverse proxy instead of trying to package up the runtime inside the container (this of course presumes your workload is speaking http).
We do have better support for that coming soon, but in the meantime you rarely need it. There's http APIs for everything.
@masnider Thanks for update. We are using reverse proxy for external clients(web) to connect to our micro services which are hosted in service fabric cluster. Reverse proxy doesn't have any way to customization like number of times to retry, retry patterns like (Circuit breaker) etc. Those can be achieved using Naming service SDK.
@masnider How to access reverse proxy from inside container? I cannot find doc on that. localhost does not seem to work, and it seems like I need to find out the gateway IP with some boring code, and use it to access the reverse proxy on host VM. However, that breaks when the reverse proxy uses HTTPS, which is our production setup.
@qrli - There are some environmental variables configured inside containers which contains gateway ip address to connect to reverse proxy. But i was not able to read those in C#.
Hello Team,
we tried of using naming service SDK inside containers but it was having dependency of runtime assemblies.
we tried with below approach of loading service fabric runtime inside containers which worked and we are able to use SDK now but couple of things like we are not able to read environmental variables which are setup by these two exes.
C:\SFFabricBin\vc14_redist.x64.exe -quiet C:\SFFabricBin\vcredist_x64.exe -quiet
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-services-inside-containers
our webapis runs under IIS. we logged issue with servercore team, but they need to know how environmental variables are set inside those exe.
https://github.com/Microsoft/iis-docker/issues/75
Thanks, Naresh Khatri.