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.