Freigeben über

ARM concepts in Azure Stack for the WAP Administrator – Resource Deployment

  • Artikel

Hello Readers! This blog is part 4 of the series "ARM concepts in Azure Stack for the WAP Administrator." In this post we'll discuss how resource deployment concepts (in particular for VMs) you are familiar with in Windows Azure Pack (WAP) map to the brand-new Microsoft Azure Stack Technical Preview 1.

Note Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

I'm including the table of contents for this series of post so that you'll find it easier to navigate across the series:

Table of contents

  1. Introductory post, and some first information on the Azure Stack POC architecture and ARM's role
  2. Cloud Service Delivery
  3. Plans, offers, and subscriptions
  4. Resource Deployment – this post
  5. Packaging and publishing templates on Azure Stack
  6. Multi-tier applications with ARM
  7. In-guest configuration with ARM, and technologies such as Virtual Machines Extensions, including PowerShell Desired State Configuration (DSC)
  8. Troubleshooting IaaS deployments in Azure Stack

We will update the post with links to the new posts, as we publish them. With no more delay, let's get started!

 

Resource deployment in WAP

Windows Azure Pack (WAP) administrators can offer cloud services to their tenants that are similar to some of the services available in Azure Classic, such as SQL Server databases, web sites, or virtual machines. When offering virtual machines, the WAP admin can enable tenants to deploy two types of virtual machines:

  • A Standalone Virtual Machine, which basically is a virtual machine with an operating system installed, such as a sysprepped Windows Server 2012 R2 or a specific Linux distribution.
  • A Virtual Machine Role, which is typically a virtual machine with an operating system installed and with an application installed and configured, such as a domain controller, a SQL Server, or a VM with SharePoint installed.

A WAP administrator can offer standalone VMs by creating virtual machine templates in System Center Virtual Machine Manager (VMM) and/or they can offer VM roles by creating Virtual Machine Role Templates using VMM and WAP.

Explaining how to create standalone VM templates and VM roles is out of the scope of this blog, and they have been extensively documented, so let's take a quick look at the tenant experience to deploy stand-alone VMs and VM roles that have been made available in a plan by a WAP administrator.

WAP Tenant Portal

Deployment begins when a tenant signs in to the WAP tenant portal, which offers a very similar experience to the one available in the Azure Classic Portal:

If the tenant wants to create a standalone virtual machine (a VM with the operating system only), they must click on +New à Standalone Virtual Machine à From Gallery

Then the tenant can select one of the templates made available by the WAP Admin (for example, Windows Server 2012 R2), and then follow the wizard to provide the details for the new VM, such as Name, Password, Product Key and the network to which the VM should be connected.

In case the tenant prefers to deploy a virtual machine with an application already installed and configured, the tenant can deploy a new VM Role by clicking on +New à Virtual Machine Role à From Gallery

The tenant will then receive an experience that is consistent with the Azure Classic Portal to select one VM Role from the gallery:

The tenant needs to follow the wizard to provide the details of the specific VM role being deployed. For example, for a domain controller the tenant should provide domain DNS name, domain NETBIOS name, and safe mode admin password:

Note that the information the tenant needs provide on the wizard will change depending on the VM role being deployed. We will discuss this in detail in the next blog post in this series.

PowerShell

Instead of using the WAP tenant portal, tenants can use PowerShell to deploy a new standalone VM or a new VM role. This has been extensively documented before, and you can refer to this great blog post from Charles Joy which describes in detail how to leverage Azure PowerShell to deploy a VM role as a WAP tenant administrator. Also, Marc van Eijk wrote a blog with samples to deploy WAP stand-alone VMs and VM roles via PowerShell.

One thing you'll notice is that the way you deploy a virtual machine in WAP is different from how you do it in Azure Classic. Take for example these cmdlets:

You will use different cmdlets depending on your target environment, WAP or Azure Classic. If you take a look at the blogs from Charles and Marc above, you'll notice than deploying a VM role in WAP via PowerShell is different from how you deploy a VM in Azure Classic.

Let's now review how to deploy resources in Microsoft Azure Stack TP1.

 

Resource Deployment in Azure Stack

In Azure Stack, you can use the same tools available to deploy virtual machines and other cloud resources to your Azure Stack subscription just as you'd do in Azure (in the Resource Manager deployment model). This is because, as highlighted in this previous post from this series, Azure Stack is consistent with the new Azure Portal and Azure Resource Manager. Azure Stack uses the same portal and the same APIs as public Azure, meaning that you can use the same tools and deploy resources in the same way you do today with the new Azure Portal and Azure Resource Manager. What this means is that you don't have to learn new tools to start deploying resources in Azure Stack. Also, it means that the applications you write for Azure Stack will run in Azure. Without more introduction let's review at the different tools available:

Portal

In WAP you had two portals, Admin and Tenant; in Azure Stack there's only one portal: the Microsoft Azure Stack portal (in Azure Stack TP1 the portal URL is https://portal.azurestack.local/.) This is possible because Azure Stack is powered by ARM (the same ARM available in public Azure), and one of the benefits of ARM is Role Based Access Control (RBAC). RBAC has been a top request from users of Azure Classic and WAP, and now we have it in Azure and Azure Stack. Thanks to RBAC we have only one portal, and admins have a different view of the portal than tenants do. For example, an admin can configure resource providers and create offers/plans, and a tenant can deploy new virtual machines, web apps, or interact with his/her resources. The picture below depicts the Azure Stack Portal with an admin signed in:

 

In this view you can see that the admin has access to create new Services and Locations, and Tenant Offers and Plans. These actions needs to be done by an Azure Stack Admin only.

The picture below depicts how a tenant can create, for example, a new VM. The view is exactly the same as tenant would see when deploying a new VM in Azure. Notice that the tenant does not have the possibility to create services, locations, or tenant offers and plans:

Compare the picture above to the picture below, which shows what a tenant sees when deploying a new virtual machine in the new Azure Portal:

In the new Azure Portal, you see more services than in Azure Stack, but the Azure Stack team is working to bring more Azure Services to Azure Stack. As a sample, you now have an early preview of Azure PaaS services for Azure Stack, including the Web Apps Resource Provider. Another thing you might notice is that in Azure there are more marketplace items than in Azure Stack. Well, the good news is that you can create your own items! J Take a look at this article for information on how to add your own marketplace items to your Azure Stack deployment!

PowerShell

Many users prefer to use PowerShell to imperatively deploy resources in Azure instead of using the UI. It's imperative because you are telling ARM what to create. For example, you start with New-AzureRmResourceGroup to create a new resource group and then you start chaining other commands such as New-AzureRmVirtualNetwork, New-AzureRmStorageAccount, and so on to create a complex deployment.

In order to being able to deploy and manage my resources in Azure with PowerShell, you have to download and install Microsoft Azure PowerShell (I do this via the Web PI, but you can also get it from the PowerShell Gallery).

Once Azure PowerShell is installed, you can login to your Azure subscription and start deploying new resources via PowerShell. For online help, refer to Azure Resource Manager Cmdlets, and there is this excellent article on how to create a new ARM VM in Azure via PowerShell.

You can deploy resources via PowerShell to an Azure Stack subscriptions just as it's done with a public Azure RM subscription! You don't have to learn different cmdlets, or write totally different scripts. You use the same cmdlets and procedures you use for Azure in Azure Stack. There are only a couple of observations you should bear in mind:

  1. You have to authenticate PowerShell with your Microsoft Azure Stack environment. The details are documented here.
  2. In Azure Stack TP1, you must use Microsoft Azure PowerShell version 1.2.1 (February release), and if you launch the Web PI (at the time this blog was published), you will notice an entry for Microsoft Azure PowerShell – Azure Stack Technical Preview. You should use this version (which is actually just the renamed 1.2.1 release; you can use either version) because Azure Stack TP1 was not tested with newer Azure PowerShell versions, such as version 1.2.2 (March release).

 

 

Command Line Interface (a.k.a. CLI)

You can use the Azure Command Line Interface (CLI) to deploy and manage resources in your Azure or Azure Stack subscription from different platforms (Windows, OSX and Linux), using a set of open-source shell-based commands. In order to use the Azure CLI, you need to do the following:

  1. Install the Azure CLI on the platform of your choice
  2. Open a command window (and you can type azure to get some help information)
  3. Make sure you're in the Resource Manager mode by typing azure config mode arm
  4. Log in with your work or school id by typing azure login, and then provide your Azure account credentials

And that's it! As with PowerShell, you can start deploying resources imperatively in your Azure subscription. You can refer to this article for details on how to create a Linux VM with the CLI.

In order to deploy resources in Azure Stack using the Azure CLI, after installing it in your environment, you need to:

  1. Add the Azure Stack environment
  2. Login indicating that you're using an Azure Stack environment
  3. Make sure ARM mode is selected

The steps and commands required to connect the CLI to an Azure Stack environment are described in the Azure Stack documentation here. And that's it, you're now connected to an Azure Stack subscription via the Azure CLI and you can start deploying resources imperatively as you'd do it with your public Azure subscription.

 

Templates

Template-based deployment is one of the great new capabilities introduced with ARM. A template is a file in JSON format that defines the deployment and configuration settings for your application. This can be something as simple as a storage account, or you could define a complex multi-VM application such as SharePoint or Exchange, or you could define an application that uses IaaS (VMs) and PaaS (e.g. SQL databases) resources. The file sample below shows the basic structure for a template:

{"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#","contentVersion": "","parameters": { },"variables": { },"resources": [ ],"outputs": { }}

 

A template provides a declarative way to define your deployment, meaning that you declare what your configuration should look like, and then ARM will take care of orchestrating and managing the deployment. ARM makes sure that dependencies declared in the template are honored. Template-based deployments in ARM have certain properties, as summarized in the following list:

  • Declarative – You declare the end state of your application instead of imperatively building your application one step at the time.
  • Idempotent – You can execute the same deployment against a given target multiple times and you'll get the same outcome each time.
  • Multi-service – You can include multiple different resources in your template, such as IaaS and PaaS.
  • Multi-region – You can target the deployment to span different Azure regions.
  • Extensible – ARM provides extensions that allows you install and configure applications and OS settings inside your VMs (take for example the DSC extension). What this means is that you can not only deploy the topology of your application, but you can also initialize the application state leveraging extensions.

You don't necessarily have to start from the basic template structure described above. To help you get started, refer to the Azure Quickstart Templates GitHub repository. The repository contains a large number of sample templates that you can use to get familiar with templates and start building your application from one of the existing samples in the repository. For detailed information on how to author your templates, refer to the Authoring Azure Resource Manager templates article.

Once you've defined your template, ARM can provision the application described within the template via a deployment. A deployment is basically an entity that tracks template execution. ARM supports two types of deployments, Incremental (this is the default deployment model), and Complete. You can specify the type of deployment through the Mode property. The following table describes both deployment types:

Deployment Properties
Incremental With incremental deployment, ARM:
  • Leaves unchanged resources that exist in the resource group, but are not specified in the template
  • Adds resources that are specified in the template but do not exist in the resource group
  • Does not re-provision resources that exist in the resource group in the same condition defined in the template
Complete With complete deployments, ARM:
  • Deletes resources that exist in the resource group but are not specified in the template
  • Adds resources that are specified in the template but do not exist in the resource group
  • Does not re-provision resources that exist in the resource group in the same condition defined in the template

Source: Deploy a Resource Group with Azure Resource Manager template

And here's the great news: while template-based deployments are available for ARM in the public cloud, as Azure Stack is powered by the same ARM as in the public cloud, you have all of the power and richness of template-based deployments in Azure Stack too! J

Azure and Azure Stack use the same template technologies, but in Azure Stack TP1 we don't have all of the resource providers available in Azure (for example, Service Bus), and some template functions are not available in Azure Stack yet (for example, subString), this means that some templates written specifically for Azure might not work in Azure Stack. You can refer to this blog from Bruno Saille in which he explains this topic in more detail, and he also provides an ARM Template Checker tool, which will check your template and report if some parts are not compatible with Azure Stack yet. Also, you can refer to the Azure Stack Quickstart GitHub repository for a list of curated templates that have been tested with Azure Stack.

By this point you may be wondering, "Alright, I got the benefits of template-based deployments, I know where to get sample ones and build my own ones, and I know what to check for my template to be deployed on Azure and Azure Stack, but how can I deploy it?" Please see below a list of tools that you can use to deploy templates as well as links to detailed steps depending if you're deploying the template on Azure or Azure Stack.

Tool Azure Azure Stack
Azure Portal Deploy with the portal Deploy using the Azure Stack portal
PowerShell Deploy with PowerShell Deploy in Azure Stack using PowerShell
CLI Deploy with Azure CLI for Mac, Linux and Windows Deploy in Azure Stack using the command line
Visual Studio Deploy with Visual Studio Deploy in Azure Stack using Visual Studio
REST Deploy with the REST API Coming soon!

 

Deploying a template with the tools described in the table above is exactly the same if you're doing it on Azure or Azure Stack. You don't have to learn something new or change your application. The only difference is how you connect to the target environment. Once you're connected (for example, authenticated to the Azure Stack Portal or a PowerShell session), the way you deploy the template IS THE SAME if you do it on Azure or Azure Stack.

 

Something I've seen with some customers is that they have a single template to describe their application, and then they have different parameter files that contain the parameters for the application to be deployed. This lets them use only one template file and still apply unique values to target a specific environment. For example, for public Azure the deployment should target the West Europe region, while the Azure Stack deployment will target the local region.

 

 

Conclusion

WAP tenants can deploy resources in their WAP subscription mainly via the WAP tenant portal or via PowerShell (REST is another option and you can find some samples here). The WAP tenant portal look & feel is very similar to the Microsoft Azure Classic portal, hence the experience to deploy resources is also similar. With PowerShell, tenants can use the same Azure PowerShell installation to deploy resources on their Azure Classic subscription or in their WAP subscription, but the way they deploy resources is different between Azure Classic and WAP.

On the other hand, Azure Stack is consistent with public Azure in the ARM deployment model. ARM powers both Azure and Azure Stack, meaning that APIs are the same across both platforms. This consistency enables tenants to write their applications once, and then deploy them either on Azure or Azure Stack with no changes. Consistency at the API layer also means that the tools you use for deploying and managing resources on Azure will also work on Azure Stack. You need only to point the tools to the correct endpoint or environment (for example, you target your deployments to public Azure, or to a private Azure Stack environment), and then you can execute your imperative scripts or declarative templates with no changes, assuming that they call only resources and services that are available in Azure Stack.

There's already a plethora of information, best practices, and samples on the new declarative way to deploy your application via templates. We'll be providing even more samples and guidance in this area, but you can (and should) start testing template-based deployments either on public Azure, or in an Azure Stack TP1 environment. Just do a search using terms like Azure ARM templates, and you'll find a good amount of resources. You can start with the links already provided on this blog post, and also consider these additional resources from Microsoft and our MVPs:

 

Cheers,

Victor