Update: After about a year of use, as of the end of 2016, I’ve given up on AWS and moved my blog to wordpress.com. Reason? First. This is not an attempt to sell you wordpress. Use whatever blog platform you like. 2nd. (And now let’s move on.) While trying to host my (wordpress software) blog on AWS I was consistantly getting an error notification that my blog was “down”. This happened at least once a week. The only way to deal with the problem was to reboot my “instance”. According to the web, this is not an uncommon problem with self-hosted AWS blogs. The cause of this problem I’ve never figured out. WordPress claims that it’s a problem with AWS. AWS claims it’s a problem with wordpress. At this point I don’t care anymore. What is clear is that there is a level of complication at AWS that can only be dealt with by becoming a paying customer. I’m sure that more tech savvy blog users can deal with AWS (without paying), but I’m obviously not one of them. Although I can install WordPress on a server and get it running, I don’t feel like fiddling with anything any deeper than that. Also. If you ask me what the problem really is, here’s my best-guess: once an AWS self-hosted “free-tier” blog gets any traffic AWS breaks the connection between wordpress and mySQL. Unless fixed within the code of your wordpress install and/or a few adjustments are made to your mySQL database, the problem creeps up everytime your blog even gets a few hits. I concluded that if I had to start paying for this level of service at AWS that maybe I was in a bit over my head. In other words, if I had to pay for this, there was nothing at AWS that motivated me to do so. In the mean-time, I’ve tried hosting my blog at Bluehost but concluded that, although they had good service, I just didn’t feel like the whole back-end krapp of keeping my blog up. I’m now paying wordpress.com to host my blog. We’ll see how it goes. And now on to the original post…
If at first you don’t succeed… rest before trying but most definitely try again. As mentioned here, I recently migrated worstwriter.com from 1und1 hosting to Amazon Web Services (AWS). Why? Well, nothing against 1und1 but the service I migrated to makes 1und1 look a bit old and dated–and AWS is much cheaper. In fact, unless I get a lot of traffic to my site, AWS is free. Plus, I am moving to India soon and I thought it better if I oriented my web content around a service that is a bit more international. But before I get into complaining about 1un1, here’s what I did to make this move. Good luck.
Step 1
- Backup blog.
- Put backup file in a safe place.
- Install and use the WordPress (WP) plugin All-in-One WP Migration to export blog to download folder. Make sure it’s there and make sure you can find it.
Step 2
- Sign up with AWS.
- Go to EC2 and launch, setup Instance.
- Pick your server. I picked Basic Amazon Linux. Go through the setup process following all the default settings. There are a couple areas where you have to name things and provide input regarding web hosting but all-in-all getting the Instance running is easy.
- Here’s a great webpage that provides pics on how Instance setup is done.
- Btw, “Instance” is just another word for Server.
Step 3
- Migrate your domain names using AWS Route53. I was not only moving my website to a new host but I completely forgot about my domain names that were still at 1und1 when I started this.
- With that in mind, this could just as well be step 2. This did cause me some problems later during my first install attempt. (That’s right. I went through all of this more than once.)
Step 4
- Establish SSH connection using the Mac’s Terminal App.
- Note: during Instance setup you are given a security “key” in the form of a file that you must download to your computer. Save this “key” on your computer and always know how to access it. Do not lose it or throw it away.
- Use Terminal and the Linux chmod command to change the access rights of the key .pem file accordingly. Actually I’m not sure if this is required. I don’t think I did it on the second install. Oh well.
Step 5
- Using your SSH terminal connection to your AWS Instace, install LAMP. Linux Apache MySQL PHP. This is where things get fun with the CLI. If you follow AWS documentation, though, it’s a no brainer. Seriously. I did this twice and it’s the easiest part of the whole thing.
- Here’s a AWS LAMP install tutorial.
- When this is done your webserver is running–but you’re far from home.
Step 6
- Install WP.
- This is where things get fun. And allow me to add this slight poke at WP.
- Considering the requirements of launching a AWS Instance and then installing all the proper software for a webserver (LAMP), you would think that installing 7mb of files from WP would be a piece of cake. Well, it ain’t. This is the hardest part.
- AWS tutorial installing WordPress.
Take a break. Don’t drink alcohol. Espresso. Espresso. Espresso with sugar.
Here a bit about how Step 6 is the hardest. As noted (with pic) in this post, the biggest problem with WP install is being given the choice of where to install its files. This is totally confusing. I guess the choice is about whether or not you are gonna install more than one blog or if you’re a stickler for sub-directories. I still don’t know how sub-directories determine more than one blog but since I only want to get one running, the issue is mute. Anywho. After initially screwing this up and then thinking about it, this is what I’ve concluded about how to deal with this simple but devastating issue.
The Linux folder that Apache (the webserver) accesses when delivering http requests cannot change once it’s set–unless you want to configure Apache, too. No thanks! Therefore, you must install WordPress within the proper Apache directory. Hence, the AWS tutorial has you download WP with the wget command to your Instance root directory–where there is no Apache. Later on you have to move the WP folder to the proper Apache directory. Keep in mind, the way Apache is setup is that it will only deliver http requests from the Linux folder “/var/www/html”. Aghast!
Why AWS has you go through this directory mess during a simple single blog install makes no sense and is obviously confusing. If you make a wrong choice here, you basically kill the entire install when you setup WP. Also. When installing WP to a sub-directory (i.e. the Apache /html/directory) you are required to add that location to a WP-Config.php file. Why would a simple install of such a simple thing require the complexity of editing a .php file? And so. On my first install I got the directory right–probably because I didn’t think about it. But I screwed things up when I went through the WordPress setup. This also the area where I realised my domain names were still at 1und1.de. In the end, I did not want to access my site through some lengthy, computer generated URL. When I went to change that to worstwriter.com in WP>general>settings, I broke the whole thing because Apache couldn’t know where to find the html files. Aghast, aghast!
When I first made this mistake I thought I could fix it from within the WP>general>settings. Wrong! Then I tried to follow some other documentation after googling and requesting help from AWS support. That lead to actually going so far as to use the Linux nano editor to edit .php files. Again. It didt work. What a mess. Oh yeah. Aghast!
The only solution I could find to the problem was to terminate the whole Instance and start over. Which I did. What a waste, eh.
I repeated everything on a new Instance. I was very careful when choosing where to install WordPress in Step 6.
Step 7
- Once WordPress is running, use All-in-One WP Migration plugin to upload/import the file you downloaded in Step 1.
- Re-initiate your connection to WordPress.
- Log-in
- Bang.
- Done.
- Happy worstwriting, baby.
For those interested, here’s a pretty decent bunch of videos that I came across from two guys who mastered the struggle a bit better than me.
Rant on.
-Tommi
worstwriter 