[Service Fabric] Azure Service Fabric with Azure Diagnostics and Nlog log retrieval

I was recently working with a customer where we were migrating some of their Azure Cloud Services over to Azure Service Fabric.

Within their current Cloud Services, there is a process where NLog will drop a log file to a Local Resource folder. Azure Diagnostics is then used to pick up this log file and place it in a container in Azure storage for another process to pick up for processing.

With Service Fabric, we do not have the same concept of a Local Resource folder. Also, with Service Fabric, or more importantly Azure Resource Manager deployments, the only way to set Azure Diagnostics settings is to do this through an ARM template.

In order to get the NLog process of dropping the file to a folder to work, the following JSON code has to be added to the ARM template:

clip_image001

In order to find where to put the above code, you need to find the Service Fabric VM Scale set cluster (shown below in Visual Studio), select it, then in the JSON code, scroll down to where you see “publisher” : “Microsoft.Azure.Diagnostics”:

clip_image002

The blob storage account, blob container name, node folder and VM Scale set node name can be parameterized for more flexibility.

At this point in time, what cannot be parameterized or modified is how Azure Diagnostics places the file in to the blob container. Azure Diagnostics setups up a specific folder structure under the container that looks like this:

clip_image003

For more information on some of the differences between Cloud Services and Service Fabric, check out:

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-differences

 

Hope this helps you in your work with Azure Service Fabric!

[Service Fabric] Connecting to a remote Azure Service Fabric cluster using PowerShell

If you have struggled with getting the syntax and parameters correct on the Connect-ServiceFabricCluster PowerShell cmdlet like I have, I’ve decided to post the command with associated parameters that I know works every time.

This command is typically used to test connectivity from your personal machine to a .X509 secured cluster in Azure.

$ClusterName= “<your-full-cluster-name>:19000”

$CertThumbprint= “<your-certificate-thumbprint>”

Connect-ServiceFabricCluster -ConnectionEndpoint $ClusterName -KeepAliveIntervalInSec 10 `    -X509Credential `

    -ServerCertThumbprint $CertThumbprint  `

    -FindType FindByThumbprint `

    -FindValue $CertThumbprint `

    -StoreLocation CurrentUser `

    -StoreName My

Upon successful connection, you should see something similar to

clip_image001

Hope this helps you in your work with Azure Service Fabric!

[Service Fabric] The signed in user is not assigned to a role for the application

If you have setup an Azure Service Fabric cluster and secured it using Azure Active directory, you may run in to the same problem I did when I went to deploy an application from Visual Studio 2015. You can refer back to my other post on this if you are not sure how this is setup https://blogs.msdn.microsoft.com/ncdevguy/2016/12/21/securing-an-azure-service-fabric-cluster-with-azure-active-directory-via-the-azure-portal/.

In Visual Studio, whenever you publish an application to the cluster, you will be prompted to log in to Azure with your Azure subscription credentials. As you can see in the screenshot, you will see both your certificate thumbprint and AzureActiveDirectory = true.

clip_image001

Since I had all this setup, I then attempted to deploy the application. The deployment failed and I was presented with this error in the Visual Studio output window.

1>—— Build started: Project: HealthApp, Configuration: Debug x64 ——

2>—— Publish started: Project: HealthApp, Configuration: Debug x64 ——

2>AADSTS50105: The signed in user is not assigned to a role for the application ‘1458052a-a261-4d8a-8bf3-e7529ce62ba8’.

2>Trace ID: 4b8ad5d7-94e3-456d-a0f8-13a13144eb9d

2>Correlation ID: 75cddc9f-f9af-405f-8593-42af6dfd8c85

2>Timestamp: 2016-12-14 19:58:18Z

As you may recall, when you do a publish, you have to log in to your Azure subscription from the publish dialog box.

If these log in credentials, or rather this user, is not also assigned the Admin role in AAD for the web client app, then Visual Studio will not be able to connect to the cluster and therefore can’t do a publish. Normally you will add specific users that are assigned the Admin and Read-Only user roles for the app and it can be easy to forget to setup app permissions for the user logging in to Azure.

So, add that subscription user as an Admin for the Web Client app in AAD.

You should now be able to deploy the application to your secure cluster in Azure.

Hope this helps you in your work with Azure Service Fabric!

[Service Fabric] Unable to determine whether the application is installed on the cluster or not

 

I was working with a customer that was attempting to deploy a simple Service Fabric application from within Visual Studio 2015 to a secure cluster in Azure.

The cluster itself was secured via an .X509 certificate stored in Azure Key Vault. There were currently no applications deployed to the Azure cluster.

When we opened up the publish dialog in Visual Studio, the first thing we noticed was the red circular ‘x’ icon over to the right of the name of the cluster endpoint address. The error message shown here is actually a pretty common one that can be caused by connectivity issues with the remote cluster ‘Failed to contact the server. Please try again later or get help from “How to configure secure connections”

clip_image001

 

We decided first to confirm that the thumbprint was correct and that it was installed on the machine from where the deployment was being attempted.

We then decided to go ahead and attempt to publish the app to the Azure cluster just to see what happens and see what error message appears. In the output window, we saw this:

 

1>—— Build started: Project: HealthApp, Configuration: Debug x64 ——

2>—— Publish started: Project: HealthApp, Configuration: Debug x64 ——

2>Unable to determine whether the application is installed on the cluster or not

========== Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped ==========

========== Publish: 0 succeeded, 1 failed, 0 skipped ==========

 

Strange error. Was Visual Studio actually connecting to the cluster and then could not confirm that the app was there or was Visual Studio actually NOT connecting to the cluster so of course, it could not determine if the app was there?

To make sure that from the deployment machine we could actually connect to the cluster, we opened PowerShell ISE (as an administrator) and ran the following command:

 

$ClusterName= “myclustername.eastus.cloudapp.azure.com:19000”

$CertThumbprint= “<my-certificate-thumbprint>”

Connect-serviceFabricCluster -ConnectionEndpoint $ClusterName -KeepAliveIntervalInSec 10 `

-X509Credential `

-ServerCertThumbprint $CertThumbprint `

-FindType FindByThumbprint `

-FindValue $CertThumbprint `

-StoreLocation CurrentUser `

-StoreName My

 

We confirmed cluster connectivity:

clip_image002

What ensued over the next few hours were redeployments of certificates, testing other apps for deployment, testing from other machines.

 

Eventually we discovered that the problem was there was a hidden white space in front of the value for the thumbprint in the publish dialog:

clip_image003

And when I say hidden, I mean there was no indication at all that there was anything there. Until we manually re-entered the certificate thumbprint and tried a new deployment, it still appeared that Visual Studio did not have connectivity to the cluster. Once we deployed successfully, the red icon went away.

 

Hope this helps you in your work with Azure Service Fabric!

[Service Fabric] Default service descriptions must not be modified as part of an upgrade

Recently (Service Fabric SDK v 2.4.145) I had deployed a Service Fabric application to my local cluster from Visual Studio. As part of an upgrade process after I changed something in the Settings.xml file for my service, I was executing the following PowerShell code:

 

Connect-ServiceFabricCluster localhost:19000

  Copy-ServiceFabricApplicationPackage -ApplicationPackagePath ‘.’ `

-ImageStoreConnectionString ‘file:C:\SfDevCluster\Data\ImageStoreShare‘ -ApplicationPackagePathInImageStore ‘SFConfigModified’

 Register-ServiceFabricApplicationType -ApplicationPathInImageStore ‘SFConfigModified’ -TimeoutSec 300

Start-ServiceFabricApplicationUpgrade `

-ApplicationName ‘fabric:/SFConfigModified’ `

-ApplicationTypeVersion ‘1.0.17’ `

-Monitored `

-ForceRestart `

-FailureAction Rollback

This is when I received the following error in the PowerShell command window:

 

Registering application type…

Register application type succeeded

Start-ServiceFabricApplicationUpgrade : Default service descriptions must not be modified as

part of upgrade. Modified default service: fabric:/SFConfigModified/StatelessWebApi

At C:\Workshops\AzureSF\HelperFiles\testconfigchanged.ps1:13 char:1

+ Start-ServiceFabricApplicationUpgrade `

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (Microsoft.Servi…usterConnection:ClusterConne

ction) [Start-ServiceFabricApplicationUpgrade], FabricException

+ FullyQualifiedErrorId : UpgradeApplicationErrorId,Microsoft.ServiceFabric.Powershell.Star

tApplicationUpgrade

 

For some reason, the upgrade thinks I have modified my ApplicationManifest.xml file in the <DefaultServices> section, although I know I did not modify it.

 

I have discovered that this issue is something that will be corrected in the near future, but how do you get this working again to be able to do updates from PowerShell?

 

Here is what I had to do to get things working again:

  1. Open Service Fabric Explorer and remove the application from the cluster.
  2. In my PS script, after the Register-ServiceFabricApplicationType command, execute the command to do a new deployment:
    New-ServiceFabricApplication -ApplicationName ‘fabric:/SFConfigModified’ -ApplicationTypeName ‘SFConfigModifiedType’ -ApplicationTypeVersion 1.0.15
  3. Comment out the New-ServiceFabricApplication line of code.

 

From this point on, I could do upgrades to my application.