Deploying WordPress on Azure using Hybrid Containers

In the last post we looked at the different architectures that can be used to deploy WordPress in Azure. We decided to deploy our site using a hybrid container environment. This has the web service running in a docker container but the database running as a separate resource. This makes the web service a simple component which can be easily replaced if problems are experienced or scaled in response to load changes. If you haven’t already deployed any Azure services then you will need to start by deploying a resource group. This will group the WordPress resources together. Give this a name select the subscription you will be using to pay for the service and select the Azure region that you want to use.

MySQL Server Installation

Next deploy a Azure Database for MySQL Server. This will be used to host the WordPress database and will allow us to deploy additional web services connected to the same database.
You’ll need to define some basic settings as part of this deployment and you will need to record some of the details for later. The server name needs to unique across Azure and will ultimately end up with a fully qualified domain name of servername. The server admin name and password should be something complex and will be used to remotely access the database. Finally you may want to modify the pricing plan which is designed for significant production systems.
Once the database server has successfully deployed you need to create the WordPress database to the MySQL server. If you already have the MySQL tools installed you can use these to connect to the server. Otherwise you can connect using the cloud shell directly from the Azure portal. This is the command prompt in the toolbar.
If you haven’t used this before it may prompt to create a storage account. This will likely be deployed in a different Azure regions from your WordPress services but this won’t cause any problems. Once you are at the prompt you can use the following command to connect to your new MySQL server
mysql -h -u [email protected] -p
Then run the following script to create a wordpress user account in the database and create a new database.
create user 'wordpress' IDENTIFIED BY "Sup3r53crEtP455w0rd";

create database wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress';
WordPress doesn’t support connecting to a MySQL database using SSL connections out of the box. There are ways to patch this behaviour by updating the code but otherwise you will need to change the connection settings of the MySQL Server. You will also want to allow Azure resources to communicate with the server.

Web Service Installation

There are two parts to the web service. The billing component is called the App Service Plan. We’re going to be using docker containers for the web service using a Linux App Service Plan. Give the Service Plan a name, assign it to your resource group and subscription. Then make sure that it’s a Linux service plan in the same location as your database. Finally make sure that you’re happy with the billing for the site.
Now you can create the Web Application and associate it with the new service plan. Again make sure that you set the OS to linux and then select configure container.
Change to the docker tab and then enter wordpress:latest. This is the public wordpress repository and will mean that you get the latest wordpress setup whenever you update the container.
Once the web service deploys and starts you will be able to access the web service using the address. This will show the WordPress quickstart page. Select the correct language before proceeding to the database setup page.
Next fill in the connection settings for your MySQL server. you need to make sure that you use the full names in this section so the username needs to be [email protected] and the database host needs to be if you don’t use this syntax then you will end up with a connection error.
All going well you should now see the WordPress welcome page.
There’s still more to do before you have everything ready to go into production but with just a few steps you’ve got a serverless web server. this is what makes public cloud so powerful.

Options for deploying WordPress to Azure

We’ve been using to host our site. This is a cost effect solution, particularly with the cheaper subscription levels, but we decided that we really needed to drink our own kool-aid and migrate to our own public cloud. This even resulted in a saving for us as we have a Microsoft Partner account which has monthly Azure credits. Finally since we are now running our own WordPress site there are no functionality restrictions as is the case with the sites. With Azure there are a few different ways to deploy WordPress:
  1. Deploy WordPress using a VM in IaaS. This could be done using either one or several Windows or Linux VM. Using this model you need to think about whether you want to scale up or out and design this capability. You’re also running a full blown operating system so you are paying to run this as well as having to maintain it yourself.
  2. Next you could deploy everything into a container This would result in both the database and the web site running inside a container. This will have the smallest footprint but scaling the solution will be a little harder as the database is contained inside the docker container as well.
  3. You could also use the PaaS Web App service to run WordPress. This again can be either a Windows or Linux web service. In this case you will also need to deploy a database service which does allow for the web service to be scaled out if required.
  4. Finally you can also use containers but with an external database. This will use a docker image for the web service which connects to a dedicated database service. This solution actually runs on the Linux PaaS Web App so the difference between the two is how you stand up your solution. Is it pulled in from a docker image repository or do you push the web code using git into the web service?
In the end we decided on a WordPress docker image connecting to a Azure Database for mySQL server. This allowed for a shockingly quick deployment while still allowing some flexibility and the ability to expand. In the next article we’ll go through the process of how we set up this site.