So here’s my first post joining in with an IndieWeb Carnival; Take Two.

Regrets?

Right off the bat I’ll say yes, there are plenty of things I’d have liked a second take at.

I don’t see this as bad, to me this is growth. Looking back on something and seeing how you could have done it better shows wisdom and maturity.

It’d be easy to get stuck here though, wallowing in sadness and longing for what you could have had, so you have to accept it as take one and move on, which is the theme I’ll be sticking with for this post.

Take Two with Tech

I have a friend who wants to get into tech. They’ve tried before, and it didn’t stick, so this is their take two, and I want to let them know I’m proud of them for coming back.

It isn’t easy changing careers, or even considering it, when you have bills to pay and a lifestyle to maintain, but with tech it’s possible.

I’d even say a second take in tech is encouraged. Let’s look at Apple for a second. They didn’t invent the MP3 player, but they had a very popular second take on it.

First impressions matter and all that, but I think what counts in tech is the second take, and then the third, and all the improvements that reveal themselves with each iteration. My dad would probably include a reference here to WD-40 and the 39 complete and utter failures that came before it.

Personal Takes

You’re reading this on take seven two of my blog, something that could have been running for 10 years if I had stuck at it when I started it.

I’m no better with microblogging , which constantly feels like take two for me. My “how I got my website online” series stalled after the first post and needs redoing.

This week I am finishing off some work I started last week. It was only meant to take a few days, but I didn’t know what I was doing, so I had to make something just to find out what it was I was meant to be making in the first place.

All this whilst taking a second break from work. I tried it last year, went back to my job and then proceeded to burn myself out all over again.

So here I am, a year later, Taking a Break From Work and Switching Things Up: Take Two.

Kaizen (改善)

So it’s on to the next iteration.

And then the next.

As long as I’m continuously learning, always aiming to do better, that’s ok with me.

Cloud

The biggest problem with my homelab was that I kept breaking it.

I couldn’t get used to using mealie as a meal planner because I would go to use it and it didn’t work. Or it did, but I couldn’t connect to it properly. Or something else went wrong.

So for my first “release” I aimed for a “cloud”. Some people call it “HomeProd”.

I used things I was used to, and a few things I wasn’t, to make a simple, stable platform on which I could host my actual homelab.

Here’s what’s in it:

NAS

I have a machine dedicated to running TrueNAS Scale .

I bought the hype that I needed ECC RAM so that my data would be safe and so I also needed a server-grade processor, which meant a server-grade motherboard, and all the other bits to go with it.

At the time Scale had built-in Kubernetes so I used TrueCharts to set up some apps. And then they stopped working. And then there were all the updates with breaking changes. And then I got fed up.

This was meant to be a machine that did storage and I didn’t want to mess with it.

The TrueNAS devs thought the same thing and took out Kubernetes and replaced it with Docker, so I updated to follow and now I only run two storage apps on it.

Usage

• file storage over NFS to Linux and Mac and SMB for Windows
• object storage via MinIO installed as a Docker container
• backups for virtual machines via Proxmox Backup Server

and nothing else.

I just want it to do network attached storage, and I don’t want to mess with it.

Storage

• 2 NVME for 4TB of fast storage
• 1 SSD for 500GB internal storage
• 4 HDD RAIDZ2 for 10TB of slow storage

NUC

After getting burned trying to do server things on my NAS I looked for a replacement and found the Turing Pi , and then in true Kickstarter fashion it got delayed, and then delayed again.

I impatiently bought an Intel NUC.

I could have installed Linux on it and used it as a server but I wanted to use Terraform for Infrastructure as Code, so instead I installed Proxmox VE and used Terraform to create the virtual machines and LXC containers I needed with code.

This meant I could get some practise in using Ansible to configure things and try out K3s to run Kubernetes.

Usage

• compute for running services and apps
• experience using Proxmox
• practise using IaC with Terraform and Ansible
• a place to try out Kubernetes stuff
• a better GPU than the NAS for Jellyfin to use for transcoding

Services

• Pi-hole for blocking adverts as well as DNS and DHCP for my network
• Wireguard for a VPN so I can connect from out the house
• MySQL and Postgres databases for “cloud” things to use
• Caddy as a reverse proxy to provide access to my “cloud” apps and services
• Gitea for storing my git repositories
• Jellyfin to watch my own media content

Apps

• Mealie for recipe management and meal planning
• FreshRSS for my RSS clients to sync from

DeskPi

The last part of my “cloud” is the Raspberry Pi 4 I have on my desk.

(I named it before I heard about the company with the same name)

I had future plans for it, since it’s sat on my desk, so I installed the desktop version of Ubuntu and hooked it up to my second screen.

Then I installed Uptime Kuma on it to monitor all my services and apps.

Apparently I cheaped out when I bought it and got the 2GB version, so it’s really really slow and struggles with showing the dashboard.

I’ve been looking for a good excuse to buy a Raspberry Pi 5 but technically this works, so for now it can stay.

Lab

Now that the stable self-hosted part is out of the way I’m going to leave it alone and use something else for the new ideas.

My Turing Pi 2.5 has finally arrived, along with its case, 3 x RK1 compute modules and 3 x 1 TB NVME drives. I’m planning on using it as a cluster to run Kubernetes and potentially host my own website, but we’ll see about that.

Right now it’s on the bench in the lab.

Using both of them together, with a dynamic inventory to link them, has been technically possible for years but never obvious enough for me to work out.

Until I found the Terraform provider.

Ansible provider for Terraform

By using the Ansible provider you can teach Terraform what an Ansible inventory entry would look like next to the rest of its code.

You start by defining the provider:

terraform {
  required_providers {
    ansible = {
      source  = "ansible/ansible"
      version = "1.3.0"
    }
  }
}

and then you can define the Ansible inventory entry right next to the resource:

resource "proxmox_vm_qemu" "gitea" {
  cores = 1
	...
}

resource "ansible_host" "gitea" {
  name   = proxmox_vm_qemu.gitea.ssh_host
  groups = ["gitea"]
  variables = {
    ansible_user = "ansible"
  }
}

which means you don’t need to hardcode IP addresses anywhere.

You would need to terraform apply this plan so that Terraform adds these resources to the state file so that Ansible can use them.

Terraform plugin for Ansible

On the Ansible side you use a plugin to tell it how to use Terraform as its inventory.

Add the following to your requirements.yaml file:

collections:
  - name: cloud.terraform
    version: 1.1.0

and then install the collection using ansible-galaxy collection install -r requirements.yaml,

then create an inventory.yaml with the following content:

plugin: cloud.terraform.terraform_provider
# project_path: ../terraform # if your Terraform code is in a different directory
# state_file: mycustomstate.tfstate # if you wanted to define which state file

and set it as the default inventory in ansible.cfg:

[defaults]
inventory = inventory.yaml

You can confirm the plugin works by doing:

ansible-inventory --graph

which should return something like the following:

@all:
  |--@ungrouped:
  |--@gitea:
  |  |--192.168.1.211

🎉

What’s good about this is now you can be hands-off with IP addresses.

Terraform can request a new machine, wait for it to receive an IP address and then make it available for Ansible to use, without you needing to do anything.

Remote state

The Ansible plugin will default to using whichever backend you use for the Terraform state file, whether that’s local or in an S3-compatible location.

This means Ansible is always running against the current infrastructure, which helps when colleagues and automations are updating things a hundred thousand times a day.

In Conclusion

Using Terraform and Ansible together can cover all aspects of Infrastructure as Code.

The Ansible provider lets you keep all your resource code together in Terraform and then makes it available to Ansible, which uses a plugin to let it use the state file as its inventory.

What’s a homelab?

A homelab is a personal setup of computer stuff that some of us spend way too much time and money on.

Why would I want one?

Here’s a few reasons:

Learning

The biggest reason I wanted a homelab was for learning. I can get hands-on experience with tech I wouldn’t normally use, and as a DevOps Engineer that often ends up being useful at work.

Applications

There are loads of open source apps you can run for free at home.

You can block adverts , run your own Netflix and plenty more .

Services

You could backup your devices and centralise storage with a NAS, then setup a VPN and connect to it from anywhere.

How do I get one?

The biggest thing I want you to take away from this is that you already have one.

the homelab was inside you all along

Pretend for a moment you’re a mad scientist, hacking away at some computery stuff. There are several blinking lights and a faint computery hum fills the air.

What kind of computery stuff did you imagine?

Did it involve loads of blinky lights? You might be interested in networking. I bought a Ubiquiti switch and it’s way blinkier than my old one. It’s also 10 times faster.

Did you see yourself coding? Maybe you could setup your own git server, add on CI/CD and get your apps hosted on your own network. That’s what I’m doing.

Or maybe you want to try out AI on your own hardware?

Whatever it is, you can probably get started right now with the things that you already have. You don’t need to go and buy anything just yet. Start acting like a mad scientist doing computery stuff and eventually you’ll become one.

When I wanted to learn about Docker images I used my own laptop. Then when I was given a Raspberry Pi I tested out running Docker images on that and so my homelab doubled in size.

I didn’t realise it was called a homelab at the time. I was just doing computery stuff.

My Homelab v0

Macbook Pro (2012)

Raspberry Pi 1

Notebook

Pen for writing it all down, otherwise it’s not science.

There were also a few real technical difficulties starting a blog, which were more frustrating because usually I was the one who had caused them, but they were fixed pretty quickly.

No, the biggest problem came instead from me, not getting past the awkward part and making it a regular habit.

I made a slight effort earlier this year publishing a “plan” on Micro.blog but apparently it wasn’t the right time and I didn’t follow it up.

I was already aware of it, and making an effort to fix it, but I was burnt out.

What I didn’t write in my “plan” was that I would be taking some time off work for a while to recover. It’s not like I was stuck in bed, unable to move, but I had lost interest in coding and computers, which isn’t great when that’s what you do for money.

So I handed in my notice and took a break.

Two months later and I’m definitely feeling better.

The fact you are reading this at all is a testament to my newly rediscovered ability to sit down at a computer and not hate it.

I’ve also had the time to work on my homelab, on which I’ve made more progress in the last two weeks than I have in the last two years.

So maybe now is a good time to start blogging.