Bye Azure! Hello AWS

I’ve decided to move from Azure to AWS EC2 for hosting. To be honest the service at Microsoft Azure has been lackluster at best. No support and crappy performance. There are times when the machine is just simply unresponsive. AWS T2.Small instance size is pretty snappy and around the same money. In addition, Amazon offers a nice RDS service which includes backup and management. Yes, this increases my hosting cost, but it comes with better performance. My CDN is hosted on Cloudfront anyway, so hosting the server in EC2 makes sense.

Amazon RDS is not easy to setup. The first time I configured it a couple of weeks ago I had to invoke Amazon support to figure out which security setting was messed up. I wound up leveraging that today to finish the migration.

Web hosting maintenance – retiring Azure CDN and re-configuring AWS CDN

While this blog does not receive tons of traffic, I still run it so that it could handle a ton of traffic. This means leveraging CDN or Content Delivery Network technology. There are a number of providers who offer this, but Windows Azure and Amazon S3/Cloudfront are two of the best and cheapest. There are higher performance options like Mirror Image and Akamai, as well as poor-man solutions like GoDaddy or Rackspace server hosting. Akamai is pretty pricey. Mirror Image used to be about $100/mo. I can’t see why anyone would use GoDaddy when Amazon and Microsoft practically give away high quality bandwidth for CDN hosting and have a huge footprint.

The motivation for me was that the author of the Azure CDN plugin had stopped developing it a couple of years ago. As WordPress moved forward I realized I was having some image issues and finding that my images were going to multiple places. I also had installed a couple of plugins for Amazon that did the heavy lifting of synching files. This was a great opportunity to untangle the issue and clean up my hosting costs.

I used Cloudberry’s free tool for Azure Blob Explorer and S3 Explorer to access and see what was in the buckets. They are two separate tools, but they are quick and free. I then copied the content down to my local drive so I could consolidate it. Then using WinSCP I copied the content back up to my home directory on the server. From there I copied it recursively over to the virtual host directory in var/www. Then I reset the ownership and permsisions. This gave me a clean and complete set of files. From here I was able to remove the conflicting and outdated plugins. I then used Blue Velvet’s URL renamer plugin to point everything at my main URL. This allows wp-super cache to work most effectively.

I then deleted the Azure Blob after verifying it was no longer being used. This will save me a $1/mo or something silly like that. Azure CDN had comparable performance to S3. I considered putting the origin-pull CDN on Azure, but it’s a pain to configure. The actual setup is fast. Amazon gives you lots of control, Azure just sets up a basic no-frills no-control CDN. This is a recurring theme with Azure and AWS. And of course Microsoft has their head in the sand when it comes to configuring DNS on their hosting objects. In the name of security they insist that you make some funky DNS entries to verify ownership. You have to do this for every single DNS entry you want to map. What a PITA! Both CDN’s do similar things… Amazon’s just requires more up-front planning and provisions in 15 minutes. Microsoft gives you fewer choices up-front, but takes an hour to provision. Hmmmm.

Next I turned my attention Amazon. I deleted my existing Cloudfront distribution. Cloudfront is Amazon’s CDN Product. Pricing is cheap and performance is stunning. One of it’s few limitations is only allowing a URL in one distribution at a time. So this means deleting the outgoing one and creating a new one. The old one was tied to an S3 bucket. Amazon S3 is the Simple Storage Service which is Amazon’s drive in the cloud and one of the older cloud services. Once the distribution was down I was able to create a new one with a setting called origin-pull. This means that when the file is requested Amazon will fetch it from the server if they don’t already have it. If they do have it they will check to see if it’s been updated before serving it. This eliminates the need to push files to S3 and reduces S3 storage costs to a minimum.

Once I confirmed that it was setup properly I was able to retire the S3 bucket. This will help get me to a mean lean hosting state that minimizes costs.

bitly = brokely

Well, all was working until I posted… then the bitly plugin crashed the site. No amount of re-configuration would make it happy. Fortunately, deleting it was easy and fixed the problem. I noticed there was not a new version, so that suggests it wasn’t working well.

migration drama o rama

It’s been a while since I posted. I’ve been very busy remodeling my house. I do have lots of projects on my to-do list, so I’ll start posting again. I had to do some housekeeping before I started posting. First things first, my OS was failing to update. After digging into it, I realized the issue was that I needed to upgrade as I was running 13.04. A few hours later I realized I couldn’t upgrade and would need to reinstall. Thanks Ubuntu!

Fortunately, I host in Azure, so rebuilding is not a nightmare. First try was a colossal failure. The WordPress migration documentation sucks. I’ll cover that later. Second try was better, but still a failure. Third time was the charm, but I got stuck in the bear pit of security I had setup. I locked down my wp-admin directory with .htaccess. This creates a separate layer of security to protect the administrative functions. No site is totally secure, but you can usually make yours more of a hassle to break into…… which makes someone else more attractive.

It took me the better part of a day to migrate my site and update my files. That is awful and I can only imagine the headache a mere mortal would experience. I’m an IT professional with 20 years of experience and deep migration expertise. So if I am struggling, it’s going to a nightmare for most quasi-admins. Now, freely I’m not a Level 10 magician in Linux…. but I’m dangerous enough that the gremlins run at the mention of my name. lol.

One of the tools to success is keeping notes in a text file on how you setup a system. It aids the memory 12 months later when you have to re-do it. Always update these “recipes” and include references to where you found things so you can review again if needed.

Without much ado, here is my high-level recipe to migrate WordPress:
– Backup your current database and /var/www directory. Make a tar file of your /var/www
– If your host supports it, make a image backup of your server. This makes it easy to go back to that system state.
– Install new server, run updates.
– configure your virtual server and make sure it works.
– Install Apache and make sure it’s working. Basically follow the WordPress setup docs here, but don’t actually install wordpress or download it.
– Make sure PHP runs, install Mysql, lock it down, create a blank database with the same name and user/password as your old server.

– extract your tarball in /var and it will recreate your permissions and folder structure complete with usernames. You’re half way there.
– Login to mysql and import your database from your backup file.
– Your blog will run at this point. Check it.
– Now make sure you have backend access. If you have .htpassword enabled you may need to reset that up or disable the .htaccess file for wp-admin.

That’s it in a nutshell. The part about backing up is not in the damned WordPress CodEx which was written by a politician to apply to everything and be specific about nothing!

WP crashed

WordPress crashed on me this evening…. things happen.  It actually became very very slow and unresponsive, at which point I restarted the server.   The menu structure seems messed up.  Content is still there so I’m not ready to do a site restore quite yet.  I will see if I can get it working.  Thank you in advance your patience in the meantime.