This is my third blog post about PagerDuty, and the second about using the Terraform provider for PagerDuty. This time I’ll be focusing on business services.

So far I’ve not a chance to make use of business services, but I have spent quite sometime investigating and creating custom tooling using the APIs following the release in early 2020 (which was before I started on my Terraform journey). I can see how business services would be very useful when widely adopted and combined with status pages, which don’t have APIs yet 😢.

Following on from Managing PagerDuty Services With Terraform, another rather nice PagerDuty feature is Change Events. This was release at last years PagerDuty Summit. Which I started making use of these a few months ago, as they add some additional context around possible changes that were deployed that could be relevant for incidents on the service.

Using them is in GitHub is really simple, first you just need to add the integration to the service. Being on building on the Terraform in the previous post, it’s just adding another data source and resource to your Terraform:

For the last couple of years, I had been the primary maintainer for some tooling which makes heavy use of the PagerDuty REST API. Given my increasing use of Terraform plus now PagerDuty has a free account level. I thought I could get myself a PD account for receiving alerts from any monitoring for my blog that I may do and more importantly also complete a little brain bump of some PagerDuty + Terraform thoughts that are currently rattling around before start focusing on different things for my new job next week.

It’s been about 5 months since I moved this blog over to a static site build with Hugo and in this time I’ve never really gotten round to updating Hugo following new releases. So the solution that jumped out recently was to automate upgrades via GitHub actions.

Finding out the current release is very easy as Hugo is hosted on GitHub, plus they publish releases. This means it’s possible to get the tag for the latest version with Javascript as follows:

Last weekend I was doing some improvements on my blog setup, part of this was looking into how you can take CloudFormation Outputs from a serverless CF stack and use the outputs in Terraform when setting up a lambda_function_association for CloudFront instead of them being hardcoded.

This would then allow me to create a GitHub Action workflow which deploys these Lambda functions and automatically have the latest versions auto applied next time the Terraform runs to update the AWS infrastructure for CloudFront.

After a rather long editing effort and also needing to clean up Flickr (to get into the new free tier limits), last month I completed the migration of content from Wordpress (minus the odd or deleted Flickr photo post’s) to my now not so new Hugo static site.

While part of this was scripted, by writing out the markdown files for each post from the XML export via this not so pretty, but functional script:

This is my new static blog that’s built with Hugo (using the Ananke theme) and hosted in AWS, using Cloudfront with a private S3 bucket as the origin.

Following the ideals of being Cloudnative, all the infrastructure is built using Terraform and deployed via GitHub actions.

terraform {
  required_version = "~> 0.13.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
    }
  }

So far I’m finding Hugo is really nice to use, huge plus being able to write blog posts in Markdown. For various reasons: