Using GCP free tier VM for uptime and health checks

Uptime Kuma

I host a bunch of services on a server in my house, which I call Jupiter (Why "Jupiter"?). I also have cron jobs on the server which run important things like backups of my documents and photos/videos. I need to know (immediately) if:

Running health checks or down-detectors on Jupiter would not be wise as they might not notify me if the whole server was to go down. So I need a 3rd party, outside of my home network, to keep an eye on everything. The watcher would be very compute un-intensive, only hosting a couple of small docker images which don't generally do much, and so I went on the hunt for the cheapest, tiniest VMs/VPSs I could find:

These costs are all rough estimates, and don't take into account things like paying for reserved capacity up-front, additional costs for public IPs & egress traffic costs. But they give a good indicator that at the very least, it would be a cost of around £3pm.

But then I remembered that some of the bigger cloud providers offer "always free" tiers. And they have compute resources as part of that offering:

I attempted to use Azure's offering at first (as I already use Azure to host my backups, DNS, website etc.) and the terraform for this attempt can be found here. The service did boot up, but I ran into a number of issues with web sockets and what I believe to be CPU resource constraints on the host which meant that even this simple app took ages to load. Of the other cloud providers, GCP looked the best to me, especially because of the mention in their docs of a free external IP. So I believe I can host everything I need to in GCP, absolutely free.

Terraform

As with my other cloud usage, everything is controlled by Terraform, making reproducing the build simple. I won't detail the steps for getting setup with GCP and Terraform cloud, as that is detailed elsewhere (e.g. here).

Once we have setup the authorisation and provider in Terraform, we need to define our compute instance. I decided to name the VM instance "pluto" due to its tiny size:

resource "google_compute_instance" "pluto" {
	name = "pluto"
	machine_type = "e2-micro"
	can_ip_forward = "true"
	allow_stopping_for_update = "true"

	boot_disk {
		initialize_params {
			type = "pd-standard"
			image = data.google_compute_image.cos.self_link
		}
	}

	# This allows for an external IP address
	network_interface {
		network = "default"
		access_config {
		}
	}

	scheduling {
		automatic_restart = true
	}
}

# https://cloud.google.com/compute/docs/images/os-details
data "google_compute_image" "cos" {
	project = "cos-cloud"
	family = "cos-97-lts"
}

I've elected to use GCP's Container-Optimized OS (COS) which (amongst other things) comes with docker already installed.

As the boot disk only takes up 10GB, and GCP offers 30GB per month for free, I also create a 20GB attached disk to store the Docker volumes:

resource "google_compute_instance" "pluto" {
	...
	lifecycle {
		ignore_changes = [attached_disk]
	}
}

resource "google_compute_disk" "default" {
	name = "disk-app-server"
	type = "pd-standard"
	zone = "${var.gcp_region}-b"
	size = 20
}

resource "google_compute_attached_disk" "default" {
	disk = google_compute_disk.default.id
	instance = google_compute_instance.pluto.id
}

Finally, there need to be some firewall settings to allow HTTP(S) traffic through to the instance:

resource "google_compute_instance" "pluto" {
	...
	tags = ["ssh", "http-server", "https-server"]
	...
}

resource "google_compute_firewall" "http-server" {
	name = "default-allow-http"
	network = "default"
	allow {
		protocol = "tcp"
		ports = ["80"]
	}
	source_ranges = ["0.0.0.0/0"]
	target_tags = ["http-server"]
}

resource "google_compute_firewall" "https-server" {
	name = "default-allow-https"
	network = "default"
	allow {
		protocol = "tcp"
		ports = ["443"]
	}
	source_ranges = ["0.0.0.0/0"]
	target_tags = ["https-server"]
}

This Terraform gets us our very own (free!) e2-micro instance with attached disk. But we don't yet have any apps running on it.

Docker (compose)

I was going to go down the route of using cloud-init to get the e2-micro up and running with my docker containers, but it turns out someone has already wrapped up all of that into a handy Terraform module called container-server. It also handily includes Traefik with Let's Encrypt certificate generation. Everything I need!

First I wrote my docker-compose to include the 2 services I wanted to host: Uptime Kuma and Healthchecks:

version: "3"

services:
	uptime-kuma:
		image: louislam/uptime-kuma
		container_name: uptime-kuma
		restart: unless-stopped
		volumes:
			- ${DOCKER_APP_DATA}/uptime-kuma:/app/data
		labels:
			- traefik.enable=true
			- traefik.http.routers.uptime.rule=Host(`uptime.${INET_DOMAIN}`)
			- traefik.http.routers.uptime.entrypoints=websecure
			- traefik.http.routers.uptime.tls=true
			- traefik.http.routers.uptime.tls.certresolver=letsencrypt
			- traefik.http.services.uptime.loadBalancer.server.port=3001

	healthchecks:
		image: linuxserver/healthchecks
		container_name: healthchecks
		environment:
			- TZ=Europe/London
			- SITE_ROOT=https://healthchecks.${INET_DOMAIN}
			- SITE_NAME=Health Checks
			- SUPERUSER_EMAIL=${ADMIN_EMAIL}
			- SUPERUSER_PASSWORD=${ADMIN_PASSWORD}
			- APPRISE_ENABLED=True
			- PING_BODY_LIMIT=100000
			- DEBUG=False
		volumes:
			- ${DOCKER_APP_DATA}/healthchecks:/config
		restart: unless-stopped
		labels:
			- traefik.enable=true
			- traefik.http.routers.healthchecks.rule=Host(`healthchecks.${INET_DOMAIN}`)
			- traefik.http.routers.healthchecks.entrypoints=websecure
			- traefik.http.routers.healthchecks.tls=true
			- traefik.http.routers.healthchecks.tls.certresolver=letsencrypt

networks:
	default:
		external:
			name: web

And finally, using the container-server module in Terraform:

module "container-server" {
	source = "christippett/container-server/cloudinit"
	version = "~> 1.2"
	domain = "pluto.${var.root_domain}"
	email = var.email_address
	
	files = [
		{
			filename = "docker-compose.yaml"
			content = filebase64("${path.module}/../pluto/docker-compose.yaml")
		}
	]

	env = {
		TRAEFIK_API_DASHBOARD = false
		DOCKER_APP_DATA = "/run/app"
		ADMIN_EMAIL = var.email_address
		ADMIN_PASSWORD = var.admin_password
		INET_DOMAIN = "pluto.${var.root_domain}"
	}

	# extra cloud-init config provided to setup + format persistent disk
	cloudinit_part = [{
		content_type = "text/cloud-config"
		content = local.cloudinit_disk
	}]
}

# prepare persistent disk
locals {
	cloudinit_disk = <<EOT
#cloud-config
bootcmd:
- fsck.ext4 -tvy /dev/sdb || mkfs.ext4 /dev/sdb
- mkdir -p /run/app
- mount -o defaults -t ext4 /dev/sdb /run/app
EOT
}

All of this code can be found in my GitHub repo:

Configuration

Uptime Kuma

I now host 2 instances of Uptime Kuma:

As they are watching each other, I will now get a notification if one of the severs/services goes down.

Healthchecks

My cron jobs running on Jupiter now all ping the Healthchecks service running on Pluto. You can see an example of this here. Healthchecks acts in a dead-man-switch way and will notify me if anything doesn't report in correctly.