Linux Training in Coimbatore & Best Linux Server Administration Training Institute: Creating the secure cluster

Creating the secure cluster

Ensure you are logged in to Visual Studio with an account that can access the target subscription.

There are several ways to publish the Service Fabric Application, below are the two simplest options:

From the Build menu, select Publish Web1:

Or by right-clicking the Service Fabric Application (the one with the pretty icon partially obscured below):

Either method will display the main Publish screen:

As highlighted above, in the Connection Endpoint, you can select Create New Cluster. Doing so will launch the following screen:

As I am in the UK, I set the Location to UK South but left the other options as the defaults. Specifying a 3-node cluster will automatically denote it as a Test cluster in Azure - i.e. a cluster that is not suitable for Production use and has certain restrictions - for full details, please see the Service Fabric cluster capacity documentation.

You can either click Next to navigate to the Certificate tab or simply click the Certificate tab. Either will present the following screen:

As part of the wizard, a certificate will automatically be created in an equally automatically created Azure KeyVault – no need to do anything 😊 The Import certificate checkbox will import the certificate once created so you can immediately manage the cluster via the Service Fabric Explorer. The certificate password is not optional, I recommend you use a strong password even if the cluster is only intended for testing (as it is here).

Clicking Next or selecting the VM Detail tab will display the following:

At this point, you may notice that the Next button has changed to Create and is enabled. Don’t be fooled in to thinking you can skip the remaining options:

The current template does not list all the possible VM sizes but does cover the basics (and, the size can be changed later via the Portal / PowerShell / Azure CLI):

The Advanced tab has the following options:

As shown, ports 80 and 83 are enabled by default – I usually remove 83 (as I avoid using non-standard ports for publically accessible APIs - I am not sure why Microsoft even include Port 83!) but you can set the ports to whatever you require. The Application Insights key is more interesting; it not only allows you to specify the key (no surprise there) but it will automatically send the cluster messages (such as Application Starting) to the specified Application Insights instance. You will still need to send your application-specific messages to Application Insights if you want them to show there, but this does simplify monitoring the overall cluster health quite considerably.

I have entered my Application Insights key and clicked Create. After 1-2 seconds (where Visual Studio performs a series of validation checks), a confirmation screen will be displayed:

Clicking OK will return you to Visual Studio and how the output window with the status messages:

The mistake I made the first time was thinking that the Application would also be deployed – this is not the case. A second Publish will be required as we will see later. In hindsight, it is clear that we have deviated from the initial Publish route as we are creating a cluster, but that did not occur to me the first time!

The Resource group will be created, and you can monitor the creation of the cluster from either Visual Studio or the Azure Portal (although). I’ve italicized the monitor as the Azure Portal will only show the items created, not any pending items such as the actual VMs:

From the Properties option (1), we can see the Provisioning Status (2) was successful and that the nodes are being created (3).

For this test, the cluster took approximately 15 minutes to create which is far from ideal but the screenshot below shows the successful completion message (if you are wondering how / why the completion message is green, may I recommend VSColorOutput which is an excellent Visual Studio plug-in).

The Portal shows:

The Cluster state shows Baseline upgrade and this means we are good to go. OK, it really means the cluster is performing some internal upgrade tasks, but it is fully functional for our purposes so we can continue.

Publishing the Application

As with the Cluster Creation, you can use the same Publish option you used earlier - i.e. either from the Build menu or by right-clicking the Application Project. The original Publish screen will be displayed again:

You may need to <Refresh> to see the newly created cluster.

As the application does not exist, we do not need to select the Upgrade the Application or change any of the other defaults. Click Publish and you will be returned to Visual Studio. Below is a capture of the Output window just after clicking Publish.

Once completed, the Visual Studio Output window will look like the one below:

And the Service Fabric Explorer will look like:

Did you notice the issue I deliberately created? No? Neither did I as I was doing the screenshots! I didn’t change the WebAPI to use port 80 or specify the port WebAPI uses in the Cluster Creation (on the Advanced tab).

As it stands, Postman - an excellent tool for testing APIs - shows:

To resolve this, I have two choices:

Add the port to the cluster configuration or
Update the Service Manifest (shown below):

As mentioned in several posts, I am lazy by nature, so I will change the Service Manifest, but this also improves the accessibility as the port will become an industry standard port – a win-win to me!

Below is the default ServiceManifest (the pink squiggles are from the Visual Studio Spell Checker plugin showing that even Microsoft can make mistakes! Directoy…) with the Port highlighted – your port number will probably be different.

Once changed to 80, I can redeploy:

As the steps are the same, I won’t repeat them all here. The important differences are:

The Upgrade the Application must be ticked (#1 below) as, by default, Visual Studio will deploy the application as though it were a new application and the deployment will fail - even if the manifest has been updated (#2 below):

We also need to update the Manifest Versions by clicking the Manifest Versions button (#2 above). This is required so that Service Fabric knows the version is different (the how it is different does not matter as we will see below) or a Same version error will occur.

The Edit Versions screen is shown below – I have expanded the Web1Pkg but other than that, it is as is.

Whilst the above versions are using the traditional Semantic versioning, you don’t have to – all that matters to Service Fabric is that the new version is different from the current version. Below, I have continued with the Semantic versioning and updated the Config version to 1.0.1 – as the Automatically update application and service versions is ticked, and as the example is using sematic versioning, the Application Version is also increased to 1.0.1 automatically (yep, I’m lazy!)

Clicking Save will return you to the previous screen where we can simply Publish, and you will again return to Visual Studio. Below is a snapshot of the Output window: