To kick things off for 2017, the cloud team at Octopus are getting stuck into a popular UserVoice suggestion: Azure Service Fabric!
The purpose of this RFC is to discuss integrated support for deployments to Azure Service Fabric from Octopus Deploy. If there's a specific sub-feature of Service Fabric you're hoping to see, now's the perfect time to get involved and let us know whether we're on the right track.
What is Azure Service Fabric?
Microsoft explains it best in their overview:
Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable micro-services. Service Fabric also addresses the significant challenges in developing and managing cloud applications. Developers and administrators can avoid complex infrastructure problems and focus on implementing mission-critical, demanding workloads that are scalable, reliable, and manageable. Service Fabric represents the next-generation middleware platform for building and managing these enterprise-class, tier-1, cloud-scale applications.
During this discussion, there are two different concepts related to the noun
The first is what Octopus Deploy considers a Package in its package feed, which will be referred to as a NuGet/zip package.
The second is a package in the context of the Azure Service Fabric application package, which will simply be referred to as a package (for those familiar with Service Fabric, this is essentially what you feed to the
ApplicationPackagePath argument of the Service Fabric PowerShell Cmdlets).
A new step template
The proposed solution would rely on deployment of a NuGet/zip packaged Service Fabric Application. The required content of the NuGet/zip package will be discussed here. However, creation of the NuGet/zip package is a build responsibility and, as such, lies outside of the scope of this discussion.
Assuming your SF Application included two services, ServiceA and ServiceB, the NuGet/zip package would have content with the following file/folder structure:
The step would include the following inputs:
- User interface options for the various flags available in the default
Deploy-FabricApplication.ps1file (this file is included in all Service Fabric projects)
The proposed step template UI is as follows:
The deployment process would:
- Unpack the package content
- Perform variable substitutions in the
PublishProfilesxml files (we'll most likely consider variable replacement for all .xml/.config files in the extracted package)
- Use a bundled version of the Azure Service Fabric SDK and PowerShell scripts (NOTE: we are still investigating what's involved here)
- To stay consistent with the existing Azure PowerShell modules, you will be able to use a custom version of the Azure Fabric SDK if you wish by setting a system variable Octopus.Action.Azure.UseBundledAzurePowerShellModules to False, which will then use the version of the SDK installed on your Octopus Server
DeployAzureFabricApplication.ps1, which will be bundled as part of Calamari
- Like Calamari's Azure Cloud Services script](https://github.com/OctopusDeploy/Calamari/blob/master/source/Calamari.Azure/Scripts/DeployAzureCloudService.ps1), you will be able to override this script in your NuGet/zip package and customise it if you wish
Versioning NuGet/zip packages with Octopus and Service Fabric application creates an interesting discussion point, because versioning in Service Fabric is Code and Config per Service, per Application. In other words, if you’re publishing a new NuGet/zip package version from Octopus, you will need to be sure you understand how versioning and upgrades work with Azure Service Fabric applications to ensure minimal (or no) downtime.
We are still actively investigating how Octopus will best handle this. We don't know the answer yet :)
This is your chance to guide the development of this feature.
Would this be useful to you?
Is there anything on your wishlist that we haven't mentioned?