Automating Environment Creation using Microsoft Azure PowerShell

During preparations for the Web Demo, presented by Mads Kristensen at Build 2014 [watch the day 2 keynote], it was necessary to stand up multiple environments to do development, testing and dry runs of the presentation. The quickest way to accomplish this was to script out the environment provisioning with PowerShell and the Microsoft Azure PowerShell and Cross Platform Command Line Tools.

Download the Tools

In order to automate your Microsoft Azure Environments, it’s helpful to download and install the following tools.

Microsoft Azure PowerShell Tools

Microsoft Azure Cross Platform Tools

Environment Automation Script

Considering the size of our environment, the number of stamps required and the need to be agile to changes in the environments it was necessary to build out an environment setup script for our Azure resources.

Our environment consists of:

  • 3 Azure Web Sites, 1 Staging Slot
  • 1 Azure Storage Account, 2 Storage Containers
  • 1 Traffic Manager Namespace, 2 Traffic Manager endpoints

Storage and Web Sites are easy to automate with PowerShell or the Cross Platform Command Line Tools. However, there isn’t currently a way to automate Traffic Manager without programming directly against the Microsoft Azure Service Management API.

To be able to support the creation of multiple assets, using Hash tables enables a unique value for the Web Site or Storage account, while still being able to store the region for creation. This fulfills the minimum requirements for creating an Azure Web Site, or an Azure Storage Account.

Leveraging a PowerShell cmdlet, the previous environment is deleted in the begin function, then the environment is rebuilt in the process function. Service creation is an asynchronous action, so we took advantage of Jobs in PowerShell to handle creation in background threads. If additional configuration is needed on a service, the Job is waited upon until completion, before additional service calls are preformed on the service.

Here is the script we called for each stamp of our environment:

Stamp Automation Script

The Environment Automation Script takes care of the heavy lifting, while the Stamp automation script is responsible for describing the resources required in the Environment.

First we must register the environment automation script so that it can be called within the same process that is executing our stamp automation script, then describe the stamp in variables then pass it to the environment setup script.

Conclusion

We generated custom scripts to suit our needs, but this isn’t something that you would need to do. Introduced in the VS 2013 Update 2 release and the Azure SDK 2.3 tools, you can have PowerShell scripts generated for your Web Application directly within Visual Studio File New Project dialogue (for more details read Using Windows PowerShell Scripts to Publish to Dev and Test Environments)

Deployment Time Dependency Management for PHP with Composer on Windows Azure Web Sites

Windows Azure Web Sites provides the ability to manage dependencies on deployment for .NET using NuGet, and Node.js using npm. This functionality is facilitated by an open source project called Kudu which is built and maintained by the Windows Azure Web Sites team [it can also be installed on Windows Server 2012].

If you’re a PHP Developer, you should know about Composer. Wouldn’t it be great if you could use Composer on Windows Azure Web Sites to fetch your dependencies during the deployment of your PHP Application? I thought so too!

To get started, I would recommend following this tutorial to create a php web site using the windows azure command-line tools for mac and linux. It’s ok, I’ll wait… Oh, back so soon? You should now have a Windows Azure Web Site with Git Deployment enabled.

Customizing a Windows Azure Web Sites Deployment for PHP

The Windows Azure Cross Platform Command Line tools expose an extended part of the Kudu functionality called KuduScript. KuduScript can be used to generate a set of files (.deployment, deploy.cmd) which hooks a Kudu deployment, enabling a custom script to be run at deployment time.

To generate a deployment hook with the Cross Platform Tools, run the following command:

azure site deploymentscript --php [-t bash]

This will generate a deployment hook for a PHP application, you could optionally pass in –t bash which would output the script in bash instead of the default batch.

Now that we have a customized deployment script, let’s add a few customizations; one to download composer to our Windows Azure Web Site, the second to run composer to fetch our dependencies specified in our Composer.json file. Add the following two lines above the Deployment section of the deploy.cmd.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Download Composer
:: -----------------

echo Downloading Composer

IF NOT DEFINED COMPOSER_VENDOR_DIR (
	SET COMPOSER_VENDOR_DIR=%DEPLOYMENT_TARGET%\vendor

	echo Downloading Composer

	curl -sS https://getcomposer.org/installer | php

	IF !ERRORLEVEL! NEQ 0 goto error
)
php -d extension=php_intl.dll composer.phar install --prefer-dist --no-dev --optimize-autoloader

Debugging Deployment Issues

Now that you’ve added a process to your deployment that has an external dependency there will most likely come a time where you will need to diagnose issues with your custom deployment. Not to worry, Windows Azure Web Sites includes the output of the deployment script in the Windows Azure Management Portal. To view the deployment log:

  1. Click into the details view of your Windows Azure Web Site
  2. Click on the DEPLOYMENTS tab
  3. Click on the top item in the Deployment History section
  4. An arrow will appear to the right of the entry, Click the Arrow.
  5. Click on the View Log link

waws-deployment-hook-debug

Moving the Web Root in Windows Azure Web Sites

A common practice in PHP is to have the vendor directory which is created by running composer be a sibling of the web root directory. This provides a level of security as the vendor directory is not stored in a publicly accessible location avoiding public calls into third party code downloaded by composer.

This can be achieved in Windows Azure Web Sites by changing the Virtual Directory of the web root from within the Windows Azure Management Portal. Assuming my application serves it’s public content from a folder called web contained in the root of my source control, the following steps will move the web root to the web directory:

  1. Click into the Details of your Windows Azure Web Site
  2. Click on the CONFIGURE tab
  3. Scroll to the bottom of the CONFIGURE screen until you find virtual applications and directories
  4. Change the record for / from site\wwwroot\ to site\wwwroot\web
  5. Click the Save button in the Command Bar

waws-virtual-directory

Production Web Site Guidance

In a production environment setting, having an external dependency as part of your deployment process can impede the ability to deploy your application. It is up to you to understand the non-functional requirements of your application which includes the acceptable deployment time. It may be required to ensure that the latest version of your code be available in production in a moments notice. In cases such as these it is important to keep a backup of your dependencies which could either be in your production branch of source control, or maintained independently of your project. It may be necessary to stage your deployment in a staging environment before pushing to a production server. In my next post, I’ll cover how you can deploy to a Windows Azure Web Sites staging slot and swap that staging deployment into production.