The following write up will outline the example of getting WordPress running on Azure Websites with a remote MySQL database and will be covered in two parts. In the first part, the database is hosted in an Azure VM and in an Azure VNET. The example will go over using VNET integration as well as Hybrid Connections to securely connect to the Azure VNET. This assumes a pre-existing VNET that has a VM already provisioned in it.
The second part will cover hosting the database in an on-premises host that is accessible through a combination of Site-to-Site VPN and VNET integration. This will use the same pre-existing VNET. There is no need to show Hybrid Connections as there is no difference to make it work on-premises vs a VNET.
Both connectivity features are currently in Preview. That mostly means that they will continue to be improved and made better to use. It should be noted that if you have no problem making your application endpoint accessible to the internet, that is yet another option available to you and you need no extra features to use it.
Create a MySQL database
Before setting up WordPress, we need a database for it to talk to. Since this is just for demo purposes, we are going to go the easiest application path. That does not mean that it is the way to really run your MySQL database. The focus here is primarily on setting up a website with a remote database. The VM I provisioned happens to be a 2 Core 3.5GB VM with Windows Server 2012 R2 installed.
If you are making your VM and VNET for the first time, be sure to first create your VNET before you create your VM. You have to specify the VNET during the VM creation process and can’t change that after it is created. If you need more of a grounding on Azure Virtual Networks before going further, start with the information here: https://azure.microsoft.com/en-us/documentation/services/virtual-network/
Log onto your VM with remote desktop. To pull down the remote desk top rdp file, use either the new or old portal as shown.
Once on the VM, I pulled down the MySQL installer from: https://dev.mysql.com/downloads/mysql/ and ran it.
The installer works well and even disabled the firewalls for the ports used. WordPress needs a database and account to access it. To do that, the easiest thing for me is to simply open up a command shell in the C:Program FilesMySQLMySQL Server 5.6bin directory.
From there, log into mysql with:
mysql –u root –p
In my case that was:
mysql –u root –pvpndemo
To make things easy for demo purposes I am using root but you should never do that with a system you care about. Create the database with the command:
CREATE DATABASE;
I used the name hybrid for my database making my command:
CREATE DATABASE hybrid;
Give your account permissions to use the database with the command:
GRANT ALL PRIVILEGES ON *.* TO ’root’@’%’ IDENTIFIED BY ’vpndemo’ WITH GRANT OPTION; FLUSH PRIVILEGES;
Now you can exit the mysql shell. The database is set up. Before you quit your remote desktop session, get the IP for your VM if you don’t know it already. I like simply using ipconfig from the shell prompt. My ip is 10.0.1.4 and is obviously not an internet routable IP address.
Install WordPress
Instead of using WordPress from the gallery I thought I would do everything from scratch. To start I pulled down WordPress from here: https://wordpress.org/latest.zip This is a zip of the latest version of WordPress, which happens to be 4.0.
Next, I created an empty website in Azure Websites. From the new Azure Preview portal at https://portal.azure.com I used the New icon on the bottom left to bring up the website creation UI. In this case I created a site named thirdVPNdemoSite.
Before you create your website, be sure to think about the region where you want everything. If you want to make something like what we are doing in this paper then you want your website, VNET and VM to all be in the same region. You can have a website from one region connect to a VNET in another region but it should be avoided for performance reasons if nothing else.
To upload and manipulate WordPress, I used the Kudu console which makes it extremely simple. Open your website scm page by browsing to your website and editing the url to add .scm. after the site name. My website is thirdVPNdemoSite.azurewebsites.net so my scm site is thirdVPNdemoSite.scm.azurewebsites.net. Once there, go to the debug console and select CMD or Powershell.
Navigate to D:homesitewwwroot. That is where WordPress will go. To do that, I recommend that you use shell commands or the navigator. To copy WordPress up, grab the zip file and drag it onto the explorer view in the Kudu console. You will see a box appear that says, “Drag here to upload and unzip.” Drag the zip there. After this you have a WordPress directory in your wwwroot directory. I wanted my WordPress site to be at the base of my url without any application specification. To do that I needed to move the contents of what was in the WordPress directory up one level. This is easy enough by going into the WordPress directory and doing
move * ..
Next you need to configure WordPress to work with your database. While in the wwwroot directory copy the wp-config-sample.php file to wp-config.php and then edit it. The file contains the information to access your database among other things. To edit the file you can hit the edit pen in the Kudu explorer UI.
Change the items as noted in the picture including the database name, username, password and hostname. The part that has yet to be done is establish connectivity between your website and your VNET. Before doing that though it makes sense to prove the fail case. If I try to browse to the website I get the anticipated failure message because WordPress cannot access my database.
In my case I was using Chrome which gives me the above message. Other browsers have a different experiences. IE says “The website cannot display the page”.
Set up VNET integration
To enable connectivity to the database from the website we will first use VNET integration and then take down VNET integration and show how Hybrid Connections work to get to the same database. In order to enable VNET, go back to the Preview portal view of your website and browse down to see your current VNET settings.
If you haven’t put your website into a Standard pricing tier, that is the first step. If you are in a pricing tier lower than Standard then this means you will be charged more. Clicking on the Virtual Network UI when you are not yet in a Standard plan will bring up the pricing tier screen where you can make the change. The next step is to add the virtual network to your website. Again click the Virtual Network UI and you can select your VNET that you want your website to be integrated with.
If your VNET is not selectable that can only be if one or both of the following items is true. Either your VNET doesn’t have a dynamic routing gateway or it doesn’t have point-to-site enabled.
If your VNET does not have Point to Site enabled then you need to go into your Virtual Network in the current portal to set that. If you are going to try the second section in this document on working with a site-to-site VPN connection, make sure that the IP range you use for your point-to-site connection doesn’t conflict with your on-premises IP range. In my case I have 192.168.0.0 in use on-premises so I will use 10.0.0.0 IP addresses here.
If you don’t have a gateway set up then you need to add a gateway as well. If you have a gateway and cannot enable point-to-site then that is because your gateway is a static routing gateway. You will need a dynamic routing gateway instead.
Now that everything is set up, if it wasn’t earlier, go ahead and select the VNET that you wish your website to integrate with. Once your enable VNET integration with your website, the website system will exchange certificates to make sure that all communication is secure between just your website and the VNET. The green check doesn’t mean your site is connected. It means that the certificates are in sync. You can see the certificate for that your website set up for your VNET in the Virtual Network certificates tab.
There are some things that can cause the certificates to require being re-synced including adding DNS, or adding Site-to-Site VPN. If you need to resync certificates, simply click the Virtual network and hit the Sync Connection action at the top of the page.
Now when you hit your website you get to the database. The screen you should see is the language selection screen that you hit when first setting up WordPress.
Success!
Now to repeat the process with Hybrid Connections. First we need to break the VNET integration. Go to the site configuration and into the Virtual network UI and Disconnect. If you browse to the website now, you should see the same database is not available UI that you saw earlier.
Set up Hybrid Connections
Whereas VNET integration lets you access many resources in your VNET or through your VNET, Hybrid Connections gives you access only to a single application per endpoint but you are not limited to it being in your VNET. You could access applications that are each in a separate network if you needed to. While a website can only integrate with one VNET, it can integrate with many Hybrid Connection endpoints. You are limited by the quantity of endpoints covered by your BizTalk service.
To enable Hybrid Connections go to the Websites Hybrid Connections UI next to your Virtual Network UI and create a new connection to your endpoint. This will require creating a BizTalk service account if you don’t already have one. From this UI you can only create a free BizTalk account for now. That lets you have up to 5 endpoints that you can use across any number of websites. For additional endpoints use the current portal to adjust your Biztalk service plan.
After you create your hybrid connection you will see that it still shows as unconnected. The VNET integration feature uses point-to-site technology to create the integration. The Hybrid Connectivity solution uses something similar to what used to be called port bridge under the hood. Some of that was even leveraged to make this hybrid solution possible. The way it works is the website connects to a relay server. An agent placed somewhere that has access to the endpoint and to Azure is also installed. Both connect to the relay server and then through the connections a tunnel is made to a single endpoint. When specifying the host:port for the endpoint, you can use a hostname that will resolve from the host where the relay agent is being installed. Your website can then use the same hostname to access the application endpoint. This makes it a lot easier to lift and shift a given website from on-premises to Azure Websites and still be able to use the same connection strings it did while on-premises.
To finish the connection you need to install the Hybrid Connectivity agent. This next part has to be done from your VM hosting your application or from another VM in your VNET that can access your database. In my case I simply used the same VM as the one hosting the database. Open your IE browser and log into the Azure preview portal. Go to your Website and then to the Hybrid Connections UI. From your Hybrid Connections UI click on your connection.
I said to use IE but that was simply because the next step works great in IE but not as well in Firefox or Chrome. Click Listener Setup to get access to the agent installer.
To install the agent simply click Install and configure now. The installer has a few click through items and that is all it takes to install the agent. After agent install the agent will connect to the Azure relay server and open up the connection to the endpoint. Unlike VNET, you can see the connection status in the UI but this doesn’t say you can connect to the endpoint but rather that the website has connectivity to the agent. If you want or need multiple agents for redundancy then you can install multiple instances where you want. The multiple agent instances do not count against your endpoint count.
Now when you browse to the website you will be able to see the same WordPress language selection UI that you saw after getting VNET connected.Before moving onto the next section go into your Hybrid Connections UI and Unregister your endpoint from your website. It won’t delete your endpoint, unless you use Delete, but will disconnect it from your website. When you try to browse to your website you will again see the familiar failure screen.
That ends the first section that describes how to securely access resources in your VNET. The Hybrid Connectivity description is applicable in any network. You do not have to make any special provision for that to work for on-premises access. For VNET Integration the story is different. To gain access to on-premises resources through your VNET you need to set it up for Site-to-Site VPN.
On-Premises Database – Site to site VPN
In order to set up site-to-site VPN for a pre-existing VNET you need to add a local network and tie it to your VNET. This assumes you have an internet addressable gateway server that you can use for this purpose. If you don’t have an internet addressable gateway then you will have an easier time simply using Hybrid Connections as described earlier.
Assuming that you do have an internet addressable gateway, the first step is to create a local network. To do this go to the current portal and hit the New icon in the bottom left. Navigate to the Network Services -> Virtual Network -> Add Local Network.
Specify the Name, VPN Device IP address and the IP range of your on-premises network. Now that you have a local network it simply needs to be tied to your VNET. Go to the configuration tab for your VNET. You need to have at least one local network before the Site-to-site connectivity UI is visible. Simply hit the checkbox to connect to the local network and select the local network you wish to use.
On the dashboard you will now see the local network show up but will be disconnected. The next steps need to be performed on your on-premises gateway server. From the dashboard for your network in the current Azure portal, click on Download VPN Device Script on the right hand side of the screen. This brings up a screen like below.
Since I am using RRAS on Windows Server 2012 R2 I selected those items and confirmed it to download the VPNDeviceScript.cfg file. This file is a powershell script that needs to be run on your gateway server. After running it your network dashboard will show the connection as established. This update takes a few minutes so do not be alarmed if the UI doesn’t instantly respond after you make the change.
While everything now looks like it is set up there is one last item remaining as a part of the network configuration. At this time the site-to-site VPN enablement does not set up routes for any point-to-site connections in your VNET. Without the next step this means that while you can send requests down to on-premises systems from your website, you will not be able to get any replies.
Luckily this is easy to fix. You simply need to add routes on-premises to return traffic back up to your point to site connections being used by your websites. In RRAS I simply added a static route as shown.
If you don’t remember your point-to-site IP range, go to the Virtual Network space in the Azure portal and enter the Configure tab. There is no way to know what IP your website will use in your point-to-site block so you need to set up routes for the entire block.
Now your website can have access to resources in your on-premises network. To finish the demo, pick a host in your network and install MySQL as we did at the start of this document. Don’t forget to create the database and grant access to your account.
Go to your kudu console and edit your wp-config.php file. Update your host name and anything else you changed with the new database. For the sake of simplicity I simply set everything up as I did in my Azure VM so the only thing different is the hostname.
To show that you are in a known state, hit the website. You should again see the Error establishing database connection UI. Now go to the preview portal and once again integrate your website with your VNET. You should see the language selection screen once again. This time you are using your on-premises database through your VNET integration.
Troubleshooting and other information
Should you encounter problems accessing your desired endpoint there are some utilities you can use to test connectivity. The tools ping, nslookup and tracert won’t work through the Kudu console due to security constraints. To fill the void there have been two separate tools added to help debug issues. In order to test DNS functionality a tool named nameresolver.exe has been added. The syntax is:
nameresolver.exe hostname [optional: DNS Server]
To help prove connectivity we also added a tool to perform a TCP ping named tcpping.exe. The syntax for this tool is:
tcpping.exe hostname [optional: port]
The great thing and downside of TCP ping utilities is that they are hitting a specific host and port. These tools are great to tell you if you can reach your application but not to tell you simply if you can reach the host in a generic sense. If you are not sure that you are listening on the port you are trying to hit, use netstat –a to make sure you have an application listening where you thought you were listening.
The most common issue that I have seen so far has been with firewalls. One of the first things you should check if you can’t get to your application port is the firewall configuration. In the case of MySQL installation, the MySQL installer opens up the listening port 3306 automatically. Even so it’s the first thing I check if there are any issues.
Another debug point is to make sure that your website and VNET are working with the same set of information. Aside from the certs there are bits of essential information that is exchanged between websites and VNET when synchronizing certificates. It is possible you changed something in your VNET but didn’t update your website with the latest information. Resync your connection as one of the troubleshooting steps. One reason that this isn’t automatic is in part so customers can easily disable VNET access by deleting certificates.
Limitations
While these integrations enable many types of uses there are still limitations on several things. At this time you cannot use these hybrid access technologies to:
- Integrate your website with Active Directory
- Integration your website with LDAP
- Mount a drive
There are also restrictions on the quantity of VNET integrations or Hybrid Connections you can have.
- You can have up to 5 VNET integrations per Standard pricing tier Web Hosting Plan. Those 5 integrations can be used by any number of sites in that plan.
- You can have up to 5 Hybrid Connection endpoints with the free BizTalk service. Those 5 endpoints can be used by all of your websites and use is not limited to your web hosting plan but rather to your subscription.
Both Hybrid Connections and VNET integration are still in Preview and will be improved upon or before GA but already offer a lot.