Microsoft Azure Stack: Resource Manager Explained (Layer 1)

Microsoft Azure Resource manager is a single stop resolution for many complex task like deploying, updating and deleting resources which a company admin used to handle on daily basis. Consider an example where I’m planning to install a new application in my organization which requires a couple of virtual machines to host the application, a database server, databases, a virtual network, storage etc.. here each of these components are considered as separate resources which work together to keep the application running. In earlier times we used different consoles to handle each of these components, let us say Hyper-V for managing virtual machines, SCOM for monitoring, Windows Fail-over Cluster manager, PowerShell etc.. Microsoft Azure Resource Manager is the primary layer to which all Azure tools like Azure portal, Azure CLI & Visual Studio interact via Microsoft Azure Resource manager api. Microsoft Azure Resource manager API acts as an intermediate between Microsoft Azure Resource manager service and the tools. Microsoft Azure Resource manager service authenticates and authorizes the resource request coming from these tools, once authenticated the request is sent to the respective resource providers in the second layer (Resource Provider layer will be discussed in a separate article)

Fig: logical architecture of the Azure Stack POC 

Resource: Components like Virtual Machine, database, virtual network, storage accounts, etc are considered as resources which can be managed by the resource manager. Fig below shows resources available in the portal.

 

Resource Group: These are logical groups created to put together the resources having same life cycle or those belonging to same project. The main advantages of resource group is easy administration and flexible billing. Each resource can only exist in one resource group, however these resource can be moved from one resource group to another and can interact with resources in other resource group. All activities performed under a resource group is logged and can be viewed under settings tab.

You can create and administrate a resource group from an azure portal as below.

1. Navigate to the resource group you would like to visit.


2. You will find the resources allocated to the resource group as below.
 

 

3. Provide centralized monitoring and billing details for all the resources in that specific resource group.

 

Resource Manager template: Templates (in JSON format) can be used to define the resources allocated to a resource group and how they are interdependent. For example, when we try to deploy a skype for business server even before we deploy the SFB application server sql should be installed and up in running. Here we create all the resources in the same resource group however define an order in which it is deployed. Once a template is build same can be used for seamless deployment for a test environment or for staging. Resource Manager parses the JSON template and converts its syntax into REST API operations for the appropriate resource providers, REST API is the template which all the Resource Providers understands.

Sample JSON template format 

“resources”: [
{
“apiVersion”: “2016-01-01”,
“type”: “Microsoft.Storage/storageAccounts”,
“name”: “mystorageaccount”,
“location”: “westus”,
“sku”: {
“name”: “Standard_LRS”
},
“kind”: “Storage”,
“properties”: {
}
}
]

Converted REST API format for Resource Providers:

PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAc counts/mystorageaccount?api-version=2016-01-01
REQUEST BODY
{
“location”: “westus”,
properties”: {
}
“sku”: {
“name”: “Standard_LRS”
},
“kind”: “Storage”
}


We can define templates in our on ways. I can define a 3 Tier application in below mentioned ways

 1. Single template to a Single resource group

   

2. Parent template having 3 nested templates to a single resource group.

     

3. Three independent templates to with dedicated resource group having linked resources.

      


There are various ways how you can deploy resources using these templates.

  1. Deploy resources with Resource Manager templates and Azure PowerShell
  2. Deploy resources with Resource Manager templates and Azure CLI
  3. Deploy resources with Resource Manager templates and Azure portal
  4. Deploy resources with Resource Manager templates and Resource Manager REST API 

Resource Manager provides a native role based access control, something similar to what we use in Exchange Server. This Plays a major role in restricting access to each user and to organization resources. We can add users to pre-defined platform and resource-specific roles.

Predefined platform roles are as below,
1. Owner – can manage everything, including access
2. Contributor – can manage everything except access
3. Reader – can view everything, but can’t make changes
4. User Access Administrator – can manage user access to Azure resources

Predefined
resource-specific roles are as below,
1.
Virtual Machine Contributor – can manage virtual machines but not grant access to them, and cannot manage the virtual network or storage account to which they are connected.
2. Network Contributor – can manage all network resources, but not grant access to them.
3. Storage Account Contributor – Can manage storage accounts, but not grant access to them.
4. SQL Server Contributor – Can manage SQL servers and databases, but not their security-related policies.
5. Website Contributor – Can manage websites, but not the web plans to which they are connected.
Other than users, if an application want to access any specific resources, it need to be authenticated first. We can make use of a Service Principal account to authenticate an application to a resource, this can be done as here from Azure portal. We can even explicitly lock critical resources to prevent users from deleting or modifying them.

 Happy Learning…!!!
 Anoop Karikuzhiyil Babu
 Former Microsoft Premier Unified Communication Engineer
 Category: Azure
About Anoop Karikuzhiyil Babu

Started his career with Exchange 2003 as a Microsoft Support Engineer, later moved to Microsoft Enterprise Unified Communication Team as Premier Engineer. Post handling numerous Premier environments and deployments, currently settled as a Solution Architect for Messaging and Collaboration in United Arab Emirates largest Tier3 Datacenter.

Related articles

Leave a Reply