Archive for April, 2016

Migrating WordPress web site to Azure


From the IT prospective a WordPress web site requires:

  • A web server like Microsoft IIS or Apache
  • PHP
  • mySQL database

Migrating a WordPress website includes copying all its files/folder structure, and its mySQL database, and changing the wp-config.php file to point to the new mySQL database. These tasks could be complicated for a large site and may require specific skills related to web site configuration and mySQL database administration. This post goes over a very simple way to migrate a WordPress web site to Azure, using the Duplicator WordPress plugin.

Executive Summary

  • Add Duplicator WordPress Plugin
  • Create New Package
  • Create new Azure WebApp
  • Add mySQL database
  • Upload the Duplicator package to the new Azure WebApp
  • Run the Duplicator Package Installer

Add Duplicator WordPress Plugin

If you don’t have it already, add the WordPress Duplicator Plugin. On the Plugins page click Add New

WP01

Search for Duplicator, click Install Now

WP02

Create New Package

Click on Duplicator link on the left, then click Create New

WP03

Accept the defaults and click Next to scan your WordPress site

WP04

Duplicator scans your current WordPress site

WP05

and displays the result like:

WP06

In this example, I have a couple of warnings about large site size, and some large files. I check the box and click Build.

WP07

Duplicator builds the package:

WP08

The package consists of an Installer (installer.php file) and Archive (.zip file). I download both to my desktop. The zip file contains all the WordPress site files and folder structure + a scripted copy of the associated mySQL database

Create new Azure WebApp

In the Azure Portal, click New/Web+Mobile/Web App

WP09

In the Web App blade I type in the new Web App name ‘MyWebApp407’ which must be unique under .azurewebsites.net. I pick the Azure subscription from the Subscription drop down menu. I choose to create a new Resource Group. I give it a name; ‘MyWebApp-RG’. I click the arrow to create a new Service Plan

WP10

In the App Service Plan blade (middle) I click Create New,  type in MyWebApp-SP as the name, select East-US and accept the default Pricing teir of S1 Standard.

Finally, I click OK and Create

In a few minutes Azure complete MyWebApp deployment

WP11

Add mySQL database

I browse under Resource Groups/MyWebApp-RG, and click Add

WP12

I search for mySQL, and select MySQL Database by ClearDB

WP13

and click Create

WP14

I give it a name ‘MyWebAppDB’ (avoid using other than alphanumeric characters in DB name), pick East US for the location, click the arrow and OK to accept the terms, and finally click Create

WP15

Click Refresh and note the new blank mySQL database:

WP16

Upload the Duplicator package to the new Azure WebApp

If you browse to the new web site now you may see a temporary page like:

WP17

First zip the 2 files downloaded from the Duplicator Package above into 1 file:

WP18

Next browse to the KUDU page http://MyWebApp407.scm.azurewebsites.net

Click CMD under the Debug Console menu

WP19

Browse to d:\site\wwwroot

WP20

Drag the zip file from prior steps and drag it on the right side as shown below:

WP21

Azure will upload

WP22

and unzip the file

WP23

Run the Duplicator Package Installer

Browse to the installer.php file as in http://mywebapp407.azurewebsites.net/installer.php

You will see a page similar to

WP24

Back in the Azure Portal, click MyWebAppDB/Properties

WP25

Note the Database Name, Hostname, username, and password

WP26

Back in the installer.php screen, enter the required information as shown below:

WP27

Click ‘Connect and Remove All Data’, click ‘Test Connection’, check the box to acknowledge the notices, and click ‘Run Deployment’

Click OK to continue..

WP28

The installer extracts the Duplicator Package zip file restoring the file system and rebuilds the mySQL database from the script contained in the zip file

WP29

Accept the defaults and click Run Update

WP30

The Installer makes the selected changes to the WebApp config files

WP31

Follow the installer instructions to do final testing:

WP32

Step number 2 above is actually important. Clicking on the link next to ‘2.’ above will take you to the site admin login page:

WP33

Use the same credentials from the original site.

Adjust your permalinks setting as it is on the original site.:

WP34

As a last step, once the site users have tested that everything looks OK, add a custom domain to the site and switch the domain DNS records to point to your new Azure site.

 

 

 

 

 

 

Advertisements

Powershell script to Auto-Expand StorSimple volume based on amount of free space


StorSimple Hybrid Cloud Storage array is an on-premise iSCSI SAN that extends seamlessly to the cloud. iSCSI volumes provisioned from a StorSimple device can be expanded but cannot be shrunk. So, a typical recommendation here is to start a volume small and grow it as needed. Growing a volume is a process that does not require down time. This script grows a StorSimple volume automatically based on set conditions of volume free space and a not-to-exceed value.

The input region of this script is the one that should be edited by the script user:

Expand01

Similar to the script that monitors StorSimple Backups, the values for SubscriptionName, SubscriptionID, and StorSimpleManagerName variables can be found in the classic Azure Management Interface under your StorSimple Manager node Dashboard and Device pages:

Monitor-StorSimple05

and the RegistrationKey:

Monitor-StorSimple06

and the SSDeviceName (StorSimple Device Name)

Monitor-StorSimple07

The value for the SSVolumeName (StorSimple volume name) variable can be found under the device\volume container:

Expand02

Notify variable can be either $true or $false. This instructs the script whether or not to send email notification when an expansion is triggered,

Similarly, Expand variable can be either $true or $false. This instructs the script whether or not to expand the volume when an expansion is triggered, When set to $false (and Notify is set to $true) and an expansion is triggered, the script will send an email notification that an expansion is triggered but will not do the actual expansion.

ExpandThresholdGB and ExpandThresholdPercent variables are used by the script to identify the amount of free space on the volume below which a volume expansion is triggered. Only one of these variables is needed. If both are provided the script will use the larger value.

  • Example 1: If the volume size is 100 GB, and the ExpandThresholdGB is set to 10 (GB) and the ExpandThresholdPercent is set to 15 (%), the script will trigger a volume expansion if the amount of free space is at or below 15 GB
  • Example 2: If the volume size is 100 GB, and the ExpandThresholdGB is set to 10 (GB) and the ExpandThresholdPercent is set to 5 (%), the script will trigger a volume expansion if the amount of free space is at or below 10 GB

Similarly, the ExpandAmountGB and ExpandAmountPercent variables instruct the script on how much to expand the volume once expansion is triggered. Only one of these variables is needed. If both are provided the script will use the larger value.

  • Example 1: If the volume size is 100 GB, and the ExpandAmountGB is set to 10 (GB) and the ExpandAmountPercent is set to 15 (%), the script will expand the volume by 15 GB once expansion is triggered.
  • Example 2: If the volume size is 100 GB, and the ExpandAmountGB is set to 10 (GB) and the ExpandAmountPercent is set to 5 (%), the script will expand the volume by 10 GB once expansion is triggered.

The value assigned to the variable NotToExceedGB is used by the script as volume maximum size that the script must not exceed. For example, if the prior 4 variables instruct the script to expand a 900 GB volume by an additional 200 GB and the NotToExceedGB variable is set to 1024 (1 TB), the script will expand the volume by 124 GB only to reach the NotToExceedGB amount but to not to exceed it.

DiskNumber and DriveLetter are values that the script user should obtain from the server’s Disk Management screen of the file server using this iSCSI volume:

Expand05

As of the time of writing this post and script (1 April 2016), there’s no way to correlate a volume on a file server to a volume on a StorSimple device. For example, if you create 3 volumes of the same size on a StorSimple device and call them data1, data2, and data3, and present them to the same file server and format them with the same file system and block size, and use volume labels data1, data2, data3, there’s no way to tell if data1 on the StorSimple device is the volume labeled data1 on the file server. This is why it’s recommended to provision and format StorSimple volumes one at a time and use the same volume label when formatting the volume as the volume name on StorSimple. Long story short, it’s the user’s responsiblity to:

  1. Make sure the DrviveLetter and DiskNumber correspond to the SSVolumeName, and
  2. Update the DrviveLetter and DiskNumber values if they change on the file server due to adding or removing volumes.

One last point here; if this iSCSI volume is presented to a Windows Failover cluster, this script must be run on the owner node.

LogFile is the path to where the script will log its actions – each log line will be time stamped. This could be on a network share.

EmailSender is the name and email address you wish to have the email notification appear to come from. For example: StorSimple Volume Size Monitor <DoNotReply@YourDomain.com>

$EmailRecipients = @(
‘Sam Boutros <sboutros@vertitechit.com>’
‘Your Name <YourName@YourDomain.com>’
)

is an array that takes one or more email addresses in the format shown above.

SMTPServer is your SMTP relay server. You need to make necessary configuration/white-listing changes to allow your SMTP server to accept and relay SMTP email from the server running the script.

Sample script output:

Expand06

another example:

Expand04

and example of email notification:

Expand07

Possible future enhancements to this script include:

  1. Rewrite the script as a function so that it can handle several volumes
  2. Rewrite the script to use Powershell remoting, so that it does not have to run on the file server.
  3. Add functionality to detect if the target file server is a member of a failover cluster, and to automatically target the owner node.