WordPress on Azure – Part3: Installing WordPress

This is the third post in a 6 part series on running WordPress on Azure, with the purpose of getting started with Azure and learning some base skills while actually producing something useful, namely your own WordPress blog. This series is primarily aimed at IT professionals wanting to make a start with Azure.

PART 1 – “Hello world! So this is WordPress … on Azure 🙂” provided a high-level overview of the components and activities needed and PART2 – “WordPress on Azure – Part2: Creating and using your Azure subscription” looked at how to get your own Azure subscription and getting started with Azure. Today we will be looking at actually deploying and configuring WordPress.

WordPress on Azure – Part3: Installing WordPress

As discussed before, WordPress will be deployed as PaaS service. In other words we will not be creating a (virtual-) server, configuring the OS and actually installing the application and database on it, we will be making use of the Azure platform services to host the web site and the database. The web site and database needed to run WordPress will thus be consumed “as a Service”; rather than running our own Web Server and our own Database Server, we will only be consuming the database itself and the web engine itself.

The Azure marketplace provides an extensive set of services and “templates” for deploying solutions such as WordPress. This means most of the hard work in deploying and configuring these services has been done for you. In the case of WordPress, a template is available which deploys a web app, deploys a database and installs and configures WordPress for you. You simply have to select the template, fill a couple of variables and say “make it so” while Azure does all the hard work (well Azure and the guy that was kind enough to built the template).

Before we start, make sure you have created a Resource Group to which you will be deploying the services required for WordPress to run. If you have not yet done so, skip back to PART2, search for “resource group” and follow the instructions to create a resource group in a region close to you.

Now open the Azure admin portal (https://portal.azure.com), click on “Create a resource” (green “+” sign) in the top-left of the screen, type in “WordPress” in the search bar that opens and press ENTER.

Several WordPress options are displayed. Feel free to click through those and read their descriptions.

You will notice that some deploy full servers, for example “WordPress on Linux” and others are custom WordPress implementations for specific situations, specific versions or for addressing specific security concerns. We want the top one, just “WordPress” as this gives us a standard WordPress site making use of standard azure PaaS services, without deploying any special servers specifically for WordPress. Select the one that is named just plain “WordPress” and in the pane than opens on the right, select “Create”.


To deploy WordPress, the template we just selected specifies that we need to compete a number of variables (or you could say “answer some questions”), providing information such as the name of our site and the size or the web server and database we need. The size, or “tier” we select for each respective services influences primarily the performance we can expect to achieve, but also influences the options available (such as adding your own domain name to our site rather than using the Microsoft auto-generated name) and the level of redundancy built into the service (for example making it “Highly Available” and providing us with an SLA for up time).

The first page you will see after clicking “create” looks like this; let’s run though the options:

  • App name: The app name determines the publicly accessible URL of you web site; which will be “your site name”.azurewebsites.net. If you plan to add your own domain name to your site this does not really matter, however if you want to make use of the Microsoft provided domain name, make sure you choose a sensible name for your site.

 

  • Subscription: If you have multiple Azure subscriptions, make sure you choose the right one.

 

  • Resource Group: The Resource Group is the “container” where this site, it’s web service, database and all other elements used on Azure to power this site will be stored. Choose the Resource Group we created earlier, in PART2. If you have not created one yet, you can choose “create new” over here.

 

  • Database Provider: Here you have two options to choose from, namely:
    • MySQL in App: This provides you with a compact MySQL deployment running inside the app service itself (i.e. sharing the underlying server with your web site). This option is perfect to small dev/test environments or where your primary focus is WordPress itself and you are not really interested in the underlying Azure mechanics.
    • Azure Database for MySQL: This provides you with MySQL fully hosted and managed in Azure “as a Service”. If your intention is either running this site in production or you wish to be able to reproduce some of the items we cover later in this series, such as monitoring and backup, choose this option.

  • App Service Plan / Location: The App Service Plan is the “Web Server” where your site will be running. It determines the physical location (region) where your site is hosted, the size (performance and SLA) of your site and the features available to you. Click on it, then select “Create new”.
    • Give your app service (web server) a name, for example “WordPress”.
    • Choose the Azure Region, for example “Western Europe”.
    • Click on “Pricing tier” to open the selector. For now, select “Dev/Test” and the “F1” (free) Tier. We will look at the other options later.
    • Click “OK” to create tour App Service Plan and select it once created, which will take you back to the main WordPress creation wizard.

  • Database: This will create our MySQL database for us and allow us to select the Pricing Tier (again affecting performance and SLA) of our database. Click on it to open the database creation screen:
    • Server name: This is the name of the database (micro-)server that will be used to host your database. Give it a sensible name, such as “WordPress-MySQL-Server”.
    • Choose a username and password for the database admin and store this somewhere safe, such as in KeyPass.
    • Version: Except if you have very specific requirements, choose the latest.
    • Pricing Tier: As with the App Service, the Pricing tier determines the performance as well as availability options for the database. There is an important decision to make here as changing from the “Basic” pricing Tier to any other is not supported after creation. This means if you do choose Basic and decide to use the database for serious production purposes at a later time, you will have to backup the database, crate a new database server, restore your data there and reconfigure your application.
      • For my blog though, 1 vCore has proven to be sufficient thus far and the option is there to scale from 1 to 2 vCores within the Basic plan.
      • I chose 50GB as initial database size but as with the vCores, you can choose a smaller value and increase this later as needed.
      • You can further choose the backup retention period. Backup storage up to the size of your production database is provided free of charge. This is typically sufficient for roughly 7 days’ retention. In my case this is enough but if you want a longer retention you can increase it up to 35 days. Note that additional storage above your database size will incur a small storage cost.
      • You can lastly your redundancy options. For the basic Tier you only have 1 option, namely “Locally Redundant”. This ensures your data is stored redundantly, multiple times within the same Azure region.
      • Once you’re done select “OK”.
    • Database Name: Once back in the main database creation screen, give your database a name, e.g. “WordPress” and select “OK”.

 

  • Application Insights: This is an immensely powerful platform that monitors you web-app in real time, detects performance anomalies and helps you debug eventual problems. For now, we will leave it disabled but we will return to Application Insights later to see wat it can do for our WordPress site.

 


When you’re done making your choices, click “Create” to start the process of creating the database server, database, web service, web site and installing WordPress for you. As always you can monitor the progress by clicking the little bell in the top-right of the screen. You can also zoom into on all activities by opening the “Activity log”.

 


When the App Service and Database have been created, open up your blog resource group and your should see three resources:

  • An App Service Plan: Your “web server”.
  • An App Service: Your WordPress site.
  • An Azure Database “server”, which contains the database of your WordPress site.

 


To perform basic WordPress configuration, click the “App Service”. The next screen will show you various details of the App Services where your WordPress site has been installed. Click on the URL in the top-right, which will open a new screen prompting you to perform the initial WordPress site configuration.

The wizard will guide you though the WordPress setup. Follow the steps by selecting your language (cool, Afrikaans is in there as well!) and complete all the requested details such as your blog’s Title, you admin username and password (don’t use the same one you used for your Database and remember to store it safely). If you are running WordPress purely for learning, select “Discourage search engines from indexing this site”, which helps (slightly) in ensuring there is no unnecessary traffic to your site (which ends up costing you money). Finally click “Install WordPress“, which will start the installation and base configuration of the actual WordPress engine on your web server. This typically only takes a couple of seconds, once done you receive confirmation that installation was successful and you are provided with a link to log into your site. For future reference, you can reach your WordPress Admin section by browsing to your_site_ult/admin. The site’s URL is the one you clicked on when viewing the details of your App Service.

I won’t go into the details of using WordPress here, but HERE is a great guide to getting started as first-time WordPress used.


One last tip: Your site will, no matter how obscure, most probably receive a lot of SPAM. Within the first day of publishing my first blog post, the comments section was full with spam posts. For me, this was solved by taking two actions:

  • Configure “Akismet Anti-Spam“. This is done by browsing to the “Plugins” section in the Admin portal and selecting “Enable” next to the Akismet plugin. Once enabled you will be prompter at the top of the screen to configure your Akismet account. For me this was worth the effort.
  • I went a step further and configured all comments to require approval before being posted. I did this by browsing to “Settings”, “Discussion” in the Admin portal and selecting “Comments must be manually approved”. I’m not sure whether this is really what I want so I might come back on this one once I feel I have a better grip on preventing SPAM on my site.

Hopefully you will now have a live, working WordPress site hosted on Azure. Spend some time familiarising yourself with WordPress Admin and with Azure App Services and MySQL.

In the next post we will look at the various options you have to increase sizing and performance, and the implications they have on the cost of your site. I will also share some real-world figures with regards to the hosting costs of my own blog site.

Follow the links below to read each of the articles in this 6 part series:

Leave a Reply

Your email address will not be published. Required fields are marked *