7

I have a Service Fabric application with multiple services that can be configured for "Dev", "Test", "Stage" and "Production" on Azure.

My goal is to have 1 cluster for my "Test" & "Stage" environments and another for "Production". The obvious reason is for cost savings!

I am using Visual Studio Online Build/Release. Here is where I am running into issues:

I can update my configuration settings for "Stage" and deploy to my cluster - however since the application name is going to be the same as the existing "Test" application it overwrites that application on that cluster with the new configuration updates for "Stage".

Obviously I can "Create App Instance" from within Service Fabric Explorer - but there are no ways for me to inject new configurations that way - only to set a new name for that instance, which would run another instance configured the same as the base.

So I thought - OK, I'll just upload new versions with different configurations and deploy instances from Explorer - but not only does this seem messy, it still attempts to upgrade the existing application I have running.

I also need to reconfigure my ports per service withing each application instance so that they can all live in the same cluster and behind the same load balancer, but there does not seem to be a way to override the node in the ServiceManifest....

So my question is: What is there a best practice for managing and isolating multiple application instances with separate configurations and service ports so that you can have one configured for "Test" and another for "Stage" and have both live in the same cluster?

INNVTV
  • 3,155
  • 7
  • 37
  • 71
  • I am doing exactly the same like you for the same reason. Is there any word of wisdom or article that helped you with this? – Adam Aug 29 '17 at 19:04

3 Answers3

8

You're on the right track. I always recommend one cluster for dev/test/staging and a separate cluster for production.

The trick is in fact to create new application instances for each deployment and provide new configuration values through Application Parameters. Service Fabric Explorer doesn't expose this yet, but you can do it using the SF management APIs:

Creating new application types or versions for each environment is messy and not really the intended use case.

Vaclav Turecek
  • 9,020
  • 24
  • 29
  • 2
    Thanks Vaclav. Is there a road map for when this will be exposed within SF Explorer? I'm assuming this scenario requires setting up a different port id for any services that require them per configuration? Is there any documentation on how to best achieve this? – INNVTV Apr 17 '17 at 22:25
1

I've managed to do this using ApplicationParameter xml files and choose the right one during deployment in VSTS. This, for example, is my Cloud.xml which I use for deployment to my test environment. The trick is the Name parameter on the second line. I've specified the port using this documentation: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-how-to-specify-port-number-using-parameters

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/DotNetCoreTest" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="Web1_InstanceCount" Value="2" />
    <Parameter Name="ServiceEndpoint_PortNumber" Value="8909" />
  </Parameters>
</Application>

This is the xml file for Staging: Staging.xml

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/DotNetCoreStaging" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="Web1_InstanceCount" Value="2" />
    <Parameter Name="ServiceEndpoint_PortNumber" Value="8910" />
  </Parameters>
</Application>
E. Staal
  • 525
  • 5
  • 18
0

For now i have been doing it by having 2 copies of Solutions in which i will be changing the below parameters

  1. ApplicationTypeName in ApplicationManifest.xml inside ApplicationPackageRoot folder
  2. Name in Cloud.xml file inside ApplicationParameters folder.
  3. Port in ServiceManifest.xml file inside PackageRoot folder of WebAPI project.

Let me know if there is a better way to do it, since i have to deploy the .NET application into Linux Service Fabric Cluster. I cant do it using Visual Studio.

Gnana Selvan
  • 61
  • 7