DEV Community

lykins
lykins

Posted on

Nomad Image Factory - Intro

Howdy.

Just a quick introduction in preparation for my series to expand on my HashiConf talk.

Unfortunately, I had to cut out portions of building a full end to end Nomad Image Factory from my talk, but I am going to use my blog to fill in what was missed.

My series of posts are going to be as follows:

Setting up Nomad - Development Server and Cluster

Preparing for my talk, I did not get the chance to play with Consul, so I am going to give it a shot, as well.

My presentation covers running Nomad with the -dev flag, as well as, bootstrapping a cluster.

For my blog, I am going to use my own homelab to show how lightweight Nomad is.

Homelab

Homelab Features:

  • 1 - Cheap 'dumb' Switch
  • 3 - cheap minicomputers
  • 1 - 13-year-old Lenovo laptop.

I think my wife is ready for me to move it somewhere else.

Containerizing GitHub Runner

To be transparent, most of the heavy lifting was based on two blog posts. I updated mine to be ephemeral, so after each successful or failed action, the container will exit out, forcing Nomad to recreate. Also added in a few additional packages which are more custom for my Packer templates.

How to containerize a GitHub Actions self-hosted runner

Deploying Self-Hosted GitHub Actions Runners with Docker

In addition to using ephemeral runners, I used the Docker plugin with Packer to build it. This gave me a chance to finally play with Docker + Packer to build an image. Pretty simple process overall.

Multipurpose Packer Templates

Took a different approach with Packer than I had done in the past.

variable "platform" {
  type        = string
  description = "The list of sources to build."
  default     = env("PLATFORM")
}

locals {
  build_source = lookup(local.sources, var.platform, ["source.amazon-ebs.docker"])
  sources = {
    aws     = ["source.amazon-ebs.docker"]
    azure   = ["source.azure-arm.docker"]
    vsphere = ["source.vsphere-clone.docker"]
  }
}

build {
  sources = local.build_source
Enter fullscreen mode Exit fullscreen mode

This is driven by the choices made by inputs when manually kicking off the pipeline. It also allows scaling Packer templates to be much simpler when adding additional sources into the same template. I do not know why I never tried this approach in the past, but it worked out really well for the demo.

Just a FYI, one of the better repositories for vSphere builds are managed by a few folks from VMware (Broadcom). Really appreciate the work they put in it, a bit than what the average user would need, but it really took a Packer template

vmware-samples/packer-examples-for-vsphere

GitHub Actions Pipeline

Nothing too major here, in my experience most of my pipeline I try to keep pretty straightforward for simplicity.

The GitHub Actions inputs were inspired by this repo from a HashiCorp team.

tfo-apj-demos/packer-images

Running Jobs on Nomad

I'm going to go over a few examples of how you can run a job. I will deploy my GitHub Actions Runner to a cluster with the following methods:

  • UI
  • CLI
  • Terraform
  • Nomad Pack

In my talk I believe I covered the UI, CLI and Nomad Pack methods. I might have cut out the CLI for time, but I cannot remember.

Scaling Nomad

I could be wrong, but I think the most common method for scaling with Nomad would be with the Nomad Autoscaler running as a job on the cluster:

hashicorp/nomad-autoscaler

Nevertheless, there are a few options to scale Nomad:

Nomad Autoscaler Overview

Also worth looking at the scaling block since placement has different context on how it scales:

Scaling Block


Welp, that is it for now. It is late, and I am going to call it a night. Hope someone finds this useful, but my wife also thinks I need to improve my writing and communication - which is the main reason I decided to blog.

Take care,
lykins

Top comments (0)