For my first (true) modification to my new Jeep Wrangler Unlimited, I decided it was time to move those seats in the back further back! You see, in the stock Unlimited, the rear bench seats are awesome and comfortable. The rear seats are a bit close to the back of the front seats. Now, if you add kids car seats, that puts the faces right up onto the front seats. It also has them sitting straight up into the air! My kids couldn’t even nap without kinking their necks, or banging their heads into our head rests. So – its time to modify!
Luckily a friend told me about a very simple modification. The folks over at Ohio Diesel Parts have a great Jeep Wrangler Rear Seat Recline Kit to solve the problem. The kit will drop the back of the seat 2.5 inches back, and raise the tilt of the lower seat by 1 inch or so. The cost is reasonable, $52 originally, but $26 on sale at the time of this post. That will basically allow the kids to sleep a bit more comfortably, and not have their heads next to my head rest (where they can talk or scream me deaf!).
Basically, it is a bolt on modification. First, you remove the factory 4 floor bolts with an 18mm socket on the front of the rear seats. Next, you raise the seats up vertically, and remove the back 3 floor bolts holding the remainder of the floor mounts in place. Then, you add in spacers to the back 3 floor bolts and re-attach the factory bolts (Ohio Diesel sends you longer ones if you need). Lower the seats back into place, on top of the 4 extra tall spacers, and re-attach with the provided extra long bolts (these are 17mm socket bolts).
Note: these bolts are tight, so use an impact wrench or a breaker bar to get them out. Also, there is one bolt on the back three, on the driver side, that is damn near impossible to get off without an extra long 18mm socket. So good luck! I will admit, they were in there good and tough!
Once you are done, the seats look like they are back to stock, but with a much nicer recline on the top seat. And now there is a better pitch on the bottom seat. As you can see from the pic, the effect is subtle, but it is noticeable. My youngest road in this today, and told me “daddy, this is much more comfortable.” Don’t know if he was just making me happy, but he seemed to like it! For such a reasonably priced modification, it is a great bang for the buck!
Once you have a solid WordPress website running on Azure App Services as a Web App, the next logical step that everyone wants to do is map a Custom Domain to it. For developers, this step is often overlooked as this is a go-live activity, and not necessarily something that they are accustomed to having to concern themselves with. For infrastructure engineers, this is fairly straight forward in traditional hosting. For the Cloud, this is… interesting.
If you haven’t yet created a WordPress in your Azure subscription, check out this post for a good write-up on how to get that done.
There is a great tutorial from Microsoft on this particular topic, at least for the Custom Domain mapping part. The intersection of WordPress and this step though, can be a bit challenging. I am going to break this up into a couple of sections to make it a bit easier to follow.
Configure your Domain Provider for the appropriate DNS records (A record, CNAME, TXT, etc).
Configure the custom domain host mappings in Azure, in the App Service for your Web App.
Get your SSL certificate with a CSR for Azure
Add your custom SSL certificate to Azure, in the App Service for your Web App.
Configure the custom SSL certificate domain host mappings in Azure, in the App Service for your Web App.
Azure App Service Web App – Forcing HTTPS!
Update WordPress for the new URLs.
A fully functional WordPress site running on Azure in an App Service Web App. And that App Service Plan that contains the App Service cannot be the free tier – it must be in a paid subscription.
Purchased a custom domain EXTERNALLY from a third party like GoDaddy.com (note – you CAN purchase custom domain from inside of Azure using their automations. I’ve done it and it is very straight forward. But assuming that you already have your custom domain, and you didn’t buy it from Azure, then this is the guide for you!).
Purchased a custom SSL certificate EXTERNALLY from a third party like GoDaddy.com (same note as above).
Access to a Windows 10 or Windows Server (for exporting and alterations to the SSL certificate – you can do this from another type of machine, but this tutorial will focus on this).
FTP access to your WordPress installation in Azure
Configure your Domain Provider for the appropriate DNS records (A record, CNAME, TXT, etc)
First, we need a CNAME record for our “www” subdomain. “www” is a subdomain of a primary domain, so it needs its own record. You need to connect with your Domain Provider (like GoDaddy.com), and manage your DNS records. Create a CNAME record for your site that maps the name “www” to your internal Azure site name (in the form of <app_name>.azurewebsites.net). This will also have a TTL entry – you can put whatever you like, but I usually stick with 1 hour.
Next, we need an A record for our primary domain. Again, connect with your Domain Provider, and manage your DNS records. Create an A record for your site that maps your App Service Web App external public IP address from Azure with your domain @ (the @ means root).
Last, we need to create a TXT record to map the site’s default hostname (<app_name>.azurewebsites.net). This is required during configuration in Azure – so if you want to remove it afterwards, you can. Create a TXT record for your site that maps your internal Azure site name (in the form of <app_name>.azurewebsites.net) to your domain @ (this @ means root).
When you are done, you should have three records that look something like this:
Configure the custom domain host mappings in Azure, in the App Service for your Web App
Once we have our Domain Provider configured, next we configure Azure. If you log into the Azure Portal, and navigate to your App Service for your Web App, you will want to connect to the “Custom Domains” blade for the site.
Inside of this blade, there is a section for “Custom Hostnames”. This is where we will do the work.
First, we need to add a Hostname for “www”. Click on the “+” button to add a new Hostname. The Hostname value should be your www.<customdomain>.com value. You will then select Validate, which will check your Domain Provider to ensure that you are configured correctly. Once it validates, make sure that the type of Hostname is set for CNAME. Then click Add Hostname, and you are done.
Next, we need to add a Hostname for our primary domain. Click on the “+” button again to add a new Hostname. The Hostname value should be <customdomain>.com value. You will then select Validate, which will check the TXT record on your Domain Provider to ensure that you are configured correctly. Once it validates, make sure that the type of Hostname is set for A record. Then click Add Hostname, and you are done.
If everything has worked correctly, you should be able to open your browser and navigate to either the www.<customdomain>.com or <customdomain>.com and pull open the site. It will likely redirect you back to your Azure name <app_name>.azurewebsites.net, but that is ok! It means that we have configured the DNS settings in both our Domain Provider and Azure correctly.
It may take a while for the DNS records to propagate from the Step above. Sometimes it is almost instant, others it can take a few hours. Just keep checking once and a while to see.
Get your SSL certificate with a CSR for Azure
For SSL certificates, it is definitely easier to purchase and deploy through Azure than it is to do a custom certificate from a 3rd party. Be that as it may, almost everyone will get their certificate from a 3rd party, especially if you work somewhere that already has an existing web site. So – this section is for you!
There are a couple of things we will need here. First, access to the SSL certificate itself. Normally, SSL cert’s are tightly controlled by an IT department – so you may not be able to do this step alone without involving others. But, assuming you get access to the SSL cert, the rest of this can be accomplished fairly easily.
Also, we will need a piece of software to make this process easier for us (you can do this by hand using other OpenSSL tools, but for simplicity, I’m going to use a GUI tool). DigiCert has a tool that really makes this easy for us, as well as some pretty good instructions to walk you through the process. Their documentation is a bit dated, but you will get the general gist from this post. Download the DigiCert Certificate Utility for Windows and install it on a Windows machine that is server class or has all of the Certificate capabilities (like a machine running IIS correctly).
DigiCert Certificate Utility for Windows
First, if you don’t already have a SSL cert, then you will need to get one. If you have a new domain, or it is a new cert, you will likely be asked to create a CSR (Certificate Signing Request). If so, then this utility will help. Click on the “Create CSR” link to start the creation.
Note: In traditional hosting, you would run this utility on the actual web server that would be hosting your website. This is a security measure. But in Azure, there isn’t a physical machine – so we can’t do that. The best we can do is install the cert somewhere else, and export the cert for use in Azure. So, we are running this tool on a mock web server machine.
Certificate Type: SSL
Common Name: www.<customdomain>.com
Subject Alternative Names: if you have a multi-domain cert, it is the SANs that you want to include. If that doesn’t apply to you, leave blank.
Organization: your company’s legal name (or rather, the owner of the SSL cert).
Department: if applicable. I usually put IT.
City: the city where the company is legally located
State: you get the point…
Country: still with me??
Key size: important… you need at least 2048. This is a requirement in Azure.
Provider: Microsoft RSA SChannel Cryptographic Provider
Click Generate. It will then present you with text for your CSR to provide to your SSL provider (save it in case you need it again later).
Add your custom SSL certificate to Azure, in the App Service for your Web App.
Ok – so if you made it this far, you now have received the SSL cert from your SSL provider. Yatzee!!
But we are not out of the woods yet. Fire up DigiCert again, and click on the Lock symbol. We now need to import our SSL cert that we just received and install it locally. Click “Import”, navigate to the cert (*note: either CRT or CER file), enter friendly name as www.<customdomain>.com, and finish.
You should now see your cert in the window. Select the cert in the window, and click “Export Certificate”. In the Export wizard, select “Yes, export the private key” and the .pfx file (and ensure to include all certificates in the certificate path if possible). You will be prompted for a password – create it and remember it – this is critical for installing it in Azure. Finish the dialogs and save the exported pfx file. You now have your SSL Certificate ready for import into Azure!
Configure the custom SSL certificate domain host mappings in Azure, in the App Service for your Web App
Now, its time to upload the SSL cert to Azure. Go back to the Portal, and navigate to the SSL Certificates blade of your Azure App Service Web App.
Select “Upload Certificate”, and select your PFX cert file. When prompted, enter the password you used in the previous step. Once it is uploaded, it will appears in your SSL certificates blade.
In the SSL bindings section, click Add binding. You need to add an IP-based SSL binding for your www.<customdomain>.com binding, and an IP-based SSL binding for your <customdomain>.com binding. Both times, select the certificate that matches the custom domain.
If you made it this far, it is time to test again. Open a browser window and try to navigate to your custom domain, this time with https://www.<customdomain>.com. If successful, you should be able to pull open your site and it should work (same as before, it may reply back with the <app_name>.azurewebsites.net URL, but we are going to fix that next).
Azure App Service Web App – Forcing HTTPS!
Ok, this bit is optional, but it is one that I’m pretty passionate about. We went through all that trouble to configure this, why not force all traffic into SSL? Well – its better for SEO, its more secure, and it makes your visitors feel better, right?
Its actually easy to do this in .NET using URL Rewritter (which is deployed into Azure). Simply modify the web.config file for your site to include the re-write rules. Open your FTP program of choice, find your web.config for your site, and add the following to the <system.webServer> node of your web.config:
Ok – we are in the home stretch. This is the last bit, but arguably the most challenging. WordPress developers have known for a long time that WordPress stores the fully qualified URL for eveything in its database. Some of those storage techniques are also hashed into sizes. Its everywhere – and its a pain to change by hand. (Opinions aside about relative versus absolute URL management – I’m not a WordPress author – so I can’t throw stones).
So – if you are comfortable with WordPress and you know how to update everything, be my guest! I, on the other hand, like a Database Search and Replace Script in PHP from Interconnect/it. This tool will work wonders in simplifying the process, albeit it is scary to run. Basically, you need to download the software, and move a “hidden folder” via FTP to your live running site. Then, navigate to it quickly as it is live and real. Once there, you will enter the full url of your old site (https://<app_name>.azurewebsites.net) and replace it with the new url of your site (https://www.<customdomain>.com). Click “Dry Run” to see what it thinks it wants to do and review thoroughly. If you are comfortable, fire it up and let it rip and replace. When you are done, click the “Delete Me” link and make sure it is gone (verify VIA ftp).
I strongly encourage you to only execute this on a backed up database in case of trouble. It is live modifying your WordPress database, including your Permalinks. So be cautious.
Ok – we are done. Fire up your browser, and navigate to your site (https://www.<customdomain>.com). Your site should come up now, with the right URL in the browser window, SSL encrypted. You should be able to navigate around, and it should be working as expected; you should also be able to get into the Admin side of WordPress as before, and verify that all of the links are updated and functioning. Lastly, verify that your Permalinks are correct.
So, you want to run WordPress on Azure? Well good news for you is, it is pretty straight forward now, thanks to both WordPress and Microsoft! There are a couple of things that you need to get the basics of WordPress running on Azure. Once you have done these basics, there are a few additional “tweaks” you can make to your WordPress installation that will take advantage of other Azure Native services (Next blog – so stay tuned!).
Step 1: Create your Azure Subscription.
You will need an Azure Subscription. I’m not going to cover off on how to create one of these (and there are a ton of resources out there that can assist you there, checkout Creating a free Azure subscription). But assuming that you can get one of these created, we can continue with the interesting bits.
Step 2: Create yourself a Resource Group.
I would suggest starting off with a new Azure Resource Group, as you may end up creating and deleting this installation a few times (as you are experimenting), and this will help protect your other assets.
Step 3: Create a WordPress instance from Azure Marketplace.
Add a new Resource, and search the Azure Marketplace for “WordPress”. When you do, you will find many variants. I have tried most of them, and all have their nuances. But, my preferred is the “WordPress” instance, from WordPress, for Web + Mobile. My reason for this is, this instance will deploy into an Azure App Service for a Web Site. That means no infrastructure to manage! Additionally, this will allow you to auto-scale and auto-heal the installation as you grow into your WordPress site. Select the “WordPress” instance, and lets configure it.
Step 4: Configure the WordPress instance.
This is pretty basic, but there are a few important pieces to note. First, pick an app name wisely. This URL will end up going all the way into WordPress, and unless you are extremely familiar with altering the URLs inside of WordPress via MySql, you will have to live with this (for now – a future blog post, I’ll cover how to alter this for custom Domains and “migrations” later).
Next, the subscription you deploy this into will direct what options you have for sizing and database providers. For this demo, i’m using a MSDN subscription.
The Resource Group should be “use-existing”, and choose the one that you setup in Step 2.
The Database provider is the first hard choice you have to make. As of this blog post, there are three options:
Azure Database for MySql (Preview): Azure Database for MySql is in preview and is very new. This is an Azure PaaS solution for hosting and managing a MySql database, much like a Azure SQL database. I’m running this one as it is Free and this is a demo.
MySql in App: MySql in App is a database provider where the database will be deployed in the same App Service as your website code. For many PHP developers, this is the way you are used to deploying MySql. But I would recommend against this option as it will drive the sizing of your App Service much higher than necessary, and end up costing you more in the long run. Additionally, there are some known limitations with this and some Plugins. Just stay away!
ClearDB: This is likely the best option for a true production site (as of the time of this blog post). You have the options to pick the size and performance characteristics of the database, and it is very reasonably priced. But, I would only do this for a permanent installation once you are sure you know what you are doing.
For the database, select a good name for your server. This will do a quick check to make sure that your preferred name isn’t already taken. Then, add your admin username and password (and save them!!!). Leave version 5.7 as is. Choose the pricing tier that makes sense for you (as you can see I’m choosing Basic and it has been just fine for me). Finally, pick your database name.
Next, you need to create an App Service plan. There is a ton of documentation out there on considerations for choosing an App Service plan (resources of the instance, size of the disk available on the web server, number of deployment slots, etc). I won’t go into too much detail on this topic (I’ll review PaaS sizing in another blog post). However, I would suggest choosing a wise size that will allow you to develop without crushing your Azure spend. You won’t need much “disk” (I will cover off on that in a few). So, I usually choose S1.
Finally, Application Insights. I highly recommend enabling Application Insights. This will allow Azure’s AI to monitor your website, and provide you with very valuable tips when things go wrong, and help monitor the health of your site.
Once you have done all of this, sit back and let Azure provision everything for you.
Step 5: Setup WordPress!
Once you are complete, you will see the following deployed into your Azure Resource Group:
An Application Insights Resource
An App Service Plan
An App Service (this is your WordPress site!)
An Azure Database for MySQL server
Click on the Name of your App Service, and this will bring you to the overview tab of your website. Note the URL – this is your URL! If you click it, it will open a new tab with your website, and you will be greeted with the standard WordPress installation instructions.
That’s it! You have just deployed WordPress on Azure! In the next blog, I’ll cover off on some tips and tricks that you should do to customize your WordPress on Azure installation to take advantage of the Cloud!