July 15, 2017hugo aws static-sites web
I was looking at my blog for the first time in a while thinking, “Man, this site may as well be static for all I update it.” And so I made the site static! But fancy though.
I used a static site generator called Hugo, written in Go, and said farewall to WordPress (and GoDaddy, who were charging an exorbitant sum to host my site and doing a terrible job at it). Because nothing should ever be that easy, I also set the site up to be hosted on Amazon S3 and CloudFront. Finally, I set up a GitLab runner and CI pipeline to automatically preview and deploy when I push to the repository this site is hosted on.
Here’s how I did it.
Building a website with Hugo
Hugo, as will surprise no one at all, is basically tailor made to build infrequently-updated blogs. I take all my notes at work in markdown so I figured I may as well write my blog in it too. There are also a number of really sweet themes out there for it that are well-suited to blogging.
After skimming the documentation, installing Hugo on my Windows laptop for use in Cygwin I set up my first project.
hugo new site dcowsill.com
I found a theme that I liked and cloned it into the project directory. The author suggests cloning the project as a submodule, but since I wanted to make some tweaks and changes to the project and not have to manage a separate forked form of it just for a blog I plan on neglecting anyway I just cloned it regular-wise.
cd themes git clone https://github.com/calintat/minimal
Then I can update my
config.toml file to use the new theme, make any changes I needed to make and I’m off to the races.
I didn’t do anything fancy to convert my existing WordPress blog posts to markdown for use in the new site because really I just wanted to keep the one. I suppose if you wanted to you could write something to scrape the old site or even go through a SQL data dump and then go from that to markdown in some weird way but that sounds like a lot of work.
Once everything was more or less where I wanted it it was time to think about dumping it into S3.
Dumping it into S3
Amazons AWS management console already a helpful wizard for setting up a static site so I used that. It was easy enough to
hugo my project, zip up the public folder and then upload it to Amazon. The static website wizard creates an S3 bucket for you, a CloudFront distribution and awaits a Route 53 connection later down the road too.
I created a new public zone in Route 53 and set the Amazon nameservers on the domain.
Not surprisingly, there was a problem. It turns out that the static website wizard doesn’t do a great job of serving up HTML files in subdirectories of your S3 bucket.
I found this after a bit of searching and pointed CloudFront at the S3 bucket’s endpoint URL rather than the S3 bucket’s URL and after a bit of thinking the site was fully functional.
Setting up GitLab CI to deploy to S3
I found this great guide from GitLab that walks you through setting up a regular static site to deploy to S3. Since I was using Hugo instead of writing HTML files by hand like a pleb I had to make some modifications but other than that my approach was the same.
I had an EC2 instance kicking around, so I installed the GitLab runner on that. Something about trusting a GitLab shared runner with S3 API keys rubs me the wrong way.
After getting the runner registered I created an Amazon IAM user for the purpose. God help anyone who has to regularly work with the fine grained policy permissions on AWS though. There are 54 individual permissions you can set for S3 alone. The only pre-packaged policies available to you for S3 are read only or god-mode, which is unhelpful. Fast forward 30 minutes of me squinting at the screen at camelcase permissions and that’s done.
Once I had the pipeline running on the correct runner and
awscli installed on it everything just worked. Which surprised me.
I really like the idea of static sites rather than full on WordPresses if you’re just building a simple ‘Hey hire me and read all about the awesome stuff I do’ blog. Amazon’s hosting is orders of magnitude cheaper, the site itself is much more secure and I got the opportunity to work with some technology I don’t normally, so wins all around. Obviously this project doesn’t get inspire its for ease of management, but with the CI aspect taking care of the uploading for me it is rather friendly to use. For me at least.
This process probably seems a bit daunting to the average user. However, for small web presences that don’t get updates a lot it can be a good alternative to WordPress (and the expensive garbage-tier hosting, shameless web developers and security risks that go with it). There are other static site generators out there and hosting that is more suited to static sites like Git(Lab|Hub) Pages, but whatever. I had fun.