Search code examples
powershellazure-service-fabric

Temporarily disabling default services in servicefabric using powershell

The concrete question

For those who just want the direct questions:

  • Is there a way to temporarily disable default services on a ServiceFabric application type so that a new application can be installed (using Powershell) without automatically installing any default services?
  • A proposed solution here is to remove the default services from the manifest and later restoring them. I am able to write a PowerShell script to adjust the application manifest accordingly, but how do I update the application type using Powershell - assuming I already have altered the manifest?

Any solution that solves the contextual problem without requiring manual config meddling is acceptable - my proposed solution is probably not the only possible solution. We do explicitly want to avoid manual meddling.

When allowing meddling, we are already able to just comment out the default services when we need to. We're specifically looking for a solution that requires no meddling as this reduces bugs and debugging issues.

The context

I'm running into an issue with using the application manifest's default services during local development.

I am aware of the general "don't use default services" advice, and it is being followed. During CI build, the default services are removed and will not be relied upon for any of our clusters in Azure. The only exception here is local developer machines, which use default services to keep the developer F5 experience nicer by enabling all services when starting a debug session.

We have written specialized scripts that provision a new tenant (SF application) with their own set of services (SF service). Not every tenant should get every service, we want to opt-in to the services, which is what the script already does (based on a mapping that we manage elsewhere, which is not part of the current question as the provisioning script exists and works).

However, when default services are enabled, every tenant already gets every service and the actual opt-in provisioning is useless. This is the issue we're trying to fix.
This same script works in our production cluster since there are no default services configured there. The question is solely focus on the local development environment.

Essentially, we're dealing with two scenarios during local development:

  • When debugging, we want the default services to be on because it allows us to run all of our services by pressing F5 (and not requiring any further action)
  • When testing our provisioning script, we don't want default services because it gets in the way of our selective provisioning behavior

I'm aware that commenting the default services out of the manifest solves the issue, but this requires developers constantly toggling the content of the manifest and reinstalling the application type, which we'd like to avoid.
Ideally, we want to have the default services in the manifest (as is currently the case) but then have the provisioning script "disable" the default services for its own runtime (and restore the default services before exiting), as this gets us the desired behavior in both cases.

What is the solution that requires the least manual developer meddling to get the desired behavior in both scenarios?

I'm currently trying to implement it so that the provisioning script:

  1. Copies the application manifest to a backup location
  2. Removes the default services from the real manifest
  3. Updates the application type using the new manifest (i.e. without default services)
  4. Runs the provisioning logic
  5. Restores the real manifest using the backup manifest from step 1
  6. Updates the application type using the restored manifest (i.e. with default services)

It is specifically steps 3 and 6 that I do not know how to implement.

Solution

  • Consider having two sfproj projects in the solution. One with default services, one without.

    Also look into using a start-service.ps1 script instead of default services. This way the two projects can use the same application manifest.

    https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-debugging-your-application#running-a-script-as-part-of-debugging