Service Fabric: Constructing service context for Guest Executables with Environment Variables
Continuing with the theme of the previous article, my goal was to find a way to simulate feature parity of guest executables with the first-class support for C# applications. C# applications are provided a ServiceContext object and also have the FabricRuntime.GetCodePackageActivationContext() which gives lots of information about the package, node, etc but I could not find any documentation on how construct this information for Guest Executables.
In my previous article I showed how to read the <Package>.Endpoints.txt file to construct the listening address for the guest executable enabling them to use the assigned port. This was a big deal since without dynamic port assignment you would only be able to have 1 instance of the service running per node basically making Service Fabric unusable for non C# languages.
After playing around some more I realized there would probably be some information hidden in the environment variables of the host process. If you recall all services have a service manifest which specify a SetupEntryPoint and EntryPoint such as below:
These executables are invoked by a host process called FabricHost.exe. This mans it’s possible for the host process to setup service specific environment variables for the execution of the specific service instead of only exposing those directly on the node.
I updated my Express application to expose the environment variables and compared them with those on my actual machine and compared the differences. Here are the extra data you can use:
You can see it’s missing stuff that would be needed to construct the end point like protocol, scheme, uri prefix, etc so I think we would still have to use Endpoints.txt which is slower than reading environment variables, but at least it’s only a one time initialization cost. Notable additions are ApplicationName, NodeName, Username which would be valuable to know in logs when troubleshooting which node or application has a failure.
That being said, I was a little let down there isn’t more information here. Given that they already are adding custom variables for guest executables you think it would be trivial to add more important things like service name, individual versions, etc or whatever needed to completely match capabilities of the C# programs. Once work around might be to hard code these custom environment variables inside the ServiceManifest. It is kind of dual maintenance but at least the information will be available.
Anyways, hope that helps unblock some use-cases for Guest Executables.