Background Info

So, a couple years back I decided to leverage a CloudFormation template to scaffold a WordPress blog. Do note that this link is close to what I used, but it isn’t exactly what I used. It spun up a load balancer, ec2s, did the networking. It did most of the work to get the infra up and running. Generally speaking I’ve been pretty happy with the results, but I’ve become a Terraform fan since I started this project. I’ll go over a couple of headaches I had in maintaining the setup as of recently.

My Complaints

1. The CloudFormations UI

I make all my CloudFormations config changes via the AWS CloudFormation UI. I probably should have version controlled this stuff once that feature came out in 2023. It doesn’t seem to have existed around 2022 when I first got this stuff standing. Some common changes I make include things like wordpress packages, php versions, etc. We’d want these changes reflected on every new instance that gets created by the load balancer so they need to be written down in the CloudFormations template. The EC2s are ephemeral.

The AWS CloudFormations UI gives you a tiny text editing screen to update a huge json file. The UI isn’t super intuitive and there aren’t any clear ways to revert to a previous version of your config. Again, had I introduced git into the mix I probably would’ve been a lot happier.

My general recommendation here is steer clear from the UI. Go down the version controlled route if you have the bandwidth. Worse case scenario is that you make a change, break your infra, and can’t roll back if you’re managing the template via the UI.

2. Php Versions on My EC2

I spent a hilarious amount of time trying to install a newer version of PHP on my ec2. In my first attempt I thought I’d just hack off php version so that I’d pull the latest version during each deploy. Again, I was doing this in CloudFormation and didn’t know what format yum would want the php version. I deploy the template and 5 minutes later…

Boom. My websites down after the change. So I ssh into the box and start combing through the logs. It turns out the newest version of PHP my ec2 will install is 5.~ if I dropped the PHP version number. The latest general PHP version is 8.0 as of 2024/01. My theme at least required 7.something. So when I tried visiting my website, I’d get a “your site’s theme can’t be found.” The theme installation was failing due to version conflicts.

Note, your cloud init logs can be found at /var/log/cloud-init-output.log.

Change directory to the log folder mentioned above and run:

cat cloud-init-output.log

and you should see a ton of output on your screen. Looking for “error” or “failed” in the text might speed your search up. If you can’t find a cause in there, check out some of your other logs.

While still in the EC2, I ran:

yum search php

This gave me a bunch of stuff I could potentially install, but still the most recent version of PHP that was available was 7.3. So I go ahead and re-pin my version in the AWS CloudFormation UI.

I wait like 5 minutes for the changes to get deployed.

And then recheck my instance. My website was still down. Back I go into the EC2 to try to find out why.

I found that the newer version of my theme required a newer version of PHP. So again, I had to pin my theme to an earlier version.

Conclusion

Eh. CloudFormation was great for getting up and running quickly but changes to the template get deployed slowly, rollbacks are slow, the UI is questionable and doesn’t give me enough space to make edits.

I’ve found myself wanting to upgrade the PHP version, wordpress version, etc and struggle to add the additional info into the json.

While it was super helpful to get up and running, I’ve probably spent several days just dealing with CloudFormation itself.

Alternatives

I use Terraform very often for my day job. I’ll probably just go down the Terraform route instead of the CloudFormation route.