Just like Pinocchio wanted to be a real boy, I want to be a real programmer!
Spot instances can make running a website really, really cheap. In my experience, though, it hasn’t been as cheap as I had hoped. So I re-created this site using a t2.micro EC2 instance which is supposed to run at less than $0.01 an hour.
Of course, as the site runs, it needs a static IPv4 address which adds an additional half a cent cost. This isn’t super expensive, mind you, but it adds up.
Okay, I haven’t posted for a few months YEARS now – sorry!
I had been running this site on a (very) basic EC2 spot instance for a while, then I found out last month that the bid price was too low and it wouldn’t start. For some reason, AWS doesn’t let you just change the bid price – you have to create an entirely new spot instance. This isn’t that hard but if you haven’t done it for 4+ years, it’s a bit of a challenge.
Luckily I managed to get it all up and running, but it took looking at an AWS guide to get it to work.
Okay, so after checking the site, I noticed it was down AGAIN. Cause? That pesky DNS issue. For some odd reason, this website’s IP address keeps changing even though I didn’t restart it.
Solution? Add an Elastic IP address. This will keep DNS consistent, and so far, it keeps working. I won’t use an elastic load balancer as I was trained for because it incurs too much of a monthly cost. But I may do that just for testing if it becomes necessary.
I thought I would look at my website since I view it so seldom, and lo and behold, IT’S DOWN!!!
First I tried restarting the AWS EC2 instance – NO SITE!
Next, I tried to SSH in, but the IP address has changed since i rebooted.
Got the new IP, started SSH, got in. httpd and mysqld aren’t running (Dufuq?)
Tried restarting them but couldn’t!!! Have I been hacked?
After I calmed down, I saw that I needed to sudo.
Once I did that, I was able to restart httpd and mysqld
But now I can’t see the site in my browser. Clearly this is a Route 53 / DNS issue.
Updated DNS entry with new, correct IP address. Now comes the waiting game, as pinging the domain name reveals the old IP address:
(My OS is in Japanese. Trust me, the pings were timing out).
After a few minutes, the IP address is correct and the site comes up:
Phew! It’s nice that the right IP address shows up, but I can’t test because it’s not responding to pings:
I decided to add a security policy so I can ping just for testing.
Instead of adding it to the main policy, I’m going to do the “Photoshop layer” thing and create a new policy that I can add/remove at will and apply it to the same EC2 instance.
I created a Echo reply rule and allowed it from anywhere (this is for testing).
Okay, it’s set for both incoming and outgoing. Great! Let’s test it:
Hmmm. Failure. Oh, snap! I need to set the instance itself to allow pings. Duh!
I had to look it up, but I found the iptables command that would work best. I normally wouldn’t set this to respond to pings from everywhere but this is for testing.
Okay, the security policy is in place, the DNS entry is correct and the iptables/local firewall is set. Let’s test again:
Success!! I can rest easy now. And since the ping policy is separate from the main security policy, I can turn it off/on at will, or delete it outright.
I love AWS!!
Okay, now that I’ve made a major change to this website, I’m back on and will keep this site up! I set this site up as part of my Amazon Web Services (AWS) training. A site like this uses a database to store its information, and mine was using Amazon’s wonderful RDS (relational database service) for my database. RDS has a number of great features; the database is always running, it’s scalable and Amazon does all of the maintenance.
The catch? Cost. Even with the cheapest plan I was paying about $25 a month for the database alone. That’s just too much for a low volume website!
So I came up with a plan: run the database on the same server. It’s not as cool or as flashy, but it will save money which is my ultimate goal. Plus I’ll have to migrate from RDS to a .sql file, how hard could it be, right?
Looking up entries on the web, it turns out there are lots of tutorials on how to do just the opposite: migrate SQL to RDS. This required a lot of digging around. I was hoping for a nice, step-by-step, oral tradition via screenshot guide that would hold my hand through the process. Fortunately, I found something on docs.aws.amazon.com that really fit the bill. Turns out you can run mysqldump on your RDS instance and it will do the job just as if you’re running it on a normal MySQL instance. Viva la cloud-ia!
(Just do you don’t have to rip your hair out like Bender, here is the resource I found.)
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
So I ran mysqldump using my RDS instance ID, database root password and it worked like a charm!