So after I got my Standalone Service Fabric Cluster setup and working I decided the Unsecure template wasn’t good enough and I wanted to try my hand at the x509 template. I went through the entire process (I’ll post on that later) however I was unable to access the Service Fabric Administration Console nor was I able to connect via PowerShell…even from a client that had the x509 certificate installed!
So, like a dog walking back with its tail between its legs I decided to just get going and get up and productive using the Unsecure template. However after Removing the x509 cluster, cleaning up the Service Fabric installation, and re-creating the Unsecure cluster, I was back again able to connect to the Administrative Console (port 19080) but not able to connect via PowerShell (port 19000).
The really strange part is that the Cluster Administration Site works but I can’t connect through PowerShell from my development workstation. The error that I was getting was as follows:
WARNING: Failed to contact Naming Service. Attempting to contact Failover Manager Service…
WARNING: Failed to contact Failover Manager Service, Attempting to contact FMM…
WARNING: No connection could be made because the target machine actively refused it 192.168.1.117:19000
Connect-ServiceFabricCluster : No cluster endpoint is reachable, please check if there is connectivity/firewall/DNS
At line:1 char:1
+ Connect-ServiceFabricCluster 192.168.1.117:19000
+ CategoryInfo : InvalidOperation: (:) [Connect-ServiceFabricCluster], FabricException
+ FullyQualifiedErrorId : TestClusterConnectionErrorId,Microsoft.ServiceFabric.Powershell.ConnectCluster
So I went back and tried to see if I could connect locally from the server itself. I had to install the Service Fabric SDK on the server and the Azure PowerShell cmdlets just for good measure.
Flawless. However, I figured I would try using the server’s own IP Address. Surely it would resolve, no? However, I find that doesn’t work even on the local machine!
This got me thinking. I used the original DevCluster configuration and I recalled that in this file the ‘ipAddress’ for each of my nodes was set to ‘localhost’.
Now, I’m going to change the cluster config and see if that fixes anything.
First I remove the Unsecure cluster.
Then I call clean up.
This is the first time this happened so it might have something to do with me installing the Service Fabric SDK.
After uninstalling IIS and rebooting it appears to be cleared out…
Now I modify the Unsecure template file to use my server’s intended IP address.
Saved it as a different template file so I don’t mess with the original DevCluster config.
Run the cluster installation.
Verify that I can access the console locally and remotely…
Sometimes it takes a bit of time before everything is up and running and reporting healthy…
Eventually it all comes online…
Attempt to access remotely using PowerShell…
It works! So it looks like leaving ‘localhost’ in the DevCluster is really only for local development and if you want your cluster to be accessible from a remote machine you need to specify a different endpoint.