Updating to WordPress 4.2.2 on Azure App Service

This post is going to be relatively short, but I’ll update it with more information as I receive more feedback from users.

File System Issues

Recently there were some changes made in WinCache (v1.3.7.4) which reroutes file system calls such as is_dir, is_filefile_exists to a manifest in Wincache. This means that there is a potential for files that have been deleted on disk, to report as still available. This causes issues when updating WordPress, themes or plugins from a PHP script (such as the one used by the internal WordPress update tool). To remove these redirects follow the instructions below:

  1. Create a file called .user.ini (provided it doesn’t already exist)
  2. Append wincache.reroute_enabled=0 to the end of the file
  3. Upload the .user.ini file to the d:\home\site\wwwroot directory

This will remove any file system based errors which may occur during the update.

Database Issues

If you are running a giant WordPress blog on Azure App Service, there is the possibility that the database updates will take longer than the request timeout time. This will cause HTTP 5xx error messages when you are attempting to update.

Composer Support for Azure App Service Web App via Site Extension

In a previous post I outlined how to enable deployment time dependency management with Wep App by hooking the deployment with Kudu. In this post, I will explain how I iterated on the techniques used  in that previous post, to enable Composer in Web App via a Site Extension which lowers the barrier to use Composer with Web App.

Cool, but what exactly is a Site Extension?

Site Extensions are a means of extending the Azure App Service platform. The best part about Site Extensions are that they can be created by anyone, it is as simple as creating a Website, WebJob or IIS Module, an applicationHost.xdt file (applicationHost.config Transform), and possibly some supporting files to help install or setup the Site Extension components. These components are then packaged with NuGet and uploaded to the Site Extension Gallery

More information is available on how to create a Site Extension is available in the Kudu Wiki.

Now, How do I use Composer in Web App?

To get started with Composer on Web App, you’ll need to install the Site Extension, luckily I wrote a post which explains how to enable a site extension. You’ll find Composer in the list of Site Extensions.

Creating a web site which uses Composer

Composer has a number of different ways that it can be leveraged, you can run it as a tool from the command line directly to have it build files or you can manually create a composer.json file. I’ll refer you to the documentation to figure out how you’d like to use it.

For my application, I crafted the composer.json file by hand using Packagist as a reference for my file dependencies. I wanted to create an application which lists files from a particular container in Azure Storage, this means I would require the Microsoft Azure SDK for PHP and it’s dependencies. Here is my composer.json file.

{
  "require": {
      "pear-pear.php.net/HTTP_Request2": "*",
      "pear-pear.php.net/Mail_Mime": "*",
      "pear-pear.php.net/Mail_mimeDecode": "*",
      "microsoft/windowsazure": "*"
  },          
  "repositories": [
      {
          "type": "pear",
          "url": "http://pear.php.net"
      }
  ],
  "minimum-stability": "dev"
}

The composer.json file should be placed in the root of the repository. The Composer Site Extension has the COMPOSER_VENDOR_DIR set to d:\home\site\vendor which is out of the public wwwroot directory so that the dependencies cannot be addressable publicly.

Now that we have our dependencies taken care of simply build a PHP application which requires the autoloader which is created for us by composer, then write our code. Here is my index.php file which iterates over items in my storage container.

<?php

require_once "../vendor/autoload.php";

use WindowsAzure\Common\ServicesBuilder;
use WindowsAzure\Common\ServiceException;

$blobRestProxy = ServicesBuilder::getInstance()->createBlobService(getEnv('CUSTOMCONNSTR_BlobConnectionString'));

try {
    // List blobs.
    $blob_list = $blobRestProxy->listBlobs(getenv('container'));
    $blobs = $blob_list->getBlobs();

	echo "<ul>";
    foreach($blobs as $blob)
    {
        echo "<li><a href=".$blob->getUrl().">".$blob->getName()."</a></li>";
    }
	echo "</ul>";
	
} catch(ServiceException $e){
    $code = $e->getCode();
    $error_message = $e->getMessage();
    echo $code.": ".$error_message."<br />";
}

Deploy! and Configure

Now we’re ready to deploy the application and configure a few of the settings to make the application come to life. Click the button below to deploy the application into your Microsoft Azure Subscription:

This Deploy to Azure button could be configured to set these App Settings automatically on deployment, If you see a azuredeploy.json file in the repository you can disregard the following steps. As I have found the time to make the Azure Resource Manager template to hydrate these values.

Add the following App Settings to the App Settings list in the Portal:

  • container – This is the name of the container in your storage account that you’d like to list the values of. This is referenced in the code above by the call to getenv(‘container’) which reads this value from an environment variable
  • DEPLOYMENT_SOURCE – Typically, I would add a .deployment file to the respository to change the project config setting to web as this will change the deployment directory and only deploy the items in the web folder. Due to how the Composer site extension is hooking the deployment, the .deployment file doesn’t work so this setting is needed to let Kudu know that the contents of web should be copied to the wwwroot directory

Add the following Connection String to the Connection Strings list in the Portal:

  • BlobConnectionString – This should contain the connection string for your azure storage account. Set the type to Custom.

There is an assumption here that you actually have a few items in the storage account. If you don’t upload a few now then refresh the website.

That’s it! You have successfully deployed a PHP application which uses composer!

How to enable a Site Extension in Azure Websites

Site Extensions are an amazing part of Azure Websites, they have the ability to (surprise, surprise) extend the functionality of a Website by providing new language support or some new functionality to the site. This can be seen from my last post where I added WordPress Command Line Interface support to Azure Websites.

In that post, I showed how you can use the new preview portal to add the site extension, but in this post I wanted to talk about both the Current Management Portal as well as the Preview Portal so there is single place to find both instruction sets.

Site Extensions (Management Portal)

There is no integration within the management portal to enable Site Extensions, but all isn’t lost. You can still add site extensions from your Kudu Console (SCM Site), one of the easiest ways to get to your website is the portal (provided you’re already there). You can click Browse to launch your website.

image

Once our website loads, we can change the URL, slightly, to enter into the Kudu Console. You’ll notice I’ve added the https:// protocol to the beginning of the URL and .scm after the name of the website.

image

In the navigation bar, you will see Site Extensions.

image

There are two tabs on the Site Extensions page, Installed and Gallery. There might not be anything listed under installed at first. Click on gallery to get the list of Site Extensions you can install.

image

Clicking on a plus sign on a gallery item will install the Site Extension. After the Site Extension is install, you must hit the “Restart Site” button in the upper right hand corner of the Site Extensions page. Clicking on the circled letter ‘i’ will display the detailed information for the Site Extension.

Site Extensions (Preview Portal)

There is direct Site Extension integration in the Preview Portal. We’ll start from the default blade for our Website.

image

Click on Settings in the Command Bar. This opens the settings list in which we will find an option for Extensions.

image

This opens a blade which lists previously installed Site Extensions, and has an add button to add new Extensions to our website.

image

Click Add. This opens the Site Extension gallery, where we can select a new Site Extension to enable.

image

The next step is to accept the legal terms for the Site Extension.

image

Then finish the installation process by clicking OK.

image

You can Browse, Update or Delete the Site Extension by right-clicking on the entry in this list.

image

Enabling WP CLI in Azure Websites

WordPress is the most popular CMS on the Web so there are obviously a great set of tools surrounding it to enable the wide variety of developers who build on the WordPress platform. One of such tools is WP CLI which is a command line interface for managing your WordPress site. In this post, I’m going to cover how to install the WP CLI site extension into your Azure Websites hosted WordPress install to enable command line access to your site.

Steps

  1. Install WordPress on Azure
  2. Install WP CLI Site Extension
  3. Command line to WordPress

Install WordPress on Azure

This step is a little bit out of scope for this topic, if you’re savvy enough to know there is a command line tool for WordPress, I’d assume you’d know how it set it up. If for some reason you don’t know, I’m just going to leave these here:

Install WP CLI Site Extension

To add a site extension, you need to login to the Azure Portal and go into your site.

image

If you scroll to the bottom of the site blade, you will find a part called Extensions which on that which will open the Site Extensions blade.

image

Scroll down the list until you find WordPress CLI, click on the item, then accept the license terms. Click OK and the site will begin to install the extension.

Command line to WordPress

Ok great, I have the Site Extension installed but how does that help me? I want to use the command line. There are two different command lines that I want to show off.

Kudu – Debug Console (Web Based)

When you create an Azure Website in the background a second site is created at http://<site-name>.scm.azurewebsites.net which exposes the Kudu Console (Kudu is the deployment engine for Azure Websites). You can access this site using either OAuth (which is enabled by default) or Basic Auth (http://<site-name>.scm.azurewebsites.net/basicauth). It’s cool that you have web based access to your website.

 image

KuduExec (Terminal, PowerShell, Command Prompt)

Although it is really cool to be able to use the command line in a web browser, wouldn’t it be nice to be able to use your command line of choice? Well, the team thought so too, and enabled it using Node.js. KuduExec is a command line tool which gives you command line access to your Azure Website.

Screen Shot 2015-01-22 at 2.43.38 PM

To install KuduExec, first you’ll need to install Node. Once you have node and npm installed run the following command.

npm install kuduexec –g

After kuduexec installs you can run it from the command line to login. To use KuduExec, type in kuduexec then the scm endpoint for your site (hint: http://<site-name>.scm.azurewebsites.net) then use your deployment credentials to login.

Then you have full access to your Azure Websites site.

Enjoy!

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.