How to Over-Engineer a Blog

By George Gonzalez

- 5 minutes read - 924 words

Like many of my colleagues in the Mac Admin field, I had been wanting to start a blog for a while. True, there are many, many Apple related blogs out there, so why one more?

At the core, I love technology, so I was partly motivated to share the unique tidbits that I ran across in my day-to-day. But another part was about the how, about the technology involved. I’m always looking to step out of my comfort zone and try something new. So in this post I wanted to share the components and my pipeline for this blog and hopefully motivate some of you to do the same.

Sure you can pay for a service that includes CMS and hosting, nothing wrong with that. But I wanted to over-engineer this :) and learn something along the way.

Recipe:

  • Hugo for site creation
  • AWS for Hosting
  • AWS Amplify
  • Route 53 for DNS (since I was already in the AWS ecosystem)
  • Google Analytics for telemetry
  • Disqus for comments
  • GitHub for code repo
  • VMware ESXi hosting build VM
  • Docker Hub
  • Docker running on VM for dev build
  • Kubernetes Cluster for dev testing
  • NGINX for local dev testing
  • Jenkins for CI\CD
  • Progress Kemp Load balancer for overkill

Building

I won’t go into a detailed how-to for each of the pieces above since the documentation wikis, man pages and readme files for each technology used are sufficient for learning and setting them up. Not to mention that this would be a really long post. Also, YMMV and of course, there is some (a lot) of trial and error along the way.

The process usually starts in an Ubuntu VM on my ESXi home lab server that serves as a build machine. This VM has a git repo with the contents of the macoasadmin.org site. With the Hugo binary I’m able to create new posts and also run the Hugo server to view the content rendered live.

The VM is accessed via SSH, which allows me to work on the site from my iPad or any other device. My editor of choice? vi on linux and for Hugo markdown files MacDown on macOS or Obsidian on iPadOS. But honestly, I do most of the writing on vi while SSH’d to the build VM.

During the post editing process I commit this code to GitHub, where I can then access it from any of my devices to continue the editing process while mobile. This also allows me to quickly return to a previous state if I change my mind.

Once the post is created, proofread, checked and re-checked then a single script builds and publishes the site on a docker server running on another VM in ESXi. That docker container is running NGINX and accessing a local folder for the web content.

If that build succeeds, then it moves on, and like the title of the post says, this is way over-engineered! A Jenkins server then pulls down the development branch from GitHub, it also downloads the latest version of Hugo, creates a build environment, builds the static site and then creates a docker image containing the static site and NGINX. This build process is similar to what AWS Amplify does, minus the docker container of course. The created image is then automatically pushed to Docker Hub.

But why stop there! The Docker server pulls down the latest image and spins up a container to verify it is working.

That should be enough right? Well not really, then comes the Kubernetes cluster. This is running on physical Dell mini PCs, a master and 3 nodes. And did I mention there is a load balancer in the mix? A deployment sets up the site with replicas, networking etc. for access from inside the network.

As the most interesting man in the world said: “I don’t always test my code, but when I do, I do it in Production.”

Test in Production

Deploying

Once the site is up and tested then comes the easy part. A single merge to the main branch and push to GitHub triggers the AWS Amplify job to build and deploy the site to the internet.

Lessons

Along the way, a lot of coffee was consumed and definitely I learned a lot.

Picking a domain name is hard! - Something short, easy to remember, easy to type, and just when you think you found it, it’s already taken, sometimes by a squatter.

What about the pictures! - Especially talking about Apple, it’s hard to not use copyrighted material, just because an image is out there doesn’t make it free. Sites like Pixabay offer good content.

What do we talk about? - A lot of what we do at work is proprietary, it is important to make sure you don’t overshare. Finding a balance is important.

How much time will this take? - As much as you want to spend on it. Building the site and the ecosystem to support it is one thing. Creating content is another, and in my case, I decided to manually translate the content, so that doubles that time.

I think I hate YAML - Sometimes.

Final words

If you work in IT, I highly recommend you at least try a similar project. If you are reading this site you may be in the mac admin field. Don’t limit yourself to just Mac, broaden your technology horizons as much as possible. The cross-pollination is worth it, it will greatly improve your skills. See it as an investment in yourself, and have some fun along the way.

–GG