Service Fabric reverse proxy port configurability

Question

I'm trying to write an encapsulation to get the uri for a local reverse proxy for service fabric and I'm having a hard time deciding how I want to approach configurability for the port (known as "HttpApplicationGatewayEndpoint" in the service manifest or "reverseProxyEndpointPort" in the arm template). The best way I've thought to do it would be to call "GetClusterManifestAsync" from the fabric client and parse it from there, but I'm also not a fan of that for a few reasons. For one, the call returns a string xml blob, which isn't guarded against changes to the manifest schema. I've also not yet found a way to query the cluster manager to find out which node type I'm currently on, so if for some silly reason the cluster has multiple node types and each one has a different reverse proxy port (just being a defensive coder here), that could potentially fail. It seems like an awful lot of effort to go through to dynamically discover that port number, and I've definitely missed things in the fabric api before, so any suggestions on how to approach this issue?

Edit:

I'm seeing from the example project that it's getting the port number from a config package in the service. I would rather not have to do it that way as then I'm going to have to write a ton of boilerplate for every service that'll need to use this to read configs and pass this around. Since this is more or less a constant at runtime then it seems to me like this could be treated as such and fetched somewhere from the fabric client?

Answer 1

After some time spent in the object browser I was able to find the various pieces I needed to make this properly.

public class ReverseProxyPortResolver
{
    /// <summary>
    /// Represents the port that the current fabric node is configured
    /// to use when using a reverse proxy on localhost
    /// </summary>
    public static AsyncLazy<int> ReverseProxyPort = new AsyncLazy<int>(async ()=>
    {
        //Get the cluster manifest from the fabric client & deserialize it into a hardened object
        ClusterManifestType deserializedManifest;
        using (var cl = new FabricClient())
        {
            var manifestStr = await cl.ClusterManager.GetClusterManifestAsync().ConfigureAwait(false);
            var serializer = new XmlSerializer(typeof(ClusterManifestType));

            using (var reader = new StringReader(manifestStr))
            {
                deserializedManifest = (ClusterManifestType)serializer.Deserialize(reader);
            }
        }

        //Fetch the setting from the correct node type
        var nodeType = GetNodeType();
        var nodeTypeSettings = deserializedManifest.NodeTypes.Single(x => x.Name.Equals(nodeType));
        return int.Parse(nodeTypeSettings.Endpoints.HttpApplicationGatewayEndpoint.Port);
    });

    private static string GetNodeType()
    {
        try
        {
            return FabricRuntime.GetNodeContext().NodeType;
        }
        catch (FabricConnectionDeniedException)
        {
            //this code was invoked from a non-fabric started application
            //likely a unit test
            return "NodeType0";
        }

    }
}

News to me in this investigation was that all of the schemas for any of the service fabric xml is squirreled away in an assembly named System.Fabric.Management.ServiceModel.