I’ve started redeploying my websites on Azure App Services. In this post, I’ll explain the rather simple architecture and how I am going through my own little digital transformation or cloud transformation.
For the last few years, this site (http://aidanfinn.azurewebsites.net) has been hosted on an Azure virtual machine running Windows Server 2012 R2 and an aging copy of MySQL. Once upon a time, before having a family, that was fine. I had lots of time, and a willingness to “muck in”. These days, I prioritise my time and my time is limited. I want to focus on content, not on admin … and isn’t that the point of the cloud?
That’s why I made the decision to switch from an IaaS virtual machine in Azure to Azure PaaS in the form of App Services, a part of Azure that has consumed a good bit of 2018 for me so far. This decision included this site, and I decided to build a new WordPress site for my Azure training business, Cloud Mechanix, on http://www.cloudmechanix.com.
The architecture is pretty simple:
Azure Database for MySQL Server
Both of my sites run on WordPress and that means MySQL – something that I know nothing about and have had problems with in the past – resulting in a complete VM restore back in the preview days of Azure Backup for IaaS VMs. If you want to know nothing about installing/running/backing up a database, then Azure Database services are for you! Many IT pros will have heard of Azure SQL, but there are also MySQL and PostgreSQL implementations of the service.
I deployed 1 instance of MySQL Server for each website. I tried to deploy 1 instance only, with multiple databases, but the second WordPress site just wasn’t having it. I’ve used the Basic tier and so far, the size seems to be OK.
A storage account was also created, and I configured diagnostics exports of both database instances to blob storage using Azure Monitor.
App Service Plan
A single app service plan hosts both websites. I decided to go with the Standard tier because I wanted backup functionality, not just custom domains that the Basic tier would offer. I offset this by being a little clever with the sizing. The plan is using a single instance (Windows Server 2016 IIS virtual machine under the covers), with content stored on a back-end SMB 3.0 share (also under the covers). I deployed the small S1 instance, keeping the costs down. However, aidanfinn.com is running on a decent spec D2s_v3 VM with 2 cores and 4 GB RAM. To offset the drop in resources and to enable peak demand, I’ve enabled autoscaling, supporting 1-2 instances. The autoscaling is configured to go to 2 instances if CPU or RAM exceeds certain thresholds for 10 minutes, and to drop to 1 instance if CPU or RAM drops back down below those thresholds.
There is one app service for each website. I have deployed a storage account for backing up the websites every morning (at different times), including their databases – you can’t have enough backups!
Making The Deployment Easy
it sounds like I deployed a lot of stuff, right? Actually the WordPress, published by WordPress, template in the Azure Marketplace for App Services & Azure Database for MySQL Server made it really easy! It created the app service plan (first deployment only), the app service, and the database instance/database. Then I ran the template again, using the existing app service plan, and creating a second piring of app service and database instance/database. Then I logged into the default WordPress page of each site, and configured my credentials.
Changing the WordPress Settings URL
The default URL of the WordPress site in Settings will be configured and greyed out to use the default Azure domain name, even after you associate your own domain name with the site. The trick to changing the URL is to:
- Configure the FTP password for the app service
- Get the FTP username and server name from the app service properties
- Connect to the app service using FTP
- Browse to the /site/wwwroot folder
- Download wp-config.php and edit it
Look for a line with define(‘WP_DEBUG’, false);
Straight after that, add the following line:
Upload the wp-config.php file back to the site.
Browse to the new URL of the site, e.g. www.mynewdomain.com/wp-login.php, and sign in. This will update the WordPress URL settings of the site.
Re-download the wp-config.php file, remove the above line that you added, and upload the file again.