Creating a secure Service Fabric Cluster in Microsoft Azure with internal load balancer on an existing virtual network – Part 2

This is the second part of the post in this series that I am talking about the implementation of a customized Service Fabric on Azure. The default functionality of the Microsoft Azure to create Service Fabric via portal does not allow you to use an existing virtual network or an internal load balancer. In this blog post I walk you through creating a secure Service Fabric on Microsoft Azure on an existing virtual network with an internal load balancer.

I have divided this post into two parts:

Part1 – Creating a secure Service Fabric Cluster in Microsoft Azure with internal load balancer on an existing virtual LAN

Part2 – Creating a secure Service Fabric Cluster in Microsoft Azure with internal load balancer on an existing virtual LAN

In the first part of this post, we have talked about the basic information regarding Service Fabric implementation, prerequisites and the first two steps of the process. Now we continue on that basis.

Step 3 – Modifying the template.json

As you see, the basic service fabric cluster creation via portal does not let you to add the scaleset to an existing VNET, or have an internal load balancer. We modify the template file to have these features available to us.

First, make a copy of the template.json to work on. Open it in your favorite code editor application (mine is Visual Studio Code!)

Then change these items in your newtemplate.json file

Change to the ‘parameters’ section of the ARM template

You have to change some parameters in your ARM template to suit your needs.

Find the subnet0Name in the parameters section of the ARM template (around line 42 – all of the line numbers may change in the future due to azure new releases). Change the default value to the name of the existing subnet in your existing vnet (Server-Subnet)

Change the subnet0Prefix parameter (line 46) default value to the address space of your subnet (172.16.0.0/24)

Then add two new parameters after that, for the resource group name and name of your VNET:

 

Change “test_res_12” and “Server-VNET” values accordingly to reflect your own environment in the above code.

Then, because we want to use internal load balancer, we no longer need the dns name in the parameters section. So comment out the dnsName parameter since we no longer need it. (line 100)

And also you can comment out the virtualNetworkName, addressPrefix since we are using an existing VNET (line 92)

For the internal load balancer, you have to add an address for it (put it at the line 238 at the end of all parameters):

Make sure to use the IP address of your own environment here.

That’s all with the parameter and you need no further changes. But since the ARM template for the Service Fabric use some default names for the parameters, if you want to have more customized environment, it is good to change the following names as well:

  • clusterName (Line 11): the default name is Cluster. It is good to change it to a more unique name.
  • adminUserName (line 79): the username to login to the instances of the scaleset. The default is testadm. You can change it to something else
  • vmNodeType0Name (line 229): the node type name

 

Change to the “variables” section of the ARM template

We have to change the vnetID variable to use the existing VNET (line 249)

Change to the “resources” section of the ARM template

We don’t need to create a VNET since we already have it. So you have to comment out the VNET creation section in the resources. Search for “Microsoft.Network/virtualNetworks”

In the resources section and comment it out (from line 300 to 325)

Then you have to remove the dependency on the VNET creation in other section. So comment out the the virtual network from the ‘dependsOn’ attribute of the Microsoft.Compute/virtualMachineScaleSets

Search for the Microsoft.Compute/virtualMachineScaleSets (line 595) then on the dependsOn section comment out the virtual network:

Because we do not need public ip address to be created, search for Microsoft.Network/publicIPAddress in the resources section and comment out the creation of this resource type (line 326 to 341)

Remove the IP address dependsOn attribute of Microsoft.Network/loadBalancers, so you don’t depend on creating a new IP address. Add the virtual network dependsOn attribute because the load balancer now depends on the subnet from the virtual network (line 348)

Change the load balancer’s frontendIPConfigurations setting from using a publicIPAddress, to using a subnet and privateIPAddress. privateIPAddress uses a predefined static internal IP address. To use a dynamic IP address, remove the privateIPAddress element, and then change privateIPAllocationMethod to Dynamic. (line 351)

In the Microsoft.ServiceFabric/clusters resource (line 778), change managementEndpoint (line 816)to point to the internal load balancer address. Make sure you use https.

Step 4 – deploy the modified template to the Azure

Now you have a new modified template.json file that you can deploy to the Azure to create your customized service fabric environment!

You have to run these cmdlets in order to deploy the template.

Make sure to replace your values for the resource name, location and path to the new template.json file.

It will ask you for some parameters here and you have to enter them:

  • clusterLocation
  • computeLocation
  • vmStorageAccountName
  • certificateThumbprint
  • sourceVaultValue
  • certificateUrlValue

After entering these values it takes a couple of minutes to create all the resources and become ready to use.

Happy using Service Fabric!

Update – 4/19/17

I put the completed json file with a Microsoft word document of this post in my GitHub account:

https://github.com/farchide/ServiceFabric/tree/master/ARMTemplateExistingVNETInternalLB

About

MCSE, PMP, With more than 12 years experience in Microsoft technologies.

View all posts by

4 thoughts on “Creating a secure Service Fabric Cluster in Microsoft Azure with internal load balancer on an existing virtual network – Part 2

  1. Hello ! I’ve recently did almost the same config, but I had a problem – service fabric did not see nodes. Repeated with your config – problem remains the same. May this be because address space of my vnet is 10.1.0.0/16, but service fabric is in 10.1.1.0 subnet and lb ip ip is 10.1.1.10. Scale set is assigned ip 10.1.1.4 and I don’t understand why cluster does not see node.

      1. Hi
        your address space seems correct. What is the error that your are getting?
        what do you mean that ” Service Fabric does not see nodes”?
        since it is an internal service fabric, if you want to connect to nodes via RDP, you have to create a jump box VM in the same VNET and then RDP to the nodes.

Leave a Reply