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?
A single Service Fabric node type/scale set can not contain more than 100 nodes/VMs. To scale a cluster beyond 100 nodes, add additional node types.
Azure Service Fabric is Microsoft's platform-as-a-service (PaaS) and is used to build and deploy microservices-based cloud applications.
Service Fabric uses partitions as the scaling mechanism to distribute workloads to different service instances. A partition can have one or more replicas. Service Fabric uses replicas as the availability mechanism. A partition has one primary replica and may have multiple secondary replicas.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With