Moving Forward with Hugo
Introduction
A couple weeks ago, I posted my first blog post which went over some of the options I was considering using for my blog. In that post it was somewhat obvious the direction I was leaning, but I still wasn’t 100% sure.
Goals
Since then, I have been playing around with a couple of the options, and have decided to go ahead and deploy my site using Hugo. I won’t go into all the reasons I chose this route, but a primary driver was thinking about the infrastructure requirements to make it a “simple” way to blog. Hugo itself is “simple”, however deploying it with some of my goals makes it less so.
DigitalOcean
I have decided that I want to host this via DigitalOcean, because it’s where I do most of my “experimentation” work. I do have services with both AWS(REF4) and GCP(REF5), however those are primarily for clients - I’d like to keep my personal work isolated, at least for now. Plus, DigitalOcean allows me to refer others and potentially reduce my own hosting costs. If you use my referral link, you will recieve a $100 credit to use within 60 days, and I will recieve a $25 credit after you spend $25 - win win!
Private Git Repo
Hugo manages its contents using Git, meaning that at some point, I will need to open a repository for the site. Now I know that I can use github, or gitlab to create a private repo, I think I am leaning towards self-hosting my Git repo. I have thought about doing this with a simple [Git Server]#(REF9), though I might want to use something more full-featured, like Gitea, or perhaps even Gitlab CE. To start, I will be using a local-only Git repo, and using SCP to copy the generated files up to my web server. This can be easily transitioned to using a remote Git server once I get around to building that.
Build Server
Once I have a Git server up and running, the next step is to automate deployments to my web server. I have decided to use Jenkins for this, however other options may be worth looking into. I know that Jenkins gets a lot of criticism for being an “old” tool, or being complex, however I don’t feel that these assessments are fair, or complete. Yes, it is old - but old does not mean bad. I’ve yet to see a convincing argument for why Jenkins would be a bad choice. This is a topic I will probably visit in the future, if I get time to test some alternatives.
Web Server
Next, it’s time to pick a web server. Since we are only hosting static files, the web server we use will not have a huge impact. Although I have more experience with Apache Web Server, I have decided to use NGINX. This will at least provide me the opportunity to learn a bit more about NGINX, though we won’t be doing much with it, at least to start.
High Availability
I have a goal to make this site “highly available”. While I recognize that this is completely overkill for a personal blog, I think it will good practice - plus, it potentially gives me more to blog about. Because the site will be comprised entirely of static content, high availability will be a breeze. I don’t have any databases to worry about, and won’t even need to worry about FS replication, since I can deploy to each destination server separately. To achieve this, I intend to use a pair of HAProxy hosts, and a pair of NGINX hosts. If I get really ambitious, I may even set up geographic redundancy in the future, using DNS as a method to switch between the “active” geographic site.
DNS / Registrar
Speaking of DNS, I will be using CloudFlare as my nameserver, and NameCheap as my registrar. Although CloudFlare offers caching services, I will not be relying on any of that - the only role CloudFlare will play - at least to start - will be DNS.
TLS Termination
Finally, the site will of course be HTTPS/TLS encrypted, as all sites should be.[1] To achieve this, I will be using LetsEncrypt to provide the certificate. My goal at the start is to support HTTP/2, and to achieve an A+ rating on Qualys SSL Labs SSL Server Test. I will also work on getting a decent score on securityheaders.io, but that is less important - at least to start.
Next Steps
With all of that covered, it’s time for me to get to work. I will post this in its plaintext format, with my next blog post being hopefully the first I publish using Hugo! See you on the other side!
References
1. ^ Why HTTPS for Everything?. CIO.gov. Retrieved 09 January, 2021.