Installing CakePHP in the Microsoft Azure Preview Portal

A while back, last year actually, I wrote a blog post on how you can Install CakePHP on Windows Azure Web Sites using the App Gallery. At Build 2014 we introduced a new Preview Portal which enables much more to an application owner including in-place billing information, application analytics and a whole new way to visualize your cloud experience.

In this thread, I’ll show you how to create a new CakePHP application via the Preview Portal.

If you’re an experienced CakePHP Developer, you might want to check out Sunitha Muthukrishna blog post on using CakePHP’s Bake Console Tool on Microsoft Azure Websites.

Install CakePHP on Azure Web Sites

From the Start Board, select the Azure Gallery.

image

This will open the App Gallery Blade, where you can select from a list of categories. Select Web, then CakePHP.

image

This will start the CakePHP installation, select Create. Thus begins your Journey.

image

You’ll need to create a new resource group. Enter a name for your Resource Group, then click on the Website configuration

image

You’ll need to select your Hosting Plan. For this demo, I created a free site.

image

Then configure the application, by clicking on Web App Settings. Set the Security Salt and Cipher Seed.

image

Then select the datacenter location you’d like to deploy your application to.

image

Click OK to finish the Web Site Configuration and move on to create the Database.

image

Select Database.

image

Accept the Terms for the ClearDB database.

image

Select a different subscription, if required. Then click Create.

image

Your site has started to deploy and should be ready for you to start creating within seconds.

image

You can monitor your application, change settings, or set up source control from your new site.

image

Enjoy!

How to backup a Web Site running on Microsoft Azure Web Sites

Keeping regular backups is important for anything on the web, nay technology, especially for mission critical applications, enterprise applications, or keeping your meme generator application from Build 2014 [not sure what I’m talking about? Watch the Day 2 Keynote].

In this example, I’m actually going to outline how I keep a backup of my blog, yes the one you’re currently reading right now. It is running on WordPress and represents a good portion of my journey into a career in technology, that means it’s countless hours of my time that I continuously have the opportunity to read what I’ve done in the past after doing a quick Bing search on something I’m currently working on.

Take a Backup of a Web Site.

In the Microsoft Azure Management Portal select the Web Site you wish to backup.

image

As you can see in the image below, I run my site in a Shared Web Site. This provides me with enough resources for people navigating my blog to get an excellent experience without it being too heavy on my pocket book.

image

The backup feature of Web Sites only works in Standard, so for now, I’m going scale my site to Standard. This is as simple as clicking on the Standard Button, then clicking on Save in the command bar at the bottom of the screen.

image

Once I click on the Save button, I am prompted to let me know that scaling to standard will increase my costs, but I’m not too worried as I’ll be scaling back down to shared again shortly.

image

After the scaling task finishes, I’ll be able to use the form in the Backups navigation to select my storage account I wish to have my backups save to, the frequency in which they are saved as well as a database which is linked to my Web Site as a Linked Resource in the previous tab.

image

So I’ll select my favourite storage account.

image

And include my ClearDB database which is linked to my site to be backed up as well.

image

Then I’m only one click away from knowing all my archived hard work is saved for me in my storage account.

image

After the backup is done, pay attention because this is important, I go back into the Scale tab and scale my site back down from Standard to Shared. This moves me back down into the lower billing range that I am comfortable running my site in.

What does Microsoft Azure Web Sites Backup?

In the image below you can see two files which identify a backup. The first which is an xml file describing the site that was backed up at a high level including the custom domain, web site service domain as well as the name of the database which was backed up. The second file is a zip file which contains a backup of your site which I will outline in more detail below.

image

Here is a quick snapshot of the contents of the zip file: a fs folder, a temp folder, a meta file and a file named the same as your database.

image

What is in the Azure Web Site Backup zip folder

FS – if you haven’t already guessed it, FS stands for File System. This retains a snapshot of the file system of your web site at the time the backup was taken. This includes both the site and logFiles folders so you have access to anything you would need.

Temp – My temp folder was unused.

Meta – This is an xml file which describes all aspects of your website including but no limited to Custom Domains, Configured SSL Certificates, App Settings, Connection Strings, Default Document settings, Handler Mappings (for custom FastCGI Handlers); Remote Debugging, Web Sockets. I could go on, but I believe you get the picture, if it’s something you set in the portal for your web site, it’s backed up in this file.

Database Name – In my case, I had a MySQL database selected, so this file is a MySQL dump file. This can be used to completely restore my database from schema to data.

Using Guzzle to Interact with the Windows Azure Management API

Guzzle is a very simple abstraction over cURL which provides a great HTTP client for working with web services. This provides a great way of interacting with the Windows Azure Management API with PHP. In this example, I’m going to show how you can enable and disable an SSL Certificate in a Windows Azure Web Site using the Windows Azure Management API.

The majority of Windows Azure Web Site tasks can be automated using either the Windows Azure PowerShell cmdlets or the Windows Azure Cross Platform Command Line tools. This includes the ability to upload an SSL Certificate for your Web Site, however at this point there is no ability to bind the SSL Certificate to the Web Site itself. That’s where Guzzle and the Windows Azure Management API come into the picture.

You can do the following exercise from the Windows Azure Management Portal by following the instructions in the article Enable HTTPS for a Windows Azure web site. This entry is to demonstrate how you can achieve SSL Certificate binding as part of an automated environment script.

Automating SSL Certificate Upload to Azure Web Sites

Before we start interacting with the Management API let’s get the Windows Azure Web Site ready by adding the SSL Certificate to the Environment. This task is incredibly simple to accomplish using the Windows Azure Cross Platform tools.

SSL certificates can be uploaded only in Standard mode. Learn more about configuring custom domains.

azure site cert add [ssl-cert-path].pfx --key [cert-password] [web-site-name]

That’s it! The cert will now be added to the Windows Azure Web Site.

Create and Upload Export a Windows Azure Management Certificate

You could very well create and upload a management certificate of your own by creating one with OpenSSL and uploading it via the Windows Azure Management Portal (Settings > Management Certificates). However, there is a much easier way to achieve this without having to generate your own certificates, by using the Windows Azure Cross Platform Tools.

azure account cert export [--subscription]

The optional subscription parameter can be either the name of the subscription name or id from the azure account list command output.

Create a PHP Application with Guzzle to interact with the Windows Azure Management API

This is where things get fun! Let’s start by creating a composer file to acquire Guzzle.

Next we’ll want to take a look at the documentation for how to Enable or Disable SSL in Windows Azure Web Sites with the Management API. This gives us the information for the rest endpoint, http verb and xml/json payload to enable or disable the SSL Certificate.

Warning! At the time of writing SSL Certificates are only available for upload/binding if the Web Site is in Standard Mode. If the site isn’t in Standard Mode your requests will return with the status code HTTP 400 Bad Request.

Enable SSL JSON Playload

Disable SSL JSON Playload

PHP Source Code

To enable or disable SSL in a Web Site you will need to make a PUT request against the management API pass in your SubscriptionId, the webspace of the site, the site name and the Client Certificate. In Guzzle the request is constructed by the client, which you can pass an array of values into for replacement when you create the request by calling the PUT method.

Conclusion

This is how simple it is to make calls to the Windows Azure Management API from PHP using Guzzle. This blog post covers the usage of JSON for the request payload, however, there is a full example available as a Gist if you’d like to see how this can be done with XML.

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.

Important: Update to Default PHP Runtime on Windows Azure Web Sites

In upcoming weeks Windows Azure Web Sites will update the default PHP version from PHP 5.3 to PHP 5.4. PHP 5.3 will continue to be available as a non-default option. Customers who have not explicitly selected a PHP version for their site and wish the site to continue to run using PHP 5.3 can select this version at any time from the Windows Azure Management Portal, Windows Azure Cross Platform Command Line Tools, or Windows Azure PowerShell Cmdlets. The Windows Azure Web Sites team will also start onboarding PHP 5.5 as an option in the near future.

Explicitly Selecting a PHP version in Windows Azure Web Sites

If you wish to continue to run PHP 5.3 in your Windows Azure Web Site, follow one of the options below to explicitly set the PHP runtime of your site.

Selecting the PHP version from the Windows Azure Management Portal

After logging into the Windows Azure Management Portal, click on the Web Sites navigation item from the left hand menu.

image

Select the Web Site you wish to set the PHP Version for, then Click the arrow to navigate to the details screen.

image

Click on the CONFIGURE tab.

image

Ensure the value selected beside the PHP Version label is 5.3.

image

Perform any action which will require a save that will indicate the PHP 5.3 selection is intentional and not a reflection of the current platform default:

  • Add an App Setting
  • Temporarily toggle to PHP 5.4 or OFF
  • Enable Application or Site Diagnostics
  • Add/Change the Default documents

Click on the Save button in the command bar at the bottom of the portal.

image

Selecting the PHP version from the Windows Azure Cross Platform Command Line Tools

Run the following command from your terminal of choice, be sure that the Windows Azure Cross-Platform CLI Tools are installed and the appropriate subscription is selected.


Selecting the PHP version from the Windows Azure PowerShell Cmdlets

Run the following command from a PowerShell console, be sure that the Windows Azure PowerShell Cmdlets are installed and the appropriate subscription is selected.

Enabling Zend®Guard Extension in Windows Azure Web Sites

Zend®Guard enables you to encode and obfuscate your code to help protect against reverse engineering. It’s understandable that someone would want to help protect their hard work by encoding it, but in order to execute this encoded source on a server it is necessary to enable an extension to decode the source prior to execution.

Getting Started with ZendGuard

Using ZendGuard is out of the scope of this article, as there is plenty of documentation around the process on the Zend Guard User Guide. If you’d like to get the quick overview, watch this video below:

Zend Guard Basics by Zend Documentation

ZendGuard Setup in Web Sites (default runtime)

In order to enable ZendGuard in Windows Azure Web Sites you will need to acquire ZendLoader.dll from the ZendGuard Download page. The remaining steps we will configure php which is built into the Windows Azure Web Sites environment.

Installing a Zend Extension in Windows Azure Web Sites

Now that we have the ZendLoader assembly let’s make sure that it’s loaded into the extensions list in the default php.ini file. We can do this by selecting the configure tab in your Web Site and adding an App Setting.

image

There are a number of reserved App Settings in Windows Azure Web Sites to configure a number of different parts of the default runtime experience, in this particular case we’re going to use PHP_ZendExtensions to load ZendLoader.dll into the default PHP Runtime Zend Extension list.

Ensure you  download the proper ZendLoader.dll for your PHP Version.

As you can see in the image below, the an app setting is created with the key PHP_ZendExtensions and the value bin\ZendLoader.dll, which is a semi-colon delimited list of relative paths in this case the ZendLoader.dll will need to be placed in a bin directory off the root of the Web Site.

You can upload the DLL file via FTP, or download it directly to the bin directory in your Windows Azure Web Site by using KuduExec, which I’ll use to download the .user.ini file later in this article.

image

With the assembly in the PHP pipeline, we still need to do some custom configuration to the php.ini via the .user.ini file. I have created a .user.ini which captures all of the configuration settings available to ZendGuard as well as a command to turn off WinCache file caching which is required in order for ZendGuard to operate.

To demonstrate another feature of Windows Azure Web Sites, let’s use KuduExec to download the .user.ini file into our Windows Azure Web Site using curl.

KuduExec – The Windows Azure Web Sites Command Line

First things first, in order to use KuduExec you need to have it available on your local machine. KuduExec is written in Node.js which you will need installed and configured on your machine. To download KuduExec, use the following command to install it globally on your system.

npm install kuduexec -g

Now let’s look at how to connect to our command line in Windows Azure Web Sites:

kuduexec https://<deployment-user>@<dns-namespace>.scm.azurewebsites.net

Enter your Deployment Password to login to the Windows Azure Web Sites command line. You can download the .user.ini file from a Gist the following curl command:

curl -O https://gist.github.com/SyntaxC4/6084034/raw/cd8e1e27cbaa45db25f94be51968960bf71276bf/.user.ini

Note

Depending on your ZendGuard configuration, you may need to change some of the zend_loader settings.

Exit KuduExec by typing exit.

Refresh the PHP Configuration

By default, PHP is configured to refresh it’s settings from the php.ini file every 300 seconds (5 minutes), you can force this to refresh immediately by doing a Web Site reset.

You can confirm ZendGuard is configured by looking at the following sections of the phpinfo output:

image

image

Deploying your ZendGuard Encoded Application

There are many ways to upload content in Windows Azure Web Sites as described in this list of PHP Tutorials. After ZendGuard encodes the application code, the index.php file in my example looks like this:

image

The actual file is a simple echo of phpinfo()

image

Conclusion

In this example, I demonstrated how to configure ZendGuard with the built in PHP runtime in Windows Azure Web Sites. This will allow you to run your ZendGuard Encoded and Obfuscated code in a highly scalable hosting environment. It is also possible to set up ZendGuard using the Bring Your Own Runtime functionality, which I will explain in a future blog post upon request in the comments below.