Importing a Hetzner VM into a new Terraform template

I’m creating a new VM on Hetzner that I want to manage with Terraform, but this is the first time I’ve used the Hetzner Provider. Rather than stumble through the required options for a new VM, I used the -generate-config-out option with terraform plan to generate the Terraform config for me based on the currrent config.

Here’s my starting point for my main.tf:

terraform {
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.45"
    }
  }
}


# Set the variable value in *.tfvars file
# or using the -var="hcloud_token=..." CLI option
variable "hcloud_token" {
  sensitive = true
}

# Configure the Hetzner Cloud Provider
provider "hcloud" {
  token = var.hcloud_token
}

import {
  id = "name-of-my-hertzner-vm"
  to = hcloud_server.name-of-my-new-terraform-resource
}

On running:

terraform plan -generate-config-out=generated.tf

I now have the equivalent Terraform config for my VM, in generated.tf, and now I can include this in my main.tf and manage it incrementally via Terraform from this point onwards.

ssh into Hetzner VMs with an ssh key

During VM creation, assuming you added an ssh public key value when prompted:

Add an entry like the following to your ~/.ssh/config:

Host ip-of-your-new-vm
PreferredAuthentications publickey
IdentityFile ~/.ssh/name-of-your-private-key

ssh into your VM with:

ssh root@ip-of-your-new-vm

Mac OS X and MacOS versions

As someone who tinkers with older Macs, I often forget which versions of Mac OS X are earlier or later just based on name, so for future reference here’s a quick list (summarized from wikipedia):

10.0Cheetah
10.1Puma
10.2Jaguar
10.3Panther
10.4Tiger
10.5Leopard
10.6Snow Leopard
10.7Lion
10.8Mountain Lion
10.9Mavericks
10.10Yosemite
10.11El Capitan – most recent version that can be installed on my 2008 Mac Pro 3,1 without using DosDude’s Patcher or OpenCore Legacy Patcher etc
10.12Sierra
10.13High Sierra
10.14Mojave
10.15Catalina
11Big Sur
12Monterey
13Ventura
14Sonoma
15Sequoia

GitLab CI – allowing later stages to run if manual job in previous stage is not run

By default, later stages will not run if a previous stage in your GitLab pipeline fails. If you have a manual job in a previous stage, not running that job will also block later stages from running automatically.

To allow a later stage to run, mark any optional/manual jobs with ‘allow_failure: true’

For example:

stages:
- build
- setup
- deploy

build:
stage: build
script:
- doTaskA

optional-setup:
stage: setup
script:
- doOptionalSetup
allow_failure: true
when: manual

deploy:
stage: deploy
script:
- doTaskC
when: manual